Acht Minuten. So lange brauchte ein Angreifer, unterstützt durch Large Language Models, um von gestohlenen Zugangsdaten in einem öffentlichen S3-Bucket zu vollem Admin-Zugriff auf eine AWS-Umgebung zu gelangen. Das Sysdig Threat Research Team dokumentierte den Einbruch am 28. November 2025. Die im Februar 2026 veröffentlichten Ergebnisse liefern eine der detailliertesten Fallstudien zu KI-beschleunigten Cloud-Angriffen. Der Angreifer kompromittierte 19 verschiedene AWS-Principals, missbrauchte Amazon Bedrock für den Zugriff auf sechs verschiedene LLM-Familien, injizierte Schadcode in Lambda-Funktionen und versuchte GPU-Instanzen für Krypto-Mining hochzufahren.
Das ist keine Red-Team-Übung und kein Proof-of-Concept aus einem Forschungslabor. Es passierte in einer produktiven Umgebung.
Phase 1: Offene Credentials und sofortiges LLMjacking
Der Angriff begann mit etwas, das es 2026 nicht mehr geben sollte: Zugangsdaten in einem öffentlichen S3-Bucket. Der Bucket enthielt Retrieval-Augmented-Generation-Daten (RAG) für KI-Modelle, und zwischen diesen Daten lagen IAM-User-Credentials mit Lese-/Schreibrechten auf AWS Lambda und eingeschränktem Zugriff auf Amazon Bedrock.
Innerhalb von Minuten nach dem Zugriff wechselte der Angreifer zu LLMjacking. Diese von Sysdig Mitte 2024 erstmals dokumentierte Technik nutzt kompromittierte Cloud-Credentials für den Zugriff auf gehostete LLMs. Der Angreifer rief Modelle aus sechs verschiedenen Familien über Bedrock ab: Anthropic Claude, Meta Llama, DeepSeek, Amazon Nova Premier, Amazon Titan Image Generator und Cohere Embed. Die potenziellen Kosten für das Opfer allein aus dieser Phase können $46.000 pro Tag übersteigen, wenn Angreifer Quota-Limits über mehrere Regionen hinweg maximieren.
Das LLMjacking diente zwei Zwecken. Der Angreifer nutzte die Modelle zur Generierung von Schadcode für die nachfolgenden Angriffsphasen, während er gleichzeitig das Bedrock-Kontingent des Opfers verbrannte, eine Ressource, die sich direkt in Geld umrechnet.
Warum LLMjacking gefährlicher ist als klassischer Credential-Diebstahl
Klassischer Credential-Diebstahl verschafft Zugang zu Infrastruktur. LLMjacking verschafft Zugang zu Intelligenz. Der Angreifer bekommt nicht nur Rechenleistung, sondern einen On-Demand-Codegenerator, einen Aufklärungsassistenten und ein Entscheidungsunterstützungssystem. Die Modelle übernehmen Fehleranalyse, generieren Exploit-Skripte und reagieren auf unerwartete API-Antworten schneller als jeder menschliche Operator. Sysdig stellte fest, dass der Angreifer eine Umgehungstechnik einsetzte: max_tokens_to_sample wurde auf -1 gesetzt, was eine Validierungsausnahme statt einer Zugriffsverweigerung auslöst und so die Gültigkeit der Credentials bestätigt, ohne Sicherheitswarnungen auszulösen.
Phase 2: Lambda-Code-Injection und Privilegien-Eskalation
Mit validierten Credentials und etabliertem LLM-Zugriff ging der Angreifer zur Privilegien-Eskalation über. Das Ziel: eine bestehende Lambda-Funktion namens EC2-init.
Der kompromittierte IAM-User hatte UpdateFunctionCode- und UpdateFunctionConfiguration-Berechtigungen für Lambda. Der Angreifer ersetzte den Code der Funktion durch einen LLM-generierten Payload, der drei Operationen durchführte:
- IAM-User-Enumeration mit Access-Key-Extraktion über das gesamte Konto
- S3-Bucket-Auflistung und Inhaltsabruf mit Fokus auf Secrets, Konfigurationsdateien und weitere Credentials
- Cross-Account-Rollenübernahme mit Versuchen, die
OrganizationAccountAccessRoleüber verbundene AWS-Konten hinweg zu übernehmen
Der injizierte Code trug mehrere Kennzeichen von LLM-Generierung. Kommentare waren auf Serbisch verfasst. AWS-Account-IDs im Code waren halluziniert, mit auf- und absteigenden Ziffernmustern (123456789012, 210987654321) statt realer Kontonummern. Referenzen verwiesen auf nicht existierende GitHub-Repositories für ML-Trainings-Skripte. Der Code zeigte außerdem eine ungewöhnlich umfassende Fehlerbehandlung, typisch für LLM-Output, aber untypisch für menschlich geschriebenen Exploit-Code.
Der Angreifer erhöhte das Ausführungs-Timeout der Lambda-Funktion von 3 auf 30 Sekunden, um dem Payload genügend Zeit für die Enumeration zu geben.
Der Geschwindigkeitsvorteil
In dieser Phase wird die KI-Beschleunigung am deutlichsten sichtbar. Ein menschlicher Angreifer müsste IAM-Berechtigungen manuell enumerieren, ausnutzbare Konfigurationen identifizieren, den Injection-Payload schreiben, testen und bei Fehlern iterieren. Das LLM komprimierte diesen Workflow in einen einzigen Codegenerierungsschritt. CSO Online berichtete, dass die gesamte Privilegien-Eskalationsphase, von der Lambda-Injection bis zum Admin-Zugriff, innerhalb des 8-Minuten-Fensters abgeschlossen wurde.
Phase 3: Laterale Bewegung über 19 AWS-Principals
Der Lambda-Payload funktionierte. Der Angreifer kompromittierte 19 verschiedene AWS-Principals: 6 verschiedene IAM-Rollen über 14 Sitzungen, plus 5 IAM-User. Er erstellte einen neuen User mit Admin-Rechten namens “frick” als Persistenz-Mechanismus.
Die Ziele der Datenexfiltration zeigen einen erfahrenen Operator mit fundiertem Verständnis der Cloud-Architektur:
- AWS Secrets Manager: Credentials für nachgelagerte Dienste
- EC2 Systems Manager: Parameter mit Datenbankverbindungen und API-Keys
- CloudWatch Logs: Aufklärung über laufende Workloads
- Lambda-Funktions-Quellcode: Identifizierung weiterer Angriffsflächen
- CloudTrail Events: Analyse aktiver Logging- und Erkennungsmechanismen
Das letzte Ziel, CloudTrail, ist besonders aufschlussreich. Der Angreifer prüfte die Erkennungsfähigkeiten, bevor er über das weitere Vorgehen entschied. Das ist kein blindes Vorgehen. Es ist methodisch, und der LLM-generierte Code übernahm die Entscheidungslogik.
Phase 4: GPU-Kapern und die JupyterLab-Hintertür
Nach Erlangung des Admin-Zugriffs wechselte der Angreifer zur Monetarisierung. Er fragte EC2 nach Amazon Machine Images ab, die für Deep-Learning-Anwendungen geeignet sind, und versuchte GPU-Instanzen der Oberklasse zu starten. The Register berichtete, dass der Angreifer SSH-Keys und Security Groups vorbereitete und dann eine kostspielige GPU-Instanz mit Skripten zum Installieren von CUDA, zum Deployen von Training-Frameworks und zum Öffnen eines öffentlichen JupyterLab-Interfaces auf Port 8888 startete.
Der JupyterLab-Server ist das Detail, das Sicherheitsteams beachten sollten. Wie Sysdig feststellte, fungiert er als “Hintertür zur Instanz, die keine AWS-Credentials benötigt”. Jeder, der die URL entdeckt, kann beliebigen Code auf der GPU-Instanz ausführen, ohne sich bei AWS zu authentifizieren. Die Instanz wurde nach 5 Minuten beendet, vermutlich weil AWS-Quota-Limits griffen oder automatische Erkennung auslöste.
Diese Monetarisierungsphase ist der Endpunkt, der moderne Cloud-Angriffe von klassischen Einbrüchen unterscheidet. Der Angreifer ist nicht primär an Daten interessiert (obwohl er reichlich mitnahm). Er will Rechenressourcen, speziell GPU-Zeit, für ML-Training-Workloads, Inhaltsgenerierung oder den Weiterverkauf des Zugangs an andere Operatoren.
Was sich für DACH-Unternehmen ändern muss
Die Sysdig-Angriffskette legt fünf Schwachstellen offen, die die meisten AWS-Umgebungen teilen. Für Unternehmen im DACH-Raum kommen regulatorische Anforderungen durch den EU AI Act und die DSGVO hinzu.
1. Credentials in öffentlichen S3-Buckets
Das darf es 2026 nicht mehr geben. Jeder S3-Bucket mit Zugangsdaten, RAG-Daten oder Konfigurationsdateien muss über S3 Block Public Access auf Kontoebene gesperrt sein. Im DACH-Raum ist die Offenlegung personenbezogener Daten über öffentliche Buckets zudem ein DSGVO-Verstoß, der Bußgelder von bis zu 4% des Jahresumsatzes nach sich ziehen kann.
2. Lambda-Berechtigungen sind zu breit
UpdateFunctionCode und UpdateFunctionConfiguration auf Lambda sind faktisch Code-Ausführungsberechtigungen. Wenn ein IAM-User beide plus PassRole hat, kann er beliebigen Code injizieren, der mit der Ausführungsrolle der Lambda-Funktion läuft. Diese Berechtigungen müssen auf spezifische Funktionen beschränkt werden, nicht auf Wildcards, und UpdateFunctionCode-Events müssen in CloudTrail überwacht werden.
3. Amazon Bedrock Logging ist standardmäßig deaktiviert
Model Invocation Logging für Bedrock ist nicht standardmäßig aktiviert. Ohne dieses Logging hinterlässt LLMjacking keine Audit-Spur. Aktivieren Sie Model Invocation Logging nach CloudWatch und S3 und erstellen Sie Service Control Policies (SCPs), die den Bedrock-Zugriff auf die tatsächlich genutzten Modelle beschränken.
4. Cross-Account-Rollenübernahmen werden nicht überwacht
Der Angreifer versuchte, OrganizationAccountAccessRole über verbundene Konten hinweg zu übernehmen. Diese Rolle existiert standardmäßig in AWS Organizations-Mitgliedskonten und gewährt Admin-Zugriff. AssumeRole-Aufrufe für diese Rolle müssen überwacht und durch Trust-Policy-Bedingungen eingeschränkt werden.
5. Erkennungszeit in Stunden, Angriffe in Minuten
Das strukturelle Problem: Ihr SOC operiert im menschlichen Zeitmaßstab. Dieser Angriff operierte im Maschinenzeitmaßstab. Darktrace’s 2026-Umfrage ergab, dass nur 14% der Organisationen ihren KI-Verteidigungssystemen autonome Gegenmaßnahmen erlauben. Wenn ein Angriff in 8 Minuten abgeschlossen ist, ist eine mittlere Reaktionszeit von 30 Minuten um den Faktor vier zu langsam.
Das größere Bild: KI-Kompression der Kill Chain
Der Sysdig-Angriff ist kein Einzelfall. Er ist ein Datenpunkt in einem Trend. Palo Alto Networks’ Unit 42 demonstrierte, wie KI-Agenten eine vollständige Ransomware-Kampagne auf 25 Minuten komprimieren. Anthropic legte offen, dass die chinesische staatsnahe Gruppe GTG-1002 Claude für 80-90% einer Spionagekampagne über 30 Organisationen nutzte.
Was den Sysdig-Fall besonders macht, ist die Konkretheit. Es ist kein kontrollierter Test. Der Angriff geschah in einer realen Umgebung, gegen reale Infrastruktur, mit realen Konsequenzen. Der LLM-generierte Code mit serbischen Kommentaren und halluzinierten Account-IDs liefert forensische Beweise für KI-Beteiligung, die schwerer zu bestreiten sind als theoretische Fähigkeiten.
Für Cloud-Sicherheitsteams im DACH-Raum ist die Schlussfolgerung konkret: Ihre Erkennungs- und Reaktions-Workflows wurden für Angriffe in menschlicher Geschwindigkeit konzipiert. Sie müssen für Angriffe in Maschinengeschwindigkeit umgestaltet werden. Das bedeutet automatische Credential-Rotation, Echtzeit-Anomalie-Erkennung bei Lambda-Code-Änderungen, Bedrock-Invocation-Monitoring und die Befugnis für KI-gestützte Verteidigungssysteme, ohne menschliche Genehmigung zu handeln.
Die 8-Minuten-Uhr tickt.
Häufig gestellte Fragen
Wie gelang der AWS-Einbruch in nur 8 Minuten?
Die Angreifer nutzten Zugangsdaten aus einem öffentlichen S3-Bucket und setzten Large Language Models ein, um Aufklärung zu automatisieren, schadhaften Lambda-Funktionscode für die Privilegien-Eskalation zu generieren und sich über 19 AWS-Principals lateral zu bewegen. Die gesamte Kette von initialem Zugriff bis zu Admin-Rechten dauerte unter 10 Minuten, die kritische Eskalationsphase wurde in 8 Minuten abgeschlossen.
Was ist LLMjacking?
LLMjacking ist eine Technik, bei der Angreifer gestohlene Cloud-Credentials nutzen, um auf gehostete Large Language Models wie Amazon Bedrock zuzugreifen. Der Angreifer verwendet das LLM-Kontingent des kompromittierten Kontos, um Schadcode zu generieren, Aufklärung durchzuführen und während eines Angriffs Echtzeit-Entscheidungen zu treffen. Die Kosten für das Opfer können über 46.000 Dollar pro Tag betragen.
Wie können Unternehmen LLMjacking auf AWS erkennen?
Aktivieren Sie Model Invocation Logging für Amazon Bedrock, das standardmäßig deaktiviert ist. Überwachen Sie ungewöhnliche Bedrock-API-Aufrufe, insbesondere von IAM-Principals, die normalerweise keine Modelle aufrufen. Erstellen Sie Service Control Policies (SCPs), die den Bedrock-Zugriff auf genehmigte Modelle beschränken. Achten Sie auf die Umgehungstechnik, max_tokens_to_sample auf -1 zu setzen.
Welche AWS-Berechtigungen ermöglichten den Lambda-Code-Injection-Angriff?
Der Angreifer nutzte UpdateFunctionCode- und UpdateFunctionConfiguration-Berechtigungen auf AWS Lambda aus. Diese erlaubten es, den Code einer bestehenden Lambda-Funktion (EC2-init) durch einen schadhaften Payload zu ersetzen und das Ausführungs-Timeout von 3 auf 30 Sekunden zu erhöhen. Zusammen mit PassRole-Berechtigungen gab dies dem Angreifer Code-Ausführungsmöglichkeiten unter der IAM-Rolle der Lambda-Funktion.
Was bedeutet der Sysdig-Fall für die DSGVO-Compliance?
Die Offenlegung von Credentials über öffentliche S3-Buckets kann einen DSGVO-Verstoß darstellen, wenn personenbezogene Daten betroffen sind. Unternehmen müssen nach Art. 32 DSGVO angemessene technische und organisatorische Maßnahmen treffen. KI-beschleunigte Angriffe verkürzen das Reaktionsfenster auf Minuten, was automatisierte Erkennung und Reaktion zur Pflicht macht, um die 72-Stunden-Meldepflicht nach Art. 33 überhaupt einhalten zu können.