A new ClickFix technique abuses browser cache to stage malware before the victim pastes a short command into Windows Run, PowerShell, or another trusted utility. Microsoft Threat Intelligence, as reported by The Hacker News, observed compromised websites prefetching a payload disguised as a PNG file. The lure then asks the visitor to run a command that locates the cached content, gives it a script extension, and executes it.
What the report is saying
ClickFix is social engineering that turns the target into the execution mechanism. A fake CAPTCHA, browser update, meeting error, or verification page tells the visitor to copy and paste a command. The important change in this campaign is that the full payload need not be present in that pasted command. It was already placed in browser cache. That helps attackers work around the roughly 260-character input limit in the Windows Run dialog while making the visible instruction look less suspicious.
How the infection chain works
Microsoft observed an initial VBScript searching browser-profile files with a selected prefix and comparing their byte lengths to an expected value. It copies the matching cache entry into the temporary directory as a .vbs file, then launches it through wscript.exe while suppressing output. The script collects host information through WMI, retrieves a PowerShell stage, and downloads an additional payload. Later stages can load .NET assemblies in memory and inject code into a legitimate Windows process, such as timeout.exe, to target browser and device credentials.
This does not mean ordinary cached images are inherently malicious. It means cache can become a staging area when an attacker controls a site and persuades a person to execute an instruction. Use of cmd, WScript, PowerShell, and legitimate Windows processes also weakens detection strategies that rely only on a suspicious downloaded executable.
Why this matters
ClickFix succeeds because its story matches routine workplace friction: a CAPTCHA, an authentication prompt, a broken meeting, or a browser problem. The final action is performed by the user in a built-in utility, not by a conspicuous attachment. The source cites a sharp rise in fake-CAPTCHA incidents during 2025. Organizations should not interpret this as a reason to ban every administrative tool; they should reduce the chance that an untrusted webpage can direct users to execute commands outside approved support workflows.
Signals worth investigating
- A web page asks a user to open Run, Terminal, or PowerShell as a verification step.
wscript.exe,cscript.exe, or PowerShell starts after a browser process, particularly from Temp.- A browser reads cache entries and is followed by a newly created VBScript or unusual child process.
- Unexpected RunMRU entries, scheduled tasks, outbound connections, or code injection indicators appear.
- A user reports session loss, credential prompts, or unusual account activity after visiting a lure page.
Practical checklist
- Tell staff that a legitimate CAPTCHA never requires pasting code into a system utility.
- Maintain web, network, and cloud-delivered protections, with a documented process for blocking confirmed infrastructure.
- Enable PowerShell Script Block Logging and process-creation telemetry for parent-child investigation.
- Apply least privilege and appropriate application-control policies to script hosts after testing business impact.
- If a command was run, isolate the endpoint and investigate credentials and persistence; clearing browser history alone is not remediation.
For end users, the most useful rule is simple: a verification prompt should never require copying code into Run, Terminal, or PowerShell. Report the page through the organization’s normal support route. Security controls and user awareness work together here: technical logging helps investigators reconstruct the event, while a clear warning prevents the first execution.
Conclusion
The key risk is the combination of browser-cache staging and a trusted Windows utility used as the trigger. Do not paste commands from CAPTCHA or troubleshooting prompts. Security teams should look for browser-to-WScript or browser-to-PowerShell chains and be ready to contain affected endpoints and reset exposed credentials.
Source
Adapted from The Hacker News, citing Microsoft Threat Intelligence.