ClickFix Is Everywhere: Detecting the Fake CAPTCHA-to-Malware Pipeline

ClickFix follows a consistent four-stage flow regardless of the specific campaign. First, a pretext: a fake CAPTCHA or Cloudflare Turnstile challenge, a fake browser update notice, a fake video conferencing app error, or a fake driver or codec fix. The common thread is a plausible reason for the user to take an unusual action to resolve a problem.

Second, a silent clipboard write. JavaScript on the lure page calls the browser's clipboard API to copy an obfuscated command to the user's clipboard without any visible copy action from the user, while on-screen instructions tell the victim to press Windows+R, or open a terminal, and paste. Because the page never serves a downloadable file and never itself navigates to a malicious URL, the parts of your stack built to catch malicious attachments and malicious links, email gateways, web proxies, URL sandboxing, have nothing to inspect. The only artifact that exists at this stage is a string sitting in the clipboard.

Third, manual execution. The victim opens the Run dialog or a shell and pastes. This is the step that makes ClickFix effective against otherwise well-defended endpoints: the resulting process is launched by the logged-in user through a completely legitimate operating system feature, not by an exploit or a macro. EDR tooling that scores risk partly on how a process was spawned sees a normal, user-initiated launch. The Windows Run dialog itself imposes a practical constraint here, accepting a command up to roughly 259 characters, which is one reason attackers lean on short download-and-execute cradles (Invoke-WebRequest, Invoke-RestMethod, Invoke-Expression, typically abbreviated iwr, irm, iex) rather than longer inline payloads.

Fourth, execution through a Living-off-the-Land binary, almost always powershell.exe, sometimes mshta.exe, cmd.exe, wscript.exe, or cscript.exe, frequently with a Base64-encoded argument or string concatenation specifically to defeat naive keyword matching. This is the step MITRE ATT&CK now tracks under T1204.004, User Execution: Malicious Copy and Paste, a sub-technique added specifically because this pattern had become common enough to need its own entry separate from the broader User Execution technique.

The defensive gap this exploits is structural, not a tooling failure: none of the controls built for file-based or link-based delivery apply, because ClickFix delivers neither a file nor a followed link. Two real, documented incidents on this site illustrate how differently the same underlying technique can be packaged: a Chrome extension supply chain campaign that injected ClickFix prompts into every website a victim visited, and the Booking.com Storm-1865 reservation phishing campaign that targeted hotel guests through fraudulent booking confirmations. Both used the identical four-stage mechanism described above with completely different lures and completely different payloads, which is exactly why detecting the mechanism matters more than tracking either campaign's indicators.

None of the detection logic in this guide works without specific logging enabled ahead of time. ClickFix leaves no file on disk to retroactively scan and no network request to a scanned URL, so the detection has to come from process, script, and registry telemetry that is already flowing when the execution happens.

The detection logic below is organized as a sequence: each step adds a signal that narrows false positives without requiring any single overly specific keyword list that a rotating campaign can trivially avoid. The two Sigma rules included are real, currently maintained SigmaHQ community rules, included here with full attribution rather than paraphrased, so you can deploy them directly against the log sources described above.

Validate this detection with a benign simulation, never with a live malicious sample pulled from a sandbox report or a public repository, even in an isolated lab. You do not need a real payload to prove the detection logic works, because the logic keys on the mechanism, clipboard-to-Run-to-LOLBin, not on any specific malicious content.

Build a canary chain on an isolated test VM: write an obviously benign string to the clipboard with a short local script (for example, a PowerShell one-liner that just writes a timestamp to a local log file or opens Notepad, wrapped in the same iwr/irm/iex-shaped syntax and Base64 encoding real ClickFix commands use, but pointed at nothing more than a local, harmless action). Manually open the Run dialog on the test VM and paste it, exactly the way a victim would.

Then verify each layer independently: confirm the RunMRU registry value appears with the expected content, confirm Sysmon Event ID 1 or Security Event ID 4688 logs explorer.exe launching the target LOLBin with the full command line, confirm Event ID 4104 logs the de-obfuscated script block if the test used PowerShell, and confirm your SIEM correlation rule actually fires and routes to the expected queue. Run the same simulation a second time by typing the identical short command manually, character by character, with natural typing pauses, rather than pasting it, to confirm the rule does not fire on ordinary manual Run dialog usage that happens to reference a URL or a LOLBin. A rule that fires on both cases equally is not differentiating the technique, it is just alerting on Run dialog usage broadly, which will not survive contact with a real environment.

