ClickFix, FileFix, fake CAPTCHA — whatever you call it, attacks where users interact with malicious scripts in their web browser are a fast-growing source of security breaches.
ClickFix attacks prompt the user to solve some kind of problem or challenge in the browser — most commonly a CAPTCHA, but also things like fixing an error on a webpage.
The name is a little misleading, though — the key factor in the attack is that they trick users into running malicious commands on their device by copying malicious code from the page clipboard and running it locally.
 |
| Examples of ClickFix lures used by attackers in the wild. |
ClickFix is known to be regularly used by the Interlock ransomware group and other prolific threat actors, including state-sponsored APTs. A number of recent public data breaches have been linked to ClickFix-style TTPs, such as Kettering Health, DaVita, City of St. Paul, Minnesota, and the Texas Tech University Health Sciences Centers (with many more breaches likely to involve ClickFix where the attack vector wasn’t known or disclosed).
But why are these attacks proving to be so effective?
Reason 1: Users aren’t ready for ClickFix
For the past decade or more, user awareness has focused on stopping users from clicking links in suspicious emails, downloading risky files, and entering their username and password into random websites. It hasn’t focused on opening up a program and running a command.
Suspicion is further reduced when you consider that the malicious clipboard copy action is performed behind the scenes via JavaScript 99% of the time.
 |
| Example of unobfuscated JavaScript code performing the copy function automatically on a ClickFix page without user input. |
And with modern ClickFix sites and lures becoming increasingly legitimate-looking (see the example below), it’s not surprising that users are falling victim.
 |
| One of the more legit-looking ClickFix lures — this one even has an embedded video showing the user what to do! |
When you consider the fact that these attacks are moving away from email altogether, it doesn’t fit the model of what users are trained to be suspicious of.
The top delivery vector identified by Push Security researchers was found to be SEO poisoning & malvertising via Google Search. By creating new domains or taking over legitimate ones, attackers are creating watering hole scenarios to intercept users browsing the internet.
And even if you were suspicious, there’s no convenient “report phishing” button or workflow to notify your security team for Google Search results, social media messages, website ads, and so on.
Reason 2: ClickFix isn’t being detected during delivery
There are a few aspects of why ClickFix attacks are going undetected by technical controls.
ClickFix pages, like other modern phishing sites, are using a range of detection evasion techniques that prevent them from being flagged by security tools — from email scanners, to web-crawling security tools, to web proxies analyzing network traffic. Detection evasion mainly involves camouflaging and rotating domains to stay ahead of known-bad detections (i.e., blocklists), using bot protection to prevent analysis, and heavily obfuscating page content to stop detection signatures from firing.
And by using non-email delivery vectors, an entire layer of detection opportunity is cut out.
 |
| Like other modern phishing attacks, ClickFix lures are distributed all over the internet — not just email. |
Malvertising adds another layer of targeting to the picture. For example, Google Ads can be targeted to searches coming from specific geographic locations, tailored to specific email domain matches, or specific device types (e.g. desktop, mobile, etc.). If you know where your target is located, you can tailor the ad parameters accordingly.
Along with other techniques, like conditional loading to return a lure appropriate for your operating system (or not triggering at all unless certain conditions are met, e.g. you’re visiting from a mobile OS, or from outside a target IP range) attackers have a way of reaching a large number of potential victims while avoiding security controls at the email layer and preventing unwanted analysis.
 |
| Example of a ClickFix lure built onto a vibe-coded site. |
Finally, because the code is copied inside the browser sandbox, typical security tools are unable to observe and flag this action as potentially malicious. This means that the last — and only — opportunity for organizations to stop ClickFix is on the endpoint, after the user has attempted to run the malicious code.
Reason 3: EDR is the last and only line of defense — and it’s not foolproof
There are multiple stages to the attack that can and should be intercepted by EDR, but the level of detection raised, and whether an action is blocked in real time, is driven by context.
Because there’s no file download from the web, and the act of running code on the machine is initiated by the user, there’s no context tying the action to another application to make it appear suspicious. For example, malicious PowerShell executed from Outlook or Chrome would appear obviously suspicious, but because it’s user-initiated, it’s isolated from the context of where the code was delivered.
The malicious commands themselves might be obfuscated or broken into stages to avoid easy detection by heuristic rules. EDR telemetry might record that a PowerShell process ran, but without a known bad signature or a clear policy violation, it may not flag it immediately.
The final stage at which the attack should be intercepted by any reputable EDR is at the point of malware execution. But detection evasion is a cat-and-mouse game, and attackers are always looking for ways to tweak their malware to evade or disable detection tools. So, exceptions do happen.
