A CAPTCHA does not need your terminal.

A CAPTCHA checks what you do in a browser. It does not need you to open Windows Run, PowerShell, or Terminal.

That is the tell behind ClickFix, a social-engineering technique spreading through compromised websites. The page looks like a familiar verification step. It quietly places a command on the clipboard, then walks the visitor through pasting and running it. The user does not download a suspicious attachment. They become the installer.

What happened

Netskope found more than 5,400 compromised sites across more than 2,200 organizations serving parts of this campaign over the last few months. Many were ordinary small-business sites built on WordPress or PrestaShop. Netskope was still seeing more than 300 affected sites each weekday when it published its findings on September 3.

The delivery chain is short. An injected script on a legitimate site retrieves more JavaScript from a smart contract on the BNB Smart Chain testnet. The script covers the page with a fake CAPTCHA and copies a command to the visitor's clipboard. The instructions say to open the Windows Run dialog, paste, and press Enter. That command downloads and runs the actual payload.

Using a smart contract gives the attacker a cheap, difficult-to-remove place to store the next instruction. Updating one contract changes what every compromised site delivers. The compromised website supplies trust; the blockchain supplies durable distribution; the user supplies execution.

Cisco Talos documented a current version that impersonated a Google CAPTCHA. Its pasted command reached a WebDAV path and launched a disguised DLL through rundll32.exe. The chain installed Amatera, a credential and cryptocurrency stealer, then delivered additional tools including a reverse proxy, another stealer, and an unauthorized NetSupport Manager remote-access client. Talos also recovered a macOS branch that directed visitors to open Terminal and paste a curl command.

The clever part is not the fake CAPTCHA. It is getting a real user to authorize the step your security tools were built to stop.

This is why the technique is working. Browsers warn about downloads. Mail filters inspect attachments. Operating systems distrust unsigned installers. ClickFix routes around those controls by persuading the person at the keyboard to use trusted system tools.

This is not an intelligence test

The lazy response is to blame the person who followed ridiculous instructions. That misses how people actually use the web.

Modern sites routinely interrupt work with consent banners, verification loops, notification prompts, and changing interfaces. ClickFix adds one more awkward instruction to that pile. Worse, the prompt can appear on a site the visitor has used for years because the site itself was compromised. Ars Technica reported that the technique has moved from exotic to mainstream on both Windows and macOS.

Training still matters, but "be less gullible" is not a control. Someone will follow the prompt eventually. Your job is to make that mistake observable, containable, and recoverable.

The possible loss is also larger than one laptop. Talos found collection rules covering browser data, messaging apps, password managers, authenticators, VPN software, remote-access tools, private keys, OAuth material, and certificate files. A stolen browser session or developer token can turn one pasted command into access to email, source code, cloud consoles, and customer systems.

What we would do

1. Teach one sentence, not a slideshow. A website verification will never ask you to press Windows+R, open PowerShell, or open Terminal. If it does, close the page and report the address. Put that exact message in onboarding, the help desk script, and the next security drill.
2. Make reporting safer than hiding it. Give people a fast channel to report the page, even after they pressed Enter. Do not shame the first person who tells you. Ten quiet minutes matter more than proving someone should have known better.
3. Reduce who can launch the machinery. Where the role permits it, disable the Windows Run dialog and restrict PowerShell, script hosts, rundll32.exe, and remote WebDAV execution with application control. Developers and administrators may need some of those tools. The rest of the company usually does not need unrestricted access to all of them.
4. Detect the sequence, not just a bad domain. Domains and payloads rotate. Alert on suspicious commands in the Windows RunMRU history, hidden PowerShell launched after interactive browsing, rundll32.exe loading from a WebDAV path, unexpected Windows WebClient service starts, and shell commands that immediately retrieve remote code. Mandiant's ClickFix investigation shows why the Run history and process chain are useful evidence.
5. Assume credentials left with the malware. If someone ran the command, isolate the endpoint. Preserve the process tree, command history, DNS, proxy, and endpoint telemetry. Then revoke browser sessions, API tokens, and other credentials available to that user from a known-clean device. An antivirus scan alone does not invalidate a stolen session.
6. Protect the website side too. If you operate WordPress, PrestaShop, or another content system, monitor core files, plugins, themes, and JavaScript assets for unexpected changes. Keep the CMS and extensions current, remove abandoned plugins and accounts, and review changes made through hosting or CDN control planes. A clean employee fleet does not help customers visiting your infected site.
7. Test the boring failure. Run a safe simulation that copies a harmless marker and asks a user to open Run. Confirm that endpoint controls block it, telemetry catches it, the help desk recognizes the report, and the response team can revoke sessions quickly. Awareness without a tested response is a poster.

The bottom line

If a website asks you to leave the browser to prove you are human, the verification has already failed.