The macOS malware that exploits nothing: you paste it in yourself

On 6 August, Huntress published its teardown of a Go-based credential stealer for macOS. They found it in June, during a retrospective hunt, inside a Mac they were already monitoring: it had been there for about three months. What makes the case interesting is not the binary, which is the usual thing. It is that there is no vulnerability anywhere in the chain. No CVE to look up, no minimum version to reach, no patch to apply on Tuesday. There is a web page dictating a command to a person, and a person pasting it into Terminal.

The technique has had a name for a couple of years — ClickFix — and it was born on Windows: the fake CAPTCHA, the "press Win+R and paste this to prove you are human". Against macOS it is not new either: Microsoft itself documented a campaign using fake Mac utility lures back in May. What changed in August is that the infrastructure learned to hide. One day before the Huntress report, on 5 August, Microsoft Threat Intelligence published its analysis of more than 250 domains set up to serve these lures, with a gate in front deciding who gets to see them.

The first thing the command does is not stealing

Huntress publishes the full command, and it was written by somebody who thought about what happens afterwards. The whole thing runs inside a background subshell with output redirected to /dev/null: it downloads a script with curl from an IP address, runs it with bash and deletes the temporary file. Then come four instructions that steal nothing: clear, a printf with the escape sequence that wipes the window scrollback, a history -d that removes the just-executed line from history, and an fc -p /dev/null that detaches the history file.

Translated: when the person looks up from the screen, the window will be clean and there will be nothing to show. If tomorrow that person gets suspicious and calls their IT support, the first thing IT will do is ask them to open Terminal and check what they pasted. They will not find it. That wipe is aimed at your response process: at the conversation you will have the next day.

Gatekeeper does not fail: it is not invited

This is where the argument we have been living with for years falls apart: "that does not happen on a Mac because Apple signs everything". The downloaded script profiles the machine with ioreg and system_profiler, checks uname -m to tell Apple Silicon from Intel, pulls down the matching Mach-O binary and drops it into a purpose-made folder inside ~/Library/Caches/ under a name that mimics a system service. Then it makes it executable and runs xattr -d com.apple.quarantine on it.

That extended attribute, com.apple.quarantine, is the mark the browser and Finder put on anything downloaded from the internet, and the one that triggers the notarisation check and the "are you sure you want to open this?" dialog. And here is the detail that completes the picture: curl does not set that mark. Anything pulled down through the shell is born without it, so that xattr -d is a belt over braces nobody was wearing. Gatekeeper was not bypassed and did not fail: it never came into play, because the entry path was not a download opened with a double click, it was your shell doing what you told it.

Persistence follows the same line. The binary ends up in another cache folder named after an Apple service and registers itself with launchctl bootstrap gui/501, pointing at a LaunchAgent called com.apple.softwareupdated.plist. In other words: your Mac's background items list now contains something named almost exactly like the system software updater. And to escalate, an osascript prompt asking for the password with the look of an ordinary macOS dialog: every piece is a native tool used exactly as documented. The binary is signed, too — on Apple Silicon the kernel runs nothing unsigned — but an ad-hoc signature is generated by the compiler itself and identifies nobody. What this binary never passes, because nobody asks it to, is Apple's notarisation.

DRAIN_PCT: the variable that says a lot

The part that made the headlines is the function Huntress found inside the binary, called DRAIN: it looks for Bitcoin, Litecoin, Dogecoin, Monero, Ethereum and XRP wallet addresses, checks the on-chain balance and, if there are funds, pulls a destination address either from a list embedded in the binary or from its command-and-control server and transfers the value there. With one detail the analysts flag as new: a DRAIN_PCT variable that lets them take a percentage rather than the whole balance.

A thief who takes 100% is discovered that same afternoon. One who takes a slice can pass for an app glitch, an odd fee, a "huh, that is strange". The difference between stealing and milking is exactly the difference between a one-day incident and a three-month one. And the honest caveat, which Huntress itself makes: the wallets in the binary had no publicly recorded transactions. We are not measuring loot here, we are measuring capability.

In a company, the crypto is not the expensive part

If the infected Mac belongs to a company that never touches cryptocurrency, it is easy to read this and file it away. That would be a mistake. The list of what the same binary takes before it ever reaches a wallet is the usual one: browser-stored passwords, the Keychain, cached cookies and system credentials. The session cookie is the prize, for the reason we have already written about here: a session already issued never asks for the second factor again. Whoever replays it is not authenticating; they are being you.

Which leads to the practical consequence most people skip when cleaning a machine: changing the password closes nothing. Unless you revoke the sessions and review connected applications, the attacker stays inside with the token they already had while the user congratulates themselves on the new password.

