Captcha-gated malware: when threat actors borrow anti-bot tech

A real anti-bot challenge exists to keep automation out. It collects signals, scores them, and decides whether the thing on the other end of the connection is a person. The fake one inverts the whole arrangement. It does not want to keep automation out. It wants a human, specifically, to do something a script never would: open a system shell and run a command the page handed them. The checkbox is the same orange Cloudflare checkbox you have clicked a thousand times. The text says verify you are human. The difference is that clicking it copies a PowerShell one-liner to your clipboard, and the next instruction tells you to paste it into the Run dialog and press Enter. You verify you are human by infecting yourself.

This is the technique the security industry settled on calling ClickFix, and it became the second most common attack vector on the internet in the first half of 2025, behind only ordinary phishing. ESET measured a jump of more than 500% in its own telemetry over six months. The reason it works is the reason it is interesting from an anti-bot angle: it borrows the exact UX vocabulary that legitimate bot-management vendors spent a decade teaching users to trust, and it uses the human-in-the-loop requirement as an analysis defense. A sandbox does not press Win+R. An automated URL scanner does not paste a clipboard buffer into a terminal. The malware only detonates when a real person completes a real interaction, which is precisely what a CAPTCHA was supposed to guarantee.

The sections below walk through the anatomy. First the mechanism: the clipboard injection, the lure page, and the command that lands. Then the delivery side, where compromised WordPress sites and fake-update networks like ClearFake feed victims into the funnel. Then the payloads, with Lumma Stealer as the case study, including the May 2025 takedown that put real numbers on the scale. Then the part that matters most for this blog: why gating a payload behind a human interaction defeats so much of the automated tooling defenders rely on, and what that costs the analyst. A note before going further. This is a defensive reference. It explains how the system works and names the observable artifacts; it does not hand you a working lure or a paste-ready payload.

The mechanism: a checkbox that fills your clipboard

Strip away the theming and ClickFix is three steps. The page writes a command into the operating-system clipboard. The page tells the victim to open a shell and paste. The victim runs the command, which pulls down and executes the real payload. Nothing here is a software exploit. There is no memory-corruption bug, no drive-by, no browser sandbox escape. The browser does exactly what the page asked, the user does exactly what the page asked, and the only thing being attacked is the user’s judgment.

The clipboard write is the load-bearing trick. Modern browsers expose navigator.clipboard.writeText(), which on a user-gesture (a click) will populate the clipboard without a permission prompt in most configurations. Older or fallback code paths use the legacy route: create an off-screen element, select its contents, and call document.execCommand("copy"). Group-IB and Palo Alto Unit 42 both document the fallback function appearing in the wild under the name unsecuredCopyToClipboard, a tell that has shown up across multiple unrelated kits because the same copy-paste code keeps getting reused. The point of both paths is identical. By the time the victim has clicked the friendly checkbox, the malicious string is already sitting in their paste buffer, and they have no visual indication that anything was copied.

*The five-step loop. The browser never executes anything on its own; the orange box is the point where a human gesture is mandatory, which is what blocks automated detonation.*

The string that gets copied is the second half of the trick. The classic Windows variant lands a command that runs through mshta.exe or powershell.exe, both of them signed Microsoft binaries already present on every Windows host. This is living-off-the-land: the attacker writes no executable to disk at the first stage, so there is nothing for a signature scanner to flag. The mshta form fetches and runs a remote HTML Application, which is really just a container for VBScript or JScript. The PowerShell form typically chains Invoke-WebRequest (alias iwr) into Invoke-Expression (alias iex) to download the next stage and run it in memory, frequently wrapped in a base64 blob passed to the -EncodedCommand flag so the readable command never appears as plain text in the Run box. Sucuri’s March 2025 write-up of a fake-Cloudflare campaign describes the staged command as opening a minimized command prompt, launching PowerShell without a user profile and hidden from view, downloading the trojan to a local path, and then executing an MSI installer. The exact one-liners vary kit to kit and are not worth reproducing here; the structure is the constant.

