A newly observed ClickFix campaign is using a more sophisticated delivery technique in which malicious scripts are pre-fetched into the victim’s browser cache and disguised as image content before the user executes anything. Microsoft Threat Intelligence says the compromised website loads a script payload into the browser cache while presenting it as a PNG file. When the victim later follows the familiar ClickFix instruction to open the Windows Run dialog, paste a command and press Enter, the command does not need to download the full malicious payload from the Internet. Instead, it searches the local browser cache, copies the already-staged content into a temporary VBScript file and executes it.

That change solves a practical problem for ClickFix operators. The Windows Run dialog accepts only a relatively short command string, with input effectively constrained to roughly 260 characters. Traditional ClickFix campaigns therefore need to squeeze download and execution logic into a very small command or use an initial short command that retrieves a larger second stage. By placing the real script into the browser cache ahead of time, the attackers can keep the pasted command short while still executing a much larger and more capable payload.

The attack chain observed by Microsoft uses a VBScript staged inside the Firefox profile cache. The pasted command launches cmd.exe, recursively enumerates files beginning with f_ under Firefox profile directories such as %LOCALAPPDATA%\Mozilla\Firefox\Profiles, and compares their byte sizes against an expected value. Once the matching cache entry is identified, the command copies it to %LOCALAPPDATA%\Temp\t.vbs and executes it using wscript.exe. Unlike earlier cache-smuggling techniques that searched the cached file for a specific marker, this variant identifies the payload by its expected size.

The technique is clever because the payload is already on the device before the visible execution stage begins. From the user’s perspective, they are simply following a fake troubleshooting or verification instruction. From the attacker’s perspective, the browser has already performed the delivery step. The user’s pasted command merely converts the cached object into an executable script.

That has implications for detection. Security products that focus heavily on the moment a PowerShell or Run command retrieves a remote payload may see less obvious network activity in the initial execution stage because the first substantial script is being recovered from local browser storage. The malicious content arrived earlier as apparently ordinary web content. The important event is therefore not only “what did PowerShell download?”, but also “what was staged into the browser cache immediately before the suspicious command ran?”

Once executed, the VBScript gathers host information through Windows Management Instrumentation and retrieves an additional PowerShell script from attacker infrastructure. The PowerShell component then downloads further stages, including a file identified as cab.dat, and executes the downloaded content in a hidden window. The chain eventually loads .NET assemblies into memory and injects code into a newly created legitimate Windows process, timeout.exe, with the goal of harvesting browser and device credentials.

The injected process subsequently launches PowerShell again to retrieve another memory-resident stage and establish outbound connections to additional attacker infrastructure. This progression shows that browser-cache smuggling is not the final payload. It is simply a more effective initial staging mechanism that gets the attacker past the awkward limitations of the Windows Run dialog and into a multi-stage malware chain.

The conceptual flow is therefore: compromised website → malicious script silently cached as PNG-like content → fake CAPTCHA or troubleshooting lure → victim opens Windows Run → short pasted command searches browser cache → cached payload copied to t.vbs → VBScript executes → WMI reconnaissance → PowerShell stage → additional in-memory payloads → process injection → credential theft and command-and-control.

This is a useful evolution of ClickFix because it shows that attackers are optimizing the technique rather than abandoning it. The original strength of ClickFix was always psychological: persuade the victim to execute the attacker’s command voluntarily. The new cache-smuggling variation improves the technical side of that model by reducing how much malicious content must be placed directly in the clipboard command.

ClickFix works because it moves the security boundary away from exploitation and toward user-assisted execution. There is no need to exploit a browser vulnerability, bypass Windows authentication or find an unpatched operating-system flaw. The attacker persuades the victim to use trusted system utilities against themselves. PowerShell, Windows Run, cmd.exe, wscript.exe, WMI and legitimate Windows processes all become components of the infection chain.

The user is therefore not merely clicking a malicious link.

They are effectively acting as the attacker’s execution broker.

That difference explains why ClickFix can bypass controls designed to stop conventional malware delivery. A security product may block suspicious executables arriving through email, but the victim is executing a command through Windows Run. An application may prevent automatic script execution from a webpage, but the victim copies the instructions into a trusted local utility. A browser may isolate downloaded content, but the attacker now abuses the browser cache itself as a staging area.

This latest campaign illustrates another important defensive principle: local browser artifacts can become part of malware delivery infrastructure. The cache has traditionally been viewed as a performance mechanism and, from a security perspective, mainly as a forensic source. In this attack, it becomes an intentional payload store.

That changes what endpoint telemetry is useful. Security teams should correlate browser activity with suspicious process execution rather than treating those events as unrelated. A sequence such as browser visits compromised page → unusual cache file appears → Windows Run command executes → cmd.exe searches browser profile directories → cache file copied to Temp → wscript.exe launches → PowerShell starts is far more suspicious than any individual event examined alone.

The use of file size as the payload locator is also noteworthy because it avoids embedding an obvious signature or marker in the Run command. The attacker only needs to know the expected size of the staged cache object. That reduces the amount of recognizable malicious content appearing in command-line telemetry and makes simple string-based detection less effective.

This is a good example of why behavioral chains are more durable than individual indicators. File names, payload sizes and domains can all change quickly. The underlying behavior is harder to disguise:

browser cache content becomes script → script launches interpreter → interpreter retrieves additional stages → code is injected into another process.

Those transitions are where defenders gain the most reliable visibility.

The campaign also continues the broader ClickFix trend of abusing fake CAPTCHA, verification and troubleshooting workflows. Users have been trained for years to resolve web problems by clicking refresh, accepting permissions, completing verification prompts or following browser instructions. Attackers exploit that habit by presenting an apparently minor technical problem and providing an immediate “fix.”

