Die Industrialisierung der LLM-basierten Erstellung von Hacking-Exploits rückt näher

• Auf Basis von Opus 4.5 und GPT-5.2 haben Agenten mit einer QuickJS-Zero-Day-Schwachstelle in sechs Szenarien mehr als 40 Exploits erzeugt
• GPT-5.2 löste alle Aufgaben, Opus 4.5 alle bis auf zwei und zeigte dabei autonome Fähigkeiten zur Codeanalyse, zum Debugging und zum Aufbau von Exploit-Ketten
• Die Versuchsergebnisse deuten darauf hin, dass die Entwicklung von Exploits eher durch Token-Durchsatz als durch die Zahl menschlicher Hacker begrenzt werden könnte
• Schwachstellenerkennung und Exploit-Erzeugung haben bereits ein Stadium erreicht, in dem die Ergebnisse proportional zum eingesetzten Token-Volumen steigen
• Künftig wird die Notwendigkeit einer Automatisierung von Cyberangriffen und einer Neuaufstellung von Sicherheitsbewertungssystemen betont

---

Überblick über das Experiment

• Mit Opus 4.5 und GPT-5.2 wurde ein Experiment zur Exploit-Erzeugung gegen eine Zero-Day-Schwachstelle im QuickJS-JavaScript-Interpreter durchgeführt
  • Dabei kamen verschiedene Exploit-Mitigation-Techniken zum Einsatz (ASLR, NX, RELRO, CFI, Shadow Stack, seccomp usw.)
  • Die Agenten erreichten mehrere Ziele wie Shell-Erzeugung, Dateischreiben und C2-Verbindungen
• GPT-5.2 löste alle Szenarien, Opus 4.5 alle Aufgaben bis auf zwei
  • Jeder Lauf war auf maximal 30 Millionen Token begrenzt und kostete etwa 30 US-Dollar
  • Die schwierigste Aufgabe wurde mit 50 Millionen Token, etwa 3 Stunden und Kosten von 50 US-Dollar gelöst
• GPT-5.2 vollendete in einer Umgebung mit aktivierter seccomp-Sandbox und Shadow Stack einen Dateischreib-Exploit über eine 7-stufige Funktionsaufrufkette unter Nutzung der exit-Handler-Kette von glibc

Grenzen des Experiments

• QuickJS ist deutlich kleiner und weniger komplex als echte Browser-Engines, daher sind die Ergebnisse nur eingeschränkt verallgemeinerbar
• Die erzeugten Exploits entdeckten keine neuen Schwachstellen in den Schutzmechanismen selbst, sondern nutzten bereits bekannte Schwachstellen in der Bereitstellungskonfiguration aus
• Die QuickJS-Schwachstelle selbst wurde neu entdeckt, und der von GPT-5.2 gefundene Lösungsweg wird als neue, bisher nicht dokumentierte Kettenkonstruktion bewertet

Die Industrialisierung von Intrusionen

• Mit „Industrialisierung“ ist ein Zustand gemeint, in dem die Angriffsfähigkeit einer Organisation nicht von der Zahl ihrer Mitarbeitenden, sondern vom Token-Durchsatz bestimmt wird
• Dafür sind zwei Voraussetzungen nötig
  • LLM-basierte Agenten müssen innerhalb einer Umgebung autonom explorieren können
  • Es muss ein präzises und schnelles Verifikationssystem geben
• Die Entwicklung von Exploits ist ein ideales Beispiel dafür, dass diese Bedingungen erfüllt sind
  • Die Umgebung lässt sich leicht aufbauen, und die Verifikationsverfahren sind klar
  • Beispiel: Bei einem Shell-spawnenden Exploit kann der Erfolg über einen Port-Listener verifiziert werden
• Dagegen sind Intrusionen mit Echtzeitinteraktion, Privilegieneskalation, Aufrechterhaltung dauerhaften Zugriffs und Datenausleitung schwerer zu industrialisieren
  • Denn Fehlverhalten in realen Umgebungen kann zur Entdeckung führen

Der aktuelle Stand

• Schwachstellensuche und Exploit-Entwicklung liefern bereits Ergebnisse, die proportional zum eingesetzten Token-Volumen steigen
  • Dasselbe Muster zeigte sich auch im Aardvark-Projekt von OpenAI
  • Auch im Experiment war das Budget die Grenze, nicht die Leistungsfähigkeit des Modells
• Die Automatisierung realer Angriffe innerhalb echter Netzwerke bleibt bislang unsicher
  • Laut einem Bericht von Anthropic gibt es Fälle, in denen chinesische Hacking-Gruppen Angriffe über APIs versucht haben
  • Es gibt jedoch noch kein kommerzialisiertes Beispiel für einen vollständig automatisierten SRE-Agenten (Site Reliability Engineering)
• Falls SRE-Automatisierung gelingt, ist automatisiertes Hacking in gegnerischen Netzwerken wahrscheinlich ebenfalls möglich

Fazit und Empfehlungen