There is one forensic artifact this design cannot avoid, and it is the single best detection for the technique. When a command is typed or pasted into the Win+R Run dialog and executed, Windows records it under the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. That is the Run dialog’s most-recently-used history. A ClickFix victim leaves the entire malicious command, base64 and all, sitting in RunMRU with a recent timestamp, parented in process telemetry by explorer.exe spawning powershell.exe. Unit 42 and others hunt exactly this: a RunMRU entry containing powershell, mshta, curl, or a base64 marker, correlated with an explorer.exe to powershell.exe parent-child relationship around the same time. The attacker’s reliance on the Run dialog, the thing that makes the social engineering work, is also the thing that writes the confession to disk.

Why the shell, and not a download

A reasonable question is why attackers go to this trouble at all. A fake-update page could just serve an .exe and ask the victim to run it, which is the older drive-by model this blog covers in malware delivery via the browser. The answer is that the modern browser download path is now loud. Chrome’s Safe Browsing, Microsoft Defender SmartScreen, and the browser’s own download warnings all fire on an untrusted executable. The user sees a banner, a block, a “keep anyway” friction prompt. Each of those is a chance to stop.

The clipboard-to-shell path routes around every one of those controls. No file is downloaded by the browser, so no download warning fires. SmartScreen never evaluates a file because the browser never wrote one. The command runs under the user’s own privileges through a Microsoft-signed interpreter, which most endpoint products treat as benign by default. The victim, not the browser, is the one who fetches the payload, and they do it from a shell that does not consult Safe Browsing. The technique trades a software exploit for a human one, and in exchange it gets a clean run past the entire browser security model. That trade is the whole reason the technique displaced exploit kits as a delivery method.

The disguise: borrowing the anti-bot UX

What makes this a story about anti-bot technology specifically, rather than just another social-engineering trick, is the choice of costume. The lure does not impersonate a bank or a parcel courier. It impersonates the security check itself. The pages mimic Google reCAPTCHA and Cloudflare’s “Verify you are human” interstitial down to the logo, the orange-and-white palette, and the checkbox geometry. Some kits render a spinner and a fake “Verification in progress” state. Some add a countdown timer and a short video showing the victim exactly which keys to press, which raises completion rates by removing the user’s uncertainty about the unusual instruction.

The genius, if you can call it that, is that the disguise launders the suspicious part of the request. Being told by a random webpage to open PowerShell and paste a command is obviously alarming. Being told to “complete the verification step” by a page wearing Cloudflare’s exact UI is not, because users have been trained for a decade that bot checks are a normal, tedious, faintly annoying gate they pass through to reach content. The attacker inherits all of that conditioning for free. The same trust that makes Cloudflare’s real challenge frictionless makes the fake one effective. If you have read this blog’s pieces on the Cloudflare challenge platform or Turnstile internals, the irony is sharp: the vendors built a recognizable, trusted verification ritual, and attackers cloned the ritual’s surface while keeping none of its substance.

The technique has a documented origin that explains how it spread so fast. In August and September 2024, security researchers observed real fake-reCAPTCHA lures on video-streaming and piracy sites. On 13 September 2024, John Hammond published a proof-of-concept repository named recaptcha-phish on GitHub, recreating the lure to demonstrate the technique, with a README that signs off “EdyUkAYshuNaL PoRpoiSes only” and a dolphin emoji. Proofpoint and others noted shortly after that in-the-wild campaigns were drawing on that public toolkit. Open-sourcing the lure lowered the bar from “write your own convincing reCAPTCHA clone” to “fork a repo,” and the campaign volume reflects that. This is a recurring pattern in the offensive-tooling world, where a researcher’s demonstration and a criminal’s kit are separated mostly by the disclaimer at the bottom of the README.

*The compressed timeline. Dates per Proofpoint, the recaptcha-phish repository, Microsoft's Lumma disruption announcement, and the ESET H1 2025 telemetry.*

