A Google ad showed bing.com; four stops later a fake Claude installer's copy button swapped the command

Four stops from the click to the fake page, and the results page named one of them

Push Security's report of 9 October 2026 lists four requests between a click on a Google search ad and a fake Claude download page. A fifth request, made by the command that the page's copy button supplies, fetches the code. Three of the four browser requests go to infrastructure the attacker does not own: Google's ad-click redirect, Bing's click tracker, and the website of a retailer in South America that Push says is compromised. The fourth is the fake page itself. The ad displayed one name, bing.com. Four parties' servers carried the click to the fake page, namely Google's, Microsoft's, the retailer's and the attacker's, and the screen named one of them (counts derived from Push's table).

What that count does not establish matters as much as the number. It does not identify the final payload: Push describes a downloaded file run by the macOS shell and says nothing about what the file does in this campaign, and BleepingComputer says the payload is unknown. It gives no victim count: Push says it detected the attack in a customer environment and gives no number of clicks, copies or machines. It does not say that the ad still runs, that Google or Microsoft has changed anything, or when the campaign began; the earliest date is a timestamp inside the Bing link that Push decodes to 5 October 2026, four days before the report (derived), and Push says that is "probably" when Bing generated the link. It describes macOS only and names no actor. And because the chain turns away anyone who does not arrive by the ad, a scanner, or a colleague who opens the address directly, is shown a benign page or a 404 page, so a clean result from your own check is not evidence that the destination is clean.

What the count does show is where the one working control sits. Everything visible in the chain can be forged or borrowed: the ad shows a trusted search engine's name, the page shows the vendor's genuine installation command, and the pasted command prints a message naming the vendor's real address. What runs is whatever the clipboard holds, and nothing on the page tells the reader what that is. The control that survives every hop is to read the pasted text in the terminal before pressing Return and compare it with the vendor's documented line, or to avoid the paste altogether by installing from the vendor's own page, reached by typing the address or from a bookmark. Both reports also say that the chain works only for a visitor who arrives through it: a direct visit to the fake page gets a 404 error. A reader who types the vendor's address never enters the chain at all.

The chain, stop by stop: whose servers, what each stop checks, what it lends

Push's table gives the order and the status codes, and BleepingComputer repeats the order. The diagram adds this briefing's reading of who owns each stop and what the user's screen can show at each. It carries no address, because the addresses are the attacker's indicators and Push lists them in its own report.

What each stop lends the next, in Push's account:

• Google's ad-click redirect lends the ad's place on Google's network. Push says Google's ad review approved a destination that was simply another search engine.
• Bing's click tracker lends the bing.com name on the ad and a bing.com referrer for the next stop. Bing forwards the visitor with a short JavaScript page, not an HTTP redirect.
• The retailer's page lends a real, search-indexed business. Push's working theory is that the attacker took a legitimate Bing search result for a page they had compromised and used that link in the ad.

Push adds that visiting the compromised retailer from Bing also serves the malicious page, which it takes to show that the target is Google Search users and not Bing users. That is Push's inference.

What is stated, by whom, and what is not

Two sources carry the story and they are not independent. BleepingComputer's article of 9 October reports Push Security's findings and adds none of its own, and it carries no statement from Google, Microsoft or Anthropic. No other report of the campaign was found on 10 October. This briefing therefore treats Push's report as the primary source and BleepingComputer as a second reading of it.

Claims about the Adception campaign, with the source that makes each, read on 10 October 2026. Counts and day counts are derived from the report and its dates.

