The Attack: Payloads Hidden in Plain Sight
Microsoft’s Threat Intelligence team just documented a new ClickFix variant that’s more clever than most. Instead of downloading a malicious payload when the victim runs the “fix” command, the attackers pre-cache the payload in the browser — disguised as a PNG file — then trick the user into copying it from cache to disk and executing it.
Here’s how it works: the victim visits a compromised website that serves a ClickFix lure (fake CAPTCHA, browser error, whatever). The site also pre-fetches a malicious VBScript payload into the browser’s cache, masquerading as an image file. When the victim is prompted to paste and execute the “fix” command, that command doesn’t download anything. It searches the browser’s profile folder for a cached file matching a specific byte size, copies it to %LOCALAPPDATA%\Temp\t.vbs, then executes it with wscript.exe.
No download. No network traffic at the moment of execution. The payload was already on the system, sitting in browser cache. The victim’s “troubleshooting” command just moved it and gave it an executable extension.
Once the VBScript runs, it harvests system info via WMI, downloads a PowerShell script from an external server, executes it, downloads additional stages, loads .NET assemblies into memory, and injects code into a legitimate Windows process (timeout.exe) to steal credentials.
It’s a multi-stage chain, and it works because the initial payload was already on disk before the victim ever ran the command.
Why It Works: Trust and Legitimate Tools
ClickFix attacks are effective because they abuse tools normal people trust. Instead of asking someone to download an unfamiliar executable, they ask them to paste a command into PowerShell or the Windows Run dialog — utilities built into the operating system. The user performs the action themselves, bypassing most security controls that watch for downloads or executable launches from untrusted sources.
The browser cache smuggling variant adds another layer: the payload isn’t downloaded at the moment of execution, so tools watching network traffic or download directories miss it entirely. The malicious file was fetched earlier, disguised as an image, and cached like any other web resource.
This is why signature-based detection struggles. The cached payload isn’t recognized as malicious until it’s renamed and executed. By then, it’s too late.
How FileSure Would Have Stopped It
FileSure Defend operates at the Windows kernel level via a filter driver. It intercepts file operations — open, read, write, create, delete, rename — before they complete. You define rules that specify which programs can perform which operations on which file types. Everything else is blocked.
In this attack, the kill point is the file write operation. The victim’s command attempts to copy the cached payload from the browser profile folder to %LOCALAPPDATA%\Temp\t.vbs. That’s a file write operation creating a .vbs file.
A simple FileSure rule blocks it:
Operation: Create, Write
File name filter: *.vbs; *.ps1; *.bat; *.cmd; *.js; *.wsh
Apply to: All drive types
Exclude programs: (leave empty, or whitelist only specific admin tools if needed)
With this rule active, the copy command fails. The .vbs file never lands on disk. wscript.exe has nothing to execute. The entire attack chain stops at step one.
No PowerShell stages. No downloaded payloads. No credential theft. The evildoer convinced the victim to run a command, but the command couldn’t do what it was designed to do because the file system wouldn’t allow it.
This rule doesn’t require knowing what ClickFix is, or recognizing the specific payload, or updating a signature database. It just says: unauthorized programs cannot write executable script files to this system. The rule worked yesterday, it works today, and it’ll work on the next ClickFix variant that appears tomorrow.
The Broader Pattern
ClickFix attacks have evolved rapidly. Threat actors use fake CAPTCHAs, browser errors, meeting issues, and now AI-generated summaries with invisible prompt injection to trick users into running malicious commands. The delivery mechanisms change, but the underlying requirement doesn’t: the malware has to write files to disk before it can execute.
According to CrowdStrike, fake CAPTCHA incidents increased 563% in 2025. The attacks work because they feel like normal troubleshooting. But every variant — cache smuggling, clipboard manipulation, prompt overdose — hits the same technical constraint. Code has to land on the file system before it runs.
Controlling file operations at the kernel level stops the attack upstream, before execution, before encryption, before exfiltration. You don’t need to recognize the threat. You just need to control what’s allowed to happen to your files.
Ready to see how it works? Start a free 21-day trial of FileSure Defend at bystorm.com. Install it, run our test file, and watch it get blocked in real time. No credit card required.
Source: ClickFix Smuggles Payloads Through Browser Cache to Bypass Windows Run Limits
Category: Threat Intelligence
Tags: clickfix, browser cache smuggling, vbscript, social engineering, kernel filter driver, file system security, zero-day defense
