When the AI tool install becomes the trap: Claude Code and Gemini CLI in the crosshairs of financially motivated attackers

What happened

EclecticIQ documented on May 21, 2026 a campaign running since early March that uses SEO poisoning to surface fake install pages for Claude Code (Anthropic) and Gemini CLI (Google) above the official sources in Google search. The lure domains geminicli[.]co[.]com, claudecode[.]co[.]com and claude-setup[.]com were registered between late March and early April; a broader pivot through the bulletproof host MIRhosting reveals around thirty additional domains impersonating Node.js, Chocolatey, KeePassXC and Monero. The Hendry Adrian daily security recaps from May 25 and 26 list the campaign explicitly as an ongoing threat.

What it means

Methodologically, the campaign is a confirmation of the inverse finding from last week's Glasswing wave: not only defenders, attackers too have recognized AI coding agent adoption as an operational lever. The financially motivated actor reuses a template - a short first-stage PowerShell line via irm | iex, a parallel real npm install, an in-memory infostealer with AMSI and ETW bypass running in the background - and rotates only the lure brand and the C2 endpoint. The brand selection moves from classic productivity tools like Node.js toward AI agent CLIs. That is the real evidence: AI agent tooling has established itself as a supply chain track of its own in the eCrime economy, not as a fringe case.

What it means for the German Mittelstand

For your engineering and platform teams, a quiet assumption is shifting. The developer notebook used to be treated as a side stage of the corporate identity perimeter, because production and CI/CD are abstracted above it. That assumption no longer holds. A single compromised notebook on your team hands the attacker browser cookies, Slack sessions, Microsoft Teams EBWebView data, OpenVPN configurations with key material, WinSCP and PuTTY sessions, OAuth tokens for GitHub and cloud consoles, plus every .txt and .docx file from Desktop, Documents and Downloads. Hit a senior backend developer and the attacker is sitting on the production paths.

Data protection and compliance are not a footnote in this picture, they are the entrance. Browser cookies, mail session data and cloud-sync paths contain personal data of employees, customers and third parties. An incident on an endpoint is reportable under GDPR Art. 33/34 as soon as a risk to data subjects is plausible; with OAuth token theft against production systems, that is the default assumption, not the exception. The Data Protection Officer should know - before, not after, the next suspected incident - which categories of data live on which developer notebooks.

Regulation hits twice. Germany's NIS2UmsuCG draft, section 30, demands documented risk management for the ICT supply chain - developer workstations are part of that supply chain the moment they hold production identities. The BSI Grundschutz modules APP.6 and CON.8 address the local development stack explicitly; the credibility of your audit narrative hangs on whether you introduce PowerShell Constrained Language Mode, AppLocker or WDAC, and Mark-of-the-Web enforcement before an incident, not after.

What it means for technical practice

Architecturally, the finding shows a pattern that will recur over the coming months. AI agent CLIs get installed on developer notebooks that historically aggregate local identities broadly - browser profiles, IDE tokens, cloud CLIs, VPN configurations. Every new agent CLI landing in the workflow widens the effective identity surface without that widening showing up in any central identity inventory. The stealer aims exactly there: not at the AI layer itself, but at the identity reservoir that agent adoption deposits next to it.

The counter-design is a hard separation. Agent CLIs belong in a business identity track with short-lived OAuth tokens, sandboxed execution environments (remote dev containers or cloud workspaces), and a software supply that forces installation from signed packages rather than from irm | iex pastes. MCP and A2A setups that expose internal production tools should bind their tokens to device posture and FIDO factors with conditional access.

How we handle this at Moselwal

Our secret discipline is the direct answer to this class of attack. Secrets never live unencrypted on disk: repository-bound secrets are encrypted with SOPS against age keys that sit on a YubiKey - cleartext only ever exists briefly in process memory, never on the filesystem. Interactive identities against GitHub, cloud consoles and internal platforms run through OIDC with ultra-short token lifetimes (minutes, not hours) plus FIDO2 binding to the YubiKey; a stolen browser cookie expires before the stealer can monetize it. Whatever does not fit the OIDC path - legacy logins, third-party platforms, occasional service accounts - sits in a central password manager with hardware token enforcement and scheduled secret rotation, not in browser profiles, notes or local config files. The discipline costs one round of build-up effort and permanently reduces the value of a compromised notebook to a few minutes of valid tokens - precisely the window the stealer from EclecticIQ's analysis needs.

Concrete recommendation

Set three steps in motion this week. First, an inventory of developer notebooks and the AI agent CLIs, cloud CLIs and VPN profiles installed on them. Second, PowerShell Constrained Language Mode plus an AppLocker/WDAC rule against downloaded scripts (Mark-of-the-Web enforcement), complemented by detection rules for irm | iex patterns and the C2 paths /take, /process, /validate. Third, the move to the secret stack from the previous section - SOPS-encrypted repository secrets, YubiKey-bound FIDO2 identities, OIDC with minute-scale tokens, a password manager with rotation - does not start with a vendor comparison but with a stock-take of which tokens currently sit unencrypted where. Then, work with your Data Protection Officer to extend the data protection impact assessment to the developer identity track.

This article reflects our technical and strategic assessment. It does not replace legal advice or a data protection impact assessment.

Sources

• EclecticIQ Threat Research Team - SEO poisoning campaign leverages Gemini and Claude Code impersonation to deliver infostealer (May 21, 2026)
• Infosecurity Magazine - Fake Gemini and Claude Code Sites Spread Infostealers (May 22, 2026)
• GBHackers - Hackers Use SEO Poisoning to Fake Gemini CLI, Claude Installers (May 22, 2026)
• Hendry Adrian - Cybersecurity News Daily Recap [25 May 2026] (May 26, 2026)