What happened?
In a recent post on X, Microsoft Threat Intelligence highlighted an evolution of ClickFix in which a cluster of compromised websites concealed a malicious script within a PNG image file downloaded to the browser cache. Microsoft did not publicly attribute the campaign to a specific threat actor.
ClickFix attacks typically use a fake CAPTCHA, browser update or technical error to persuade users to copy and paste a supposed “fix” into Windows Run, PowerShell or another system utility. In this campaign, however, the initial payload is already present on the device - the PNG file acts as a carrier, with the visible image helping the file appear benign while the concealed script can be recovered from the browser cache and executed locally. The user-supplied command locates the cached file by its expected size, copies it to a temporary folder with a Visual Basic Script (.vbs) extension and executes it. Once running, the script gathers device information, retrieves additional components and injects code into running processes to steal browser credentials and other sensitive information from the device.
This use of steganographic concealment represents a new way of staging larger and more complex scripts locally, allowing the attacker to use a more capable script than could be entered directly into the Windows Run dialogue. This also avoids a separate external download call for the initial script at execution time, and delays presenting the victim or security tooling with an obviously suspicious script extension.
So what?
The PNG technique is novel because it moves the initial malicious script into a file type and location that can appear routine; recovering the script from the browser cache reduces the need for a visible follow-on download at the moment of execution, limiting some network telemetry and avoiding an obviously suspicious extension during the delivery stage. This does not make the activity invisible, but it can weaken controls or investigations focused mainly on downloaded scripts and executables.
ClickFix is not a new technique, but it remains relevant because it does not depend on a single lure, command or delivery method. It is an adaptable social-engineering technique rather than a fixed technical exploit; as defenders learn to detect one pattern, attackers can alter the lure, file format, staging location or command sequence. The approach may change, but ultimately compromise still relies on persuading a user to run an attacker-provided instruction. Clear training therefore remains essential, particularly around fake CAPTCHA prompts and any website that asks users to open a system utility, paste a command or run a “fix”.
The scale of this activity reinforces its continuing relevance. CrowdStrike has reported a 563% increase in incidents involving fake CAPTCHA lures during 2025. New delivery methods should therefore be treated as an evolution of an established threat, not as an isolated technique.
What should I do?
Organisations should address both the technical and human elements of the risk. Restricting the execution of scripts staged through otherwise ordinary browser content and hunting beyond conventional download events are only half the challenge, as user education is equally important - employees should understand that a legitimate CAPTCHA or verification prompt will never require them to run code.
- Warn employees about fake fixes: Train staff to recognise fake CAPTCHAs, browser updates and repair prompts. Users should not paste commands from verification prompts into Windows Run, Terminal or PowerShell, and should treat any such request as a potential initial access attempt.
- Apply recommended protections: Enable cloud-delivered, web and network protection, and use application control to restrict untrusted scripts and reduce the ability of user-initiated commands to launch the attack chain.
- Make suspicious prompts easy to report: Encourage employees to stop and contact IT through a trusted channel when a website asks them to open a system utility or run a command. Anyone who has followed the instructions should report it immediately so the security team can investigate and contain the activity.
- Hunt beyond download events: Review browser activity, the RunMRU registry key, unusual WScript or PowerShell child processes, files copied from browser caches and scheduled tasks. The absence of an obvious script download should not be treated as evidence that no payload was delivered.
- Enable script visibility: Turn on PowerShell script-block logging and retain relevant Windows Script Host records so investigators can identify suspicious scripts and multi-stage execution, including payloads recovered from locally cached image files.