ClickFix / Fake CAPTCHA: How a fake CAPTCHA becomes a malware delivery mechanism
CAPTCHAs are designed to distinguish humans from automated systems. A user types distorted letters or clicks a few crosswalks, and in doing so proves there is a human behind the keyboard rather than a script. The whole idea rests on one assumption: A human, unlike a bot, will pause and think for a moment before acting.
ClickFix takes that assumption and turns it into the attack itself. The fake verification screen does not ask the user to prove they are human by thinking. It asks them to prove it by following an instruction quickly, without questioning it, which is the exact behavior a real CAPTCHA is designed to screen out. The victim is told to open a window, paste something, and press Enter, and none of it calls for any reasoning at all.
That is the core of the attack. There may be no malicious file or exploit involved in the initial hand-off. The attacker delivers instructions instead, and the victim carries out the execution. A test that was built to separate humans from automated scripts has been repurposed to make a human act exactly like one, executing a command without ever questioning it. Security teams track this activity as ClickFix or Fake CAPTCHA, and it is currently one of the fastest-growing initial access techniques in enterprise environments.
How ClickFix turns the user into the execution mechanism
ClickFix, also known as a fake CAPTCHA, is a social engineering technique that convinces a user to manually run an attacker-supplied command on their own machine, using tools that are already installed and trusted on that system. A fake verification page, often styled as a CAPTCHA, a Cloudflare security check, or a stalled Windows update, instructs the victim to open a system dialog, paste a command that has already been copied to their clipboard, and press Enter.
Nothing is downloaded, and nothing is attached to an email or a page. There is no payload for a security tool to catch at the moment of compromise, because the attacker never delivers a file in the first place. They deliver instructions instead, and the victim carries out the execution.
ClickFix and MITRE ATT&CK®: Why T1204.004 exists
MITRE added ClickFix to the ATT&CK framework in March 2025 as technique T1204.004, called Malicious Copy and Paste. The execution step that follows is typically mapped to a separate technique, T1059.001 for PowerShell, or to whichever interpreter the attacker has chosen to abuse. Giving this pattern its own technique ID is not just a formality. It reflects how consistently this exact behavior now appears across unrelated malware families, infostealer operators, ransomware affiliates, and state-linked groups, rather than being tied to any single group's playbook.
Inside the ClickFix attack chain
If you strip away the visual design of any individual ClickFix campaign, the mechanics underneath stay remarkably consistent from one campaign to the next.
The lure. Victims usually reach the fake verification page through malvertising—search results manipulated with SEO poisoning, a compromised legitimate website, or a phishing email that links out to the page.
The clipboard hijack. JavaScript on the page silently writes an attacker-controlled command to the victim's clipboard. The command is typically hidden from the victim, who instead sees instructions telling them what to do next.
The execution hand-off. The page then tells the victim to open a specific system tool, most commonly the Windows Run dialog, paste the copied content, and press Enter. This is the pivotal moment in the entire attack, because execution passes from a webpage, which browsers and web security tools are built to inspect, to the operating system itself, where far fewer controls are watching by default.
The payload stage. The pasted command is usually obfuscated, and it is built to invoke a tool that is already trusted on the system, such as PowerShell or mshta, to quietly fetch and run the next stage of the attack. Because nothing new is written to disk at this point, there is often nothing for a signature-based scanner to flag.
ClickFix attack variants
The lure changes shape across campaigns, but what matters for detection is which tool the user is told to open. That choice determines exactly what shows up in the logs afterward.
ClickFix (Run dialog execution): The victim opens Win+R, pastes the command, and executes it. Depending on the campaign, this can produce a process chain involving Explorer, conhost, PowerShell, curl, or mshta, along with other host telemetry.
FileFix: The user is prompted to open File Explorer, often through a fake Choose File button, and paste the command into the address bar. Depending on the campaign, this can produce a browser process handing off to PowerShell, with the pasted command also recorded in the TypedPaths registry key.
TerminalFix: The user is told to open PowerShell or a terminal directly and paste the command there. Since only one interactive process is typically involved, this tends to leave less telemetry behind.
DownloadFix: This is a proof-of-concept variant demonstrated by researcher Jean-Francois Maes. A download is deliberately staged to fail, and the user is then offered a fake repair tool that is the actual payload.
Why ClickFix detection depends on behavior, not files
Controls built around files, such as attachment scanning, download sandboxing, and known-bad hash blocking, have little to inspect in a ClickFix attack. There is no attachment to scan, and nothing is dropped to disk at the moment of compromise. The user runs the command themselves, and the processes doing the work, such as explorer.exe, PowerShell, mshta, or conhost.exe, are signed Windows components used as designed.
That doesn’t make ClickFix undetectable. It means the signal lies in behavior rather than content. PowerShell and mshta are legitimate tools, so no single process is the warning sign. What matters is the relationship between them: which process launched which, in what order, and with what arguments. Detecting that requires monitoring process activity and command-line behavior, which is harder to encode than a file signature but entirely achievable with the right telemetry.
ClickFix / Fake CAPTCHA detection with Log360
Most ClickFix campaigns follow the same basic sequence: a lure page, a clipboard hijack, and a user-driven hand-off to a trusted system tool. That sequence gives defenders a set of choke points to build detection around, regardless of how the lure is dressed up.
Log360 currently includes detection rules targeting several observed ClickFix execution paths:
ClickFix Hidden Window Execution from Run Dialog flags the Run dialog process chain, where explorer.exe spawns a hidden conhost.exe process.
ClickFix Script Host Execution from Run Dialog flags script host activity, such as mshta, launched within that same Run dialog chain.
ClickFix mshta DNS Query to External Domain flags mshta resolving payloads through DNS queries to external domains.
ClickFix FileFix PowerShell Execution from File Explorer flags the FileFix hand-off, where a browser process invokes PowerShell after a command is pasted into File Explorer's address bar.
What security teams can do
The technical controls matter, but ClickFix also exposes a simpler security problem: Users have been trained to trust familiar verification screens.
The rule for users is simple: A real verification step should never ask you to open a system window, paste a command, and press Enter.
For defenders, the lesson is equally simple: Don't just look for malicious files. Look for the behavior that happens when a user becomes the execution mechanism.
See how Log360 monitors process behavior to flag Run dialog, mshta, and FileFix activity on your endpoints.