ClickFix Fake CAPTCHAs Deliver RATs and Stripe API Malware: Windows Detection and Defense

The report was published by Flare and syndicated by Security Boulevard. Its headline promises "four different payloads," but the body describes five cases, and all five are covered here. These are Flare's findings. They have not been independently reproduced, and the indicators listed below should be treated as leads to investigate, not proof of a breach.

How the ClickFix trick works​

The steps are simple, and that is why the technique works so well. Microsoft's Security Intelligence entry for Behavior:Win32/ClickFix says the technique places a malicious command on the victim's clipboard, then instructs the user to open the Windows Run dialog (Win + R) to paste (Ctrl + V) and run a command. That command then uses living-off-the-land binaries (LOLBins) such as mshta.exe, PowerShell, curl.exe, etc. to deliver and launch final payloads.

Flare points out that the lure relies on habit. Most people have clicked through many Cloudflare-style "verify you are human" boxes without thinking about it. When a second prompt appears with instructions, plenty of non-technical users simply follow them. A security professional would find the request absurd, but the attacker isn't targeting security professionals.

Section summary: ClickFix is a delivery technique, not a malware family. The lure is always similar, but what runs after it can be almost anything.

Case one: fake DMarket page, Defender exclusion, and "CrashHandler RAT"​

This is the most technically involved chain in the report. A lookalike of the gaming marketplace DMarket shows a fake Cloudflare check with the usual three steps: Win+R, Ctrl+V, Enter. The page doesn't contain the command itself. After a successful /captcha request, it fetches the command from /api/command and copies it to the clipboard. Flare says this lets the operator change the command, withhold it, or give different visitors different commands without editing the page. According to Flare, the /captcha response was written in Russian.

The command starts an XOR-obfuscated PowerShell loader. If the loader isn't running as administrator, it writes itself to a temp script and relaunches elevated and hidden. Anyone who refused the first UAC prompt therefore sees a second one. Once elevated, the chain:

1. Downloads a legitimate script, signed by Google LLC, that adds folders to Microsoft Defender's exclusion list, and uses it to exclude the entire C: drive.
2. Downloads a password-protected ZIP from lijil[.]icu (password oldkf2026), removes Mark-of-the-Web with Unblock-File, and extracts it with a downloaded 7-Zip binary.
3. Waits a random 10–15 seconds, which Flare reads as an attempt to outlast automated sandboxes.
4. Silently installs the MSI it extracted. Flare says the MSI is signed as Microsoft.

Flare stresses that the Google-signed script is a genuine vendor utility being misused, not malware written by the attacker. Its Authenticode certificate, issued by DigiCert, is valid from April 8, 2024 to April 10, 2027. A valid signature therefore says nothing about whether this particular use is safe.

The MSI installs two stripped Go loaders, one 32-bit and one 64-bit. Flare lists several anti-analysis tricks:

• Fake Go version strings. The binaries claim Go 1.20 and 1.23, but their runtime features exist only in Go 1.24/1.25-era releases.
• Random internal package names generated for each build, compiled with -trimpath.
• A minimal import table. Only kernel32.dll is imported, and every other API is resolved at runtime.
• Fake compile timestamps from 2017–2018 on binaries built in August 2026.

The 32-bit loader hides about 447 KB of encrypted data in a section named .pdata. That section name normally belongs to 64-bit binaries, so it is an odd place to find a blob in a 32-bit one. Flare ran only this 32-bit sample, in an ANY.RUN sandbox. It loaded the .NET CLR inside its own process, ran a managed payload from memory, and connected over raw TLS to 95.85.238[.]53:56001, an address Flare says is on the Spamhaus DROP list. AMSI and Defender's AMSI provider both loaded, but the payload still reached its C2 server. The libraries the payload loaded point to WMI-based host fingerprinting, screen capture, and encrypted communications.

For persistence, the loader copied itself to %APPDATA%\Microsoft\Edge\Core\GoogleCrashHandler.exe, along with a .edge_init marker file, and the sandbox recorded registry autorun changes. The 64-bit loader was analyzed only statically. Its runtime behavior is unknown.

Flare calls the sample "CrashHandler RAT." The summary section of the report also uses the name "RATHandler," which looks like a naming slip. Flare says it found no earlier public analysis of the sample. It suggests a link to AsyncRAT but says that link remains unconfirmed.

Section summary: The key tactic here is a trusted, signed tool turning off Defender scanning for the whole system drive. Any detection logic that treats "signed by a big vendor" as "safe" should be revisited.

Case two: a Microsoft typosquat aimed at Czech users​

The domain login[.]microsoftofice[.]cz (note the single "f" in "ofice") showed a fake "I am not a robot" check. It led to a batch-script RAT that, according to Flare:

• set up persistence and fingerprinted infected hosts
• accepted commands for individual victims or broadcast to all of them
• sent command output back over a lightweight custom C2 protocol
• disguised its components as Windows processes such as RuntimeBroker.exe
• used Czech-language decoy content throughout the chain

Flare lists kupujto[.]unas[.]cz/hereissomeinterest/ and its /octopuspush/ subpath as staging and C2 paths. It calls the string —OKOKOK— in outbound POST bodies "the single best network indicator in the set."

Case three: Howdens lookalike using Stripe as C2​

This is the case most likely to worry SOC teams. The domain updates[.]howclens[.]com impersonated UK kitchen supplier Howdens by replacing the "d" with "cl", which looks almost identical in many fonts. A victim reported receiving what looked like an update email from the retailer. The fake Cloudflare checkbox put an encoded PowerShell command on the clipboard and told the user to press Win+R, type cmd, then paste and run.

