The Copy Button Is the Attack: “Adception” Malvertising Rides Bing Redirects to Push Fake Claude Installers

Google Ads for Claude, a Bing redirect, and a Terminal command that isn’t what you copied

Push Security has published a report on a malvertising campaign they call “Adception.” The attackers didn’t buy ads pointing at their own domains. They bought ads pointing at Bing, then rode Bing’s own click-tracking redirect into a fake Claude installer aimed squarely at macOS users. If your organisation’s developer laptops are Macs and nobody thinks twice about installing an AI coding tool from search results, this campaign was built for you.

The chain: Google ad, Bing hop, compromised retailer

Push discovered the campaign after spotting a malicious sponsored result for people searching “claude mac.” Typical malvertising sends victims to attacker-controlled domains that security filters can block. This one didn’t. The sponsored result displayed the legitimate bing.com domain, which made the advertisement look trustworthy in exactly the way a security reviewer checks.

Click it, and the request passes through Google’s advertising redirect, lands on Bing’s bing.com/ck/a click-tracking endpoint, and from there the browser gets forwarded to a real but compromised WordPress site belonging to a South American retailer. That site redirects you one final time to claude-desk-code[.]com, a counterfeit Claude download page.

The redirect infrastructure deserves a moment of attention. Bing’s click-tracking links use JavaScript to send visitors onward to their destination. That’s normal ad-tech plumbing. The attackers pointed that plumbing at their payload, so from Google’s ad server through Bing’s tracker, every visible hop looks like traffic Bing itself would generate.

Two layers of cloaking, one very convincing 404

The campaign goes out of its way to hide from anyone who isn’t arriving exactly the way a victim would. The compromised WordPress site checks for a Bing referrer and specific browser headers before it redirects. The fake Claude page runs JavaScript that verifies visitors came from Google or Bing. Type the URL directly into your address bar, or send a scanner at it, and you get a 404 error page. Push says this makes automated analysis of the attack noticeably harder.

Every anti-phishing control your security team runs assumes the tool can reach the payload and look at it. Cloaked campaigns break that assumption. The page your scanner sees and the page your developer sees are different artifacts served from the same URL.

The copy button is the attack

Here’s the part that stays with me. The fake download page imitates Anthropic’s real Claude installer page and displays the genuine installation command, curl -fsSL https://claude.ai/install.sh | bash. A developer who reads the command before running it, and plenty of careful developers do, sees the correct, official string.

Clicking the copy button quietly swaps the clipboard contents. Paste into Terminal and you’re running something else: a command that first prints a reassuring message about downloading Claude from Anthropic’s official website, then decodes a Base64-encoded URL pointing to lake-90[.]com, then uses curl to pull down a .dat file and pipe it straight into zsh. The victim sees the legitimate install URL on the page and in the terminal output while a completely different script executes.

Push tracks the toolkit internally as AcSig and identified several domains sharing the same macOS installation command, payload URL structure, and installer interface. The final payload remains unknown. Nobody can yet say what malware, if any, these installs drop.

What this changes for your security baseline

Three practical takeaways, because “trust no ads” is not a control.

First, the clipboard is an attack surface, and most security awareness programs have never mentioned it. The Adception page was designed so that reading the command before running it still wouldn’t save you. Train developers to install tools only from a vendor page they reached by navigating from the vendor’s own site, or better, from an internal approved list. Typing the vendor’s URL from memory beats clicking any search result.

Second, redirect chains through trusted domains make URL reputation unreliable. If your web filter scores bing.com as benign, and it should, then an ad whose visible destination is bing.com inherits that trust right up to the JavaScript handoff to a compromised third-party site. Filters that only evaluate the first URL in a chain miss this. What does catch it is behavior: a web page instructing a developer to paste a curl command into Terminal is worth flagging regardless of which domain it arrived from.

Third, cloaking means your scanners need to look like users. A tool that fetches a URL cold, with no referrer and a headless fingerprint, gets shown a 404 while the real payload serves to actual visitors. Defenders reproduce campaigns with realistic referrer chains, like Push did here, and find pages an appliance never rendered. That’s an arms race, and right now the automated tools are losing the reflexive round.

The wider pattern should worry anyone building an AI-forward security practice. Attackers treat the AI tools your engineers use daily as lure brands with real market demand. Somebody searched “claude mac,” saw an ad, copied a command, and handed a shell to lake-90[.]com. The brand being impersonated isn’t a bank. It’s the tooling your own staff asked you to license.

How eHawu closes the gap this campaign exposed

Adception succeeded because no single layer of the chain looked malicious to the systems watching it. eHawu’s network-layer monitoring doesn’t grade URLs by reputation. It watches what connections actually do after they’re established. A macOS host quietly resolving Base64-decoded endpoints and piping curl output into a shell is anomalous traffic, and anomaly is exactly what the eHawu sensor grid surfaces to your SOC before the payload calls home.

Pair that with endpoint awareness that treats clipboard-swap installs as the class of threat they are, and you cover the window between a developer clicking an ad and your EDR noticing something wrong. That window is where malvertising lives. Closing it is a network problem as much as an endpoint one.

#AdversaryInTheMiddle #Malvertising #ClickFix #MacOSSecurity #AISecurity #EnterpriseSecurity