Smuggling Code: How ClickFix Uses Browser Cache to Beat Windows Run Limits

illustration of browser cache smuggling ClickFix attack

ClickFix attacks have evolved from simple social-engineering lures into highly creative delivery mechanisms that turn a user’s own system into the execution environment. Recent Microsoft telemetry describes a variant that stages malicious scripts inside a victim’s browser cache—disguised as innocuous PNG files—and then convinces the user to paste a short command that triggers execution of that cached payload. By hiding the payload in cache entries and later reconstituting it on disk, attackers can sidestep character-length constraints in the Windows Run dialog and evade many conventional download-detection signals.

How the cache-smuggling ClickFix works

Microsoft observed compromised sites pre-fetching a script into the browser cache while labeling it as a PNG. Instead of pulling an executable from a remote host at runtime, the attack instructs the victim to paste a command into a trusted tool (e.g., the Run dialog). That command runs a small VBScript that scans the browser profile cache for cache entries with a specific filename pattern and exact byte length, copies a size-matching cache entry to %LOCALAPPDATA%Tempt.vbs, and runs it with wscript.exe. Copy output and errors are suppressed, and the payload thus executes as if it were a local script file.

From there the observed chains typically use VBScript to gather host information (via WMI), fetch an external PowerShell script (v.ps1 from cocojambo[.]us[.]com/alfa in the case Microsoft documented), and launch successive, in-memory stages. The intermediate PowerShell payload downloads a cab.dat file, reads and executes its contents in a hidden window, and ultimately loads .NET assemblies into memory. Those assemblies inject code into a legitimate process (timeout.exe) to harvest browser and device credentials, spawn additional PowerShell to pull a secondary stage from capsysnet[.]vg, and connect out to infrastructure such as ciliabula[.]cc.

Why this technique defeats Windows Run limits and detection

The Windows Run dialog truncates inputs at roughly 260 characters, which limits how much attacker-controlled code can be passed directly via paste-and-execute lures. By pre-staging the heavy payload inside the browser cache and using a tiny oneliners to reconstruct and execute it, adversaries effectively bypass the Run character limit while minimizing observable network artifacts at the time of execution. Because the payload originates from the local cache, defenses that focus on download events or network indicators may miss the critical staging phase. Additionally, ClickFix chains often rely on built-in tools (Run, PowerShell, wscript), which lowers user suspicion and makes behavior-based detection harder when it’s framed as “troubleshooting.”

Real-world campaigns, threat actors, and historical context

Cache staging in ClickFix is not entirely new: in October 2025 Expel documented a cache-smuggling chain that delivered a malware-laced ZIP, later attributed to a red-team exercise by Intrinsec. But the technique has become more prolific and diverse. CrowdStrike reported dramatic growth in fake CAPTCHA lures through 2025, and analysts have tied ClickFix campaigns to nation-state clusters as well: Microsoft and CrowdStrike linked activity to North Korea–aligned Stardust Chollima (BlueNoroff) and to Russian-aligned Sandworm in separate campaigns that used paste-to-Run and PowerShell/VBScript chains to deploy loaders and RATs (GeniexLoader and GeniexRAT were observed in one case). CTM360 has identified thousands of compromised sites hosting fake pages; attackers are even using blockchain-based EtherHiding to rotate lure hostnames on-chain without altering compromised sites directly. CloudSEK demonstrated another amplification vector: weaponizing invisible HTML/CSS tricks and prompt-overdose to make AI summarizers generate attacker-controlled ClickFix instructions for downstream distribution.

Why ClickFix works psychologically and operationally

ClickFix thrives because it blends social engineering with legitimate OS tooling. Users face CAPTCHA prompts, browser errors, and broken meetings regularly; a message asking them to “paste this command to fix the issue” fits into expected troubleshooting behavior. Unlike a suspicious executable attachment, a pasted command that invokes PowerShell or Run feels less obviously malicious. Tooling commoditization—phishing kits, automation scripts, and prebuilt lure pages—has reduced attacker effort and increased campaign velocity. Finally, rapid infrastructure rotation and minimal local download signals help these campaigns evade traditional indicator-based defenses.

Detection and mitigation guidance

Microsoft recommends layered protections: cloud-delivered web filtering, network protections, application control, and PowerShell script-block logging. Detection efforts should go beyond download events to include hunting for suspicious browser cache activity, anomalies in RunMRU registry keys, wscript and PowerShell child processes, and unexpected scheduled tasks. Practical controls and user guidance include:

Block or warn on attempts to paste commands into privileged utilities; educate users that CAPTCHAs or browser prompts should never request them to run code.
Implement application control to restrict script hosts (wscript.exe, wmic, powershell.exe) from executing unapproved scripts.
Enable PowerShell logging (script block logging) and forward logs to a central SIEM for real-time analysis.
Harden web infrastructure and monitor for compromised sites (CTM360 reported thousands of active lure pages).
Apply detection rules for processes that read browser profile folders and copy/rename cache artifacts to %LOCALAPPDATA%Temp.
Treat long-lived or in-memory-only execution patterns as suspicious and investigate parent-child process trees tied to explorer, Run, or timeout.exe–like binaries.

Conclusion

The use of browser cache smuggling to stage payloads demonstrates how attackers adapt existing features and user behaviors to overcome defensive constraints like the Run dialog’s length limit. ClickFix remains effective because it weaponizes trust in standard OS utilities and human willingness to “fix” a problem. Organizations should combine user education with platform hardening, robust logging, and behavioral hunting focused on cache access patterns and script execution to interrupt these increasingly creative chains.