Question	Stated, and by whom	Not stated
Which route did the click take?	Push lists four requests: Google's ad-click redirect (HTTP 302), Bing's click tracker (200, forwards with JavaScript), a retailer's page (302), the fake page (200). BleepingComputer repeats the order.	Whether every victim took this path, how many ad variants ran, how the retailer's site was compromised, or whether the retailer knows.
What did the copy button do?	Push: the page shows the vendor's real command and the button places a different one on the clipboard. It prints a message naming the vendor's address, decodes a hidden address, downloads quietly and pipes the file into zsh.	What the downloaded file does, or whether it ran on any machine.
How many victims?	Nothing. Push says it detected the attack in a customer environment.	Clicks, copies, executions, machines.
When did it start, and does it still run?	Push: the Bing link carries a timestamp that decodes to 5 October 2026, "probably" when Bing generated it. Both reports are dated 9 October.	The start of the campaign, the number of ads, whether the ad still runs. One Google ad campaign identifier is in Push's indicator table, not reproduced here.
Is it macOS only?	Push: the page offered a macOS download button, and "The command targets macOS users". Its indicator table lists one command.	Whether a Windows variant exists.
Who is behind it?	Push tracks the toolkit as AcSig and says several domains share the command, the payload address shape and the installer code. Its table lists eight lure or delivery hostnames (counted by this briefing).	Any actor, or any link between the toolkit's operator, the ad buyer and the compromise of the retailer.
Have Google or Microsoft responded?	BleepingComputer carries no statement from Google, Microsoft or Anthropic. None was found elsewhere on 10 October. The only Google statement found on this class of abuse concerns a different incident, in March.	Whether the ad was removed, the account suspended, or the Bing tracker changed.

Push Security sells browser security and has an interest in the finding looking large. Its report ends by saying that its customers need take no further action, and it gives no victim count, ad count or date range with which to size this one. Its figure that four in five ClickFix attacks it detects reach victims through search engines is a share of what its own customers' sessions show, not of ClickFix in general, and its 23 September report gives percentages and no absolute count of detections. Push also says AI-themed lures of this kind made up around 5 per cent of what it detected in its last quarterly snapshot. None of that makes the finding wrong. It means the numbers that would let a reader judge its size are not in the report.

ClickFix says the user fixed something. Here the page chose the command

The label ClickFix describes an attack in which a visitor is talked into running a command. MITRE ATT&CK catalogues it as Malicious Copy and Paste (T1204.004) and names ClickFix as one strategy. Push says in its March report that the label has drifted, and is now used for malicious copy and paste "even though most lures haven't been related to 'fixing' anything for a while now". In this campaign the pretext is simply wanting to install software, and the user did what the page asked.

Calling that a user error puts the failure in the wrong place. The user did paste a command. But the command pasted was not the one on the page: the page chose it, at the moment of the copy. Push makes the same point, saying that any checks that rely on reading the text on the screen "will probably fall foul of this technique". A person who reads the page carefully learns nothing, because the page is the one part of the chain the attacker controls completely. Advice that says read what you paste is sound only if it says where to read: in the terminal, before pressing Return, and not on the web page.

There is a limit to that advice, and it comes from the vendor's own page. The genuine route for the command-line tool is itself a command that downloads a script and hands it to a shell, and the vendor's setup page says the install command shows no progress while it downloads. So "downloads quietly" and "pipes into a shell" cannot be the test, because the genuine command does both. What differed here, on Push's description, was that the pasted text began with a line that printed a reassuring message, contained a step that decoded a hidden address, and passed the download to a different shell from the one the vendor's page documents. The test is a comparison with the documented command, made in the terminal.

The same family has been covered here before, and the common thread is that the label or the address was never the control. Push's second post of 9 October covers a custom-GPT cluster of the kind described in Two of at least 40 ClickFix incidents came through a custom GPT. Other briefings cover a lure on a documentation placeholder domain, a fake LastPass installer and a ClickFix injection through a compromised third-party loader.

Three gates and an ad review: why a later check sees nothing

Every gate Push describes turns away anyone who did not arrive by the ad path:

• The retailer's website redirects only when a Bing referrer and certain browser headers are present. This check is made on the server.
• The fake page runs a JavaScript check of the referrer. A visitor not referred by Google or Bing is sent to a 404 page. Push and BleepingComputer both say a direct visit therefore shows a 404.
• The toolkit requires headers sent with an HMAC (a keyed hash used to sign a request) before it supplies the malicious command, which is Push's basis for the name AcSig. Push counts two layers of cloaking; this briefing counts this as a third gate, and Push does not say what a request without the headers receives.

