ClickFix doesn't attack your knowledge. It attacks your trust.

It started with a phone call from a friend. He'd tried to log into his university's Student Association website — a site he used constantly and trusted — and hit a strange CAPTCHA screen. Something felt off. He asked me to take a look.

I did. Working with RL's Spectra Analyze, I ran interactive dynamic analysis. What I found was a textbook ClickFix attack. The student site was compromised and used as a “watering hole” to draw in potential victims. Key to the attack was a pixel-perfect fake Google verification prompt, and a clipboard that had already been silently overwritten with a malicious command before I clicked anything. Within a few hours, between five and ten students had their browser credentials, session tokens, and cookies harvested. Accounts were hijacked. No exploit. No zero-day. No vulnerability in the traditional sense.

That became the anchor for a larger investigation. After building a YARA rule to hunt for the technique across our file collection, my team and I matched more than 4,000 ClickFix samples. The picture that emerged should worry every AppSec and SecOps team reading this: ClickFix isn't a clever trick anymore. It's an industrialized attack methodology that most of the defensive stack is structurally unequipped to catch.

[ Get the report: Copy, Paste, Compromise: The Tale of ClickFix | Join the webinar ]

Why your EDR sees nothing wrong

Here's the uncomfortable part. From the perspective of your endpoint detection and response (EDR) tooling, nothing bad happens during a ClickFix attack.

The premise is deceptively simple: A victim lands on a convincing fake page — a browser update notice, a Google Meet microphone error, a Cloudflare verification prompt. The page tells them to open the Windows Run dialog (Win + R) or macOS Terminal, paste a command, and press Enter. The command is already sitting on their clipboard, written there silently by JavaScript the moment they engage with the page. They think they're proving they're human. They're actually executing a fully functional malware payload directly in memory.

That's the whole attack. And every individual step in it looks legitimate. A user launching PowerShell looks identical whether they're running an IT maintenance script or a Lumma Stealer dropper. The execution chain runs through trusted, signed system utilities — PowerShell, mshta.exe, curl, rundll32.exe — the "living off the land" binaries and scripts (LOLBaS) that administrators use every day. ClickFix Payloads download into memory and execute there, with some observed attacks never touching the disk like traditional malware.

EDR and antivirus are calibrated to detect malicious code executing the way malicious code typically executes. ClickFix doesn't execute that way. The behavior is, from the tooling's point of view, entirely expected. That's not an incidental weakness — it's the design philosophy. Construct a chain in which every component classifies as normal, even as the aggregate constitutes a full compromise.

The sophistication is rented, not built

The reason you're seeing more of these campaigns isn't that attackers got smarter. It's that they no longer need to be.

ClickFix is now a mature Malware-as-a-Service (MaaS) offering. Complete kits sell on underground forums for as little as $250 per month, up to around $1,800 for a lifetime license with software updates included. Higher tiers bundle pre-built lure templates for Cloudflare CAPTCHAs, browser updates, custom domain rotation, payload integration, malvertising traffic partnerships, and Telegram-based customer support. AV-bypass isn't a happy accident in these kits — it's advertised as a feature.

The practical consequence for defenders is a sharp rise in campaign volume with no corresponding rise in attacker skill. And the backend supporting these operations is sophisticated: one recently exposed MaaS platform managed multiple operators simultaneously, tracked cryptocurrency wallet assets, delivered a Node.js remote access trojan (RAT) whose modules never touched disk, and routed command-and-control traffic over gRPC streams through Tor.

What they're actually delivering

ClickFix is a delivery mechanism, not a payload. The threat depends entirely on what rides in behind it — and that catalog is expanding.

Lumma Stealer remains the most prolific final payload we observe. A more concerning trend is the growing use of RATs as ClickFix payloads  — XWorm, AsyncRAT, NetSupport, SectopRAT, DarkGate and more. 

Where an infostealer like Lumma executes, harvests, and exits, a RAT establishes durable access. That means hands-on-keyboard activity: discovery, lateral movement, credential dumping, and persistence — the full post-exploitation playbook, all without introducing a binary your endpoint tooling would recognize.

In the student watering hole case, the payload was zuhe.dll, a Go-based post-exploitation RAT with three stacked obfuscation layers, an anti-analysis gate that checked for 14 known sandbox environments, and multi-channel C2. It harvested credentials, cookies, session tokens, autofill data, and browsing history across every Chromium and Firefox browser on the machine — all from inside a legitimate Windows process, with no User Account Control (UAC) prompt and no alarm.

Image: The anatomy of ClickFix watering hole attack

The same campaign also weaponized blockchain. Instead of a takedown-vulnerable redirect, the attackers queried Ethereum smart contracts to retrieve their payload. There's no IP to block, no domain to flag, and no way to take the infrastructure down. That's the direction this is heading.

The only intervention points that actually work

If hash-based and reputation-based detection can't keep up with infrastructure that rotates faster than coverage develops, and EDR can't flag execution that looks like normal user behavior, what's left? Three things, and they're all structural rather than signature-based.

1. Use YARA rules to flag suspicious behaviors

First, catch the lure before the user acts. ClickFix pages have a remarkably stable behavioral fingerprint regardless of which payload they deliver: a fake verification UI, a clipboard-writing JavaScript function, and PowerShell payload indicators. That stability is the detection opportunity.

The YARA rule my team built targets exactly these structural signal groups, and it requires multiple conditions to match — minimizing false positives while catching pages regardless of infrastructure rotation. When we ran it across our file collection, it flagged 123 confirmed ClickFix lures that evaded every AV engine. Some samples were first seen within 48 hours of analysis. These are active campaigns, not historical artifacts.

2. Harden the execution environment

Second, harden the execution environment. PowerShell Constrained Language Mode is the single most effective technical control against ClickFix — it prevents arbitrary script execution even when a user launches PowerShell manually. Pair it with script block logging, the Antimalware Scan Interface (AMSI), application control through Windows Defender Application Control or AppLocker, and, where operationally feasible, suppressing the Run dialog for standard users. None of these are exotic. Most are already available in environments you manage today.

3. Educate employees about suspicious behaviors

Third, interrupt social engineering. This is the only point in the chain where human judgment can stop the attack before technical execution begins. The lesson to teach employees and other potential targets is simple and universal: legitimate software, websites, and IT tools never instruct you to copy and paste a command into the Run dialog or Terminal. Ever.

The lesson from the watering hole

I want to be clear about what the student case actually teaches, because it's easy to draw the wrong conclusion. The victims weren't careless. They were business and economics students who live online, and they were on a site they owned, visited constantly, and trusted completely.

ClickFix works because it doesn't attack your users' knowledge — it attacks their trust in systems that have every reason to look legitimate. You cannot train or detect your way out of that risk entirely. What you can do is deploy detection that targets the mechanism instead of the infrastructure, hardens the environment so the execution paths close, and gives your people one clear rule to hold onto. 

See Toni Dujmović’s full technical analysis, including the open-source YARA rule, hardening controls, and indicators of compromise (IOCs) in the ReversingLabs ClickFix research report. Plus: Join Toni in this July 21 webinar: Anatomy of a ClickFix Attack: From Fake CAPTCHA to Full Compromise.