Anatomy of a ClickFix Attack: How a Fake CAPTCHA Ends in a Pasted Payload

The attack that doesn’t need a download

Most of your defenses assume the attacker has to get a file onto the machine. ClickFix throws that assumption out the window.

In a ClickFix attack, there is no dropper, no attachment, no obvious binary to scan. The user is convinced to open a trusted Windows tool, paste a command, and press Enter. The victim becomes the delivery mechanism. That single design choice is why this technique has spread so fast across commodity crews and targeted operators alike.

Let’s take it apart, step by step, and find the one place where the whole thing falls down.

Step 1: The lure that looks like a fix

It almost always starts with a page that pretends something is broken and offers a quick repair. The most common skins:

• A fake CAPTCHA or “Verify you are human” widget that asks you to complete “verification steps.”
• A phony error box claiming a document, video, or font failed to load and needs a manual fix.
• A spoofed browser or Windows update prompt.

The psychology is precise. The user already wanted to do something (read the doc, watch the clip, prove they are not a bot). The page frames the malicious action as the last small hurdle. Frustration plus a plausible instruction equals compliance.

Where the pages come from

These lures ride on compromised legitimate sites, malvertising, fake meeting invites, and phishing emails that link out to the page. The delivery surface is wide because the payload is not on the page. The page only has to be convincing, not weaponized, which keeps it under the radar of a lot of web filtering.

Step 2: The silent clipboard write

Here is the mechanic that makes ClickFix work. When the user clicks the fake “verify” or “fix” button, the page quietly copies a command to the clipboard using standard browser functionality. No prompt. No visible copy action. The user thinks they clicked a checkbox. What actually happened is that a payload is now sitting in their clipboard, ready to paste.

The copied text is usually obfuscated so it does not look scary even if the user glances at it. Attackers pad it with spaces so the dangerous part scrolls off screen, comment it up to look like a legit fix, or wrap it in encoding.

Step 3: The instructions that walk the user to a trusted tool

Now the page gives numbered steps. The classic sequence:

1. Press Windows + R.
2. Press Ctrl + V.
3. Press Enter.

Win+R opens the Run dialog. Ctrl+V pastes the attacker’s command. Enter executes it. Other variants send the user to PowerShell or a terminal window instead. The point is the same: the user launches a native, signed, trusted Windows binary and hands it hostile input.

The FileFix cousin

FileFix is the same idea with a different destination. Instead of Run or PowerShell, the user is told to paste into the File Explorer address bar. The address bar will happily execute commands, so a pasted string that looks like a file path can actually launch a process. It is a clever pivot because “paste this path into your file browser” feels even more innocent than opening a command prompt.

Step 4: Execution under a name your tools trust

What runs is typically a living-off-the-land chain. Think of PowerShell, mshta, cmd, or curl pulling a second stage from a remote host and executing it in memory. From there you get infostealers, remote access tooling, loaders, and eventually ransomware staging.

The critical detail for defenders: the parent process is a legitimate Windows component the user launched by hand. There is no macro-enabled document, no unsigned executable double-clicked from Downloads, no exploit. The initial action is indistinguishable, at the surface, from an admin doing normal work.

Why your existing stack struggles

Run through the standard controls and you will see the gap.

• Email security never sees the payload, because the email only carries a link to a page, and the page only carries text.
• Web filtering may miss the lure because the page hosts no malware, just a convincing UI and a clipboard write.
• Antivirus has no file to scan at the moment of the lure. The malicious content is a string in the clipboard.
• EDR can absolutely catch the post-execution behavior, and good EDR often does. But that is detection after the command has already run. You are now in incident response, racing the second stage instead of preventing the first.

Every one of these tools is valuable. None of them is positioned at the exact moment the attack lives or dies: the gap between paste and Enter.

The chokepoint everyone walks past

Strip away the theming and ClickFix and FileFix have a single, shared, non-negotiable step. A malicious command has to travel through the clipboard and get pasted into an execution surface. The lure can change. The payload can change. The trusted binary can change. That clipboard-to-execution handoff cannot. It is structural to the technique.

That is the layer to defend. If you inspect what is about to be pasted into Run, PowerShell, a terminal, or the File Explorer address bar, and you block obvious command payloads before Enter is ever pressed, the entire attack collapses at step three. No download to catch, no memory forensics, no second-stage race. You stopped it at the one point the attacker could not design around.

Defend the clipboard layer

User training helps, but you cannot train your way out of a technique engineered to exploit the moment a frustrated person just wants something to work. The durable answer is a control that sits at the clipboard-to-execution boundary and intercepts the command before it runs.

ClickFix Guard was built for exactly that boundary. It watches the clipboard-layer handoff into Run, PowerShell, terminals, and the File Explorer address bar, catches the pasted command in the act, and replaces execution with a branded block screen so your users see a stop sign instead of a compromise. If you want to see where your environment is exposed at that layer, that is the conversation worth having next.