Push's general point is that a redirect lets an attacker show each checkpoint a trusted URL while deciding as late as possible who sees the malicious page. On this design a URL scanner, an ad-review crawler, an email gateway or a colleague who opens the link directly would meet a trusted page or a 404 error. That is an inference from the gates as described: the absence of a detection in a scan is not evidence that the destination is clean. An earlier briefing, three filters, one clean page, describes a different chain that hands a scanner a clean page by three separate mechanisms. The NCSC's November 2024 guidance for brands that buy advertising asks them to find out whether their partners' detection "includes 'cloaking', where the harmful nature or destination of an advert is hidden".

How the ad passed review is the open question. Google's policy pages, as read on 10 October 2026, name the structure involved. Under destination mismatch, the reasons for disapproval include "Redirects from the final URL take the user to a different domain", with an exception for certain circumstances "with prior approval"; Google's example is a manufacturer sending shoppers to a pre-approved list of retailers. Under evasive ad content, Google does not allow "Manipulation of ad components like text, image, videos, domain or subdomains in an attempt to bypass detection or enforcement action." Malicious software is called egregious, and Google says accounts are suspended upon detection and without prior warning.

Push's explanation is that the ad shows bing.com as its domain, that Google's review and URL-reputation checks see a Bing link, and that the hidden destination is a compromised retailer site rather than the lure. That is Push's reading, and Google has not commented in anything found. It would fit Google's own text if a check for redirects to another domain looks only for HTTP redirects, because Bing forwards with a JavaScript page. That is this briefing's inference, offered to show what a question to Google would need to cover: what its review followed, what it was shown, and whether it looked again after approval.

The only Google statement found on this class of abuse is about a different incident. On 24 March 2026 a Google spokesperson told 404 Media, of a sponsored result for a fake page imitating a coding tool's documentation, "We removed this ad and suspended the account for violating our policies", and said Google uses Gemini-powered tools and human review to enforce its ad policies. It says nothing about this campaign.

The genuine route, and what can be checked without trusting the page

The vendor here is Anthropic, treated as any impersonated vendor would be: each statement below is attributed to the vendor's own page as read on 10 October 2026.

• The vendor's download page, claude.com/download, lists a macOS download of the desktop app. Its separate Claude Code section lists a terminal install among its options.
• The vendor's support article "Install Claude Desktop", marked as updated over two weeks before it was read, gives the Mac steps as: visit the downloads page, choose macOS and click Download, open the file to complete installation, and launch the app from the Applications folder. It describes no terminal step for the Mac app.
• The vendor's Claude Code setup page, code.claude.com/docs/en/setup, marks a native install as recommended: one command run in a terminal. It documents a Homebrew cask and the desktop app as alternatives, says the install command shows no progress while it downloads, and says Homebrew installations do not update themselves.
• The same page says each release publishes a manifest of checksums signed with the vendor's key, and that macOS binaries are signed by Anthropic PBC and notarized by Apple, with a documented check of the signature.

That gives a reader five checks that do not depend on trusting the page in front of them. First, the address: type it or use a bookmark, and the chain never starts. Second, whether a terminal is needed at all: for the Mac desktop app the vendor's article describes none, so a page whose Download for macOS button leads to a command to paste departs from the documented route. Push says that on the fake page, clicking the download button serves the install command. Third, the pasted text: compare it with the documented line in the terminal before pressing Return. Fourth, after an install, the signature and notarisation check the vendor documents. It checks what was installed; it cannot reveal a script that ran during the install and left nothing signed behind, and it cannot undo one. Fifth, for a managed estate, the vendor's pages list Homebrew and enterprise deployment routes for macOS, which avoid a pasted line. Whether either suits a given estate is a separate decision, and Homebrew installs do not update themselves.

UK reading: staff who install tools from search results, and what each control claims

The exposed group is any organisation whose developers or staff install tools after searching for them. Cyber Essentials, the NCSC's malware guidance and Apple's own macOS protections each describe a control that could apply. The table says what each source says, in its words where the words matter, and whether the source establishes that the control stops this chain. No source read does.

Controls that could apply to a pasted command on a managed Mac, from Cyber Essentials v3.3 (April 2026), the NCSC, Apple's Platform Security guide (3 August 2026) and Push. Read on 10 October 2026. Entries marked inference are this briefing's.

