Google Ads Abused to Install Hidden macOS Malware

In recent weeks, a highly targeted malvertising campaign has emerged that specifically targets macOS developers and advanced users. By leveraging sponsored Google Ads that appear to promote trusted software brands such as Homebrew and LogMeIn, threat actors are redirecting users to counterfeit download portals. Once there, users are tricked into executing Terminal commands that quietly install powerful infostealer malware.

The implications go far beyond casual users this technique compromises credential stores, crypto wallets, browser cookies, and deep system metadata. It demands immediate attention from security teams and DevOps alike.

Brand Masquerading and ClickFix

The attackers begin by placing legitimate-looking Google Ads that display the correct URL of the software brand (for example, brew.sh). However, clicking the ad leads the user to a typosquatted domain (e.g., brewe[.]sh) or a similarly named fake site.

At this fake site, the visitor receives an installation instruction formatted for the terminal: a curl command disguised as an official installation script. When executed, the script fetches and executes malicious payloads, bypasses macOS Gatekeeper and other security controls. In this scenario, the campaign employed “ClickFix” techniques coercing the user into a copy-and-paste action that initiates the compromise.

AMOS and Odyssey Stealer

Analysis shows the primary malware drop in the campaign were two sophisticated infostealers: AMOS (also known as Atomic macOS Stealer) and Odyssey Stealer. AMOS is offered in a malware-as-a-service model for about $1,000/month and is capable of extracting browser credentials, Keychain data, crypto wallet extensions, and system metadata.

Odyssey Stealer, derived from Poseidon Stealer and AMOS, further amplifies its scope by targeting a wide array of wallet extensions, cookies, and text-based credentials. Once executed, the malware uses root-level permissions (via sudo) to enumerate services, suspend legitimate processes (such as OneDrive updaters), and blend malicious activity into routine system operations. The collected data is then exfiltrated to a command-and-control server under the attackers’ control.

Developers and Crypto Users Are Prime Targets

Unlike many broad phishing campaigns, this operation explicitly targets users who inherently trust brand names like Homebrew and LogMeIn. Developers, DevOps engineers, and crypto-currency handlers often rely on these tools daily. By focusing on a technical audience, the threat actors leverage higher-privilege environments and richer data stores.

Historically, Homebrew’s installation method itself using a curl command in Terminal is a vector easily mimicked by malicious actors. 
In this campaign, more than 85 impersonating domains were identified masquerading as Homebrew, LogMeIn, or the TradingView platform. The campaign demonstrates how even savvy users can be tricked by typo-squatting and terminal-based installation flows.

Indicators of Compromise and Key Defensive Controls

Security teams should watch for the following red flags:

• Execution of unexpected curl-based install commands in Terminal.

• Presence of domains that closely resemble trusted brands but differ by one letter or use uncommon TLDs.

• Traffic originating from Google Ads that appear as familiar brand names but lead to unknown download portals.

• Unusual sudo prompts shortly after installation, followed by data exfiltration to unknown remote hosts.

To defend against this type of threat:

• Enforce strict allow-listing of approved download sources and domains.

• Enable Endpoint Detection and Response (EDR) to monitor for abnormal shell command execution and process injection.

• Train users and specifically developers to verify installation commands manually rather than trust redirection from search ads.

• Use crypto-wallet monitoring tools and browser-credential-leak detection for early exfiltration indicators.
  (Internal Link → “See our prior blog on developer-targeted infostealers”)

Why This Matters for Enterprise Risk

This campaign is more than a typical phishing attempt it exploits the trust developers place in installation commands and trusted tooling. When infostealer malware hits a developer machine, the breach surface broadens: keys, tokens, credentials, and even internal infrastructure access can be compromised. The use of Google Ads as a delivery vector underscores that threat actors are now leveraging paid channels to evade traditional URL-filtering tools. That shift dramatically increases the attack surface for managed enterprise endpoints and highlights a gap in advertising-ecosystem security.

Mitigation Checklist for Security Teams

1. Audit and restrict shell command workflows avoid curl | bash execution without code review.

2. Monitor advertising traffic redirections and block ads leading to untrusted download portals.

3. Segment developer systems from production networks and apply robust least-privilege controls.

4. Keep EDR signatures updated to detect AMOS/Odyssey-style behavior (wallet scraping, Keychain dumps).

5. Conduct periodic phishing and malvertising awareness sessions with technical teams, focusing on brand-impersonation risks.

Frequently Asked Questions

Q1: What makes this campaign different than standard phishing?
A1: Instead of relying on email or social-engineering alone, the campaign uses paid Google Ads to mimic trusted brands and direct users to terminal-command installation flows. It targets technical users rather than general consumers.
Q2: Can traditional antivirus detect AMOS or Odyssey Stealer?
A2: Some AV solutions detect known signatures, but the attack here uses custom delivery (shell commands) and root-level privileges, making behavior-based detection and EDR telemetry more reliable than signature alone.
Q3: How can developers verify the legitimacy of a shell installation command?
A3: They should manually inspect the URL in the curl command, validate certificates, compare the script at the official repository (e.g., GitHub), and avoid blindly trusting search ads or copy-paste flows.
Q4: Should my organisation block all Google Ads?
A4: Blocking all ads is extreme. Instead, monitor ad-redirect traffic, whitelist known domains, and enforce download policy controls on endpoints.
Q5: If a system is compromised by this campaign, what should I do immediately?
A5: Disconnect from the network, collect EDR logs, review sudo history for suspicious commands, rotate credentials, isolate affected endpoints, and execute forensic analysis of clipboard history and wallet extensions.