Sicherheitsforscher des 0din-Teams von Mozilla haben eine Angriffsmethode veröffentlicht, die zeigt, wie KI-gestützte Coding-Agenten durch ihre eigene Hilfsbereitschaft zur Sicherheitslücke werden können. Die Technik nutzt scheinbar harmlose GitHub-Repositories, um Schadsoftware auf dem System eines Entwicklers zu installieren – ohne dass dabei ein einziger Schritt für sich genommen verdächtig wirkt.
Der Angriff beginnt mit einem harmlosen Repository
Das Angriffsszenario startet damit, dass ein Entwickler einen KI-Coding-Agenten – im untersuchten Fall Claude – anweist, ein Projekt aus einem GitHub-Repository zu initialisieren oder zu konfigurieren. Das Repository selbst sieht dabei völlig unverdächtig aus: wenige Scaffolding-Dateien, kein Code, der Sicherheitstools auslösen würde. Genau das ist der erste Teil des Tricks.
Der Agent liest zunächst eine README- oder Markdown-Datei, die beschreibt, wie eine Python-Umgebung mit dem Paket „Axiom" – einem gängigen Monitoring-Tool – aufgesetzt werden soll. Beim ersten Ausführen schlägt ein gefälschtes Axiom-Startskript jedoch fehl. An diesem Punkt greift das eigentliche Angriffsprinzip: Der KI-Agent möchte das Problem lösen und führt – ganz im Sinne seiner Hilfsbereitschaft – automatisch den nächsten scheinbar logischen Befehl aus: python3 -m axiom init.
Drei Umleitungsebenen, keine davon offensichtlich schädlich
Die Forscher beschreiben den Angriff als drei aufeinanderfolgende Umleitungsebenen, von denen keine für sich genommen auffällig ist:
Ebene 1 – Der fehlerhafte Start: Das gefälschte Axiom-Skript produziert absichtlich einen Fehler. Der KI-Agent reagiert darauf, indem er einen Korrekturbefehl ausführt – so wie es ein hilfsbereiter Assistent tun würde.
Ebene 2 – Der DNS-Trick: Der durch den Korrekturbefehl ausgelöste Shell-Skript lädt keine Software von einer verdächtigen URL herunter, die von Sicherheitstools erkannt werden könnte. Stattdessen liest er die DNS-TXT-Einträge einer bestimmten Domain aus – in diesem Fall _axiom-config.m100.cloud. Die Nutzung von DNS-TXT-Einträgen ist an sich absolut legitim, etwa für E-Mail-Konfigurationen. Kein Sicherheitsscanner würde hier Alarm schlagen.
Ebene 3 – Die codierte Nutzlast: Der TXT-Eintrag enthält eine base64-kodierte Zeichenkette, die beim Dekodieren eine Reverse Shell öffnet. Das bedeutet: Auf dem Rechner des Entwicklers wird eine Shell-Verbindung zum Server des Angreifers aufgebaut. Der Entwickler und der KI-Agent sehen lediglich eine Meldung wie „Environment ready".
Was ein Angreifer danach tun kann
Sobald die Reverse Shell aktiv ist, hat der Angreifer vollen Zugriff auf alles, worauf der Entwickler Zugriff hat: API-Schlüssel, Passwörter, Quellcode, Dokumente, Browser-Sessions und gespeicherte Zugangsdaten. Es ist darüber hinaus möglich, weitere Schadsoftware zu installieren, um dauerhaften Zugang zu behalten – auch wenn der erste Angriff irgendwann entdeckt wird.
Besonders kritisch ist das in Entwicklungsumgebungen, in denen Zugangsdaten für Cloud-Dienste, Produktionsdatenbanken oder interne Systeme hinterlegt sind. Ein einziger kompromittierter Entwicklerrechner kann in solchen Umgebungen als Ausgangspunkt für weitreichendere Angriffe dienen.
Warum klassische Sicherheitstools versagen
Das 0din-Team betont, dass keiner der einzelnen Schritte dieses Angriffs für sich genommen von gängigen Sicherheitswerkzeugen erkannt werden würde. Das Repository enthält keinen offensichtlich schädlichen Code. Die Netzwerkaktivität – ein DNS-Lookup auf einen TXT-Eintrag – ist völlig unauffällig. Selbst die eigenen Sicherheitsprüfungen des KI-Agenten schlagen nicht an.
Nur Umgebungen mit sehr strikten Netzwerkzugangskontrollen könnten das Öffnen der Reverse Shell verhindern. Der Großteil der Entwicklungsumgebungen bietet diesen Schutz nicht.
Was das für Entwickler und Unternehmen bedeutet
Das 0din-Team gibt zwei klare Empfehlungen: Erstens sollten Entwickler niemals blindlings einem unbekannten Repository vertrauen, nur weil es äußerlich sauber wirkt. Zweitens sollten KI-Agenten nicht damit beauftragt werden, selbstständig Sicherheitsanalysen durchzuführen – dafür sind sie nicht ausgelegt.
Für Unternehmen, die KI-Coding-Agenten einsetzen oder planen einzusetzen, ergibt sich daraus ein konkreter Handlungsbedarf:
Schränken Sie die Netzwerkzugriffe von Entwicklungsumgebungen konsequent ein.
Etablieren Sie Richtlinien, welche externen Repositories KI-Agenten initialisieren oder konfigurieren dürfen.
Behandeln Sie jeden automatisierten Schritt eines KI-Agenten mit dem gleichen Misstrauen wie manuell ausgeführten fremden Code.
Sensibilisieren Sie Ihr Entwicklungsteam für diese neue Angriffskategorie.
KI-Coding-Agenten sind leistungsfähige Werkzeuge – aber ihre Hilfsbereitschaft lässt sich gezielt ausnutzen. Wer das ignoriert, schafft eine Angriffsfläche, die mit klassischen Sicherheitsansätzen kaum zu schließen ist.
Haben Sie Fragen zur sicheren Nutzung von KI-Tools in Ihrer Entwicklungsumgebung? Das FameSystems-Team berät Sie gerne.