Security3 publishers2 min readPublished
Attackers bought the top result for "codex macos download" and kept the payload swappable
Cato Networks says a sponsored ad outranked OpenAI's own page, sending macOS developers to a Google Sites portal whose ClickFix content lives on infrastructure Google never hosted.
The Watch · Security desk
What happened
- Cato Networks found a fake OpenAI Codex download portal reached through a sponsored result that sat above OpenAI's own page for queries such as "codex macos download".
- The visible page is hosted on Google Sites, with the working lure pulled in by iframe from a separate attacker-controlled domain.
- Visitors are told to paste a Terminal command dressed as an npm install; it decodes a base64 URL and runs a shell loader with zsh.
- Newer lure versions return benign content to non-macOS visitors and at the obvious /codex/ path, serving the ClickFix page at /codexx/.
- The final Mach-O is suspected to be the Atomic macOS Stealer, based on overlaps with previously documented AMOS delivery chains.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The suspected payload is an infostealer and the delivery path is a developer install step, which puts the compromise on a machine used to build software rather than in a mailbox.
- constraint Cato's own detection guidance requires four correlated signals, so teams that cannot join search referral, web content, endpoint process and egress data have no single place to catch this.
- decision Whoever owns developer tooling now has to decide whether canonical install commands are published internally, because paid placement can sit above the vendor's page for the same query.
- contradiction The two accounts of the same report disagree on scale and certainty: three infrastructure sets against at least four, and a suspected-AMOS framing against Cato's stated refusal to call the payload...
Cato's write-up is dated August 24 [2]. The iframe is the load-bearing part of what it describes. None of the malicious content sits on the Google Site, so the operator can rewrite the pasted command and the loader behind it without editing the page Google serves [4]. Cato's Jakub Osmani and Guy Waizel describe this as combining a trusted hosting domain with independently controlled ClickFix content [5]. The practical effect is that abuse handling splits in two: a report to Google removes a front end that costs nothing to rebuild, and a block on the payload host leaves the ad and the trusted domain working [24].
The content did get rewritten. In earlier infrastructure the embedded second stage was compressed and base64-encoded; in later versions it arrives as an AES-encrypted gzip container whose decryption key is reassembled from several variables [15]. SC Media reports at least four infrastructure sets, with the obfuscation of the second-stage loader changing between them [12]. The portal also advertised a Linux download, though Cato observed active payload delivery only for macOS [18], and the final binary is universal, so Intel and Apple Silicon hosts both run it [26].
Before the Mach-O is fetched, the second stage sends a request carrying event=pasted to an attacker-controlled endpoint [7], which Infosecurity Magazine describes as recording the paste ahead of payload retrieval [9]. That is campaign measurement rather than malware behaviour: the operator learns which searches produced someone willing to paste into Terminal, whether or not the payload lands or runs [25]. The same stage clears extended attributes with xattr -c [7], stripping the download quarantine metadata that normally triggers macOS warnings about files retrieved from the internet [8].
None of this tradecraft is new to AI tooling. Cyderes' Howler Cell reported in May on a ClickFix and Google Ads campaign aimed at Windows users searching for "Claude Code install" [21], and Push Security disclosed in March an "InstallFix" campaign spreading the Amatera infostealer to Windows and macOS users searching similar terms [22]. Cato says some infrastructure in the Codex campaign has also served Claude Code-themed pages that were not hosted on Google Sites [23], which makes the Sites front end an addition to a working kit rather than a new one [27]. The researchers' own summary is that trust becomes the payload, because no single stage reliably exposes the attack [20].
What to watch
- Whether Google tightens ad review for developer-tool queries or restricts iframe embedding on Sites, the only controls that remove the front end at scale.
- Whether behavioural analysis of the Mach-O confirms or rules out AMOS, given the current identification rests on delivery-side overlap.
- Whether the same infrastructure rotates onto other AI CLI installers beyond Codex and Claude Code.