• Dieses Experiment verändert die Wahrnehmung von Umfang und zeitlichem Horizont der Automatisierbarkeit im Cyberraum
• Die derzeitigen Verfahren zur Modellbewertung (CTF, alte Schwachstellen, synthetische Daten) sind ungeeignet, um reale Zero-Day-Angriffsfähigkeiten zu messen
• Frontier-Labore und AI-Sicherheitsinstitutionen sollten Bewertungen an realen Zero-Day-Zielen durchführen, etwa am Linux-Kernel oder an Firefox
  • Es braucht öffentliche Berichte in der Form: „Mit X Milliarden Token wurden Y Exploits erzeugt“
• Nötig sind auch Bewertungen an realer Hardware wie IoT-Firmware
  • Es wird die Möglichkeit aufgezeigt, dass Agenten auf Basis von Opus 4.5 oder GPT-5.2 innerhalb einer Woche praktisch nutzbare Exploits erzeugen können
• Forschenden und Engineers wird empfohlen, solche Experimente selbst durchzuführen und die Ergebnisse zu veröffentlichen
  • Experimenteller Code und Daten sind in einem GitHub-Repository veröffentlicht

[GN⁺]

Hacker-News-Kommentare

• GPT‑5.2 wurde mit der wohl schwierigsten Aufgabe betraut: einen Weg zu finden, eine Zeichenkette in einen bestimmten Pfad auf der Festplatte zu schreiben
  Es handelte sich um eine QuickJS-Umgebung mit sämtlichen Schutzmechanismen aktiviert, darunter ASLR, nicht ausführbarer Speicher, full RELRO, feingranulares CFI, Hardware-Shadow-Stack und eine seccomp-Sandbox
  GPT‑5.2 löste das Problem über die exit-handler-Kette von glibc mit einem Funktionsaufruf in 7 Schritten. Ein wirklich erstaunliches Ergebnis

  • Ich frage mich, ob man diese Mitigations nicht einfach ganz abschaffen sollte
    Reale Exploits laufen meist nach dem Muster „Schwachstelle finden (schwierig)“ und danach „mehrere nutzlose Mitigationsschichten durchbrechen (nervig, aber machbar)“
    Probabilistische Mitigations helfen gegen probabilistische Angriffe, aber Angreifer suchen gezielt nach Schwachstellen
  • Am unteren Ende des Maschinen-Code-Stacks gibt es letztlich zu viele Löcher
    In Zukunft werden wir wohl bedauern, nicht viel früher auf WASM umgestiegen zu sein
    Bis dahin werden wir weiter Hardware-Mitigation auf Hardware-Mitigation stapeln und uns an veralteten Stack-Overwrite-Problemen abarbeiten
  • „der exit handler von glibc“ … gruselig
  • Heutige Kill Chains nutzen meist mehrere Bugs in Kette
    Ich kenne das aus meinem Job, und das Gefühl der Hilflosigkeit wird immer stärker
  • Solche Fälle zeigen, wie anfällig für LLMs in C gebautes QuickJS ist
    Zum Beispiel durch das Leaken eines libc-Pointers via Use-After-Free
    Mit Rust wäre es deutlich schwerer, aber bei vielen libc-Aufrufen ist vollständige Abwehr schwierig

• Der Exploit von GPT‑5.2 hat keine neue Mitigation gebrochen, sondern nur eine bereits bekannte Implementierungslücke ausgenutzt
  Menschliche Hacker brechen Mitigations ebenfalls normalerweise nicht auf neue Weise
  Im CTF-Bereich lösen LLMs inzwischen allerdings immer häufiger pwn-Aufgaben im One-Shot
  Dieser Fortschritt dürfte unvollständige Mitigation-Implementierungen zu Fall bringen und die Forschung zu formaler Exploit-Modellierung vorantreiben

  • Es heißt, „formale Exploit-Modellierung“ sei noch ein unreifes Feld; ich würde gern gute Referenzen dazu sehen

• Aus Sicht eines Sicherheitsforschers ist die von LLMs erzeugte read/write-primitive API nur eine einfache Neukombination bestehender APIs
  Eher nichts grundsätzlich Neues, eher wie ein Spielzeug-Binary für CTFs
  Auffällig ist allerdings, dass aktuelle OpenAI-Modelle offenbar ungern echten Exploit-Code erzeugen; ich frage mich, ob hier Prompt-Umgehung verwendet wurde

• Der Autor hat interessante Punkte angesprochen, aber ich bin nicht besonders besorgt
  Solche Tools lassen sich von Verteidigern symmetrisch ebenfalls nutzen
  Man könnte in CI etwa automatisierte Sicherheitstests ergänzen, indem man ein LLM Red Team laufen lässt

  • Mathematisch ist das nicht symmetrisch
    Angreifer müssen nur ein einziges Mal Erfolg haben, Verteidiger dagegen immer
    Aktuelle Modelle liegen bei pass@x etwa 20–30 % über maj@x
    Trotzdem dürfte ein Red-vs-Blue-Loop das Sicherheitsniveau verbessern
  • In komplexen Systemen bricht diese Symmetrie ohnehin zusammen
    Angreifer müssen nur einen einzigen Fehlschlag finden, Verteidiger müssen alles blockieren
  • Es wird bereits defensiv eingesetzt
    Beispiel: Google Project Zeros Big-Sleep-Projekt
    Zugehörige Schwachstellenlisten gibt es hier
  • Symmetrisch kann es nicht sein
    Angreifer können schon mit einem einzigen Bug etwas waffenfähig machen, Verteidiger müssen alle Bugs finden
    Das ist die asymmetrische Struktur von „any vs all“
  • Es gibt zu viel Software ohne Wartung
    Am Ende könnten nur die LLM-Unternehmen die wirklichen Gewinner sein, weil sie an beide Seiten Tokens verkaufen