The OS-detection layer is where the borrowing of anti-bot tech becomes literal. Mature kits read the visitor’s navigator.userAgent and navigator.platform and branch the instructions accordingly. A Windows visitor gets Win+R and a PowerShell command. A macOS visitor gets a different script entirely, with instructions to press Command-Space to open Spotlight, launch Terminal, and paste a shell command, which on the Mac side has been observed delivering AppleScript-based stealers in the Atomic/AMOS family during 2025 and 2026 campaigns. This is exactly the client-profiling logic that legitimate bot-management vendors run, repurposed to tailor the lure. Sucuri observed one campaign rendering its fake-Cloudflare instructions in seven languages, choosing among Spanish, French, Italian, German, Arabic, Vietnamese, and Thai. The kit fingerprints the victim the way an anti-bot system fingerprints a client, and serves a payload matched to what it found. The same instinct drives phishing-kit cloaking, where the page profiles the visitor to decide whether to show the lure at all.

The delivery side: how victims reach the page

A convincing lure is useless without traffic, and the traffic side of this wave is a story of compromised infrastructure rather than novel technique. The dominant feeder through 2024 and 2025 was ClearFake, a threat cluster known for injecting fake browser-update overlays into compromised websites. ClearFake started by telling victims their browser was out of date and serving an “update” that was malware; in May 2024 it folded the ClickFix CAPTCHA into that flow, so the fake update step became a fake verification step. The plumbing underneath, the injected script on thousands of hacked sites that decides who sees the overlay, stayed the same.

WordPress is the substrate. Sucuri’s incident work describes attackers planting malicious plugins with innocuous names like SwiftPress.php or appending obfuscated code to a legitimate bundled file such as wp-includes/js/jquery/jquery-migrate.min.js, so the injection rides along with a script every page already loads. The injected code is typically hex-encoded, decoding at runtime to a base64 string that points at the next stage. To keep their foothold, the same campaigns create hidden WordPress admin accounts with machine-generated usernames in the pattern sys_c3593e4b and exfiltrate the credentials. The fake-CAPTCHA overlay is only the visible tip; under it sits a compromised CMS, a persistence mechanism, and a reporting channel back to the operator.

The traffic itself arrives through every channel the malvertising economy already runs. Proofpoint attributes early ClickFix campaigns to the initial-access broker tracked as TA571 and to ClearFake, with later adoption by numerous unattributed financially motivated clusters and, by late 2024, by nation-state-aligned actors. CERT-UA reporting tied APT28 to ClickFix-style lures in 2024. The funnels include phishing email, SEO poisoning, and paid malvertising, the same traffic-distribution systems that fed the exploit-kit era. One October 2024 campaign documented by Proofpoint pushed a fake ChatGPT lure through Outbrain ad placements to a domain delivering XWorm, with Russian-language comments in the code that the researchers assessed were probably LLM-generated. The lure surface is new. The distribution machinery is inherited.

The payload variety is wide because ClickFix is a delivery method, not a malware family, and any operator can bolt their preferred payload onto the end of it. Proofpoint’s reporting alone lists AsyncRAT, DanaBot, DarkGate, Lumma Stealer, NetSupport RAT, Brute Ratel C4, Latrodectus, and XWorm crossing the same lure. The fake CAPTCHA is the funnel; what comes out the bottom depends entirely on who rented it.

Case study: Lumma Stealer

Lumma Stealer is the right case study because it is the payload most frequently seen behind these lures, and because in May 2025 it became the subject of a coordinated takedown that put hard numbers on a problem usually described in adjectives. Lumma, also tracked as LummaC2, is an information stealer sold as a service. It first surfaced on Russian-language crime forums in early 2023. The operator, tracked by Microsoft as Storm-2477, rents access to an administrative panel where affiliates generate customized builds and retrieve stolen data, which the ecosystem calls logs. There is a documented capability to add a personal tier-1 C2 domain for an extra fee, but the public reporting does not disclose specific subscription prices, so any exact figure here would be invented.

What Lumma takes is the standard infostealer haul, and Microsoft’s technical breakdown is specific about it. Saved passwords, session cookies, and autofill data from Chromium-based browsers including Edge and from Gecko-based browsers including Firefox. Cryptocurrency wallet data, with MetaMask, Electrum, and Exodus named explicitly. Credentials from VPN clients, email clients, FTP clients, and Telegram. And a sweep of document files from user profiles matching extensions like .pdf, .docx, and .rtf. The session cookies are the quietly dangerous part: a stolen cookie can hand the attacker an already-authenticated session, sidestepping the password and the second factor both. A stealer infection is rarely the end of the incident. It is the credential-harvesting front end for whatever comes next, which is increasingly ransomware.

