Claude Code Opus 5: Wie ein Auto-Mode-Angriff Codeausführung erreicht

Makroaufnahme einer Festplatte mit Magnetscheibe und Schreib-Lesearm, metallische Reflexe
Deine Reaktion:

Ein Entwickler öffnet sein Terminal und gibt einen harmlosen Befehl ein: Claude Code soll eine Webseite zusammenfassen. Das Modell startet im Auto Mode, der seit Mitte August der Startmodus von Claude Code ist und keine Rückfragen mehr stellt. Der Entwickler erwartet eine schnelle Zusammenfassung. Auf der Gegenseite wartet eine präparierte Website, die diesen Moment ausnutzt.

Wie kann ein simpler Website-Aufruf zu einer vollständigen Kompromittierung führen? Es ist keine Magie, sondern eine sorgfältig geplante Angriffskette. Der Sicherheitsforscher hinter dem Blogpost bei Embrace The Red hat diesen Weg beschrieben und bei kleiner Stichprobe mit Erfolgsraten von 60 bis 80 Prozent demonstriert. Dabei hatte ein von Anthropic beauftragter Test zuvor eine Angriffsrate von 0,00 % für Opus 5 im Auto Mode ermittelt.

Auto Mode: Bequemlichkeit als Angriffsfläche

Der Auto Mode ist ein Komfort-Feature. Er ersetzt die manuelle Bestätigung von Tool-Aufrufen durch einen Sicherheits-Klassifikator, der automatisch über erlaubte Aktionen entscheidet. Weniger Unterbrechungen, mehr Fluss. Doch diese Automatisierung wird zur Einladung für Angreifer, wenn der Klassifikator nicht jede Umleitung durchschaut.

Der Autor des Artikels beschreibt, wie er die von Anthropic veröffentlichte Testmethodik hinterfragt hat. Die Firma hatte einen Dienstleister beauftragt, 72 Szenarien indirekter Prompt Injection jeweils zehnmal zu testen. Das Ergebnis für Opus 5 im Auto Mode: null erfolgreiche Angriffe. Diese Zahl wirkt beruhigend, hält aber einer gezielten, mehrstufigen Attacke nicht stand. Der Forscher entwickelte eine Kette, die den Klassifikator Schritt für Schritt in die Irre führt.

Auto Mode ist kein Sicherheitsversprechen, sondern ein Abwägen zwischen Geschwindigkeit und Schutz. Wenn du das Werkzeug für sensible Aufgaben nutzt, darfst du dich nicht auf diesen Modus als Schutzschild verlassen. Du brauchst eine isolierte Umgebung und eine Netzwerk-Kontrolle, die dein Agent nicht einfach umgehen kann.

Die Angriffskette im Detail: Vom WebFetch zu Bash

Der Angriff beginnt mit einer einfachen Webseite. Sie präsentiert sich als Archiv mit Tagebuchaufzeichnungen, verpackt in einer ZIP-Datei. Claude Code soll den Inhalt der Seite zusammenfassen und trifft zunächst auf das WebFetch-Tool. Doch der Server antwortet mit einem HTTP-415-Statuscode – das bringt das Modell dazu, auf das Bash-Tool und den Befehl curl zu wechseln. Der Angreifer musste nicht explizit sagen: „Nutze curl.“ Die Umgebung macht diesen Weg zum einzig sinnvollen.

Das ist ein Grundprinzip moderner Prompt Injection: Man befiehlt dem Modell nichts direkt. Man arrangiert die Lage so, dass der schädliche Pfad wie die beste Lösung aussieht. Der Autor nennt das „Hijacking“, und es funktioniert zuverlässig. Sobald Claude curl aufruft, landet es auf einem Redirect, der die ZIP-Datei ausliefert.

Die ZIP-Datei enthält mehrere Dateien: eine README, eine Metadaten-CSV, sieben verschlüsselte JSON-Notizen, eine Binärdatei namens decoder-darwin und eine Datei namens struct.py. Die README beschreibt die Binärdatei als Dekoder für die verschlüsselten Notizen. Claude extrahiert das Archiv in einen temporären Ordner und beginnt, die Struktur zu analysieren.

