ClickFix Grows a Back Office: API-Served Payloads and a New AMSI Bypass

Key points

• Researchers scraped roughly 3,000 live ClickFix payloads and found API-driven backends serving each visitor a uniquely disguised copy of the same malware.
• The infrastructure rotates command strings, staging URLs, and loader stubs per visitor, making hash-based and URL blocklists nearly useless.
• A newly documented delivery technique structures payloads so the malicious content bypasses AMSI, the Windows Antimalware Scan Interface that script hosts use to scan buffers before execution.
• Lumma, DanaBot, and NetSupport RAT have all been observed riding this pipeline in recent months.

What changed in ClickFix infrastructure?

The social-engineering trick, bogus CAPTCHA and "verify you're human" pages that instruct victims to paste a command into the Windows Run dialog or a terminal, is now fed by API-driven backends. Each visitor gets the same final-stage malware wrapped in a different disguise: two victims hitting the same lure page receive two different command strings, two different staging URLs, and often two different loader stubs. That looks less like a phishing kit and more like a small SaaS. We covered the pattern's earlier shape in our 18 June report on a seven-wave ClickFix campaign that chained legitimate infrastructure to push malicious PowerShell to developers.

Static IOCs age out in hours against this class of infrastructure. If your detection strategy leans on adding IOCs when they appear in a feed, you are permanently one rotation behind.

How does the AMSI bypass work?

Rather than patching AMSI in memory, the noisy classic that EDR vendors have been catching for years, the new variant structures the payload so the malicious portion never lands in a scannable script buffer. The initial mshta or powershell invocation pulls staged content that is decoded and executed in a form AMSI does not see. The technique is deliberate: whoever built this understood exactly which part of the execution chain Windows scans.

Should you worry about detection gaps?

Behavioral detection on the Run-dialog vector is more durable than signature work here. explorer.exe spawning powershell.exe or mshta.exe with a long encoded argument is a strong signal, and cheap to alert on. Microsoft's guidance on constrained language mode and script block logging (documented here) is the right baseline.

Disabling the Win+R Run dialog via Group Policy is heavy-handed but effective for high-risk user populations. Stripping clipboard-paste capability from the Run dialog, which several enterprise hardening guides now recommend, is a lighter alternative.

One caveat on the numbers: 3,000 payloads is a crawl-window snapshot. Polymorphic backends generate unique payloads on demand, so true campaign volume is almost certainly larger.

The engineering effort to build API-served, per-visitor payloads with AMSI-aware staging has already been paid. Expect the pattern to migrate into adjacent social-engineering lures. That's the thing to watch, not the specific malware families riding it today.

Common questions

What is AMSI and why does bypassing it matter?

AMSI, the Windows Antimalware Scan Interface, is the layer that PowerShell and other script hosts call before executing a buffer, giving security tools a chance to inspect script content in memory. Bypassing it means malware can execute without that inspection ever occurring, regardless of what antivirus is installed.

What malware families use this delivery method?

Researchers observed Lumma, DanaBot, and NetSupport RAT delivered through this pipeline in recent months, though the backend is family-agnostic by design.

Does disabling the Run dialog fully stop ClickFix attacks?

No. ClickFix lures have been adapted to browser consoles and terminal windows as well, as our 16 June report on BabaDeda, Lorem Ipsum, and Potemkin loaders documented. Disabling Win+R removes one vector, not the technique.