*The full chain for the Lumma case. Field names and the harvest list follow Microsoft's May 2025 technical breakdown; the staging structure is the common pattern across reported campaigns.*

The malware itself is built to resist analysis once it lands, which is a separate layer from the human-gating that protects the delivery stage. Microsoft’s breakdown describes the Lumma binary using LLVM-based control-flow flattening and control-flow obfuscation, customized stack decryption, and critical Windows API calls routed through low-level syscalls and the Heaven’s Gate technique for crossing between 32-bit and 64-bit execution. The effect is that a static decompile produces unusable output and an analyst is forced into dynamic analysis, which the obfuscation and anti-sandbox checks are in turn designed to frustrate. This is the same obfuscation family this blog covers in control-flow flattening and string encryption and in the JavaScript VM obfuscation used on the anti-bot side. The defensive tooling and the offensive tooling draw from the same well.

The takedown is where the scale stops being abstract. On 21 May 2025, Microsoft’s Digital Crimes Unit, acting on a court order from the US District Court for the Northern District of Georgia, seized or blocked roughly 2,300 domains that formed Lumma’s command-and-control backbone, coordinated with the US Department of Justice seizing the central control infrastructure and the marketplaces, with Europol’s EC3 and Japan’s JC3 suspending locally based infrastructure, and with Cloudflare among the private partners. The number that makes the delivery problem concrete: between 16 March and 16 May 2025, Microsoft identified more than 394,000 Windows machines infected with Lumma worldwide. The FBI separately put the count at roughly 1.7 million instances of LummaC2 being used to steal data. Cloudflare’s account of its own role notes that it had to add Turnstile to its interstitial warning pages after finding the malware operators were bypassing an earlier, weaker version of the block. A real anti-bot challenge, deployed to slow down the people running the fake one.

A takedown is a disruption, not an ending. Reporting in the weeks after May 2025 noted Lumma infrastructure rebuilding, which is the expected outcome when the panel, the builder, and the affiliate base survive even if the domains do not. Seizing 2,300 domains raises the operator’s cost. It does not remove the technique, and the fake CAPTCHA at the front of the funnel kept running regardless of what happened to any single payload’s C2.

Why human-gating defeats automated analysis

This is the part that belongs to an anti-bot blog, because the defense the attacker gets is the exact same property a real CAPTCHA is supposed to provide: proof that a human, not a machine, is at the controls. A fake CAPTCHA gates the payload behind a human interaction, and that gate is pointed at the defender’s automation rather than the attacker’s.

Consider what the standard automated pipeline sees. A URL-detonation sandbox fetches the page, renders it, maybe clicks obvious buttons, watches for downloaded files and spawned processes, and scores the result. Against a drive-by exploit that pipeline works, because the malicious behavior happens on page load whether or not anyone is watching. Against ClickFix it sees a page with a checkbox and some instructional text. Clicking the checkbox writes a string to a clipboard the sandbox has no reason to inspect. The payload command never runs, because nothing in the automated harness opens the Run dialog and pastes. No file is downloaded, no process is spawned, no network callback to a C2 fires. The sandbox times out and scores the page clean. The malicious chain is real and complete; it simply requires a step the automation was never built to perform, and the attacker chose that step precisely because automation does not perform it.

*The same page, two observers. The human-gating step is what separates a clean automated verdict from a real infection, which is exactly the asymmetry the attacker is buying.*

There is a second, subtler benefit the attacker collects. Because the payload command is delivered through the clipboard at interaction time and is frequently fetched fresh from a server when the checkbox is clicked, the static HTML of the lure page often contains no malicious command at all. A crawler that scrapes the page source sees benign markup and a reference to a script. The dangerous string is assembled or fetched at runtime, sometimes only after the OS-detection branch picks the right variant. Static URL classifiers and content scanners that never execute the page have nothing to flag. The same evasion logic this blog describes in sandbox-evasion fingerprinting applies one layer up: instead of the malware detecting the sandbox, the delivery page detects the absence of a human and simply withholds the payload.