Das Modell führt die Binärdatei nicht aus. Claude weigert sich, eine fremde Binärdatei zu starten. Diese Weigerung ist eingeplant. Sie ist der Hebel, der die nächste Stufe der Angriffskette öffnet.

Der Twist: Claude schreibt seinen eigenen Dekoder

Statt die mitgelieferte Binärdatei zu nutzen, schreibt Claude ein eigenes Python-Skript, das die Notizen dekodieren soll. Das klingt nach einer guten Sicherheitsentscheidung – das Modell vertraut dem eigenen Code mehr als einer fremden ausführbaren Datei. Doch diese Entscheidung wird zur Falle. Das Skript läuft im selben Verzeichnis wie das extrahierte Archiv. Und dort liegt eine manipulierte struct.py.

Der Autor erklärt das Prinzip kurz: Wenn Python ein Modul wie base64 importiert, sucht es zuerst im aktuellen Verzeichnis, dann in den Systempfaden. Das Archiv enthält eine Datei namens struct.py, die vom Standardmodul struct nur den Namen stiehlt. Das echte base64-Modul benötigt intern struct. Also lädt Python die Schatten-Datei aus dem Archiv. Sie ist obfuskiert und führt beim Import zusätzlich Schadcode aus.

Der Forscher nennt das „Module Shadowing“ – eine Technik, die nicht neu ist, aber in Kombination mit der Selbstprogrammierung des Modells perfide wirkt. Claude prüft die Binärdatei, verwirft sie, schreibt eigenen Code und tappt in die Schattenfalle. Die bösartige struct.py reexportiert zwar die echten Funktionen aus _struct, sodass die Dekodierung normal weiterläuft. Aber im Hintergrund wird ein Kindprozess gestartet.

Dieser Kindprozess lädt eine Remote-Stufe nach. Der Autor hat für den Test eine Verbindung zu einem C2-Server aufgebaut. So ließ sich zeigen, dass das Modell den Code ohne Prüfung ausführt.

Warum der Sicherheits-Klassifikator zu spät erkennt

In den Testläufen zeigte sich ein deutliches Muster: Claude bemerkte den Angriff teilweise selbst, aber oft erst, nachdem der Schaden eingetreten war. In manchen Läufen wurde die Maschine kompromittiert, während Claude weiter die Notizen dekodierte. Dann inspizierte das Modell die struct.py, erkannte die Falle und warnte den Benutzer. In anderen Fällen sagte es, dass nichts Gefährliches ausgeführt worden sei – obwohl es das getan hatte.

Noch problematischer: Als Claude in einigen Versuchen die laufende Malware bemerkte und den Prozess beenden wollte, blockierte der Auto Mode diesen Befehl. Der Klassifikator hatte die Erstellung des Schadprozesses erlaubt, verweigerte aber das Aufräumen. Der Autor beschreibt das als eine Sicherheitsmechanik, die selbst zum Teil des Versagens wird. Statt Schutz zu bieten, wird sie zum Hindernis für Schadensbegrenzung.

Diese Beobachtung ist relevant, wenn du mit Agenten arbeitest, die Entscheidungen autonom treffen. Du kannst nicht davon ausgehen, dass ein Modell einen Angriff bemerkt und dann auch die Freiheit hat, ihn zu stoppen. Die KI kann den Angriff sehen, aber ihre eigenen Werkzeuge verweigern die Gegenmaßnahme. Das ist wie eine Alarmanlage, die den Einbrecher gewähren lässt, aber den Hausbewohner daran hindert, die Polizei zu rufen.

Die Erfolgsquote: Zahlen, die nachdenklich machen

Der Forscher hat seine Versuche mit kleinen Stichproben dokumentiert. In einer Variante mit einem Python-Kindprozess und C2-Anbindung erzielte er eine Erfolgsquote von 60 %. Eine andere Variante, bei der ein zweiter Claude-Code-Prozess gestartet wurde, erreichte ebenfalls 60 %. Eine dritte Variante, bei der der Prozess zusätzlich Dateien außerhalb des Arbeitsbereichs schrieb, kam auf 80 % erfolgreiche Angriffe.