The chain downloads stripe.exe, an unsigned .NET bundle with RAT features: command execution, screenshots, file transfer, and adjustable beaconing. It copies itself to %APPDATA%\Microsoft\Windows\WinSxS\MsMpEng.exe, reusing the Defender engine's filename inside a fake WinSxS folder. Flare reports that 30 of 64 VirusTotal engines detected it.

The C2 design is what stands out. The implant creates a Stripe customer record that holds a victim ID and basic system information. The operator writes commands into a pending_cmd metadata field, and the implant posts encoded results back into another field. Screenshots and large files are split across several customer objects and reassembled, and last_seen updates act as a heartbeat. Every connection goes to the legitimate api.stripe.com over a valid TLS certificate. A domain blocklist sees nothing unusual.

Flare compares this to a June 2026 Magecart campaign that also used Stripe customer metadata as a dead drop. It describes the two as independent, with no evidence of shared operators. Flare's suggested hunt is any workstation with no billing role talking to api.stripe.com. Flare also says the domain itself is legitimate and should not be blocked as malicious.

Section summary: Attackers are moving C2 into trusted SaaS APIs. Watching which machines talk to an API is becoming more useful than watching domain reputation.

Case four: a fake reCAPTCHA that launched Calculator​

A server at 18.117.141[.]76 displayed a convincing fake Google reCAPTCHA, loading the real reCAPTCHA logo straight from Google. The command it placed on the clipboard was long enough that only harmless-looking text showed in the Run box, with the actual command pushed out of view. The HTA it fetched launched calc.exe, the standard proof-of-concept payload. Flare says every VirusTotal sample it found from this infrastructure did the same.

Flare does not call this safe. The site could be an unlabelled security-awareness test, a staging setup, or something else. Someone is still maintaining it and could swap in a real payload whenever they like. Flare's position is that a legitimate awareness exercise should say so.

Case five: a Telegram page that points to the payload​

A lure linked to 193.26.115[.]174 used a basic PowerShell trick: it reversed a string at runtime to reveal a Telegram invite link. The script read the Telegram page's description and took two whitespace-separated values. It treated the first as a domain, downloaded https://<domain>/download/install, and ran the result with Invoke-Expression. The second value was captured but never used. The command also ran in a hidden window and bypassed PowerShell's execution policy for that process.

This design lets the operator change the payload host by editing a Telegram description, without touching the command. The invite had expired when Flare checked, so the final payload is unknown. No malware family can be attributed to this case.

What Windows admins should do now​

Flare argues that behavioral controls matter more than signatures here, and other published guidance agrees. Flare and others recommend:

1. Restrict the Run dialog for standard users. Microsoft's own advice is to use Group Policy to restrict or disable the Windows Run dialog (Win + R) if it is not necessary for daily operations. Huntress gives the path: User Configuration > Administrative Templates > Start Menu and Taskbar > Remove Run menu from Start Menu, then enable the policy. Huntress frames this as an optional hardening step to use where operationally feasible, so test it against help-desk and power-user workflows first. Keep in mind that the Howdens chain told victims to type cmd in Run. Removing Run breaks that sequence, but an attacker could just rewrite the instructions to use something else.
2. Control LOLBins. Microsoft recommends AppLocker or Windows Defender Application Control to block the launch of scripts and LOLBins like mshta.exe, wscript.exe, and curl.exe from user writable locations. Flare specifically suggests considering an mshta.exe block for users who don't need it, and limiting or at least monitoring curl.exe, which ships with Windows.
3. Alert on Defender exclusion changes your management tooling didn't make. Flare says this would have caught the Google-signed exclusion trick in case one. A new exclusion covering all of C: is about as clear a warning sign as endpoint telemetry gets.
4. Hunt for suspicious parent processes and Run history. Flare recommends watching for shells or mshta launched by a browser or Explorer, especially when the visible part of the command reads like reassuring text. Security Risk Advisors describes a related detection that looks for new MRU Registry entries where the values are related to CMD, PowerShell, or MSHTA commands being run.
5. Load the campaign-specific indicators, with care. These include —OKOKOK— in POST bodies, non-billing workstations talking to the Stripe API, and the hashes Flare published. Flare notes that infrastructure changes and gets reused, so confirm the surrounding behavior before blaming a specific campaign.
6. Train users on the technique, not the brand. Microsoft's guidance is to teach users that legitimate CAPTCHA systems or error messages will never require them to open the Windows Run dialog or paste commands into a terminal. The lure will keep changing logos, and that rule will still hold.

If someone has already run one of these commands, Microsoft's ClickFix entry says to disconnect the machine from all networks, check for unauthorized Run keys and scheduled tasks, check %TEMP% and AppData\Roaming for leftover files, and run a full scan with updated definitions.

Why this matters​

Flare's own figures show that the five cases it examined did not include infostealers, even though Flare cites Push Security and Microsoft, which both describe infostealers such as LummaStealer as the most common ClickFix payloads. The variety in this small sample is the useful finding. Seeing the lure tells a defender how the user was tricked, not what ran afterwards. One fake checkbox produced a new RAT, a Stripe-based C2 channel, a batch backdoor, a dead link, and Calculator. Flare's conclusion is that responders have to follow the command through its downloads, processes, persistence, and network traffic before they can judge the damage.

Restricting Run, controlling LOLBins, and monitoring Defender exclusions are basic measures that many Windows estates still haven't fully deployed.