Google Sites Abused to Deliver macOS Malware via Fake Codex Download

The infection chain ran through three stages and ended in a Mach-O payload staged in /tmp/helper, according to Cato Networks’ technical write-up published on August 24.

ClickFix instructions and the three-stage execution chain

Once a visitor reached the fake portal, the page instructed victims to open Terminal and paste a command presented as a legitimate-looking Codex installation. That pasted command decoded an encoded URL and retrieved a shell-script loader that began a three-stage infection chain.

Cato described the sequence as: the pasted command retrieved a shell-script loader, which decoded and executed a second-stage script, which in turn fetched the Mach-O final payload. Before launching the payload, the second-stage script staged it in /tmp/helper and stripped the file's extended attributes, removing the download-related quarantine metadata that normally triggers macOS warnings about files retrieved from the internet.

Infrastructure sets, path gating and evasion

Investigators mapped three distinct infrastructure sets supporting the campaign. The third set reused an iframe host seen in the first, while a second set added a simple evasion: the active ClickFix page was served from an unexpected path, and a more intuitive path returned a benign fake product page.

Cato also observed path- and operating-system-aware gating. When the Google Sites lure was opened from a non-macOS device, researchers saw benign content instead of the active lure. This selective behaviour could cause automated analysis tools or researchers to receive harmless pages rather than the exploit chain. Across the infrastructure sets, Cato noted that the loader became more heavily encrypted and obfuscated.

Overlap with the AMOS delivery framework — and what it does not prove

Cato Networks identified substantial similarities between this campaign’s delivery framework and a previously documented Atomic macOS Stealer (AMOS) infection chain. Shared indicators included encoded shell loaders, telemetry requests, update-themed payload retrieval, and universal Mach-O payloads built to run on both Intel and Apple Silicon Macs and staged in /tmp/helper.

However, Cato was careful to qualify the connection: the overlap in delivery telemetry was "strong and consistent with AMOS delivery activity," but should not be read on its own as proof of how the final Mach-O behaves once executed. The researchers explicitly cautioned that delivery telemetry alone does not establish the final payload's functionality.

What this means for security teams and macOS users

Security teams and technologists — Expect attackers to combine trusted platforms and familiar developer workflows with sponsored-search placement and embedded iframes. Detecting this campaign, Cato advised, requires correlating sponsored-search delivery, embedded web content, Terminal execution and outbound activity rather than relying on a single indicator.
End users and developers — The lure replicated a familiar installation pattern (a terminal paste-and-run instruction) and used a trusted hosting surface (Google Sites). Users who are prompted to paste commands into Terminal as part of a download flow should treat that as a high-risk action given the campaign’s demonstrated removal of quarantine metadata and multi-stage download behavior.

The campaign illustrates a deliberate blending of social engineering, trusted hosting and multi-stage technical evasion: a familiar developer workflow (paste-to-Terminal installation) delivered from a trusted domain, routing active components through hidden paths and infrastructure that respond differently to operating system and path. Cato Networks’ analysis leaves open the precise nature of the final Mach-O’s behavior, but confirms a repeatable, evasive delivery method that security teams must correlate across search, web and host-level telemetry.

Original report