"I would have noticed" is not a control

Microsoft's 5 August report is the one to show anyone who answers like that. In front of the lure pages sits a gate of roughly 2.5 KB of JavaScript that inspects the platform string reported by the browser, screen and window dimensions, WebGL signals, the timezone, whether the page is inside an iframe and whether the device has touch support. And it carries two analyst-specific tripwires: a counter that detects an open developer console, and a codec check using canPlayType("video/mp4"), aimed at catching headless browsers — the ones automated analysis systems run.

If the gate decides you are a researcher, it does not show you the attack: it serves something else. The victim sees the malicious page; the person who would go and check it does not. On top of that comes the wrapper: pages imitating GitHub downloads with a forged "verified publisher" badge. The chain Microsoft followed through that gate ended in AMOS, the most widespread macOS stealer family of recent years, and the wider campaign also distributed MacSync.

It is the same pattern we saw with hotel Wi-Fi networks tampered with to steal Microsoft 365 sessions: the target is no longer your server, it is the stretch of time when your people are out of the office with a laptop and in a hurry.

What Apple did in March, and why it is not enough

Credit where it is due: Apple saw this coming and acted. In macOS 26.4, in March 2026, a new warning appeared when pasting certain commands into Terminal. The wording is blunt — "Possible malware, Paste blocked" — and it explains that scammers often ask people to paste instructions into Terminal, and that the Mac has not been harmed. It is a well-designed defence, placed exactly where the problem happens, and it landed before the August reports.

And it still does not close the matter, and Apple's own support document shows why. There is not one warning, there are two levels. The soft one — the "Possible malware" prompt — comes with a button to paste anyway, and someone who has spent twenty minutes fighting an "error" blocking a document will press it. The hard one blocks with no way through, but it fires when what you pasted matches already-known malware, which is precisely what the next campaign's command will not be. And there is a third nuance, the most interesting one: Apple explains that the warning is aimed at people who do not regularly use Terminal and are pasting something that reached them by email, chat or a similar source. It protects the person who never opens it. Not the administrator who has it open all day, who is the one who can do the most damage by slipping.

The three months are the headline

Back to the beginning, because the uncomfortable fact in the Huntress case is not DRAIN. It is that the Mac was monitored and the thing surfaced in a retrospective hunt, months after it got in. Nobody appears to have noticed at the time. You do not fix that by buying a better antivirus: antivirus decides at the instant it sees the file and, if it does not recognise it at that instant, it lets it through; whether it looks again depends on somebody running another scan once the signature exists.

What saved this case was the other half: retained telemetry — which process launched which, what got registered in login items, what left over the network — and somebody asking questions of it weeks later. That is the difference between detection and hunting, and it is exactly what we build when we talk about EDR and MDR: not just the agent that blocks, but the history that lets you ask "has this been here since March?" and get an answer. Without that history, the honest answer to that question is "I do not know", and you cannot close an incident with "I do not know".

What we would do on Monday

None of this needs new budget. It needs somebody to sit down for a morning:

• Count the Macs. Not the ones in the inventory: the ones that exist. The Mac fleet tends to live in management, design and marketing, bought outside the usual channel, and it ends up outside the console holding everything else. Nobody manages it, so nobody looks at it.
• Check the security agent is on them too. Plenty of EDR rollouts cover the Windows fleet and leave Macs "for later". Later was March.
• Look at login items and agents. launchctl print gui/$(id -u) and the contents of ~/Library/LaunchAgents. What you are looking for will not be called "malware": it will be named after something from Apple. Look at the path before the name: an executable inside ~/Library/Caches/ has no business being there.
• Say the sentence, just one, at the next meeting. No website, no support chat and no phone call will ever ask you to paste a command into Terminal. Ever. It is the only rule you need and it fits on one line.
• If somebody already pasted it, order matters. Isolate the machine from the network before touching anything, then revoke sessions and rotate whatever lived in the Keychain and the browser. Reinstalling the Mac without revoking sessions leaves the attacker inside your cloud, looking at a clean machine.

And one thing we will not say just because it would sound good: that you must train people so they do not fall for it. Training helps. But the lure Huntress describes arrived by email with a link, and the pages Microsoft analysed imitate legitimate downloads complete with a verified badge. Designing a company's security on the assumption that nobody will ever slip is not training, it is optimism. What you plan is the afterwards: that when somebody does slip, you know the same day and not in June.

Managed detection and response across the whole fleet — Windows, Linux and the Macs management bought too — is what we run under EDR and MDR, as part of everyday cybersecurity work. If you do not know how many Macs are in your company or who is watching them, get in touch and we will count them with you.