
By Assaf Morag, Cybersecurity Researcher
A friend messaged me one word: “Help!” He had been infected with malware after following what looked like a routine Cloudflare verification prompt. While helping him respond, I had to fully analyze the website and gather strong lure detection markers.
That turned into a larger project: a script that finds live ClickFix pages so they can be reported and taken down.It also surfaced something we didn’t expect. Behind the same fake CAPTCHA, we found three previously undocumented payloads, including a new RAT we named CrashHandler, malware that runs its command channel through the Stripe API, and malware that hides its next-stage instructions in DNS responses.
This blog is a short summary explaining some of my findings.
Key Findings from Investigating ClickFix in the Wild
- One fake CAPTCHA, three different undocumented payloads. Across real-world campaigns, ClickFix delivered CrashHandler RAT, a Czech-language Microsoft impersonation RAT, and malware that uses the Stripe API as a covert command channel, none of which had been documented before. A fourth chain delivered CrocoRat, which hid its next-stage instructions in DNS responses (part of this analysis, and has a deeper dive investigation here). While the lure was identical, the malware behind it was not.
- Trusted tools and services do not guarantee safe behavior. Attackers abused a legitimate, signed Google utility to weaken Microsoft Defender, and repurposed Stripe and DNS traffic to blend malicious communication into normal business activity.
- A single infected device can expose an entire company. Infostealers delivered via ClickFix can harvest corporate single sign-on tokens, active business application sessions, internal documents, and cloud secrets, turning a personal infection into an organizational breach.
- Removing the malware is not the same as closing the exposure. If stolen credentials, sessions, or tokens remain valid, the attacker keeps access even after the infected device is cleaned.
Flare Research
Read the Deeper Investigation Into ClickFix in the Wild
One fake CAPTCHA led to three previously undocumented payloads and a fourth chain that hid its instructions in DNS. Get the full technical analysis behind these ClickFix campaigns.
The User Becomes Part of the Attack Chain
ClickFix tricks people into running a malicious command under the pretext of fixing an error or proving they are human. A fake CAPTCHA in-browser process stealthily copies a command to the clipboard, then tells the victim to open Windows Run or a terminal, paste it, and press Enter.
This creates a real challenge for security solutions. The initial interaction may contain neither an obvious malicious attachment nor a conventional credential-harvesting form. Familiar branding and routine troubleshooting instructions help carry the victim from a webpage into execution.
What the Research Adds
ClickFix as a technique is well-documented. Our contribution is the evidence behind these particular chains: how operators change delivery commands, weaken endpoint protection, conceal payloads, and repurpose legitimate services for remote control.
We began our investigation with live pages and expanded through infrastructure searches, certificate relationships, and historical website observations. We validated candidate verification flows, collected available artifacts, and combined static analysis with controlled sandbox testing.
A convincing screenshot does not establish what an attack delivers. A familiar CAPTCHA can conceal very different capabilities, and an inactive stage leaves questions that analysis must acknowledge.
Familiar Prompts, Different Consequences
The most consequential finding was the variation behind the same social engineering technique. (You can read the deeper dive into all of these following cases here).
A fake gaming marketplace delivered remote-access malware we have named CrashHandler RAT. After tricking visitors into running a command, the attackers abused a legitimate, digitally signed Google tool to weaken Microsoft Defender’s protection and installed malware designed to maintain access to the victim’s computer. For security leaders, the lesson is clear: a trusted software signature does not guarantee safe behavior. Security controls must also detect how legitimate tools are being used.
A fake Microsoft verification page in Czech delivered remote-access malware. After victims followed the instructions, attackers could collect information about their computers and remotely control them, individually or in groups. The malware disguised itself as familiar Windows software and maintained access after the initial infection. For security leaders, this shows how a routine-looking verification prompt can become a lasting foothold for attackers.
A website that impersonates Howdens (UK kitchen retailer) delivered malware that used Stripe to communicate with attackers. The malware abused the legitimate payment platform to receive instructions and send back stolen information, making its traffic harder to distinguish from normal business activity. For security leaders, the lesson is clear: a connection to a trusted service can still carry malicious activity. Detection must consider what the endpoint is doing and why it is using that service.
A fake verification website delivered CrocoRat using instructions hidden in DNS responses. The attack abused DNS to retrieve instructions that triggered malware downloads, keeping the next stage out of the command the victim pasted. For security leaders, the lesson is clear: routine network services can also carry attack instructions. Detection should also consider what the endpoint is doing and connect suspicious DNS activity with subsequent downloads and execution.
Two other cases illustrated the limits of a single observation. One chain launched Calculator, leaving its purpose unresolved. Another used a Telegram page as a changeable pointer to a payload host, but that page was unavailable during analysis. Neither observation established a completed malicious infection. Both showed why investigators must follow the delivery chain and clearly separate confirmed behavior from unresolved intent.
One Device Can Expose Corporate Access
Public reporting identifies infostealers as a dominant ClickFix payload category: Microsoft describes LummaStealer as its most prolific observed final payload, while Push Security identifies infostealers as the dominant category. ClickFix also delivers RATs and other malware, with the distribution varying across campaigns
Corporate identities, single sign-on tokens, active sessions for business applications, internal documents, and cloud or development secrets may be stolen and packaged for sale, potentially exposing the organization’s systems and data.
Those logs can enter underground markets, where buyers search for valuable accounts and corporate access. An infection reached through a personal shopping or gaming activity can therefore expose business systems accessible from that device.
Leadership should assess which identities, sessions, and secrets were reachable, alongside the malware’s capabilities. Removing the payload addresses only part of the exposure if stolen access remains usable.
Five Priorities for Security Leaders
1. Teach the behavior employees should recognize. Show the actual sequence: fake verification, copied command, Run or terminal, execution. Give employees a clear instruction to stop and report website prompts asking them to run commands, supported by a simple reporting route.
2. Reduce unnecessary execution paths. Ask endpoint teams to review application control, scripting permissions, and access to tools such as mshta.exe. Restrict Run where business requirements allow, while recognizing that attackers can use other launch methods. Validate restrictions against legitimate workflows.
3. Detect the chain across controls. Prioritize unusual shell execution following browser activity, unexpected downloads, persistence, and unauthorized Defender exclusion changes. Confirm that endpoint teams can connect these events into an investigation rather than handling each alert separately.
4. Investigate legitimate services in context. The Stripe case supports reviewing unexpected API activity alongside the responsible process and host artifacts. Blocking a payment platform indiscriminately would create disruption; understanding which systems should use it makes suspicious activity easier to identify.
5. Rehearse endpoint and identity response together. Prepare a playbook covering isolation, evidence preservation, credential rotation from a clean device, session revocation, and review of exposed secrets. Define ownership across endpoint, identity, and incident response teams before an infection occurs.
For leadership, the useful test is concrete: can your organization recognize this verification trick, interrupt the execution chain, and contain the access it may expose?
Adapting to ClickFix Attacks
The campaigns we examined used different lures, different malware, and different tricks, from a signed Google tool turned against Defender to Stripe and DNS traffic carrying instructions. Yet every one depended on the same moment, a person pasting a line of text into a dialog box. Ultimately, ClickFix attacks are social engineering. That is also where defenders have the most leverage.
Employees who recognize the sequence, endpoint controls that limit what the Run dialog and scripting tools can do, and detection that connects browser activity to the execution that follows can break the chain before it starts. Because a single infected device can hand over corporate sessions, tokens, and secrets, cleaning the machine is only half the response, and stolen access must be revoked as well. The test for any organization is whether it can recognize the trick, interrupt the chain, and contain what it exposed.
Flare Research
Read the Deeper Investigation Into ClickFix in the Wild
One fake CAPTCHA led to three previously undocumented payloads and a fourth chain that hid its instructions in DNS. Get the full technical analysis behind these ClickFix campaigns.



