Fake Codex installer outranks OpenAI in Google ads, then asks for a paste
Cato says a sponsored result for "codex macos download" leads to a Google Sites clone whose Terminal command strips quarantine flags and stages an AMOS-linked payload.
The Product Desk
What happened
- Cato CTRL published details of a macOS campaign built around a fake OpenAI Codex installer that ends with the victim pasting a command into Terminal.
- The pasted command opens with a plausible npm install string, then decodes a Base64 URL and pipes a fetched script into zsh.
- Cato attributes the delivery framework to Atomic macOS Stealer on the basis of loader URLs, telemetry, staging paths and attribute stripping.
Why it matters
- constraint Verification by visiting the link mostly fails: the live lure hides at /codexx/, the guessable /codex/ path answers with a clean product page, and non-macOS clients get benign content, so a manual...
- exposure Because the loader clears extended attributes before launching /tmp/helper, the user never meets the quarantine warning that would otherwise be their last chance to stop.
- decision Teams now have to decide whether install commands for developer tooling come from a controlled internal source or from whatever a search engine sells the top slot to.
- precedent Microsoft's Aug. 5 case, where lures moved behind browser-fingerprinting gates, marks the likely next step for this operator and would leave defenders with even less to reproduce.
Every surface the victim touches before the malware lands belongs to someone with a good reputation. The entry point is a paid Google search result that sits above OpenAI's own listing for queries such as "codex macos download" [3]. The landing page is on Google Sites and reproduces the Codex download portal down to the macOS and Linux buttons [4]. The attacker's live content arrives inside an iframe that Cato says is probably routed through a Google static-content proxy [1]. Count the hops and three of them are Google-operated properties [16].
That last one is the operational detail. Cato found no malicious code on the Google Sites page itself, so the page a reviewer inspects can stay unchanged while the ClickFix instructions behind the iframe are swapped out [1]. The lure is decoupled from the hosting reputation it borrows.
The command the page asks for opens with a plausible npm install string for Codex, then decodes a Base64 URL and pipes a retrieved script into zsh [6]. Stage one is padded with dead code and unused variables around an encoded blob it hands to eval, and stage two's first act is a request to an attacker endpoint carrying event=pasted [7]. That is conversion tracking. The operators learn how well the lure copy performs before they learn whether the payload ran.
What follows is ordinary. The script pulls the final payload to /tmp/helper, runs xattr -c to clear its extended attributes, makes it executable and launches it, and clearing those attributes removes the download quarantine metadata that would normally put a warning in front of the user [8]. Nothing was exploited. The user supplied the privilege by typing past it. Cato ties the framework to Atomic macOS Stealer on loader URL structure, the telemetry request, the /tmp/helper staging path, the attribute removal and update-themed payload URLs, calling the match strong without naming the final binary [10][11]. It ships as a universal Mach-O, so Apple Silicon is no barrier [11].
The evasion is aimed at whoever checks. The live ClickFix page sits at /codexx/ while the obvious /codex/ path returns a harmless product page, and non-macOS visitors are served benign content too [5]. An analyst who guesses the intuitive URL, or looks from a Linux box, sees a clean site. Cato's own conclusion is that no single stage reliably exposes the attack and detection depends on correlating search delivery, embedded content, Terminal execution and outbound activity [14]. That is four telemetry sources to join, on the one class of endpoint where pasting shell commands is routine work.
Cato notes that several campaigns this year have dressed delivery in AI developer tooling [15]. The artifact worth controlling is the install instruction itself: if the canonical command for a tool lives in an internal document and nowhere else, a search ad has nothing to sell. Blocking hosts is the slower track. The loader has already been reworked between infrastructure sets, with early samples compressing and Base64-encoding the second stage and newer ones using an AES-encrypted gzip container whose key is rebuilt from variables scattered through the script [9], and Cato says it blocked the reused iframe host while the operators keep rotating domains and payload locations [13].
What to watch
- Whether payloads appear for the Linux or Windows buttons on the cloned portal, since Cato observed delivery only for macOS.
- Whether Google ad review and Sites takedowns remove clones faster than the operators rotate domains and payload locations.
- Whether this operator adopts the browser-fingerprinting gates Microsoft described on Aug. 5, which would push the lure further out of researchers' reach.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption34
- Hype gap+12
- Incentives66
- Confidence57
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The Google Sites page carries no malicious code of its own; attacker content loads inside an iframe, probably routed through a Google static-content proxy, and the split lets operators refresh the ClickFix content without touching the Google Sites page victims see.
- [2]
Cato Networks' Cato CTRL threat research team detailed a macOS attack campaign built around a fake OpenAI Codex installer, ending with the victim opening Terminal and pasting a command that runs the malware, the social engineering pattern known as ClickFix.
- [3]
The campaign begins with a sponsored Google search result for queries such as "codex macos download"; the ad sits above OpenAI Group PBC's own listing.
- [4]
Clicking the ad leads to a page on Google Sites that copies the Codex download portal, down to the macOS and Linux buttons; Cato observed payload delivery only for macOS.
- [5]
Cato mapped three infrastructure sets; the live ClickFix page sits at /codexx/ while the more obvious /codex/ path returns a harmless product page, and non-macOS visitors were served benign content, so an analyst or scanner requesting the intuitive path may never be served the attack.
- [6]
The fake installer walks the user through opening Terminal and pasting a command that starts with a plausible npm install string for Codex, then decodes a Base64 URL and pipes a remotely retrieved script into zsh.
- [7]
The first stage is a shell-script loader padded with dead code and unused variables around an encoded blob it decodes and runs through eval; the second stage sends telemetry before anything else, a request to an attacker endpoint carrying event=pasted, recording that someone ran the command.
- [8]
The script pulls the final payload down to /tmp/helper, clears the file's extended attributes with xattr -c, makes it executable and launches it; stripping those attributes removes the download quarantine metadata that would normally put a warning in front of the user.
- [9]
The loader has been reworked between infrastructure sets: early samples compressed and Base64-encoded the second stage, while newer ones use an AES-encrypted gzip container and rebuild the decryption key from several variables scattered through the script.
- [10]
Cato ties the delivery framework to Atomic macOS Stealer (AMOS), with overlap covering the loader URL structure, the telemetry request, the staging path in /tmp/helper, the removal of extended attributes and update-themed payload URLs.
- [11]
Researchers described the AMOS match as strong and consistent with AMOS delivery activity without naming the final binary outright; the payload is a universal Mach-O, so it runs on Intel and Apple Silicon Macs.
- [12]
Microsoft documented a related macOS ClickFix operation on Aug. 5 that had shifted from openly served lures to browser-fingerprinting gates showing malicious content only to likely targets.
- [13]
Cato said it has blocked the reused iframe host behind the newest Google Sites lure it found, and that it is still watching the operators rotate domains and payload locations.
- [14]
The report said "No single stage reliably exposes the attack", and that detection depends on correlating search delivery, embedded content, Terminal execution and outbound activity.
- [15]
Several campaigns tracked this year have dressed malware delivery in artificial intelligence developer tooling.
- [16]
Three of the surfaces in the delivery chain before the payload are Google-operated: the search ad platform, the Google Sites landing page, and the static-content proxy Cato believes serves the iframe.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- siliconangle.comFake Codex installer tricks Mac users into pasting malware, Cato finds
1 article · August 24, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- ClickFix-Style Social EngineeringFollow
- macOS MalwareFollow
- Search Ad MalvertisingFollow
- Detection Engineering and EvasionFollow
- Commodity InfostealersFollow
- AI Developer Tooling as Malware LureFollow