What is ClickFix?

There is no exploit in a ClickFix attack. Nothing needs patching, because nothing is broken — the only moving part is the person at the keyboard.

Almost every control in a delivery chain assumes the malicious code arrives as something: an attachment, a download, a macro. Gateways scan the something, browsers check its reputation, Windows tags it with a mark of the web. ClickFix never sends the something — at delivery time nothing crosses the boundary but text on a page.

The first artefact on the machine is a command run by the logged-in user, in their own session, with their own privileges. The parent process is the shell, not the browser, and the code never has to survive a download scan because the victim types it. The user is the execution vector, which is also where the defence has to sit.

It also borrows a trust that awareness training rarely addresses: people are taught to distrust attachments and senders, not their own hands. And it is cheap — a lure page is a few hundred lines of static markup, and kits are re-skinned, so one build turns up on host after host.

Nearly every variant follows the same seven steps. Only the first and the last vary much.

1. 01Arrival. A lure page — from a compromised site the victim trusted, an advert, a search result, or a link sent to them.
2. 02Pretext. The page states a problem and promises a fix. One obvious control to press: verify, continue, fix it.
3. 03Clipboard write. That press is the point of the control: browsers require a recent user interaction before a page may write to the clipboard, and the button supplies it. The clipboard now holds the attacker's command; nothing on screen says so.
4. 04Instruction. Three numbered steps: open the Run dialog or Terminal, paste, press Enter. Seconds to follow.
5. 05Execution. The operating system launches an interpreter — usually PowerShell, sometimes mshta.exe, on macOS a shell. The attack becomes an incident here.
6. 06Loader. The pasted command does one job: fetch the next stage and run it, normally in memory, so nothing is written to disk for a scanner to find.
7. 07Payload. Usually an information stealer, sometimes a remote-access tool, occasionally a foothold sold on to somebody else.

Step three carries the attack. If a page printed a command and asked you to type it, most people would read it first and some would stop; the clipboard removes the reading step. Kits go further and pad the command so that the part visible in the Run box is a decoy — a verification code, a reference number — while the real command sits scrolled out of view.

If you followed the steps and nothing looked wrong, that means nothing. The command you ran was almost certainly not the text you were shown.

One artefact outlives all of it. On Windows, anything pasted into the Run dialog is written to the registry under RunMRU, which survives the page being taken down and is frequently the only place the original command still exists — how to read it.

The pretext is the slow-moving part. Payloads change weekly and infrastructure daily, but the stories are stable, because they have to keep working on people.

• Fake CAPTCHA verification
• Fake browser update
• Cloudflare Turnstile clone
• Fake meeting or conferencing app
• Corrupted document or repair prompt
• Generic browser or system error
• Download gate verification

The fake CAPTCHA is the one most people meet; the fake browser update came first. Each has its own page here, with the detail that gives it away.

Compromised legitimate websites are the largest source in published reporting. Script is injected into a hacked content-management install — WordPress most often — and served to a fraction of visitors by geography, user agent and whether they have been seen before. The site owner is a victim too, usually finds out from a customer, and has done nothing wrong.

Malvertising buys the traffic instead of stealing it, bidding against the names of software people are looking for. SEO poisoning aims at queries with commercial intent and no authoritative answer — cracked software, obscure drivers, niche error codes. Direct messages cover the targeted end, where the pretext is written for one recipient.

Because so much of the hosting is other people’s property, a domain appearing in ClickFix reporting is not evidence that its owner did anything. That is why this site records dated observations rather than verdicts.

On Windows, information stealers dominate: Lumma, StealC, Vidar and Rhadamanthys appear most often in public reporting. They are fast and indiscriminate — browser credentials and session cookies, password manager databases, wallet files, messaging tokens — and the theft is finished long before anyone notices. Remote-access tools appear too, and ClickFix is sometimes the first step in a chain that ends in ransomware.

On macOS the equivalent is AMOS — Atomic macOS Stealer — and its derivatives. Those chains typically end with a prompt for the account password, drawn to look like a system dialog. That prompt is the stealer asking, and granting it is the moment keychain contents become reachable.

The payload is the least stable part of the picture — the same infrastructure delivers different families from one week to the next, which is why campaigns and the families they carried are recorded separately here. Both ends of the market use the technique: the volume is commodity crime, but Proofpoint reported state-aligned clusters trialling ClickFix against far fewer, better-chosen people through late 2024 and early 2025.

The technique now has a sub-technique of its own. Before it existed, ClickFix activity was recorded under whichever interpreter happened to run, and the human step disappeared from the reporting.

Definitions are maintained by MITRE at attack.mitre.org.

Awareness is the primary control here, not a supplement to one — uncomfortable to write, because awareness training is usually the weakest layer in a stack. It is primary for a specific reason: every technical layer that normally carries the load has been designed out of the attack. One rule covers essentially the entire class, and it is short enough to survive being read once:

No legitimate website will ever ask you to press Windows+R, to open Terminal, or to paste anything into either one.

Teach the rule, not the pictures: the lures change every week and the instruction does not. The technical controls that genuinely help:

• Remove or restrict the Run dialog. The Group Policy setting that removes the Run menu also disables Windows+R. It does not close every path — the address bar, the Start search box and Terminal remain — but it breaks the exact steps most lure pages give.
• Monitor RunMRU. Alert on writes to the Run dialog’s history containing interpreter names, encoded-looking arguments, or values far longer than a human would type. One of the highest-fidelity, lowest-volume detections available anywhere.
• Alert on process ancestry. A scripting interpreter whose parent is the desktop shell is not normal on a workstation, particularly with a hidden window or an encoded argument. The macOS equivalent is a shell launched from Terminal that immediately reaches the network.
• Turn on PowerShell logging — script block, module and transcription, with useful retention. Without it the loader stage leaves almost nothing behind.
• Log egress. The loader has to fetch something from somewhere, and DNS and proxy logs are usually the only evidence that survives.

One caution: variants keep arriving. FileFix replaces the Run dialog with the File Explorer address bar; others use the Start search box. Controls keyed to one keyboard shortcut age badly; controls keyed to education and process ancestry do not.