Control and source	What the source says	Stops this chain?
Cyber Essentials v3.3, malware protection: anti-malware option	Must "prevent malware from running", "prevent the execution of malicious code" and "prevent connections to malicious websites over the internet".	Not established. Depends on the product knowing this payload, host or behaviour, and Push says hosts are replaced within days.
Cyber Essentials v3.3: application allow listing option	"Only approved applications, restricted by code signing, are allowed to execute on devices."	Inference: it governs applications. A pasted command hands a script to the system shell, so whether a product intercepts it is a product question.
Cyber Essentials v3.3: user access control	Malware "would typically be executed with the same privilege level of the user's account".	Limits reach only if the account is not an administrator. A standard developer account may still hold cloud and source-control credentials (inference).
NCSC, Mitigating malware and ransomware attacks, action 3	Only permit "applications trusted by the enterprise to run on devices", and "disable or constrain scripting environments and macros". The examples given are PowerShell and Office macros.	Not established for macOS: the page names no macOS example.
Apple: terminal paste protection, macOS 26.4 or later	A warning appears on paste into Terminal only if Terminal has not been opened for more than 30 days, no common developer tooling is detected, and the paste comes from a listed app such as a browser.	By design not for people who use Terminal or have developer tools, which includes most who would install a command-line coding tool (inference).
Apple: pasteboard command blocking, same page	After a paste into any terminal, XProtect traces the process tree, checks network artifacts against Apple's Safe Browsing Service, and blocks a known malicious source or behaviour consistent with known malware.	Not established. Depends on whether this payload host or behaviour was known; no source tested it.
DNS and web filtering	Push says attackers use "domains that can be thrown away and replaced within days" and that IoC-based detections for such campaigns "are of limited value".	A list helps only once the host is on it, and cloaking hides the lure from list builders (inference). Push sells a different control.
EDR on macOS	Push says the standard guidance is to baseline normal use and alert on unusual parent processes and command lines, and that IT automation, MDM tools and admin scripts make that noisy.	Could see the behaviour: a shell started from a terminal that decodes and pipes a download. Not established that any given product alerts.
MDM limits on Terminal and unapproved applications	No source read for this briefing. Described as a control, not a finding.	Narrows who can paste a command. Does not inspect what is pasted (inference).

Reporting the ad. Google's help page says to select More or Info on the ad, then Report ad, choose a reason and submit. Google's Trust and Safety team reviews the report, and egregious or repeat violations can lead to an advertiser's account being suspended. The ASA's Scam Ad Alert system takes reports of suspected scams in paid-for space, including paid-for search ads, and says that anyone who reached a suspected scam website through an ad should report the ad to it. It passes obvious scams, where it has enough information, to platforms and ad networks for removal. Its examples are fake celebrity news, false endorsements, implausibly cheap products and weight-loss claims; whether it would treat an ad that leads to malware as an obvious scam is not stated on its page. In 2024 it received 1,691 reports and sent 177 alerts to platforms (derived share: 10.5 per cent). Its page gives Action Fraud as the route for anyone who has fallen victim to fraud or cyber crime.

Regulation is not an answer yet. Ofcom published draft fraudulent advertising codes of practice for Category 1 and Category 2A services, which include search services, on 10 July 2026. The consultation closed on 2 October 2026 and Ofcom plans its statement by mid-2027 at the latest. The duty it describes concerns a paid-for advertisement that amounts to a listed offence, such as fraud by false representation under the Fraud Act 2006. Whether an ad that leads to malware meets that test, and whether a named service is under the duty for it, are legal questions this briefing does not answer.

What to do, in the order worth doing

The first three steps reduce the chance of a paste. The next two make the next victim less likely. The last two limit the damage.

What could not be verified

The question that exposes the gap

Every check this chain was built to pass looked at the page, the address or the referrer: the ad review, the URL scanner, the colleague who opened the link, the reader checking the command on the screen. The thing that ran was none of those. It was the clipboard. So when a developer on a managed Mac pastes a line from a web page, what in your estate compares it with what they were shown?

Key facts