For a broader validation exercise, have your red or purple team run this simulation across a sample of representative endpoint builds and user profiles, not just a single clean test image, since Script Block Logging and command-line auditing Group Policy settings can silently fail to apply on endpoints that were provisioned before the policy existed.

This detection logic targets the technique's most common current form. A determined attacker who knows this logic exists has several ways to defeat individual layers of it, and no single control below closes every gap on its own.

Splitting execution across multiple short Run-dialog invocations, each individually below the keyword and pattern thresholds, is the most direct evasion. A first paste might only set an environment variable or write a small file with no network reference and no verification keyword; a second, separate paste retrieves and executes it. Neither individually matches the combined-signal rule in Step 3, and the RunMRU entries for each half look unremarkable in isolation.

Switching to a Living-off-the-Land binary outside your keyword list is a low-effort evasion against any static list. Attackers already rotate away from powershell.exe and cmd.exe toward less commonly monitored binaries, conhost.exe, forfiles.exe, msiexec.exe with uncommon switches, or whatever LOLBin happens to already be installed and trusted in the target environment. Any detection built on an enumerated binary list needs regular review against current LOLBAS research, not a one-time configuration.

Defeating Script Block Logging directly is possible through PowerShell version downgrade attacks, invoking the legacy PowerShell 2.0 engine, where Script Block and Module Logging are unavailable, or through AMSI bypass and .NET reflection techniques that execute code without ever populating a full script block event. Where this succeeds, Event ID 4104 simply never fires, which is why the process-creation and registry layers in this guide are not optional fallbacks, they are load-bearing.

Using a different execution surface entirely defeats the RunMRU-specific layer outright. The FileFix variant pastes into the File Explorer address bar instead of the Run dialog, which does not write to RunMRU at all. Pasting directly into a terminal, or into a different protocol handler's input field, produces no equivalent registry artifact either. This is precisely why Step 3's process-lineage and content-matching logic has to stand on its own without depending on the registry signal being present.

Finally, artificially delaying execution after the clipboard write specifically targets the dwell-time heuristic in Step 5. An attacker aware that near-zero-latency paste-to-execute is a scored signal can instruct the victim to wait, or build the delay into the payload itself, to make the timing look more like deliberate manual typing.

Every layer in this guide trades false positives against false negatives, and the right setting depends on how much legitimate Run-dialog and PowerShell one-liner activity exists in your specific environment, not on a fixed industry number.

Alerting on any single signal, any explorer.exe-to-PowerShell launch, any RunMRU entry containing a URL, any Base64-encoded command line, produces unmanageable volume in most enterprise environments, because helpdesk staff, software deployment tooling, and power users all generate that traffic constantly for entirely legitimate reasons. This is exactly why Steps 2 through 4 require multiple weak signals to co-occur before an alert fires, matching the 'all of selection_*' logic both cited Sigma rules use rather than triggering on any one selection alone. Requiring the combination cuts volume substantially, at the cost of missing an attacker who deliberately keeps each individual signal below the combined threshold, the splitting evasion described above.

The opposite failure mode is over-tuning specifically to reduce noise. Narrowing the verification-keyword list to only the exact words seen in past incidents, or requiring the literal word 'captcha,' creates a detection that ages out quickly as campaigns rotate their lure wording, and it is precisely the kind of narrow, incident-specific tuning that this guide is trying to avoid in favor of detecting the mechanism.

The practical middle path most environments land on: run the multi-signal correlation rules in alert-only mode continuously, route high-confidence matches (process lineage plus content plus registry artifact, all three together) to an immediate, fast-SLA triage queue with authority to isolate the host, and route single-signal or two-of-three matches to a lower-priority hunting queue for periodic analyst review rather than paging on-call for every partial match. Reassess the keyword and LOLBin lists on a fixed schedule against current threat reporting rather than only after your own organization is hit, since the entire premise of detecting the technique instead of the campaign is that the useful signal predates your own incident.