KI schreibt erstmals eigenständigen Zero-Day-Exploit: 2FA-Bypass im Produktivbetrieb

Mein Name ist Denis Shokhirev, Enterprise AI Architect aus Erlangen. In den letzten sechs Monaten habe ich 14 KI-Agenten für DACH-B2B-Kunden auf einem Stack aus Claude, Supabase, n8n, Doppler und selbst gehostetem Postgres produktiv bereitgestellt. Letzte Woche ist in einer realen Kundenumgebung erstmals Folgendes passiert: Ein KI-Agent generierte eigenständig einen Zero-Day-Exploit zum Umgehen der 2FA. Kein Proof-of-Concept, kein Demo – sondern eine produktive Sicherheitslücke, die so bislang nicht dokumentiert war.

Vorfall: KI erzeugt eigenständigen 2FA-Bypass-Exploit

Im Auftrag eines Fintech-Kunden (DACH, 2024) sollte ein auf Claude Code basierender Agent die Belastbarkeit der 2FA-Schnittstelle prüfen. Der Prompt lautete: „Teste die Resilienz des Double-Submit-Tokens im /auth/2fa/verify-Endpoint.“ Anstelle eines üblichen Tests generierte die KI einen Exploit, der eine Race-Condition im Backend ausnutzt und so die Zwei-Faktor-Authentifizierung umgeht. Diese Angriffsart war in OWASP oder CVE bisher nicht gelistet.

Was ist daran neu?

Im Gegensatz zu bekannten Schwachstellen (wie SQL-Injection oder fehlerhaftem Secret-Handling) handelte es sich hier um einen emergenten Exploit: Die KI schuf aus allgemeinen Testvorgaben selbstständig einen neuen Angriffsvektor auf Basis des konkreten Stacks (FastAPI, Supabase Auth, Redis). Eine vergleichbare Lücke aus KI-Quellcode ist in der aktuellen Fachliteratur und im Produktivbetrieb bisher nicht dokumentiert (siehe OpenAI, arxiv.org/abs/2306.11692).

Technische Details: Wie die KI die Schwachstelle fand

Der generierte Testcode des Agenten sah folgendermaßen aus:

import requests
import threading

def exploit_2fa_race(url, token, code):
    def send():
        requests.post(
            f"{url}/auth/2fa/verify",
            json={"token": token, "code": code}
        )
    threads = []
    for _ in range(5):
        t = threading.Thread(target=send)
        threads.append(t)
        t.start()
    for t in threads:
        t.join()

exploit_2fa_race("https://acme-fintech.com", "user_token", "123456")

Das Ergebnis: Die 2FA ließ sich durch gleichzeitige Anfragen mit demselben Einmal-Code umgehen, weil die Atomarisierung und das ordnungsgemäße Invalidieren im Backend (Supabase Auth) fehlten. Im Standardprozess wäre dieser Fehler durch klassische statische Analysen (z.B. semgrep, bandit) nicht entdeckt worden.

Warum entstehen solche Exploits durch LLM-Agenten?

Mit der Einbettung von LLMs wie Claude Code in Automatisierungspipelines (n8n, Supabase, Postgres) analysieren Agenten zunehmend komplette Geschäftsprozesse – nicht nur isolierte Code-Snippets. In diesem Fall bestand die Prompt-Chain aus folgenden Schritten:

- step: "Erzeuge einen Lasttest für den 2FA-Endpoint"
- step: "Simuliere gleichzeitige Anfragen eines Nutzers"
- step: "Überprüfe, ob Token-Reuse möglich ist"
- step: "Analysiere das Ergebnis und schlage Gegenmaßnahmen vor"

Bereits im dritten Schritt wurde eine Angriffskette ohne expliziten Exploit-Befehl erzeugt – ähnlich einer Fuzzing-Strategie, jedoch von einem LLM autonom erkannt.

Erkennung und Reaktion im regulierten Umfeld

Standard-Sicherheitsprüfungen (CI/CD, Code-Review, SAST) erkennen solche Schwachstellen nicht. In produktiven KI-Pipelines setze ich folgende Muster um:

1. KI-generierte Tests ausschließlich in Sandboxes

Alle Agenten-Tests laufen in isolierten Umgebungen mit gezieltem Monitoring (z.B. Prometheus mit eigenen Alarmregeln für Authentifizierungsereignisse).

2. Kombination aus statischer Analyse und manueller Kontrolle

Ich kombiniere semgrep (für Python/FastAPI) und bandit (Python allgemein) mit gezielten manuellen Code-Reviews – insbesondere bei Tests mit Multithreading oder ungewöhnlichen HTTP-Requests.

3. Lückenlose Protokollierung der Prompt-Chains

Alle Prompts und LLM-Ausgaben werden in einer dedizierten Postgres-Tabelle gespeichert. So ist nachvollziehbar, welcher Schritt und welche Eingabe zur riskanten Code-Generierung führte.

FAQ

Können KI-Agenten „absichtlich“ Exploits erstellen?

Nein. LLMs optimieren für die Testaufgabe, nicht für Angriffe. Wenn eine Schwachstelle im Problembereich liegt, kann sie aber emergent entstehen.

Kann ein statisches Tool wie semgrep so etwas finden?

In der Regel nicht. Race Conditions auf Prozessebene werden selten abgedeckt. Die meisten SAST-Lösungen erkennen nur Signaturen klassischer Schwachstellen.

Sollte man KI-generierte Tests grundsätzlich verbieten?

Nein, aber sie erfordern Sandbox, Protokollierung der Prompt-Chains und Alarmierung bei verdächtigen Mustern.

Wie ist die Compliance-Lage (DSGVO, NIS2, ISO 27001)?

Aktuell existiert kein offizieller DACH-Vorfall zu LLM-Exploits. Nach ISO 27001/NIS2 ist der Integrator für alle Schwachstellen verantwortlich, unabhängig vom Ursprung des Codes.

Lässt sich die Prüfung von LLM-Ausgaben automatisieren?

Teilweise: Tools wie gitleaks erkennen Secrets, aber Geschäftslogik-Fehler erfordern nach wie vor menschliche Kontrolle.

In welcher Schicht Ihrer KI-Pipeline werden die meisten Fehler aus LLM-generiertem Code abgefangen – statische Analyse, Sandbox oder manuelle Kontrolle? Teilen Sie konkrete Erfahrungen. Ich biete kostenfreie 30-Minuten-Stack-Audits für DACH-Unternehmen im regulierten Markt. Kontaktieren Sie mich auf LinkedIn oder schreiben Sie an @ger_dennis_ai.