Wenn die KI-Tool-Installation zur Falle wird: Claude Code und Gemini CLI im Visier finanziell motivierter Angreifer
26. Mai 2026. EclecticIQ hat am 21. Mai eine seit März laufende SEO-Vergiftungs-Kampagne offengelegt, die Entwickler auf gefälschte Installations-Seiten für Claude Code und Gemini CLI lockt - und im Hintergrund einen fileless PowerShell-Infostealer zieht. Die Daily-Security-Recaps vom 25. und 26. Mai tragen die Welle weiter. Die KI-Agenten-Tooling-Adoption ist damit als eigene Supply-Chain-Spur in der Bedrohungsökonomie angekommen.
AI-generated · gpt-image 2.0
Was ist passiert
EclecticIQ hat am 21. Mai 2026 eine seit Anfang März laufende Kampagne dokumentiert, die mit SEO-Vergiftung gefälschte Installations-Seiten für Claude Code (Anthropic) und Gemini CLI (Google) über die offiziellen Quellen in der Google-Suche platziert. Die Lure-Domains geminicli[.]co[.]com, claudecode[.]co[.]com und claude-setup[.]com wurden zwischen Ende März und Anfang April registriert; eine breitere Pivotierung über den Bulletproof-Hoster MIRhosting zeigt rund dreißig zusätzliche Domains, die Node.js, Chocolatey, KeePassXC und Monero imitieren. Die Hendry-Adrian-Daily-Security-Recaps vom 25. und 26. Mai listen die Kampagne explizit als laufende Bedrohungslage.
Einordnung
Methodisch ist die Kampagne eine Bestätigung des inversen Befunds aus der Glasswing-Welle der Vorwoche: nicht nur Defender, auch Angreifer haben die Adoption von AI-Coding-Agenten als operative Hebelstelle erkannt. Der finanziell motivierte Akteur reusiert ein Template - eine kurze Erst-Stage-PowerShell-Zeile via irm | iex, parallel echtes npm install, im Hintergrund ein in-memory Infostealer mit AMSI- und ETW-Bypass - und rotiert nur die Lure-Marke und den C2-Endpunkt. Die Marken-Auswahl wandert dabei von klassischen Productivity-Tools wie Node.js hin zu KI-Agenten-CLIs. Das ist der eigentliche Beleg: KI-Agenten-Tooling ist als eigene Supply-Chain-Spur in der eCrime-Ökonomie etabliert, nicht als Randerscheinung.
Bedeutung für den Mittelstand
Für Ihre Entwicklungs- und Plattform-Teams verschiebt sich eine stille Annahme. Das Entwickler-Notebook galt lange als Nebenschauplatz der Unternehmens-Identität, weil Produktion und CI/CD darüber abstrahiert sind. Diese Annahme trägt nicht mehr. Ein einzelnes kompromittiertes Notebook in Ihrem Team liefert dem Angreifer Browser-Cookies, Slack-Sessions, Teams-EBWebView-Daten, OpenVPN-Konfigurationen mit Schlüsselmaterial, WinSCP- und PuTTY-Sessions, OAuth-Tokens für GitHub und Cloud-Konsolen sowie alle .txt- und .docx-Dateien aus Desktop, Documents und Downloads. Wer einen Senior-Backend-Entwickler trifft, sitzt anschliessend auf den Produktionspfaden.
Datenschutz und Compliance stehen damit nicht hinten an, sondern vorne. Browser-Cookies, Mail-Session-Daten und Cloud-Synchronisations-Pfade enthalten personenbezogene Daten von Beschäftigten, Kundinnen und Drittparteien. Ein Vorfall an einem Endgerät ist nach DSGVO Art. 33/34 meldepflichtig, sobald ein Risiko für die Rechte der Betroffenen plausibel ist; bei OAuth-Token-Diebstahl gegen produktive Systeme ist das die Default-Annahme, nicht die Ausnahme. Die DSB sollte vor - nicht nach - dem nächsten Verdachtsfall wissen, welche Datenkategorien auf welchen Entwicklungs-Notebooks liegen.
Regulatorisch trifft Sie das doppelt. Das NIS2UmsuCG-Entwurfsfeld § 30 verlangt ein dokumentiertes Risikomanagement der IKT-Lieferkette - Entwickler-Workstations sind Teil dieser Lieferkette, sobald sie produktive Identitäten halten. BSI-Grundschutz-Bausteine APP.6 und CON.8 adressieren den lokalen Entwicklungs-Stack ausdrücklich; die Glaubwürdigkeit Ihrer Audit-Erzählung hängt daran, dass Sie PowerShell-Constrained-Language-Mode, AppLocker oder WDAC und Mark-of-the-Web-Enforcement nicht erst nach einem Vorfall einführen.
Bedeutung für die technische Entwicklung
Architektonisch zeigt der Befund ein wiederkehrendes Muster der nächsten Monate. KI-Agenten-CLIs werden auf Entwickler-Notebooks installiert, die historisch lokale Identitäten breit aggregieren - Browser-Profile, IDE-Tokens, Cloud-CLIs, VPN-Konfigurationen. Jede neue Agent-CLI, die im Workflow landet, weitet die effektive Identitäts-Oberfläche aus, ohne dass diese Erweiterung in einem zentralen Identitäts-Inventar landet. Der Stealer zielt genau dorthin: nicht auf die KI-Schicht selbst, sondern auf das Identitäts-Reservoir, das die Agenten-Adoption beifügt.
Der Gegenentwurf ist eine harte Trennung. Agenten-CLIs gehören in eine geschäftliche Identitäts-Spur mit kurzlebigen OAuth-Tokens, sandboxed Ausführungs-Umgebungen (etwa Remote-Dev-Container oder Cloud-Workspaces) und einem Software-Bezug, der die Installation aus signierten Paketen statt aus irm | iex-Pasten erzwingt. MCP- und A2A-Setups, die intern produktive Tools exponieren, sollten ihre Token mit Conditional Access an Geräte-Posture und FIDO-Faktoren binden.
Wie ich das handhabe
Meine Secret-Disziplin ist die direkte Antwort auf diese Angriffs-Klasse. Secrets liegen bei mir nie unverschlüsselt auf der Platte: Repository-gebundene Geheimnisse verschlüssele ich mit SOPS gegen age-Schlüssel, die auf einem YubiKey sitzen - Klartext entsteht nur kurzlebig im Prozess-Speicher, nicht im Dateisystem. Interaktive Identitäten gegen GitHub, Cloud-Konsolen und interne Plattformen laufen über OIDC mit ultrakurzer Token-Gültigkeit (Minuten, nicht Stunden) plus FIDO2-Bindung an den YubiKey; ein gestohlener Browser-Cookie verfällt, bevor der Stealer ihn monetarisieren kann. Was nicht in den OIDC-Pfad passt - Legacy-Logins, Fremd-Plattformen, vereinzelte Service-Accounts - sitzt in einem zentralen Passwortmanager mit Hardware-Token-Pflicht und planmässiger Secret-Rotation, nicht in Browser-Profilen, Notizen oder lokalen Config-Files. Die Disziplin kostet einmaligen Aufbau-Aufwand und reduziert dauerhaft den Wert eines kompromittierten Notebooks auf wenige Minuten gültiger Tokens - präzise das Fenster, das der Stealer aus EclecticIQs Analyse braucht.
Konkrete Handlungsempfehlung
Setzen Sie diese Woche drei Schritte an: erstens, ein Inventar der Entwickler-Notebooks und der dort installierten KI-Agenten-CLIs, Cloud-CLIs und VPN-Profile. Zweitens, PowerShell-Constrained-Language-Mode plus AppLocker/WDAC-Regel gegen heruntergeladene Skripte (Mark-of-the-Web-Enforcement), ergänzt um Detection-Regeln für irm | iex-Muster und C2-Pfade /take, /process, /validate. Drittens, der Umstieg auf den Secret-Stack aus der vorigen Sektion - SOPS-verschlüsselte Repository-Secrets, YubiKey-gebundene FIDO2-Identitäten, OIDC mit Minuten-Token, Passwortmanager mit Rotation - beginnt nicht mit einem Vendor-Vergleich, sondern mit einer Bestandsaufnahme, welche Tokens heute wo unverschlüsselt liegen. Anschliessend mit der DSB die Datenschutz-Folgenabschätzung für die Entwickler-Identitäts-Spur fortschreiben.
Dieser Beitrag spiegelt meine technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.
Programmiert seit 2002 – autodidaktisch gelernt, 2012 mit KO-Web selbständig gemacht. Über 100 Projekte, Fokus auf Security, Performance, Automatisierung und Qualität. Heute freiberuflich: DevSecOps-Beratung, Schulungen und Softwareentwicklung.
