KI-Agenten entwickeln eigenständig Exploits für Sicherheitslücken

Autonome Exploit-Entwicklung im Praxistest

Laut dem neuesten Beitrag in Sean Heelan’s Blog wurden auf Opus 4.5 und GPT-5.2 basierende Agenten damit beauftragt, Exploits für eine zuvor unbekannte Schwachstelle im QuickJS-Javascript-Interpreter zu erstellen. Die Aufgabenstellung umfasste verschiedene Schutzmechanismen und unterschiedliche Zielvorgaben von Shell-Erzeugung über Dateischreiboperationen bis zur Verbindung mit Command-and-Control-Servern.

Das Ergebnis: Die Agenten generierten mehr als 40 verschiedene Exploits über sechs unterschiedliche Szenarien. GPT-5.2 bewältigte sämtliche Aufgaben, während Opus 4.5 zwei Szenarien nicht löste. Der vollständige technische Bericht samt Code wurde auf Github veröffentlicht.

Token-Durchsatz als limitierender Faktor

Die zentrale Erkenntnis des Experiments betrifft die künftige Entwicklung offensiver Cybersecurity. Die verfügbare Token-Kapazität könnte zum entscheidenden Engpass werden – nicht mehr die Anzahl verfügbarer Sicherheitsexperten. Organisationen könnten ihre Fähigkeit zur Exploit-Entwicklung, Netzwerk-Infiltration und Privilegien-Eskalation primär durch ihren Token-Durchsatz skalieren.

Beide Agenten entwickelten aus der QuickJS-Schwachstelle eine funktionale Schnittstelle zum Lesen und Modifizieren des Adressraums im Zielprozess. Diese Fähigkeit mussten sie durch Quellcode-Analyse, Debugging und iteratives Testen selbstständig aufbauen.

Die meisten Aufgaben wurden in unter einer Stunde gelöst. Das Token-Limit von 30 Millionen pro Agent erwies sich als ausreichend für alle Szenarien außer der komplexesten Herausforderung. Bei Opus 4.5 verursachten 30 Millionen Token Kosten von etwa 30 US-Dollar.

Komplexe Schutzmaßnahmen überwunden

Die anspruchsvollste Aufgabe verlangte von GPT-5.2, eine Zeichenfolge in einen bestimmten Dateipfad zu schreiben, während mehrere Schutzmechanismen aktiv waren: Adressraum-Layout-Randomisierung, nicht-ausführbarer Speicher, vollständiges RELRO, feinkörnige CFI, hardware-basierter Shadow-Stack, Seccomp-Sandbox und eine QuickJS-Version ohne OS- und Dateisystem-Zugriffsfunktionen.

Der Agent entwickelte eine Lösung, die sieben Funktionsaufrufe über den Exit-Handler-Mechanismus von glibc verkettete. Diese Aufgabe benötigte 50 Millionen Token und etwa drei Stunden Rechenzeit bei Kosten von rund 50 Dollar.

Einschränkungen der Aussagekraft

Heelan weist auf zwei wesentliche Vorbehalte hin: QuickJS verfügt über deutlich weniger Code und geringere Komplexität als Javascript-Interpreter in Chrome oder Firefox. Die Erkenntnisse lassen Wahrscheinlichkeitsaussagen für künftige Entwicklungen zu, liefern aber keine definitiven Aussagen über aktuelle Fähigkeiten bei komplexeren Zielen.

Die erzeugten Exploits demonstrieren keine neuartigen Durchbrüche bei Schutzmechanismen, sondern nutzen bekannte Schwachstellen – dieselben, die auch menschliche Exploit-Entwickler ausnutzen. Die vollständigen Exploit-Ketten sind jedoch neu, da die QuickJS-Schwachstelle zuvor unbekannt war.

Voraussetzungen für Industrialisierung

Die Automatisierung erfordert laut Heelans Analyse zwei Kernbedingungen: Der Agent muss den Lösungsraum durchsuchen können und benötigt eine präzise, schnelle Verifikationsmöglichkeit ohne menschliche Intervention. Bei Exploits ist dies direkt umsetzbar – funktioniert die normalerweise nicht verfügbare Fähigkeit nach der Ausführung, war der Exploit erfolgreich.

Ein drittes Merkmal beeinflusst die Automatisierbarkeit: Wenn keine Offline-Suche möglich ist und bestimmte Agent-Aktionen die Suche dauerhaft beenden können, wird Industrialisierung schwieriger. Dies betrifft Aufgaben wie initialen Zugriff durch Exploits, laterale Bewegung und Zugriffsaufrechterhaltung, wo eine falsche Aktion zur Entdeckung und Beendigung der Operation führt.

Aktueller Entwicklungsstand

Bei Schwachstellenerkennung und Exploit-Entwicklung lassen sich bereits Token gegen konkrete Ergebnisse eintauschen. Dies zeigt das Aardvark-Projekt von OpenAI: Höherer Token-Einsatz führt zu mehr gefundenen Fehlern besserer Qualität. Auch in Heelans Experimenten bildete das Budget den limitierenden Faktor, nicht die Modelle.

Bei anderen Hacking-Aufgaben fehlen öffentliche Informationen. Der Anthropic-Bericht über ein chinesisches Hackerteam, das deren API für Angriffskoordination nutzt, zeigt zumindest Versuche in diese Richtung. Die Automatisierung von SRE-Arbeit ähnelt konzeptionell der Arbeit eines Hackers im gegnerischen Netzwerk – sollten Unternehmen erfolgreich SRE-Agenten mit Spitzenmodellen verkaufen, wären dieselben Modelle wahrscheinlich auch für Hacking-Aufgaben einsetzbar.

Empfehlungen für Evaluierung

In seinem Blogbeitrag fordert Heelan Frontier Labs und KI-Sicherheitsinstitute auf, ihre Modelle anhand realer Ziele mit Zero-Day-Schwachstellen zu evaluieren und zu veröffentlichen. CTF-basierte Tests mit synthetischen Daten liefern keine ausreichenden Erkenntnisse über Zero-Day-Fähigkeiten bei schwierigen Zielen.

Bei der nächsten großen Modellveröffentlichung wären Angaben wie „X Milliarden Token gegen Linux-Kernel und Firefox eingesetzt, Y Exploits produziert“ wertvoll – unabhängig vom Wert von Y. Entscheidend ist ein sehr hoher Wert für X.

Forschern und Ingenieuren empfiehlt Heelan, sich anspruchsvolle Exploit-Probleme auszusuchen, maximale Token-Mengen einzusetzen und die Ergebnisse zu dokumentieren. Der veröffentlichte Quellcode der Experimente steht für eigene Versuche zur Verfügung.

Entdecke mehr