ClickFix Attacks Expand Using Fake CAPTCHAs, Microsoft Scripts, and Trusted Web Services: 11 Crucial Insights for Modern Defenders


What’s New in the Latest ClickFix Wave

If you’ve been tracking ClickFix for the past year, the core idea will feel familiar: attackers don’t “hack” the machine first—they convince a human to run the first command. Microsoft has described ClickFix as a social engineering technique that pushes victims into executing malicious commands themselves, which helps it slip past many automated defenses.

What’s new—and frankly, more worrying—is how neatly the latest campaign stitches together:

  • Fake CAPTCHA pages that look like normal web friction,

  • Trusted Windows components that proxy execution (instead of launching PowerShell directly),

  • In-memory loaders that reduce on-disk artifacts,

  • Trusted third-party web services used as infrastructure “helpers” for configuration and delivery.

This combination makes the attack chain harder to auto-detonate in sandboxes and harder to spot with simple “block PowerShell” thinking.

Why fake CAPTCHAs keep working

Fake CAPTCHA lures are effective because they match what users already expect: “prove you’re human,” “continue,” “verify,” “fix this quick.” People have been trained by real websites to comply with verification steps—so the attacker borrows that trust.

The “copy–paste into Run” trap

ClickFix’s special trick is turning the user into the initial access vector. Instead of relying on an exploit, it relies on a workflow: copy a command, open Windows Run, paste, press Enter. That’s “normal behavior” from the operating system’s point of view—until it isn’t.

The Campaign at a Glance

Researchers have documented a recent chain distributing Amatera, an information stealer, through a ClickFix-style fake CAPTCHA flow. The twist: the initial command doesn’t launch PowerShell outright. It abuses a signed Microsoft App-V script to begin execution through a more trusted path.

Stage 0: The lure page and fake verification

Victims land on a page that looks like a standard verification step. The page instructs them to “verify” by pasting a command into Windows Run—classic ClickFix mechanics.

Stage 1: App-V script as a proxy for PowerShell

Instead of calling powershell.exe directly, the chain leverages SyncAppvPublishingServer.vbs, a signed script associated with Microsoft Application Virtualization (App-V), executed via wscript.exe. The attacker uses it to retrieve and run an in-memory loader from an external server.

This matters because defenders often key off obvious execution paths—PowerShell launched from the Run dialog, suspicious parent/child process relationships, or known “living-off-the-land” patterns. Proxying through a trusted component complicates that.

Stage 2: In-memory loaders and sandbox checks

From there, the loader chain performs checks to avoid analysis environments and continues in stages, with PowerShell scripts functioning as intermediate loaders executed in memory.

Why SyncAppvPublishingServer.vbs Matters

This isn’t “new magic,” but it’s a smart choice for attackers because it blends into legitimate system behavior. MITRE ATT&CK explicitly notes that adversaries may abuse SyncAppvPublishingServer.vbs to bypass PowerShell execution restrictions and proxy execution via a trusted, signed alternative to directly invoking powershell.exe (technique T1216.002).

MITRE ATT&CK framing and what defenders should infer

When MITRE labels something as a technique, it’s a signal that:

  • It’s been observed,

  • It’s repeatable,

  • It maps to a predictable set of telemetry if you’re collecting the right logs.

Translation: if your program doesn’t currently treat wscript + SyncAppvPublishingServer.vbs + suspicious arguments as high-signal, you’re likely missing an important lane.

Enterprise targeting via App-V availability

A particularly sharp detail: App-V is generally present only in Enterprise/Education editions and modern Windows Server environments. That means the chain may fail on Home/Pro systems—and that aligns with a focus on managed enterprise targets.

“Living Off the Land” Meets “Living Off the Web”

The campaign doesn’t just live off Windows tools—it also lives off trusted web services.

Google Calendar (ICS) as a dead-drop resolver

Researchers observed the chain pulling configuration from a public Google Calendar ICS file, effectively using a reputable third-party service as a dead-drop style resolver. This design lets the actor rotate infrastructure quickly without rebuilding earlier stages—raising the cost of takedowns and blocking.

CDNs and steganography in images

Later stages involve retrieving a PNG from external domains and extracting an encrypted/compressed PowerShell payload hidden in the image, which is then decrypted and executed in memory. This dovetails with broader reporting that ClickFix waves have used image-based hiding techniques and fake update experiences to increase success rates.

The Bigger Trend: ClickFix Variants and Builders

ClickFix is no longer a single “trick.” It’s a category of social engineering patterns that keeps mutating.

Microsoft and other researchers have highlighted how ClickFix has become a widespread initial access method, largely because it is built on legitimate user actions and trusted tools—making it look benign to many endpoint defenses until you correlate context.

You’ll see variants and adjacent ecosystems described with names like:

  • “fix the glitch” style lures,

  • fake browser updates,

  • fake missing font or system component prompts,

  • traffic distribution systems (TDS) pushing victims into these flows.

The key point: the attacker doesn’t need a novel exploit if they can scale a convincing workflow.

Why variants scale so fast

Once a template works, it gets reused across:

  • Compromised sites,

  • Malvertising,

  • Phishing,

  • SEO poisoning,

  • Social-media creator targeting.

And because the first step is “you did it yourself,” the chain often starts in a telemetry gray zone.

What this implies for user training

