Fake Claude Installer Campaign Used Google Ads and Bing Redirects to Deliver ClickFix Command

A campaign documented by Push Security used a Google Search advertisement, Bing’s click-tracking infrastructure and a compromised retailer website to direct users toward a fake Claude download page. The page attempted to use a ClickFix-style technique: it showed a legitimate installation command while placing a different command on the visitor’s clipboard.

The investigation, published October 9, 2026, does not establish the attacker’s identity, the number of intended victims or whether the campaign produced successful infections. Push Security also said the final malware family was unknown. The evidence supports describing the operation as an attempted delivery of attacker-controlled shell code, not as a confirmed malware infection.

How the redirect chain worked

According to Push Security, the campaign targeted searches for “claude mac” with a Google ad. The displayed destination was Bing, rather than the fake Claude page itself. The click path then moved through Google’s advertising redirect, Bing’s click-tracking endpoint, a compromised retailer website and finally a page designed to resemble a Claude download site.

Push Security attributed the name “Adception” to this type of advertising and redirect activity. The use of multiple intermediary destinations made the final page less visible in the initial ad listing and helped the campaign control how visitors reached it.

The campaign also used cloaking and referral checks. These mechanisms restricted delivery to visitors arriving through the intended route, rather than presenting the same content to every visitor or automated reviewer. The evidence does not establish how the retailer website was compromised, who owned it or whether it has since been remediated.

The fake page changed the copied command

The page displayed Anthropic’s legitimate installation command, creating the appearance that the visitor was following a normal Claude setup process. However, Push Security found that the page’s copy button placed a different command into the clipboard.

That command streamed downloaded content into `zsh`, meaning the user could be prompted to paste and run attacker-controlled shell code while believing it was the installation command shown on the page. The reports do not establish the payload’s complete execution behavior or identify a malware family.

This is why the activity is described as a ClickFix attack: the technique relies on persuading a user to copy and execute a command themselves. The label describes the delivery behavior, not a confirmed infection or a specific malware strain.

What is confirmed—and what is not

Push Security’s findings establish the observed advertising and redirect path, the use of cloaking and referral checks, and the mismatch between the command displayed on the page and the command copied by its button.

Several important details remain unknown. The evidence does not independently establish the campaign’s duration, geographic targeting, victim count or advertiser-account status. It also does not identify the attackers, determine how the retailer website was compromised or confirm that users completed the command-execution step.

Push Security characterized the activity as a notable use of a Bing search-result redirect as a Google-ad destination. That novelty assessment should be treated as the vendor’s assessment rather than an independently provable claim.

The reported indicators may also be short-lived. Domains and redirect infrastructure associated with the campaign should therefore be treated as reported campaign indicators, not as guaranteed current infrastructure.

Why the advertising route matters

The campaign did not rely on a fake download page alone. It combined paid search placement with redirects, a compromised intermediate website and selective content delivery. That structure allowed the operators to present a plausible path from a user’s search to a page impersonating a legitimate software installation experience.

It also illustrates why the visible destination of an advertisement may not fully describe the page a visitor ultimately reaches. In this case, the route passed through Google and Bing infrastructure before reaching the compromised retailer site and the fake Claude page.

Google’s published policies prohibit compromised destinations, malware, cloaking and attempts to circumvent review systems. Based on the behavior described by Push Security, the technique appears inconsistent with or prohibited by those policies. The available evidence does not show that Google formally determined that this specific campaign violated its policies.

Guidance for site owners and advertisers

Google’s documented remediation for compromised destinations includes cleaning the affected site, checking Search Console and Safe Browsing, and then resubmitting or appealing the advertisement. Those steps are relevant to owners or advertisers whose websites are used as part of a redirect chain.

The evidence does not support broader recommendations beyond those documented measures. It also does not establish the status of the compromised retailer website or the advertising account involved in this case.

For users, the central warning from the observed technique is specific: the command displayed on a page may not be the command placed in the clipboard. A prompt to paste shell code as part of a software installation should therefore be treated as a distinct execution step, rather than as proof that the page is genuine.

The campaign’s final payload remains unidentified, and successful infections have not been confirmed. What Push Security documented is a carefully routed attempt to use search advertising and a fake Claude installation flow to persuade users to execute attacker-controlled code.