ClickFix Delivery Is an On-Demand API Now, and It Guts Every Content-Based Detection You Have
Per The Hacker News writeup of Bert-Jan Pals’ OrangeCon research, someone pulled roughly 3,000 live ClickFix payloads and found the delivery isn’t a fixed command at all — it’s a metered backend API. Ask one of these servers for 100 payloads and you get 100 different builds, each wrapped in a rotating stack of encoding, compression, and encryption layers, matched to the visitor’s OS and served in 25 languages. The operational consequence is the whole point of this post: any ClickFix detection that keys on the literal contents of the pasted command, the encoded blob inside it, or a specific string IOC starts losing coverage within days, because the thing you’re matching is regenerated per request. That doesn’t make content detection worthless — it still earns its keep for clustering, reputation, and retrospective hunting — but as a live, exact-match block it’s renting, not owning. The detection that lasts is the one that never has to read the payload at all.
TL;DR
- ClickFix payload delivery is now a server-side, on-demand API — access-token-gated, per-request randomized, OS-matched, 25 languages — so string IOCs against the pasted one-liner or the encoded blob lose coverage within days of writing them (they keep value for retrospective hunting, not live blocking).
- The newer “Downloads-folder orchestrator” variant keeps the clipboard command minimal and pulls a benign-looking file down first, specifically to keep the payload out of anything that scans the pasted command inline — which undercuts controls that rely on inline PowerShell visibility (AMSI scanning, and script block logging / 4104 when the real code runs from a downloaded file), demoting them to corroboration rather than a gate.
- The durable detection is content-blind by construction: a shell whose parent is
explorer.exe,WindowsTerminal.exe, orwt.exe, carrying a hidden-window flag plus a download and/or execution primitive, with an outbound connection within seconds of spawn.- The input surface churns too — Win+R (RunMRU), Win+X-to-Terminal, and FileFix are three different boxes the victim gets told to paste into — which is exactly why an input-specific rule like the RunMRU registry watch is a cheap backstop, not coverage.
- Tune the ancestry rule in week one by carving out build/CI hosts and service-account SIDs by OU or tag, requiring at least two suspicious tokens instead of a lone
-enc, and gating on near-immediate egress — that combination is what makes it deployable, though the volume before and after depends heavily on your environment.
This matters because ClickFix is not a niche you can defer. Microsoft’s threat-intel team reported the technique hitting thousands of enterprise and end-user devices every day, with Defender Experts watching thousands of machines per month actually execute the pasted command — EDR already running on the box. The Hacker News writeup puts ClickFix at 47% of the initial-access cases Defender Experts tracked, notes ESET clocked a 517% jump from late 2024 into the first half of 2025, and cites a single ClearFake wave touching as many as 147,521 systems since late August 2025. This is a mainline initial-access vector, and the move from hand-rolled scripts to on-demand payload servers is what keeps the crews a step ahead of content-based detection at almost no cost to themselves.
The delivery is a service now
The part worth internalizing from Pals’ teardown is that the command isn’t authored per campaign — it’s dispensed per victim. The backend behaves like any other SaaS endpoint: it accepts a request, checks an access token, logs the caller, and returns a fresh, randomized command. That’s why 100 requests come back as 100 different builds — worth being precise about what varies: it’s the command construction and the obfuscation wrapping that change per request, not proof of 100 independently compiled malware families underneath. The obfuscation isn’t a single scheme you can unwrap once and signature; it’s an alternating combination of encoding, compression, and encryption layers — Base64, Deflate, AES, TripleDES, Rijndael — combined and reordered by the delivery infrastructure rather than fixed per campaign. The same platform fingerprints the visitor’s operating system and hands back a matching command — macOS variants running right alongside the Windows ones — and localizes the lure across 25 languages.
Read that as an industry, not a toolkit. When delivery is a metered service, the marginal cost of making your specific IOC stale is one API call. There is no static artifact on the delivery side for you to anchor to, by design.
Why this kills content-based detection
Walk through the reflexes most teams reach for first and watch each one expire.
String IOCs against the pasted command. The command text is different on every pull, so a rule matching the literal one-liner — or the CAPTCHA-flavored *robot*/*captcha* strings that used to ride along in it — catches only the builds that predate your rule. Worse, the giveaway phrases lived on the web page the user already closed; they never had to appear in the pasted command at all.
YARA/regex on the encoded blob. With the encoding scheme itself rotating across five primitives, the byte patterns you’d signature shift build to build. You can win for a week. You cannot win for a quarter.
Hashing the stager. Per-request randomization means the downloaded second stage is effectively unique per victim, so hash-based blocking has nothing stable to key on.
Then there’s the method built specifically to blind the controls that watch the pasted command. In the newer Downloads-folder orchestrator variant, the clipboard command is deliberately minimal and benign-looking: the page quietly drops a file into the Downloads folder, and the pasted line just moves that file, unpacks it, and runs the script inside. AMSI — the interface AV uses to scan script content as it runs — sees only the benign orchestrator line, because the malicious body never appears inline; it arrives separately, from disk. PowerShell’s script block logging (Event ID 4104) is a distinct subsystem — it’s generated by PowerShell’s own logging, not by AMSI — but against this staging trick it has a related blind spot: if the interesting code executes from a downloaded file, or through a non-PowerShell path, 4104 can record the orchestrator while the payload never surfaces as a logged script block. The honest caveat cuts both ways — if that downloaded stage is PowerShell and script block logging is on, 4104 will still capture it, so the gap is real but not absolute. Treat inline-visibility controls (AMSI scanning, script block logging) as corroboration against this variant, not the primary control.
The detection that has nothing to read
If the payload content is regenerated per request, stop trying to read it. The durable signal is the shape of the execution, and it’s content-blind on purpose — command line plus egress, scoped by ancestry.
The binary alone is useless: powershell.exe under explorer.exe is a routine sequence on every workstation, and no EDR blocks it by default because that would break half of IT. You read the arguments and the graph, not the strings.
The stack that holds up regardless of which build the server dispensed:
- A shell process (
powershell.exe,pwsh.exe,cmd.exe) whose parent isexplorer.exe,WindowsTerminal.exe, orwt.exe, and - a command line combining a hidden-window flag (
-w hidden,-windowstyle hidden) with a download primitive (iwr,Invoke-WebRequest,irm,Net.WebClient,curl,Start-BitsTransfer) and/or an execution primitive (iex,Invoke-Expression,-enc/-EncodedCommand,FromBase64String), and - an outbound network connection from that process within a few seconds of spawn.
None of those three conditions inspects the payload’s content — they key on window state, on the presence of a fetch/exec verb, and on graph shape and timing. That’s exactly why they survive a delivery model whose whole job is to make the content different every time.
The tooling largely exists. Splunk shops have most of it in the Fake CAPTCHA Campaigns analytic story, whose clipboard-execution search keys on the hidden-window variants combined with iwr/iex/Net.WebClient — just don’t let the CAPTCHA keywords be a required condition, for the reason above. On Defender, Pals’ own hunting queries give you the process-side follow-through; graft the WindowsTerminal.exe/wt.exe-parent condition onto it so you cover the terminal variants, not just the Explorer-rooted ones. On Elastic the same logic works but the ingest is messier — you reconstruct the tree off process.parent.name and join to network events yourself, and the join window is where your false-positive rate lives or dies.
The input surface churns too — which is why the registry rule isn’t coverage
Content is one moving variable; the input box the victim pastes into is the other. The lure can tell the user to press Win+R and use the Run dialog (which writes the command to the RunMRU registry key — the classic, cleanest artifact), or Win+X then Terminal (which opens wt.exe and writes no registry value), or Ctrl+L to paste into the File Explorer address bar (the FileFix variant, documented by BleepingComputer, which also skips RunMRU). Manuel Arrieta’s breakdown of the Win+X variants is worth reading on the Terminal case specifically: because wt.exe fires without a -p profile argument when launched off the Win+X menu, WindowsTerminal.exe-as-parent is a soft starting fingerprint — but Arrieta flags that operators can prefix wt.exe to fragment the process tree and defeat a naive parent-child match, so treat it as one input among several, not a gate.
The takeaway for the registry rule everyone ships first: the RunMRU watch is cheap and near-zero false positive, and it still catches the Win+R commodity campaigns that haven’t migrated — which is most of the low-effort end of the market. Keep it. There’s a companion SigmaHQ rule for suspicious space characters in the RunMRU path that catches the whitespace-padding trick; keep that too. Just stop treating a quiet RunMRU dashboard as evidence you’re covered — it goes silent the instant a campaign flips its lure to Win+X or FileFix, same payload, same infostealer, no registry write. It’s a backstop for one input method, not the detection.
What the first week of tuning looks like
The RunMRU rules barely need tuning — filter S-1-5-18 (SYSTEM) and you’re basically done. The command-line-plus-ancestry rule is the one that floods if you ship it wide open in a developer-heavy org, and the noise comes from three predictable places, in rough order of volume.
Build and CI agents are the worst — a GitLab runner or Jenkins node executing powershell -NoProfile -EncodedCommand against build scripts all day will hammer any -enc-based rule, and -enc on its own is worthless as a signal because SCCM, GPO client-side extensions, and plenty of legitimate tooling use encoded commands routinely. Second, developer workstations where Invoke-WebRequest/iwr is just how people pull things. Third, IT and helpdesk staff who live in Terminal and paste multi-line snippets, which is precisely the WindowsTerminal.exe → pwsh.exe shape you’re keying on.
First-round fixes, concretely: exclude build-agent host groups and service-account SIDs by OU or host tag, not by a hostname regex you’ll forget to maintain. Require at least two of {hidden-window flag, download primitive, iex/FromBase64String} rather than any single token, which flattens the encoded-command-only false positives. Gate on the near-immediate outbound connection — a legit admin one-liner often doesn’t beacon within seconds of spawn, and a ClickFix stager usually does (a patient operator can sleep, proxy, or stage through a browser download to sidestep exactly this, so weight it, don’t gate hard on it). How much noise you start with and how far tuning drops it depends entirely on your dev population, endpoint count, admin practices, and logging coverage — a 200-seat software shop and a 200-seat accounting firm look nothing alike — so budget for a real tuning cycle before this goes to production rather than a number I could promise you.
Mapping and what actually reduces it
The heaviest control here isn’t technical. ClickFix is user-driven execution, so AT-2 (awareness training) is load-bearing — “no legitimate CAPTCHA or file path ever asks you to open a terminal or paste into Run” is one of the few security-awareness lines that maps to a specific, teachable motor action. On the technical side, CM-7 (least functionality) is where you cut surface: disabling the Run dialog via GPO (NoRun) blunts the Win+R variant, but understand its ceiling — it does nothing against Win+X or FileFix, so don’t let it show green on a control matrix and call the technique covered. WDAC or AppLocker constraining who can run arbitrary interpreted PowerShell is the control that changes the outcome (application control also reaches into CM-5 access-restrictions-for-change and AC-6 least privilege, not just CM-7); in a locked-down tenant where users are already in Constrained Language Mode, most of this problem evaporates. In a flat commercial environment with local admin sprinkled around, it doesn’t.
The rest maps where you’d expect. The command-line-plus-ancestry-plus-egress detection is SI-4 (monitoring). ASR rules blocking obfuscated scripts and script-borne child processes are SI-3 (malicious code protection). Script block logging and process-creation auditing are AU-2/AU-12 — with the caveat above that the Downloads-folder method is built specifically to keep the interesting content out of AMSI’s inline-scanning path, so treat 4104 as corroboration, not a gate. If you want the SC hook, mshta-delivered HTA payloads sit under SC-18 (mobile code), worth a policy line given how often the commodity variants still reach for mshta.exe.
| Control | What it covers here |
|---|---|
| AT-2 | The “no CAPTCHA/file-path opens a terminal” user message |
| CM-7 | Constrain PowerShell via WDAC/AppLocker; NoRun only blunts Win+R |
| SI-4 | Command-line + ancestry + egress detection in the SIEM |
| SI-3 | ASR rules against obfuscated scripts and script child processes |
| AU-2 / AU-12 | Process-creation auditing; 4104 as corroboration (AMSI-starvation limits it) |
| SC-18 | HTA/mshta mobile-code restriction |
The through-line: the attacker made both of their variables cheap to change — the payload content, via an on-demand server, and the input surface, via a rotating set of paste boxes. Every detection you anchor to one specific value of either variable ages out in days to weeks. The constants are the execution shape and the egress timing, and those are what you build on. Keep the registry rules as the cheap backstop they are, put your real engineering into the content-blind ancestry-and-egress signal, tune the CI hosts out of it in week one, and stop trying to out-signature a build server whose entire purpose is to never hand you the same string twice.
Sources
- Researcher Analyzes 3,000 Live ClickFix Payloads, Exposing API-Driven Malware Delivery (The Hacker News)
- Think before you Click(Fix): Analyzing the ClickFix social engineering technique (Microsoft Security Blog)
- Investigating ClickFix incidents (KQL Query)
- Beyond the click: unveiling fake CAPTCHA campaigns (Splunk)
- Hunting ClickFix Win+X variants (Detect FYI)
- FileFix attack weaponizes Windows File Explorer for stealthy PowerShell commands (BleepingComputer)
- Suspicious space characters in RunMRU registry path — ClickFix (Detection.FYI / SigmaHQ)
This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.