When the user is the exploit: how ClickFix quietly became the most common way in

Ronnie Mathew — Tue, 02 Jun 2026 06:05:21 +0000

A finance employee is booking a restaurant for a team dinner. The reservation site asks her to verify she is human. She has done this a thousand times. The page tells her to press the Windows key and R, paste what is already on her clipboard, and hit Enter. She does it without thinking. There is no download, no attachment, no warning from her antivirus. The verification box disappears and the site loads normally. Nothing seems wrong.

What actually happened is that she just ran a PowerShell command that installed an information stealer on her machine. Within minutes, her browser cookies, saved passwords, and active session tokens are on their way to a server she will never see. No malware got past the email filter, because nothing arrived by email. No file triggered the endpoint agent, because she typed the command in herself.

This is ClickFix, and in the space of about eighteen months it has gone from a curiosity to the single most common way attackers gain initial access. Microsoft attributed roughly 47 percent of initial access attacks in 2025 to this one technique. That is not a niche trick anymore. It is the front door.

The uncomfortable truth is that ClickFix does not exploit a software vulnerability. It exploits the user's willingness to follow instructions, and most of our defences were never designed to stop that.

How the attack actually works

ClickFix is built around a simple deception. The attacker compromises a legitimate website or stands up a convincing fake, then replaces a routine step such as a CAPTCHA or a browser error with a fake version. The fake prompt tells the user that to prove they are human, fix a display problem, or complete verification, they need to perform a few quick steps.

Those steps are almost always the same. Press Windows and R to open the Run dialog, or open a terminal. Paste the command that has already been copied to the clipboard in the background. Press Enter. The user believes they are completing a security check. They are actually executing the attacker's code with their own hands.

The payload is usually a PowerShell command that quietly downloads and runs the real malware. Common families seen through late 2025 and into 2026 include information stealers such as LummaStealer, StealC, and Amatera, along with remote access tools like AsyncRAT and Xworm. The exact payload varies. The delivery method does not.

Variants have multiplied quickly. CrashFix dresses the lure up as a system crash dialog. FileFix abuses the File Explorer address bar instead of the Run dialog. A DNS-based version hides the command inside an nslookup query. The surface details keep changing, but every variant relies on the same thing: convincing the person to run the command themselves.

Why it slips past tools that should catch it

Most of the security stack in a typical organisation is built to inspect things that arrive. Email gateways scan attachments and links. Endpoint detection watches for malicious files being written and executed. Sandboxes detonate suspicious downloads in isolation to see what they do. ClickFix is designed to make all of that irrelevant.

There is no attachment to scan, because the lure is a web page. There is no malicious file to detect at first, because the initial action is a command the user types into a trusted system tool. Sandboxes that analyse downloaded files never get the chance, because nothing is downloaded in the way they expect. The attacker has effectively moved the point of compromise from the network to the keyboard.

This is also why CAPTCHA-gated lures have become so popular. A fake CAPTCHA does double duty. It builds trust with the user, who associates the checkbox with safety, and it blocks automated security crawlers, which cannot solve the challenge and therefore never see the malicious page behind it. Microsoft tracked CAPTCHA-gated phishing more than doubling in a single month in early 2026, reaching close to twelve million attacks in March alone.

The technique sits inside a broader pattern worth naming. The malicious action is hidden inside a workflow the user already trusts and expects to be safe. Fake tech support flows, consent phishing that abuses real sign-in screens, and QR-code device-linking scams all follow the same logic. ClickFix is the most successful example of the pattern, not the only one.

The shift this represents

For most of the last two decades, defenders have made it steadily harder to break into systems. Patching improved. Exploit mitigations got better. Email filtering matured. The result is that buying or developing a working software exploit is expensive and unreliable, while convincing a person to paste a command costs almost nothing and works often enough to be worth it at scale.

Generative AI has tilted this further. The lure pages, the instructional videos, and the supporting text can now be produced quickly, in any language, tuned to whatever brand or context the attacker wants to imitate. Security researchers have already documented ClickFix campaigns that use short videos to walk victims through the steps, and campaigns that target specific groups such as content creators with offers of verified badges. The economics now favour deception over exploitation, and attackers have noticed.

What detection looks like when the file is not the signal

If the file is no longer the reliable signal, detection has to move to behaviour. The good news for security teams is that ClickFix leaves a fairly distinctive trail, even though it avoids the usual tripwires.

The most reliable signal is the process lineage. A browser spawning a command interpreter is unusual in most environments. When that command interpreter is PowerShell, launched with encoded or obfuscated arguments, shortly after a user interacted with a web page, that sequence is worth a high-confidence alert. The same goes for the Run dialog being used to launch a script, which is rare for ordinary users and common in these attacks.

Other useful signals include command lines that reference clipboard contents, PowerShell reaching out to a freshly registered domain, and unusual use of living-off-the-land binaries that proxy execution through trusted Microsoft components. None of these are conclusive on their own, but together they describe a behaviour that legitimate users almost never produce.

For teams running a SIEM, the practical work is to build and tune detections around this behaviour rather than around file hashes. In platforms like IBM QRadar, that means correlation rules that tie a browser parent process to a script interpreter child process, enriched with reputation context on any domain the command contacts. The detection logic should be specific enough to avoid drowning analysts in noise from legitimate administrative scripting, which is exactly the kind of tuning discipline that separates a useful rule from one that gets ignored.

Why awareness training is necessary but not enough

The obvious response to a social engineering attack is to train people to recognise it. That training matters, and the specific message is simple enough to land: no legitimate website will ever ask you to open a terminal, paste a command, and run it. If a verification step asks you to do that, it is an attack. That single rule, understood widely, would stop most ClickFix attempts.

But training alone is a fragile defence. People are busy, distracted, and conditioned to complete verification steps quickly. The same employee who would pass a phishing quiz on a calm Tuesday afternoon will paste the command when they are rushing to book a venue before a meeting. Defences that depend on every person being alert every time will eventually fail, because that is not how attention works.

The stronger position is to reduce what a successful lure can achieve. Restricting who can launch script interpreters, controlling access to the Run dialog through policy, and making sure session tokens are short-lived all limit the blast radius when someone does fall for it. Phishing-resistant authentication such as passkeys and hardware security keys is particularly valuable here, because even when an information stealer grabs a session token, cryptographically bound credentials are far harder to replay.

Where this leaves defenders

ClickFix works because it turns the person into the delivery mechanism, and our industry spent twenty years building defences aimed at everything except that. The technique is cheap, adaptable, and effective, which means it is not going away. If anything, the variants emerging through 2026 suggest it is still being actively developed.

The realistic path forward is not a single product or a single training session. It is layered. Teach the one rule that matters, so people have a chance to stop the attack themselves. Build behavioural detections that catch the attack when training fails, focused on process lineage rather than files. Reduce privileges and shorten token lifetimes so that a successful lure yields as little as possible. And tune those detections continuously, because the surface details of the lure will keep changing while the underlying behaviour stays the same.

The attackers have understood something important about modern security. The hardest layer to patch is the human one, and the most trusted moments are the routine ones. Defenders who internalise the same insight, and design for the moment a careful person makes a careless click, are the ones who will stay ahead. The decoy here is not a fake server. It is a fake sense of safety, and the work of defence is to make that fake safety expensive for the attacker to manufacture.

Originally written by Ronnie Philip Mathew. Views are my own.

Tags: security, cybersecurity, infosec, threatdetection, soc