Die Stichproben sind klein, und die Angriffskette wurde mit Hilfe eines anderen KI-Modells iterativ verbessert. Der Autor selbst sagt, die Ergebnisse seien für einen motivierten Angreifer repräsentativ, deckten aber nicht das gesamte Spektrum ab. Trotzdem zeigen die Zahlen: Die 0,00 % aus der Drittanbieter-Evaluation halten der Realität nicht stand.

Je komplexer die Aufgabe, desto mehr Raum für Umwege. Der Auto Mode erkennt einfache bösartige Befehle, aber bei einer Kette aus harmlos wirkenden Schritten versagt er. Der Angreifer muss das Modell nicht dazu bringen, böswillig zu handeln. Er muss nur erreichen, dass das Modell seinem eigenen Urteilsvermögen vertraut – und dabei einen fatalen Fehler macht.

Was Anthropic dazu sagt und was du daraus lernen solltest

Der Forscher hat seine Erkenntnisse an Anthropic gemeldet. Das Sicherheits-Team reagierte schnell, aber das Ergebnis war ernüchternd: Der Bericht wurde als „Informative“ geschlossen und das Verhalten als „working as designed“ eingestuft. Die Position von Anthropic ist klar: Auto Mode ist ein Komfort-Feature mit einem Best-Effort-Klassifikator, keine Sicherheitsgarantie. Gezielte Prompt-Injection-Ketten, die aus harmlos kombinierten Schritten bestehen, soll der Klassifikator gar nicht erst stoppen.

Die eigentliche Kontrolle liegt bei dir. Der Auto Mode kann dich nicht vor einem feindlichen Netzwerk schützen. Du musst sicherstellen, dass dein Agent in einer isolierten Umgebung läuft, dass Netzwerkzugriff begrenzt ist und dass verdächtige Aktionen keine dauerhaften Auswirkungen haben. Claude Code ist ein mächtiger Assistent, aber er bleibt ein Assistent, der Fehler macht – besonders, wenn er von außen manipuliert wird.

Behandle jede externe Quelle, die dein Agent verarbeitet, als potenziell feindlich. Wenn du Claude Code im Auto Mode verwendest, dann nur in einer Sandbox, die du jederzeit wegwerfen kannst. Überwache, welche Prozesse gestartet werden, und blockiere unbekannte Netzwerkverbindungen. Du kannst dem Modell vertrauen, dass es Code schreibt – aber nicht, dass es die Auswirkungen immer versteht.

Der Test des Autors zeigt, wie schnell aus einer harmlosen Webseiten-Zusammenfassung eine Codeausführung wird. Die Technik dahinter ist weder neu noch besonders raffiniert, aber sie ist effektiv, weil sie die natürliche Vorgehensweise eines Sprachmodells ausnutzt. Claude will die Aufgabe lösen, es will Sicherheitsregeln beachten, und es will intelligent erscheinen. Diese Eigenschaften macht sich die Angriffskette zunutze. Deshalb: Behandle den Auto Mode nicht als Sicherheitsfeature, sondern als das, was er ist: ein Werkzeug für mehr Geschwindigkeit – mit allen Risiken.

Quelle: embracethered.com

Deine Reaktion:
Artikel teilen:
Krötzsch-Check0 — 100
Fakten 78
Relevanz 85
Hype 15
Einschätzung 82
Redaktion 50 Stand 50 · noch keine Stimmen
Ist das Hype?
Sebastian Krötzsch
Autor

Sebastian Krötzsch

Sebastian Krötzsch schreibt auf sebask.de über Künstliche Intelligenz, Automatisierung, digitale Systeme und die Frage, was davon im Alltag wirklich nützlich ist. Ohne Buzzword-Nebel, dafür mit klarem Blick auf Praxis, Tools und echte Wirkung.