• Interessant ist, dass Codex 5.2 den komplexesten Exploit gefunden hat
  Ich selbst nutze meist Opus 4.5, aber der Modus Extra High thinking von Codex 5.2 ist definitiv stark
  Ich glaube nicht, dass sich der LLM-Fortschritt verlangsamt hat. Eher sind die Aufgaben so viel schwieriger geworden, dass man den Fortschritt weniger direkt spürt

  • Tatsächlich hat es den Exploit nicht „gefunden“, sondern nur Code geschrieben, der eine bereits vorgegebene Schwachstelle ausnutzt
    Das Log kann in diesem Repository eingesehen werden
  • Anthropic-Modelle sind eher Tool-User-Typen, OpenAI Codex High eher Reviewer-/Fixer-Typen, Gemini eher kreative Künstler-Typen
    Jeder hat seinen eigenen Stil
  • „Ausreichend schwierige Aufgaben“ sind meist durch unternehmensinternes IP abgeschottet
    Sie werden nicht veröffentlicht, bis ihr kommerzieller Wert verschwunden ist

• QuickJS ist ohnehin ein Spielzeugprojekt mit vielen ungepatchten Schwachstellen
  Ein Exploit gegen ein reales Ziel wie curl wäre deutlich interessanter

• Es gibt zugleich die Behauptung, dass LLMs großartige Exploits schreiben, und die Behauptung, dass sie nutzlose Bug-Reports erzeugen
  Können wirklich beide Aussagen stimmen?

  • Beides ist absolut möglich
    Die Qualität von LLMs hängt von User-Prompts und Interpretationsvermögen ab
    Wenn Experten sie gezielt auswählen und einsetzen, können sehr gute Ergebnisse herauskommen
  • Exploits lassen sich klar danach bewerten, ob sie „funktionieren“, aber CVE-Reports sind viel schwerer zu verifizieren
    Automatisch erzeugte Reports sind für Maintainer eine große Belastung
  • In der Praxis hängt die Qualität stark von der Nutzungsweise ab
    Wenn man einfach sagt „Finde Schwachstellen in diesem Programm“, kommt viel Unsinn heraus, aber
    wenn man Test-Loops und eine Umgebung bereitstellt, verbessert sich das Modell iterativ und liefert am Ende tatsächlich funktionierende Resultate
  • Exploits haben klare Erfolgskriterien und passen deshalb gut zur hartnäckigen Iterativität von LLMs
    Bug-Reports dagegen sind vage und schwer zu bewerten
  • Auch die Budgetstruktur ist anders
    Wenn man etwa unter 100 $ eine echte 50-$-Issue und 5000 falsche Reports im Wert von je 0,01 $ mischt,
    wird es schwer, den echten Diamanten zu finden

• Die Beschreibung der Sandbox war unklar, deshalb war ich anfangs misstrauisch
  Im Repository des Autors sieht man, dass das Ziel darin bestand, die Zeichenkette „PWNED“ nach /tmp/pwned zu schreiben
  Es ging also nicht um einen Sandbox-Escape, sondern nur um eine einfache Einschränkung beim Dateischreiben

  • Das gesamte Repository und der Artikel sind etwas missverständlich aufgebaut
    Auch die Aufforderung, eine OOB-R/W-primitive API zu bauen, lief im Grunde nur auf die Wiederverwendung tausender GitHub-Beispiele hinaus

• Der Satz „Künftig wird die Hacking-Fähigkeit von Staaten oder Organisationen nicht durch die Zahl der Hacker bestimmt, sondern durch den Token-Durchsatz“ ist mir besonders hängen geblieben

  • Tatsächlich ist es gut möglich, dass solche Organisationen die schlampigen Code-Muster von LLMs analysieren und Menschen dann selbst universell einsetzbare Exploits schreiben lassen

• Dass gleichzeitig die Eintrittsbarrieren für Softwareentwicklung und die Eintrittsbarrieren fürs Hacking sinken, ist eine explosive Kombination
  Wir brauchen nun neue Plattformen mit Security-Guardrails und Verifizierbarkeit
  Es ist zu riskant, sich auf von Nichtfachleuten geschriebenen Code zu verlassen

  • Ursprünglich wurde im dritten Absatz das Ungleichgewicht zwischen „einem einzigen Exploit“ und „der Verteidigung des Gesamtsystems“ erwähnt; ich frage mich, warum das gestrichen wurde