ClickFix Attacks Evolve to Better Hide Malicious Payloads

Threat actors are now hiding payloads by using DNS TXT records and browser cache pre-fetching, making it tougher to spot early attack stages.

Attackers are altering ClickFix tactics to hide payloads until after the victim has already performed the trusted action, as two recent examples showcase.

ClickFix has become a prominent social engineering technique in the past few years, due largely to how it exploits human problem solving tendencies as well as trust in software. A typical ClickFix attack presents victims with a fake technical problem or verification prompt, then instructs them to paste and execute a command that has often already been copied to their clipboard.

Sometimes the prompt is attached to a phony CAPTCHA puzzle, while other times the victim visits a fake Zoom call that requires an update to “fix” a supposed technical issue. In any case, it almost always involves pasting code into Windows Run, PowerShell, or the MacOS Terminal.

The examples of threat actors employing this technique continue to pile up, and new research from two vendors shows how it continues to evolve to better evade detection measures.

Hiding the ClickFix Payload

Flare cybersecurity researcher Assaf Morag today presented his findings on a new campaign involving CrocoRat, a remote access Trojan (RAT) and cryptocurrency stealer. Flare found the campaign through a deliberately misspelled domain displaying a blurred house-wiring diagram, although researchers do not know how victims were initially directed to the page.

A user visits this page, possibly intended to be delivered through a malicious email or website, and is prompted with a fake reCAPTCHA checkbox next to a spoofed Cloudflare logo and classic “Open PowerShell and paste the text” ClickFix instructions.

But instead of directly retrieving the next-stage payload, the pasted PowerShell command queries a DNS TXT record through an attacker-controlled DNS server. The record returned by that server contains the next PowerShell instruction, effectively telling the system where to go next. That response supplies yet another PowerShell instruction that initiates the subsequent download chain, while keeping that next-stage instruction out of the command directly copied to the victim’s clipboard.

The DNS step can help the infection chain get one step farther before some defenses have enough context to recognize what is happening, as it means fewer forensics to work with.

Flare also discovered an unexecuted Python launcher in the malware package that indicates the developers were experimenting with different payload strategies depending on the victim environment.

A Flare spokesperson tells Dark Reading that “the script is designed to select persistent remote access for systems that appear corporate, while deploying both the RAT and credential and cryptocurrency stealers on systems that appear personal.”

“This suggests the operator may prioritize a quieter foothold on corporate targets, potentially limiting theft activity that could trigger detection,” the spokesperson says.

Chached Commands Lurking in Websites

The second example of this progression comes from Microsoft Threat Intelligence, which on X shared its findings connected to a ClickFix campaign involving a “cluster” of compromised websites. In this case, the user visits a website, and that website pre-fetches a script payload into the browser cache disguised as a PNG file. This happens before the user is instructed to paste malicious code copied to the clipboard.

“When a user is later tricked into executing the malicious command, the cached website content is already on the device, loaded, and ready to be executed,” Microsoft’s post read. “This helps to hide the payload script and helps bypass the character limit of the Run dialog.”

The cached payload then reaches back out for additional PowerShell and later-stage payloads, which EDR can still possibly catch. Still, like the campaign covered in Flare’s research, this attack redesigns the initial ClickFix-to-payload transition to get past the first line of defense.

Defending Against Evolving ClickFix Attacks

Microsoft noted in its post that Microsoft Defender protects against elements across the ClickFix attack chain, and recommends users deploy security protection tools across the web and network, application control, and PowerShell script-block logging.

Flare’s blog includes specific detections for CrocoRat, but Morag also noted the value of prevention in ClickFix attacks, saying “the most effective control is reducing the chance that a copied command becomes executed.”

“Organizations should train users specifically on ClickFix patterns: fake CAPTCHA pages, ‘press Windows+R,’ ‘paste this command,’ and ‘verification failed’ prompts,” he wrote. “Technical controls should restrict or alert on clipboard-to-Run execution patterns where possible, harden PowerShell logging, enable script block logging, and apply application control rules that prevent interpreters from running out of writable directories.”

ClickFix attacks are tricky and pervasive, but as of today, they also largely follow similar templates from a social engineering standpoint. That consistency makes the technique useful for user awareness training.

As for where the technique goes next, Flare says CrocoRat and similar campaigns suggest ClickFix will continue to evolve through convincing lures, familiar-looking commands, and concealed next-stage instructions. “Without speculating about specific methods that could give attackers ideas, I expect more threat actors to adapt this attack vector with their own variations,” the spokesperson says.