That is psychologically effective because the user feels they are resolving an inconvenience rather than making a security-sensitive decision.

A message saying:

“Download and execute this unknown program”

naturally creates suspicion.

A message saying:

“Press Win + R, paste this quick fix and press Enter”

looks more like technical support.

The operating-system tools are familiar, which reduces anxiety.

Unfortunately, familiarity is not a security control.

Microsoft’s recommendation remains extremely simple and probably more useful for ordinary users than any detailed explanation of browser-cache internals:

A CAPTCHA should never require someone to run a command.

No legitimate CAPTCHA, browser verification, video-conferencing fix, Cloudflare-style check or website troubleshooting prompt should ask users to open Windows Run, PowerShell, Command Prompt, Terminal or another command interpreter and paste instructions provided by the webpage.

That principle is increasingly important because ClickFix has expanded far beyond one cybercrime campaign. The technique has been adopted by financially motivated actors and state-linked groups alike. The Hacker News notes recent use by North Korea-linked Stardust Chollima/BlueNoroff and Russia-linked Sandworm, demonstrating that the same basic social-engineering pattern can support very different objectives.

For organizations, security awareness alone is not enough. Users will eventually make mistakes, particularly when the lure appears during a normal business task. Technical controls should therefore reduce the consequences of that mistake. Microsoft recommends web and network protection, application control, cloud-delivered protection and PowerShell script-block logging, while defenders should monitor the RunMRU registry key, suspicious WScript or PowerShell child processes and newly created scheduled tasks.

Application control can be especially effective in environments where ordinary users have no legitimate reason to run VBScript or arbitrary PowerShell scripts. The campaign relies on wscript.exe, cmd.exe, PowerShell and later process injection. Restricting these components does not eliminate social engineering, but it forces attackers to find another execution path.

Organizations should also consider browser-cache activity when investigating ClickFix incidents. Clearing browser cache is not a substitute for endpoint remediation after code has executed, but examining cached objects can help reconstruct the initial payload and determine what content was staged before the victim ran the command.

PowerShell logging remains important because the later stages still rely heavily on PowerShell even though the first payload comes from cache. Script-block logging can reveal decoded commands and downstream activity that is not obvious from the initial Run command.

The campaign also highlights a broader problem with security controls based primarily on download events. Traditional malware thinking assumes that the dangerous event happens when a malicious executable crosses from the Internet onto the endpoint. Modern attacks increasingly blur that boundary. Payloads may arrive inside browser caches, HTML, images, archives, cloud documents, temporary storage or legitimate application data before later being converted into executable form.

The useful question is therefore not simply:

“Was a malicious file downloaded?”

It is:

“Did web content later become executable code?”

That is a much stronger detection model.

The browser-cache approach also demonstrates how attackers combine otherwise harmless system behaviors into a malicious chain. A browser storing cached data is normal. cmd.exe reading files is normal. Copying a file to %TEMP% is normal. wscript.exe executing a VBScript is legitimate functionality. PowerShell performing WMI queries is also legitimate. Each event can appear ordinary in isolation.

The maliciousness exists in the sequence and context.

That is becoming a recurring theme across modern attacks.

Defenders who rely heavily on binary reputation or individual-event signatures will struggle when attackers increasingly use legitimate operating-system components to assemble the attack dynamically.

The response therefore needs to become more contextual:

What process launched this tool?

What happened immediately before it?

Why is this browser cache file suddenly being executed as VBScript?

Why did a Run command enumerate Firefox cache entries?

Those questions expose intent better than asking whether wscript.exe itself is malicious.

The browser-cache technique is also useful to attackers because it separates delivery from execution in time. The malicious payload may arrive while the victim is simply viewing the compromised webpage. The execution happens later when the user follows the ClickFix instruction.

This separation can frustrate investigation because the security event that matters may have occurred minutes earlier in a completely different process.

Defenders therefore need enough telemetry retention and cross-process correlation to connect the browser session with the later command execution.

The attack demonstrates a wider trend in ClickFix development. The basic psychological trick remains stable, but the technical mechanisms surrounding it continue to evolve. Attackers have used direct PowerShell commands, clipboard manipulation, malicious archives, custom GPTs, compromised websites, blockchain-based lure infrastructure and now browser-cache staging.

The innovation is not in convincing users to paste commands.

Attackers already know that works.

The innovation is in making the command shorter, less suspicious, more reliable and more difficult for security controls to analyze.

That is exactly what browser-cache smuggling provides.

The current chain can be summarized as: compromised website → cached script disguised as PNG → fake verification instructions → user pastes short Run command → browser cache searched by file size → cached object becomes t.vbs → VBScript gathers system data → PowerShell downloads additional stages → .NET payloads execute in memory → legitimate timeout.exe receives injected code → browser and device credentials targeted → secondary in-memory stage establishes outbound C2.

The most useful lesson for defenders is therefore not to obsess over the PNG disguise or one particular cache filename.

Those details will change.

The durable indicator is the unusual transition:

browser data → script file → scripting engine → PowerShell → injected process.

And for users, the rule remains much simpler:

If a website tells you to paste something into Run or PowerShell to prove you are human, the website has already failed the humanity test.

A new type of ClickFix attack is using compromised websites to trick users into executing a malicious payload cached in a web browser's cache. "Instead of downloading and executing remote payloads like the typical attack pattern, in this attack, the websites pre-fetch a script payload into the browser cache disguised as a PNG file," the Microsoft Threat Intelligence team said in a post on X.

Source: ClickFix Smuggles Payloads Through Browser Cache to Bypass Windows Run Limits via The Hacker News — published 06 Oct 2026.