You type "claude download mac" into Google. You click the top result (sponsored ad, verified badge, URL is claude.ai). You land on a shared Claude chat titled "Running Claude Code on Mac", tagged "Shared by Apple Support" in the top right corner, with a bash command to paste into Terminal. Thirty seconds later, your Keychain is on a server in Sydney. No falsified URL anywhere in the chain. No typo-squat. No fake domain.
TLDR: A live malware campaign this week uses verified Google Ads and claude.ai shared chats to drain Mac Keychains. Nothing in the chain is technically fake. That's the part that should worry you.
The scammers keep getting better at this. Let me walk you through what happened, because every single step of this attack looks legitimate until you understand what "legitimate" actually means in 2026.
15,600 Macs, One Google Search, One Pasted Line

The campaign was first flagged by Berk Albayrak, a security engineer at Trendyol, on May 9. By the time BleepingComputer covered it two days later, Moonlock Lab was tracking 15,600+ Macs touched by the broader MacSync infostealer family (this Claude variant is the latest iteration, not the entire body count). Anvilogic published a full technical breakdown the same week.
Here is the entire chain in one frame. Five steps. Every single one is technically legitimate, except the one in red.
A sponsored ad. Verified. claude.ai. You click. You land on a real Claude shared chat hosted on Anthropic infrastructure, titled "Running Claude Code on Mac", with a user-controlled label saying "Shared by Apple Support" in the top right. There is a code block. The code block contains a one-liner. You paste it into Terminal because that is exactly what every legitimate dev tool onboarding has trained you to do for fifteen years.
It's muscle memory at this point, the same reflex that makes you press A through a dialog box you've read a hundred times.
The thing that makes this attack different from the usual phishing is that you can follow the entire chain without finding a single thing that is "fake" in the classic sense. The URL is claude.ai because it really is claude.ai. The ad is verified because Google really considers the advertiser legitimate, a Sydney company called KB & CO Holdings PTY LTD. The shared chat really exists and really was shared on Anthropic servers.
The only lie in the whole chain is the words "Shared by Apple Support", typed by the attacker into the title of their own chat.
That is the entire attack. A title.
Paste That Command Into a New Claude Tab and Ask What It Does
This is the part that nobody on Medium has written yet, so let me state it plainly. The same AI that is being weaponized as malware distribution infrastructure is also the best defense you have against this attack, and the demo takes thirty seconds.
Open a new Claude conversation (or ChatGPT, or Gemini, pick your favorite). Paste the suspicious command. Ask: "what does this command do, and decode any base64 in it."
That's it. That's the whole technique.
On a command of this shape (a base64-wrapped curl piped straight into bash, which is the documented pattern Albayrak found in the malicious chat), the model unwraps it in seconds. It decodes the base64 into a readable URL (in the original campaign, the C2 was hosted on customroofingcontractors.com, a small American roofing business whose site was compromised and turned into delivery infrastructure). It explains the -k flag disables SSL verification. It explains the -f flag tells curl to fail silently with no error message. It flags the whole pattern as consistent with macOS malware delivery.
You just used a Claude tab to defend yourself against an attack that uses a Claude tab as distribution infrastructure. The irony is free.
I tested the same prompt on three different models. All flagged the command in under thirty seconds. None require a security background. None require you to know what base64 is. You just need to see the words "this looks like malware delivery" and close the tab.
Use the model that's distributing the malware to read the malware. C'est la vie.
Why "Check the URL" Stopped Working
Twenty years of security training taught you a single rule. Check the URL. The reasoning was simple: the domain tells you who owns the billboard, and for two decades, forging the message required forging the billboard. So checking the billboard was enough.
That equation broke quietly, sometime around the moment platforms decided that letting users publish content on the platform's main domain was a great product feature. Shared chats on claude.ai and chatgpt.com. Public pages on sites.google.com and pages.dev. The domain seal now guarantees that the platform exists and owns the domain. It says nothing about the individual message sitting inside it.
Anthropic did the right thing on paper. The shared chat carries an explicit warning banner: "Content may include unverified or unsafe content that does not represent the views of Anthropic." It's visible. It's worded clearly. The legal box is checked.
The problem is the line just below it. The user-controlled chat title. The attacker typed "Shared by Apple Support" into their own chat title, and that single line restores an illusion of authority that the disclaimer above it is supposed to demolish.
A reader scanning the page in two seconds reads: Anthropic, Apple Support, code, paste. The warning banner is real and the title is fake, but both share the same visual real estate, and the human eye does not weight them differently when scanning. The disclaimer plus user-controlled label combo doesn't survive any reader who is not already trained to mistrust the chat title specifically.
AdGuard wrote exactly this critique three months ago, when the same pattern was being used to distribute fake Homebrew install commands via Cloudflare Pages and Google Sites. Their formulation was sharper than mine: putting user-generated content on the main second-level domain creates a level of trust that the content has not earned. They also noted the disclaimer is invisible on mobile. Three months later, here we are, same architecture, same attack, different platform, fifteen thousand more victims.
The billboard is real. The message on it is not.
This Pattern Has Been Live for Six Months. Nobody Wants to Fix It.
The pattern that hit Claude this week is the fifth public iteration in six months.
November 2025 saw fake ChatGPT Atlas installers pushed via the same ClickFix social engineering loop. December 2025 added Mac cleanup queries pointing to the same payload. February 2026 brought Homebrew install commands hosted on Cloudflare Pages and Google Sites (the iteration AdGuard documented in detail). March 2026 saw The Hacker News tracking the campaign migrating to Belgium, India, and the Americas with dynamic AppleScript generation. May 2026 lands on Claude shared chats.
Five iterations, six months, interchangeable surface. Anvilogic's diagnosis is sharper than mine: defenses that look at what a command does will outlast defenses that look at where the page lives. The surface will keep moving. That is the entire industry summary, and platforms cannot win this game by patching the surface alone.
So why does nobody fix it? The honest answer is that nobody has the right incentive structure. Google collects ad money from the advertiser (KB & CO Holdings, paying Australian dollars to push compromised installers, that's the business transaction Google is being paid for). Anthropic hosts the user-generated content that drives engagement metrics for the shared chat feature, which is a product feature people genuinely use. Neither company has a strong commercial reason to invest aggressively in scanning before the fact.
The security budget at most platforms lives in the same drawer as the espresso machine warranty.
The operational cost falls entirely on the end user who pastes the command.
This is not unique to Anthropic. I wrote a piece a few weeks ago about a different shared-content attack pattern on Claude Cowork, where the same root cause (user content gets the platform's authority by default) created a prompt injection surface inside the file collaboration feature. OpenAI has the same model. xAI has the same model. The architectural choice to let user content ride on the main domain is industry-wide, and it's a product decision, not a security oversight.
If you're waiting for the platforms to fix this before the next campaign, look at the calendar. The platforms have known for six months. Six months is the answer.
The 4-Reflex Playbook

Four reflexes. Ordered by effort, from cheapest to highest. The first one alone neutralizes the entire attack surface that hit Mac users this week, so if you only remember one, remember number one.
1. Pull, don't push. When you want to download a piece of software, type the URL directly into the address bar. Never click a sponsored result, even if the URL looks right. The vendor's real result is one position below, free, and points to the right place. The two seconds you save by clicking the ad cost 15,600 people their Keychain this week. Pull means: you go fetch the software from where you know it lives. Push means: you let the search engine decide what to show you first. The push model is broken when the first slot is auctioned to whoever paid the most, including attackers.
2. Check who paid for the ad. If you click the sponsored result anyway (which you should not, but sometimes onboarding flows route you through Google), open the three dots on the ad and look at "About this advertiser." If the entity paying for the ad is not the vendor (Anthropic, Apple, Mozilla, brew.sh, whatever you actually meant to download), close the tab. On this week's campaign, the advertiser panel showed KB & CO Holdings PTY LTD, registered in Sydney, Australia. Anthropic is incorporated in Delaware. The mismatch is the entire signal you need. Google won't catch this for you. You have to look.
3. Never paste a Terminal command you didn't write. Not from Claude shared chats, not from StackOverflow, not from YouTube tutorials, not from official-looking documentation pages you reached via an ad. If you did not type the command, you do not paste it.
This is the hardest reflex to adopt because half the dev ecosystem has spent fifteen years training you to do exactly the opposite. Every CLI worth installing has a curl | bash one-liner in its README: Homebrew, oh-my-zsh, nvm, rustup, Claude Code itself. We trained an entire generation of devs on a workflow that is structurally indistinguishable from this attack, then handed them a security checklist that says "don't paste random commands." We are the call coming from inside the house.
Ship CLIs all you want, I argued for them at length a few months back. The install flow is still the soft spot, and the industry has not figured out a clean alternative yet.
4. If you must paste it, decode it first with AI. Section two, again. Open a new Claude tab, paste the command, ask what it does. If the answer mentions SSL verification disabled, silent failure, remote shell execution, or any URL you don't recognize, close the tab and walk away. Thirty seconds of verification against your Keychain, your iCloud, your saved browser passwords, and whatever wallets you had unlocked at the time. That's the price comparison.
That is the playbook. Four reflexes, no tools to install, no subscription to pay, no certification to earn. The hardest part is unlearning fifteen years of "just paste this."
The human filter we learned over twenty years rested on a hypothesis that is no longer true: that to falsify a message, you had to falsify the billboard. This week it's claude.ai. Next week it's the ad for the next Cursor, the next Notion, the next Linear hosted on a legitimate Google Site. The mechanism will last for years. The reflex that holds against it fits in one sentence.
Verify the action, not the origin.
Sources
- Berk Albayrak, original discovery thread on X (May 9, 2026)
- Hackers abuse Google ads, Claude.ai chats to push Mac malware, BleepingComputer
- MacSync Infostealer Delivered via Claude and ClickFix, Anvilogic Threat Research
- How a Real Claude.ai URL Is Distributing Mac Malware Through Google Ads, UCStrategies
- Claude Google Ads Malware Poisoning macOS, AdGuard, February 19, 2026
- ClickFix Campaigns Spread MacSync macOS Infostealer, The Hacker News
Top comments (0)