Kai Ole Hartwig
5 Min. Lesezeit
Von

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.

Zwei cremefarbene Briefumschlaege auf dunklem Schiefer, einer mit oxblutrotem Wachssiegel, der andere geoeffnet mit messingfarbenem Schluesselbrieffoeffner, im Hintergrund ein Messing-Schluesselkasten mit zwei fehlenden Schluesseln.
gpt-image 2.0

Content Credentials

Signiert von
der Quelle, außerhalb dieser Website
Herkunft
KI-generiert — gpt-image 2.0

Die Datei trägt ein signiertes Herkunftsmanifest. Es dokumentiert, wie das Asset entstanden ist — es ist keine Aussage über die Richtigkeit des Inhalts.

Rohdaten der Prüfung öffnen

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.

Quellen

Über den Autor

Foto von Kai Ole Hartwig.

Kai Ole Hartwig

Freiberuflicher DevSecOps-Berater · OnlyOle Consulting

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.