Fake Claude Code install sites are pushing malware that steals API keys, developer credentials, crypto wallets, and other sensitive data.

The trust that makes developer tooling so easy to adopt is exactly what this campaign exploits. A developer searches for Claude Code installation instructions, finds what looks like official documentation, copies the provided command, pastes it into a terminal, and the compromise is already complete before the software finishes installing. The legitimate tool often installs successfully alongside the malware, which is precisely the point – nothing looks wrong because nothing visibly goes wrong.

Straiker researchers who documented the campaign found over 88 fake domains built to impersonate Claude Code and other developer platforms, including Cline, JetBrains, Snowflake, and Perplexity Comet. Since March 2026, the people behind this operation have kept their infrastructure in constant rotation – when one site gets taken down, another surfaces quickly – while leaning on SEO manipulation and Google ad purchases to push their fraudulent pages into the top results above the real documentation.

How the Installation Commands Are Weaponized

The method itself is not complicated, which is part of why it works. These sites hand developers commands that read as completely normal, but tucked inside the string are hidden separators – an “&” character, for instance – that quietly trigger malicious actions while the real installation moves forward in parallel. From the developer’s perspective, everything behaves exactly as expected. The software installs, the terminal clears, and no moment triggers suspicion. The infection has already taken hold.

Across the campaign, researchers saw attackers shift between multiple delivery approaches –  rundll32.exe pulling in malicious DLLs, mshta.exe being abused, commands encoded in Base64, scripts pulled from GitHub, and JavaScript-based payloads. Swapping between these keeps the campaign slippery against tools that rely on recognizing known patterns, because no single method stays in use long enough to become a reliable detection signature.

The main payload the researchers traced back is ACRStealer, a credential-stealing malware strain that has been updated with stronger encryption and evasion features. After execution, it works through a multi-stage chain – encrypted communications back to the attacker infrastructure, execution that leaves minimal traces on disk, and built-in mechanisms that make forensic analysis harder after the fact.

What the Malware Is Actually After

Where most infostealers chase banking credentials and saved passwords, this campaign was put together with the AI development environment specifically in mind. API keys, authentication tokens, and cloud credentials from tools like Cline and Continue.dev are the primary targets, sitting alongside browser passwords, password manager vaults, VPN credentials, crypto wallets, and messaging app data.

The crypto theft goes a step further than wallet credential harvesting. Researchers found a clipboard hijacker embedded in the campaign that watches for copied wallet addresses and swaps them out silently for attacker-controlled ones. No additional interaction is required from the victim – the redirect happens in the background, and the first sign anything went wrong is usually a transaction that never arrives.

The emphasis on AI credentials reflects where value has shifted in developer environments. A stolen LLM API key translates directly into unauthorized usage charges. Cloud development credentials frequently open doors well beyond a single developer’s machine – into repositories, deployment pipelines, and production systems that would be far harder to reach through conventional credential theft.

Why Security Awareness Training Hits Its Limit Here

The Straiker team flagged something that deserves attention: campaigns that deliver working installations through pages that look correct, on URLs that appear legitimate, are not reliably stopped by training developers to spot suspicious behavior. The usual signals – odd domains, unexpected permission requests, warnings during install – are absent. Everything about the experience feels normal because the attackers engineered it that way.

Defenses should focus on technical controls. Directly sourcing commands from official vendors is key, though distinguishing official sources from convincing fakes remains difficult when fraudulent pages rank higher due to paid placement.

Endpoint and application controls block unauthorized scripts and fileless execution. Continuous API key scanning limits exposure. DNS filtering removes risky new domains before developers access them.

Least-privilege access and phishing-resistant MFA serve as the backstop – constraining what an attacker can actually do with stolen credentials when the other layers don’t catch the compromise in time. Against a campaign built this carefully, some percentage of developers will get hit regardless. The controls determine how much it costs when it happens.

The Infrastructure Problem

Part of what makes this campaign durable is how it is built to absorb takedowns. Eighty-eight domains spread across reputable hosting platforms, constantly refreshed as individual sites get reported and removed, means that conventional abuse-reporting and domain takedown responses are a management exercise rather than a resolution. The operation is structured to outlast that process.

For security teams, that shifts the focus away from chasing individual malicious pages and toward the developer environment hardening and credential governance that decides what an attacker actually walks away with. The campaign is not going away. The practical question is what it can reach when it lands.

Research and Intelligence Sources: Straiker, eSecurityPlanet, Claude

To participate in our interviews, please write to our CyberTech Media Room at info@intentamplify.com 



🔒 Login or Register to continue reading