Acht Minuten bis AWS-Admin: Wie ein offener S3-Bucket und eine Admin-Lambda reichten
Ein Angreifer übernahm laut Sysdig ein AWS-Konto in acht Minuten. Der Weg führte über einen offenen S3-Bucket und eine Lambda-Rolle mit Admin-Rechten. Die KI hat den Angriff nur beschleunigt.
6 Min. Lesezeit
Am 28. November 2025 übernahm ein Angreifer ein komplettes AWS-Konto in acht Minuten. Vom ersten gestohlenen Zugangsschlüssel bis zu vollen Administratorrechten. Dokumentiert hat den Fall das Sicherheitsteam von Sysdig. Brisant ist die Geschwindigkeit: Eine KI erledigte Aufklärung und Skripterstellung in Echtzeit. Der Türöffner selbst war ein bekannter Konfigurationsfehler.
Das Wichtigste in Kürze
- Acht Minuten bis Admin: Laut Sysdig kompromittierte ein Angreifer ein AWS-Konto in unter zehn Minuten. Über gestohlene Schlüssel aus einem offenen S3-Bucket bis zu einem selbst angelegten Admin-Nutzer.
- Der Fehler saß in der Config: Eine Lambda-Funktion trug eine Ausführungsrolle mit Administratorrechten. Wer die Funktion umschreiben durfte, erbte diese Rechte. Ein neuer Exploit war nicht nötig.
- Die KI war der Turbo: Sie schrieb Angriffscode und erkundete das Konto in Echtzeit. Der Branchen-Median für Angriffe liegt laut Mandiant trotzdem bei 14 Tagen. Der Achtminuten-Fall ist die Ausnahme mit besonderen Voraussetzungen.
Verwandt:Wie eine Argo-CD-Lücke den ganzen Cluster öffnet / AWS und Azure unter EU-Aufsicht
Acht Minuten vom S3-Bucket zum Admin-Schlüssel
Der Einstieg lag offen im Netz. In einem öffentlich erreichbaren S3-Bucket lagen Trainingsdaten für ein KI-System, darunter gültige Zugangsschlüssel eines IAM-Nutzers. Dieser Nutzer durfte wenig, aber eine Berechtigung genügte: Er konnte den Code einer bestimmten Lambda-Funktion ändern. Die Funktion hieß EC2-init. An ihr hing eine Ausführungsrolle mit Administratorrechten.
Von hier lief alles schnell. Der Angreifer schrieb die Funktion um, ließ sie neue Zugangsschlüssel für einen Admin-Nutzer namens frick erzeugen und las das Ergebnis direkt aus der Antwort der Funktion. Kein Umweg über einen externen Server, kein Reverse Shell. Anschließend griff er auf 19 verschiedene AWS-Identitäten zu, legte einen zweiten Hintertür-Admin an und sicherte sich so den Zugang mehrfach ab.
Dann wurde es teuer. Über den KI-Dienst Amazon Bedrock zapfte der Angreifer fremde Sprachmodelle auf Kosten des Opfers an. Parallel startete er eine GPU-Instanz für rund 30 Euro pro Stunde, um eigene Modelle zu rechnen. AWS beendete die Instanz nach fünf Minuten wegen Kapazitätsgrenzen. Verräterisch war der Code selbst: serbische Kommentare und erfundene AWS-Konto-Nummern verrieten, dass ein Sprachmodell mitgeschrieben hatte.
Kein Zero-Day, sondern eine Kette bekannter Fehler
Die Achtminuten-Zahl klingt nach einem Bruch mit allem, was man über Cloud-Sicherheit weiß. Der Blick auf den Angriffspfad zeigt das Gegenteil. Keine unbekannte Schwachstelle, kein KI-spezifischer Exploit. Jeder einzelne Schritt nutzte eine dokumentierte Fehlkonfiguration.
Langlebige Zugangsschlüssel lagen in einem öffentlichen Bucket. Eine Lambda-Ausführungsrolle trug Administratorrechte, obwohl sie diese nie gebraucht hätte. Ein schwach berechtigter Nutzer durfte fremden Funktionscode überschreiben. Diese drei Fehler zusammen ergaben die Kette. Jeder für sich ist seit Jahren bekannt und in jedem AWS-Härtungsleitfaden benannt.
Die KI hat den Angriff beschleunigt und automatisiert. Ermöglicht hat sie ihn nicht. Wer den Fall als Beleg dafür liest, dass KI die Cloud unsicher macht, verfehlt die eigentliche Ursache. Und damit die Stelle, an der Verteidigung wirkt. Die Ursache ist reparierbar, ganz ohne KI-Abwehr.
Warum die Minuten-Zahl in die Irre führt
Ein zweiter Datenpunkt rückt die Sache zurecht. Googles Sicherheitseinheit Mandiant wertet jedes Jahr hunderttausende Stunden Incident-Response aus. Im Report M-Trends 2026 vom 23. März steht ein Satz, der der Panik widerspricht: Man betrachte 2025 nicht als das Jahr, in dem Angriffe direkt durch KI entstanden.
Die Zahlen stützen das. Die mediane Verweildauer eines Angreifers im Netz stieg 2025 auf 14 Tage, von 11 im Jahr davor. In 52 Prozent der Fälle bemerkten die Unternehmen den Einbruch zuerst selbst. Ausgenutzte Schwachstellen bleiben mit 32 Prozent der häufigste Einstiegsweg, im sechsten Jahr in Folge. Das Gros der Angriffe bewegt sich weiter im Tage- und Wochenmaßstab.
Der Achtminuten-Fall ist real, aber er ist der Ausreißer, kein neuer Durchschnitt. Er wurde nur so schnell, weil die Voraussetzungen ideal lagen. Für Verteidiger ist das die gute Nachricht: Wer diese Voraussetzungen beseitigt, nimmt dem schnellen Angriff die Grundlage.
Fünf Schritte, die AWS-Konten jetzt härten
Kein Hersteller-Patch löst das Problem, denn es liegt in der Einrichtung. Genau dort lässt es sich beheben. Die Reihenfolge ist nach Wirkung sortiert.
- Langlebige Schlüssel abschaffen. Statt dauerhafter IAM-Schlüssel gehören kurzlebige Rollen und temporäre Anmeldedaten in den Regelbetrieb. Ein geleakter Schlüssel, der nach einer Stunde wertlos ist, öffnet keine Tür mehr.
- Admin von Ausführungsrollen trennen. Keine Lambda-Funktion braucht Administratorrechte, um ihre Aufgabe zu erledigen. Jede Ausführungsrolle bekommt genau die Rechte ihrer Funktion, nicht mehr.
- Öffentliche Buckets aufspüren. S3-Buckets mit Trainingsdaten landen leicht versehentlich im Netz. Ein regelmäßiger Scan auf offene Buckets und darin liegende Zugangsdaten schließt den häufigsten Einstieg.
- Bedrock per Leitplanke sichern. Service Control Policies begrenzen, wer teure KI-Dienste und GPU-Instanzen überhaupt starten darf. Das deckelt den Schaden, wenn ein Konto doch fällt.
- Laufzeit überwachen. Neue Admin-Nutzer, fremde Bedrock-Aufrufe und plötzlich gestartete GPU-Instanzen sind klare Signale. Wer sie in Echtzeit sieht, stoppt den Angriff mitten im Lauf.
Fehlkonfiguration gegen gehärtetes Setup
Der Unterschied zwischen dem Achtminuten-Konto und einer sicheren Umgebung liegt nicht in einem neuen Werkzeug. Er liegt in Voreinstellungen, die man kennen und setzen muss.
| Aspekt | Der verwundbare Fall | Gehärtetes Setup |
|---|---|---|
| Zugangsschlüssel | langlebig, im offenen Bucket | kurzlebige Rollen |
| Lambda-Ausführungsrolle | Administratorrechte | nur Funktionsrechte |
| S3-Buckets | öffentlich mit Zugangsdaten | privat, regelmäßig gescannt |
| Wirkung eines geleakten Schlüssels | Weg zum Konto-Admin | nach einer Stunde wertlos |
Was Teams aus dem Fall mitnehmen
Die Aufregung um die acht Minuten lenkt vom eigentlichen Befund ab. Der Angriff war schnell, weil die Basis-Hygiene fehlte. Kurzlebige Anmeldedaten, sparsam vergebene Rollen und ein Blick auf offene Buckets hätten die Kette an jeder Stelle unterbrochen. Diese Maßnahmen sind alt, unspektakulär und wirksam.
Ein Detail sollte Verteidiger zusätzlich wachrütteln. Sysdig warnt, dass die verräterischen KI-Spuren im Code bald verschwinden. Bessere Agenten schreiben keine serbischen Kommentare und erfinden keine Konto-Nummern mehr. Das Fenster, in dem sich ein KI-gestützter Angriff am Code erkennen lässt, schließt sich. Bleibt die Härtung, die schon heute jeden dieser Schritte ausbremst.
Häufige Fragen
Was ist LLMjacking?
Beim LLMjacking übernehmen Angreifer gestohlene Cloud-Zugänge, um über Dienste wie Amazon Bedrock teure Sprachmodelle laufen zu lassen. Die Rechnung zahlt das Opfer. Im Sysdig-Fall zapfte der Angreifer fremde Modelle an und startete zusätzlich eine GPU-Instanz auf fremde Kosten.
Stammt die Achtminuten-Zahl von Google beziehungsweise GTIG?
Nein. Der konkrete Achtminuten-Fall stammt vom Sicherheitsteam von Sysdig. Googles Mandiant-Report M-Trends 2026 liefert die Einordnung und nennt eine mediane Verweildauer von 14 Tagen. Beide Quellen zusammen ergeben das vollständige Bild.
War eine unbekannte Schwachstelle im Spiel?
Nein. Der Angriff nutzte ausschließlich Fehlkonfigurationen: langlebige Schlüssel in einem offenen S3-Bucket und eine Lambda-Rolle mit Administratorrechten. Ein Zero-Day war nicht beteiligt, ein Patch wird nicht gebraucht.
Was ist der schnellste Schutzschritt?
Langlebige IAM-Schlüssel durch kurzlebige Rollen ersetzen und keiner Lambda-Ausführungsrolle Administratorrechte geben. Damit fehlt dem beobachteten Angriff sowohl der Einstieg als auch der Sprung zum Admin.
Lesetipps der Redaktion
Bildquelle: KI-generiert (Juli 2026)