The defensive answer follows from where the technique is weak rather than where it is strong. The lure page itself is hard to catch automatically, so the durable detections live on the endpoint, after the human has already acted. The RunMRU registry artifact is the cleanest signal: a Run-dialog history entry containing powershell, mshta, an encoded-command marker, or a URL fetch, fresh and parented by explorer.exe. Process telemetry showing explorer.exe spawning a script interpreter, which almost never happens in normal use, is the corroborating event. PowerShell script-block logging and module logging capture the decoded command even when the Run box only ever held base64. None of these prevent the first execution. They catch it quickly, before the stealer finishes its sweep or the loader pulls the next stage. Layered on top, the controls that remove the human’s ability to comply at all: locking down or removing the Run dialog through policy, constraining PowerShell with Constrained Language Mode and execution policy, and the structural fix on the platform side. Newer macOS releases added friction to Terminal that interrupts blind paste-and-run, which attacks the social-engineering step directly by making the unusual action harder to complete without noticing.

Closing: the trust they did not build

The thing worth sitting with is how cleanly this technique converts a security control into an attack surface. For a decade, anti-bot vendors taught a billion users that a checkbox saying “verify you are human” is a safe, routine gate. That training was the product. It reduced friction, it built trust, it made the challenge feel like part of the web rather than an obstacle. Then a kit on GitHub showed that the same trust, the same orange checkbox, the same muscle memory, could be pointed the other way, and within eighteen months it was the second most common way malware reached a Windows desktop.

The asymmetry at the center of it is precise. A real CAPTCHA uses the human-versus-machine distinction to keep automation out of a service. The fake one uses the identical distinction to keep automation, the defender’s automation, from ever seeing the payload. The same property protects opposite goals depending on which side of the gate you stand on. That is why the cleanest detections are not on the page but on the endpoint, in the registry key the Run dialog writes when a person finally does the thing no sandbox would: the RunMRU entry, timestamped, holding the whole base64 command in plain view, left behind by a victim who clicked verify and meant it.

---

Sources & further reading

• Proofpoint (2024), Security Brief: ClickFix Social Engineering Technique Floods Threat Landscape — the foundational write-up; threat-actor attribution (TA571, ClearFake), payload list, and dated campaign examples.
• Palo Alto Unit 42 (2025), Fix the Click: Preventing the ClickFix Attack Vector — clipboard-injection mechanism, RunMRU and process-telemetry hunting, defensive recommendations.
• Group-IB (2024), ClickFix: The Social Engineering Technique Hackers Use to Manipulate Victims — the execCommand/unsecuredCopyToClipboard fallback and the fake-CAPTCHA page structure.
• Microsoft Security (2025), Lumma Stealer: Breaking Down the Delivery Techniques and Capabilities — Storm-2477 MaaS model, the harvest list, and the binary’s obfuscation (control-flow flattening, Heaven’s Gate).
• Microsoft On the Issues (2025), Disrupting Lumma Stealer: Microsoft Leads Global Action — the takedown: ~2,300 domains seized and 394,000 infected machines in two months.
• Cloudflare Cloudforce One (2025), Cloudflare Participates in Joint Operation to Disrupt Lumma Stealer — Cloudflare’s role, including adding Turnstile to interstitials after a bypass.
• Sucuri (2025), Fake Cloudflare Verification Results in LummaStealer Trojan Infections — WordPress compromise details, malicious-plugin names, multilingual lure, hidden-admin persistence.
• ESET / WeLiveSecurity (2025), ESET Threat Report H1 2025 — the +500% telemetry jump, second-place ranking among attack vectors, cross-platform reach.
• John Hammond (2024), recaptcha-phish (GitHub) — the 13 September 2024 proof-of-concept that documented and accelerated the fake-reCAPTCHA lure.
• Sekoia (2025), ClickFix Tactic: Revenge of Detection — mshta versus PowerShell attack chains, the explorer.exe parenting trick, and detection angles.
• Netskope (2026), macOS ClickFix Campaign: AppleScript Stealers and New Terminal Protections — the macOS branch: Spotlight-to-Terminal lures, AppleScript stealers, and new OS friction.
• The Hacker News (2025), ClickFix Malware Campaign Exploits CAPTCHAs to Spread Cross-Platform Infections — integrated cross-platform OS-detection logic targeting Windows and macOS from one entry point.