If you’ve ever searched “Claude for Mac” and clicked the top result because you were in a hurry, you’re the target. Push Security found an “Adception” campaign where the ad looks clean because it shows bing.com, then quietly bounces you through Bing’s click-tracking (bing.com/ck/a), a hacked WordPress site, and cloaking checks—until you land on a fake Claude download page . The nasty part: a ClickFix-style “copy” button swaps the command you think you’re pasting with a malicious one that runs curl into zsh on macOS, while your terminal output still looks like it’s downloading from the real Claude URL . This outline breaks down how the trap works, what to look for, and the practical habits and controls that stop it.
How the scam stays believable: the “clean” ad, the trusted redirect, the hidden detour
The reason this “Adception” malvertising campaign works is simple: it doesn’t ask you to trust something shady. It borrows trust from brands you already rely on when you’re in a hurry—Google Search ads and bing.com—then slips the malicious part in between.
Here’s the chain Push Security documented, in plain language:
- You search something like “claude mac” and a sponsored result shows up at the top.
- The ad looks safer than most malvertising because the displayed destination is a legit domain: bing.com. That “bing.com” label lowers your guard.
- When you click, you don’t go straight to Claude (or even straight to an attacker site). The click flows through ad plumbing and lands on Bing’s click-tracking endpoint:
bing.com/ck/a. - That Bing tracking link forwards you to a real but compromised WordPress site (in this case, a retailer site), which is acting like a “traffic broker” for the attackers.
- Only then do you get redirected to the fake Claude download page (Push tracked one destination as
claude-desk-code[.]com).
Why each hop makes you less suspicious
Attackers aren’t just trying to get you to a fake Claude installer page. They’re trying to get you there without triggering the two things that stop most bad clicks: your instincts and automated scanning.
- “bing.com” as the ad’s destination makes the ad feel boring and legitimate. Most people won’t scrutinize a well-known search engine domain in the top slot.
bing.com/ck/ais a real click-tracking endpoint. Researchers noted Bing’s redirects can use JavaScript-based forwarding, which gives attackers room to route traffic in ways that still “look like” Bing-originated activity.- The compromised WordPress site is a credibility shield. It’s a normal domain with normal history, so reputation-based filters may hesitate. And it’s easier for attackers to rotate victims through hacked sites than constantly burn new domains.
Cloaking, explained like a bouncer at the door
This campaign also used multiple layers of cloaking—think of it like a bouncer who only lets in guests who came from the “right” line, dressed the “right” way.
Push Security’s write-up (as summarized in reporting) describes two checks:
- On the compromised WordPress hop: it checks for a Bing referrer plus specific browser headers before it redirects you onward. If you don’t match (like a scanner, a bot, or a direct visit), you may never see the next stage.
- On the fake Claude site: it uses JavaScript to verify you arrived from Google or Bing. If you try to open the malicious URL directly, you get bounced to a 404 page—a cheap but effective way to waste investigators’ time and starve scanners of the real content.
That’s the “hidden detour” part. The scam isn’t one bad page. It’s a guided path that only reveals the payload when the visitor behaves like a real human coming from search.
And once you’re on that fake download page, the attackers don’t even need you to run a traditional installer—they just need you to trust what you think you’re copying and pasting.
The ClickFix twist: when the page shows one command, but your clipboard holds another
Once the redirect chain drops you onto the fake Claude page, the attackers stop relying on “looks legit” branding and start exploiting something most of us do on autopilot: click Copy → paste into Terminal.
This is the ClickFix move.
What you see vs. what you paste
On-screen, the page can display a perfectly reasonable-looking Claude install command. In the campaign Push Security tracked, the fake page showed Anthropic’s legit-looking installer pattern:
curl -fsSL <https://claude.ai/install.sh> | bash
But when you click the Copy button, the site doesn’t copy what you see. It writes a different command into your clipboard.
That’s the trap: your eyes “verify” the page, but your clipboard is what gets executed.
Why this is so effective on macOS
macOS power users are used to installing tools via Terminal. Attackers know that, and they build the fake installer flow around it.
In the documented sample:
- The substituted command prints a message claiming it’s downloading Claude from Anthropic’s official website. That’s social engineering aimed at your terminal trust.
- Behind the scenes, it decodes a Base64-encoded URL that points to attacker infrastructure (one example was
lake-90[.]com). - Then it uses
curlto silently download a .dat payload and pipes it straight intozshfor execution. That’s the classic “download + run” in one line, with almost no friction.
The nastiest detail: your terminal can lie by omission
Even if you’re careful and glance at what you pasted, this attack tries to keep you calm:
- Victims may still see the legitimate Claude URL both on the page and echoed in the terminal, even though a different script is actually being executed.
So the “sanity check” most people do (“Yep, I see claude.ai in there”) can fail.
A quick mental model (use this every time you see a copy button)
If a website asks you to run a command and offers a one-click Copy, treat it like untrusted code until proven otherwise.
Red flags worth stopping for:
- Any
curl | zsh/curl | bashpattern, even if it’s common in legit installers - Commands that print reassuring status text (“Downloading from official site…”) while doing extra steps
- Anything that looks like encoding/decoding (Base64) inside an install one-liner
Spotting it fast: indicators you can check in under 60 seconds
ClickFix works because it hijacks momentum. So your best defense is a 60-second pause before you download anything or run anything.
Fast checks you can do as a human (no tools needed)
Use this checklist when you’re searching for installers like “Claude for Mac”:
- Is it a sponsored installer ad? If yes, slow down. This campaign was delivered via a malicious Google ad targeting “claude mac.”
- Does the ad “destination” look too clean? Attackers made the ad appear safer by showing a legitimate bing.com domain as the visible destination.
- Do you see
bing.com/ck/aanywhere during the click? That’s Bing’s click-tracking endpoint, and it was used as a hop in the redirect chain. If you catch it in the status bar, address bar, or a link preview, treat it as a warning sign. - Do you land on a domain that isn’t the vendor? In the reported chain, users were ultimately sent to a lookalike destination like
claude-desk-code[.]comrather than an Anthropic-controlled domain. - Try opening the final URL directly in a new tab. In this campaign, direct access could kick you to a 404 page. That “works only from search” behavior is a big tell.
Behavioral tells defenders can watch for (quick triage signals)
If you’re on a security team, these patterns are worth logging and alerting on because they show up even when the page content is cloaked.
h3) Referrer/header gating (classic cloaking behavior)
- The compromised site in the chain checked for a Bing referrer and specific browser headers before redirecting.
- That means the same URL can behave “normal” for a real user click, but dead-end for a scanner.
h3) JavaScript-driven redirects
- Bing’s click-tracking redirects can use JavaScript to forward the browser, which makes the chain harder to reason about from static URL analysis alone.
h3) Inconsistent behavior between fresh clicks vs. direct navigation
- The fake site used JavaScript to verify the visitor came from Google or Bing.
- Practically, that creates a useful detection hint: users who arrive via search see a “download” flow, while analysts opening the URL directly see a 404 or unrelated content.
If you train yourself (and your team) to look for these signals, you’ll catch most malvertising redirect-chain attacks before you ever reach the point where a fake installer can ask you to run anything.
Practical defenses that actually hold up (habits + controls + monitoring)
If you want protection that survives a real workday (tabs everywhere, Slack pings, deadlines), you need two layers: habits that cut off malvertising at the source and controls that catch the stuff humans miss.
Habits that scale across a team
- Skip sponsored results for installers. This campaign started with a malicious Google ad targeting “claude mac.”
- Type the vendor domain yourself (or use a bookmark you trust). If you’re about to install Claude, you shouldn’t end up on a random domain like
claude-desk-code[.]com. - Treat “one-line installers” as code execution. If an install flow involves Terminal, assume the site is asking for the keys to your machine. Extra caution is justified even when the command looks standard.
- Don’t paste commands you didn’t type or fully inspect. Especially anything that resembles
curl | bashorcurl | zsh. In this campaign, the command in the clipboard wasn’t the command shown on the page. - If you must copy/paste, add a speed bump:
- Paste into a plain-text editor first (Notes/TextEdit in plain text mode).
- Read it left to right.
- Only then paste into Terminal.
Security controls: block the chain, not just the final page
h3) Browser + network controls (stop redirect-chain abuse)
- Flag or challenge click paths that include tracking redirects like
bing.com/ck/ainside an ad-driven flow. That endpoint was used as a hop before the user reached the compromised site and then the fake download page. - Detect JavaScript-driven redirects in secure web gateways / browser isolation tooling. Researchers noted Bing click-tracking redirects can use JavaScript forwarding, which gives attackers wiggle room to shape the chain.
h3) Endpoint detection: catch “download → shell” behavior
Set alerts for process patterns that don’t belong on employee laptops:
curl(or similar) spawningzsh/bash- Scripts launched immediately after a network fetch
- Terminal executing long, obfuscated one-liners (encoding/decoding shows up in real samples)
This campaign specifically downloaded content and piped it directly into macOS zsh for execution. That’s a clean detection opportunity.
h3) Web hygiene: reduce compromised-site “stepping stones”
Attackers routed victims through a legitimate but compromised WordPress site before sending them to the fake Claude page. If you operate WordPress (marketing sites count), basic hardening matters:
- Keep core/themes/plugins updated
- Remove abandoned plugins
- Lock down admin access and add MFA
- Monitor unexpected outbound redirects and injected JavaScript
Account safety side-note: don’t hand fake pages your real identifiers
Even if you avoid running a bad command, fake pages often try to capture emails, phone numbers, and signups.
For signups on new tools or SaaS trials, using Cloaked identities (masked email and phone) is a simple way to limit fallout if you land on the wrong page. It keeps account recovery and verification from being tied directly to your real number or inbox—useful when the “download” page isn’t what it claims to be.



