ClickFix Grows a Back Office: API-Served Payloads and a New AMSI Bypass
Researchers pulled roughly 3,000 live payloads from ClickFix infrastructure and found a polymorphic delivery pipeline built to defeat Windows script scanning.

ClickFix has stopped being a copy-paste gimmick and started behaving like a service.
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 that hand each visitor a functionally identical payload wrapped in a different disguise. Researchers who scraped roughly 3,000 live payloads across current ClickFix campaigns describe an infrastructure that looks less like a phishing kit and more like a small SaaS.
The operational shift matters. Static IOCs age out in hours. Two victims hitting the same lure page get two different command strings, two different staging URLs, and often two different loader stubs, all resolving to the same final-stage malware family (Lumma, DanaBot, and NetSupport RAT have all been observed riding this pipeline in recent months).
More interesting is the delivery method. The same research surfaced a technique built to slip past AMSI, the Windows Antimalware Scan Interface that PowerShell and other script hosts call into before executing a buffer. 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 at all. The initial mshta, conhost, or powershell invocation pulls staged content that is decoded and executed in a form AMSI does not see.
For defenders, a few things follow.
Block-on-hash and URL blocklists are close to worthless against this class. If your detection strategy still leans on "we'll add the IOC when it shows up in a feed," you are permanently one rotation behind. Behavioral detection on the Run-dialog vector is more durable: explorer.exe spawning powershell.exe, mshta.exe, or cmd.exe with a long encoded argument is a strong signal, and it is cheap to alert on. Microsoft's own guidance on constrained language mode and script block logging (documented here) remains the right baseline.
Disabling the Win+R Run dialog via Group Policy is heavy-handed but effective for high-risk user populations. So is stripping clipboard-paste capability from the Run dialog, which several enterprise hardening guides now recommend.
A caveat on the numbers. The 3,000-payload figure is a snapshot from crawling active infrastructure; the true campaign volume is almost certainly larger, since polymorphic backends generate unique payloads on demand and only samples that were actually served during the crawl window were captured.
Expect this pattern — API-served, per-visitor payloads with AMSI-aware staging — to migrate into adjacent social-engineering lures. The engineering effort to build it has already been paid.