Traditional awareness training (“don’t click links”) isn’t enough. ClickFix thrives on procedural compliance—the user believes they’re completing a legitimate verification flow.

Effective training for this era is specific:

  • “Never paste commands into Run/Terminal from a website.”

  • “CAPTCHA pages should never instruct you to open system dialogs.”

  • “If a page asks for copy/paste steps, stop and report.”

Detection Opportunities Across the Kill Chain

Even sophisticated chains leave footprints. The goal is to pick the footprints that are hard for attackers to avoid without breaking their own chain.

Endpoint telemetry and command-line signals

Hunt for:

  • wscript.exe launching or interacting with SyncAppvPublishingServer.vbs

  • Unusual command-line parameters containing delimiters or injected PowerShell patterns

  • Hidden window PowerShell invocation (even if proxied)

  • Process ancestry: browser → Run dialog behavior → script host activity

MITRE’s technique description is a good starting reference for expected patterns and defensive mapping: 

 https://attack.mitre.org/techniques/T1216/002/

 

Network and DNS patterns

Consider detections for:

  • Unexpected outbound requests to calendar/ICS resources in contexts that don’t match business use

  • Suspicious image (PNG) retrieval patterns followed by script execution bursts

  • Newly registered or low-reputation domains used as staging

Identity signals (token theft and account takeover)

Information stealers are often a bridge to:

  • Session cookie theft,

  • Password theft,

  • MFA fatigue or bypass attempts,

  • Account takeover and lateral movement.

If you see ClickFix-like activity, assume credential exposure is possible and pivot to identity protection quickly.

Hardening Playbook for Enterprises

Here’s the practical part—controls you can apply without turning your environment into a glass museum.

Reduce LOLBin abuse without breaking business

  • Apply application control (e.g., WDAC/AppLocker) where feasible for script hosts and high-risk binaries.

  • Use EDR policies that raise severity when script hosts spawn suspicious child behaviors.

  • Put special watch rules around wscript.exe, cscript.exe, and signed scripts used in proxy execution paths.

Browser and web filtering guardrails

  • Block newly observed lure domains quickly (your web proxy/DNS filtering is still your friend).

  • Use browser isolation for risky browsing contexts (contractors, third-party access, BYOD portals).

  • Consider restricting clipboard/script execution prompts in high-risk user groups.

User workflow “speed bumps”

Because the chain requires manual steps, your best defense is to make the steps socially “weird” and procedurally discouraged:

  • Add a security banner and training snippet specifically about never pasting commands from web pages into system tools.

  • Provide a one-click “Report suspicious CAPTCHA” option in the browser or email client.

  • Make reporting easy and praised—speed matters more than perfect forensics at the first alert.

Incident Response: What to Do if You Suspect ClickFix

When you suspect a ClickFix event, treat it like probable credential compromise plus possible malware execution.

Immediate containment checklist

  1. Isolate the endpoint (network containment if possible).

  2. Reset credentials for the affected identity and review active sessions.

  3. Hunt for similar telemetry across the fleet (same script host patterns, same domains).

  4. Pull EDR triage package (process tree, command lines, network connections, loaded modules).

Forensics priorities

  • Memory artifacts (because much of the chain is in-memory)

  • Evidence of token/cookie access or browser credential store access

  • Persistence mechanisms (even if the stealer itself is “hit and run”)

FAQ

1) Why are fake CAPTCHAs so effective in enterprise environments?

They mimic normal web behavior and rely on conditioned user compliance. The user thinks they’re completing a routine verification step, not executing code.

2) What makes this campaign different from older ClickFix chains?

A key difference is the use of SyncAppvPublishingServer.vbs (App-V) to proxy execution through a trusted Microsoft component instead of launching PowerShell directly.

3) Why is App-V relevant to targeting?

Because App-V is commonly associated with Enterprise/Education Windows editions and server environments, the technique can bias toward managed enterprise systems.

4) How can defenders detect proxy execution through signed scripts?

Focus on parent/child process relationships, command-line arguments, and unusual script host activity—especially wscript.exe with App-V scripts and suspicious injected parameters.

5) Does blocking PowerShell solve this?

Not by itself. Attackers can proxy execution and run PowerShell in memory. You need behavioral detections, script host monitoring, and user workflow controls.

6) What’s the fastest user-facing rule that reduces risk?

“Never paste commands into Windows Run, Terminal, or PowerShell because a website told you to.”

7) Where can I read Microsoft’s own analysis of ClickFix?

Microsoft’s security blog post provides an overview of the ClickFix technique and why the user interaction step helps it evade some conventional defenses: 

https://www.microsoft.com/en-us/security/blog/2025/08/21/think-before-you-clickfix-analyzing-the-clickfix-social-engineering-technique/

Conclusion

The most important takeaway isn’t that any single stage is “novel.” It’s that the chain is engineered to progress only when it unfolds exactly as the attacker expects—human interaction, trusted Windows components, and trusted web services stitched together into an execution path that’s difficult to sandbox and annoying to block outright.

If you want a single practical focus for the next quarter: tighten controls around user-driven command execution, monitor script-host proxy behaviors, and treat “verification” copy-paste instructions as a high-severity social engineering signal.

(And yes—mentioning it once more for SEO consistency:) ClickFix Attacks Expand Using Fake CAPTCHAs, Microsoft Scripts, and Trusted Web Services is a headline that captures where initial access is heading: less exploit-driven, more workflow-driven.