Acht Minuten haben gereicht. Von exponierten cloud bis hin zur vollständigen administrativen Kontrolle in AWS – der von Sysdig dokumentierte Angriff zeigt , wie schnell eine cloud kompromittiert werden kann, wenn Automatisierung, Identitätsmissbrauch und permissive cloud zusammenkommen.
Es gab keine Zero-Days, keine malware keine neuartigen Exploit-Ketten. Der Angreifer stützte sich ausschließlich auf gültige Anmeldedaten, native AWS-Dienste und automatisierte Entscheidungsprozesse, um mit maschineller Geschwindigkeit vom ersten Zugriff zu Administratorrechten zu gelangen.
In den letzten Wochen haben wir uns mit dem frühen Verhalten autonomer KI-Agenten befasst, wie sie begannen, in gemeinsamen Umgebungen miteinander zu interagieren und sich gegenseitig zu beeinflussen, und wie sich schnell eine Koordination ohne menschliches Zutun entwickelte.
Dieser Vorfall zeigt, was passiert, wenn diese Dynamik auf eine reale cloud angewendet wird.
Was wir erwartet haben, ist nun zu beobachten: Die Aufklärung beschleunigt sich, und sobald ein Angreifer eine Identität kontrolliert, kontrolliert er effektiv die Umgebung. Das Ergebnis ist keine neue Art von Angriff, sondern eine dramatisch schnellere.
Diese Analyse führt Schritt für Schritt durch den Angriff und zeigt auf, wo dieser an Dynamik gewann, wo Verteidiger realistisch gesehen hätten eingreifen können und warum eine identitätsbasierte Verhaltenserkennung mittlerweile die einzige praktikable Möglichkeit ist , cloud zu stoppen, die sich mit KI-Geschwindigkeit ausbreiten.
Wenn die Automatisierung die Angriffszeitachse zusammenbrechen lässt
Dieser Vorfall ist besonders bemerkenswert, weil KI Reibungsverluste beseitigt hat. Der Angreifer hat nicht vorsichtig sondiert oder Schwachstellen miteinander verknüpft. Dank Automatisierung konnte er Dienste auflisten, Berechtigungspfade bewerten und Eskalationen schneller ausführen, als dies ein menschlicher Bediener manuell hätte tun können.
Für Verteidiger würden die meisten der damit verbundenen Aktionen für sich genommen legitim erscheinen. API-Aufrufe wurden authentifiziert, auf Dienste wurde über genehmigte Mechanismen zugegriffen und Berechtigungen wurden missbraucht, nicht umgangen.
Das einzige verlässliche Signal war das Verhalten: Wer handelte, wie schnell bewegten sie sich und welche Abfolge von Handlungen vollzog sich über die Dienste hinweg.
Angriffsablauf auf hoher Ebene
Auf hoher Ebene verlief der Angriff in fünf Phasen:
- Erster Zugriff über exponierte Ressourcen
- Dienstübergreifende Aufklärung
- Privilegienerweiterung durch Missbrauch von Lambda
- Beharrlichkeit und Expansion
- Ressourcenmissbrauch und Datenexternalisierung
Obwohl die gesamte Sequenz viele einzelne Schritte umfasste, war nur ein Teil davon entscheidend für den Erfolg. Wenn diese Schritte erkannt oder gestoppt werden, schlägt der Angriff vollständig fehl.
Phase 1: Erster Zugriff über exponierte Cloud
Was ist passiert:
Der Angriff begann außerhalb des AWS-Kontos und richtete sich nicht gegen eine bestimmte Organisation.
Der Angreifer suchte nach öffentlich zugänglichen S3-Buckets, deren Namen den üblichen Namenskonventionen für KI-Tools und cloud entsprachen. Jede AWS-Umgebung, die diesen Konventionen folgte, war ein potenzieller Einstiegspunkt.
In einem Bucket fand der Angreifer Dateien mit IAM-Zugriffsschlüsseln. Mit diesen gültigen Anmeldedaten authentifizierte er sich direkt im AWS-Konto des Opfers.
Aus Sicht von AWS hatte sich eine gültige Identität erfolgreich angemeldet.
Warum das wichtig ist:
Hier beginnen viele cloud unbemerkt. Probleme mitCloud schaffen oft die Einstiegsmöglichkeit, aber der Missbrauch von Identitäten bestimmt, wie weit ein Angreifer gehen kann.
Nach der Authentifizierung ging der Angreifer sofort zur nächsten Phase des Angriffs über.
Phase 2: Dienstübergreifende Erkundung mit Maschinengeschwindigkeit
Was ist passiert:
Nach der Authentifizierung führte der Angreifer eine umfassende Erkundung über mehrere AWS-Dienste hinweg durch, darunter S3, Lambda, EC2, IAM, Bedrock und CloudTrail.
Die Aktivität war schnell, systematisch und automatisiert. API-Antworten wurden in Echtzeit erfasst und ausgewertet, um realisierbare Eskalationspfade zu identifizieren.
Warum das wichtig ist:
Die Erkundung ermöglicht alles, was danach kommt. Ohne Einblick in Dienste, Rollen und Vertrauensverhältnisse bleiben Eskalationspfade verborgen.
Hier verändert die Automatisierung die Gleichung. KI-gestützte Tools ermöglichen es Angreifern, API-Antworten zu erfassen, Berechtigungen zu bewerten und in Sekundenschnelle gangbare Wege zu identifizieren.
Für SOC-Teams stellt diese Phase die früheste realistische Möglichkeit dar , einzugreifen. Sobald die Ausweitung von Berechtigungen beginnt, verringert sich das Zeitfenster für Maßnahmen drastisch.
Dieses Verhalten entspricht weitgehend den in MITRE ATLAS dokumentierten Techniken zum Missbrauch gültiger Konten und zur Erkennung cloud . Anstatt neue Techniken zu entwickeln, beschleunigte der Angreifer bekannte Verhaltensweisen durch Automatisierung.
Phase 3: Lambda-Missbrauch als primärer Engpass
Was ist passiert:
Der Angreifer konzentrierte sich auf eine vorhandene AWS Lambda-Funktion und nutzte diese als Mechanismus zur Ausweitung von Berechtigungen.
Zunächst änderten sie den Code der Funktion und erhöhten deren Ausführungszeitlimit. Diese Lambda-Funktion verfügte über eine Ausführungsrolle mit ausreichenden Berechtigungen, um IAM-Benutzer und Zugriffsschlüssel zu erstellen.
Als Nächstes riefen sie die modifizierte Funktion auf. Bei ihrer Ausführung erstellte die Funktion neue IAM-Zugriffsschlüssel mit Administratorrechten.
Jeder einzelne Schritt war für sich genommen legitim, aber zusammen genommen verwandelten sie eine routinemäßige Automatisierungskomponente in einen Eskalationspfad.
Warum das wichtig ist:
Diese Sequenz war der Punkt, an dem der Angriff unumkehrbar wurde.
Wenn ein Teil davon versagt, bricht die Kette. Wenn die Funktion nicht geändert werden kann, kann sie auch nicht missbraucht werden. Wenn sie nie ausgeführt wird, werden keine neuen Anmeldedaten erstellt. Wenn sie ausgeführt wird, aber keine Admin-Zugriffsschlüssel erstellen kann, kommt der Angreifer zum Stillstand.
Lambda-Funktionen konzentrieren Automatisierung und Privilegien auf eine Weise, wie es nur wenige andere Dienste tun. Ausführungsrollen sind oft weiter gefasst als beabsichtigt. Codeänderungen sind selten und werden nur oberflächlich geprüft. Aufrufe sind zu erwarten und üblich.
Nichts an dieser Sequenz verstößt gegen die AWS-Richtlinien oder löst einen eindeutigen Kontrollfehler aus. Das Risiko wird erst sichtbar, wenn man sich ansieht, wie sich das Verhalten der Funktion verändert hat und was dadurch unmittelbar danach ermöglicht wurde.
Dies ist ein wiederkehrendes Muster bei modernen cloud . Angreifer müssen die Infrastruktur nicht ausnutzen. Sie verwenden sie für andere Zwecke.
Phase 4: Programmatische Privilegieneskalation
Was ist passiert:
Mithilfe der modifizierten Lambda-Funktion erstellte der Angreifer neue IAM-Zugriffsschlüssel mit Administratorrechten.
Dies war eine Privilegienerweiterung ohne Ausnutzung.
Der Angreifer nutzte lediglich eine Ausführungsrolle, um Aktionen auszuführen, zu denen er berechtigt war, jedoch nicht in der von seinen Entwicklern vorgesehenen Weise.
Von diesem Moment an war der Angreifer praktisch Eigentümer des Kontos.
Warum das wichtig ist:
Für Verteidiger scheitern herkömmliche Sicherheitskontrollen oft an dieser Stelle. Identitäts- und Zugriffsmanagementsysteme setzen Richtlinien durch, nicht Absichten.
Sobald Administratorrechte bestehen, treten die meisten Kontrollen in den Hintergrund. Sobald administrativer Zugriff besteht, verringert sich der Umfang der Reaktionsmöglichkeiten und die Behebung von Problemen wird erheblich komplexer.
Phase 5: Beharrlichkeit und Expansion
Was ist passiert:
Nachdem sich der Angreifer Administratorrechte gesichert hatte, konzentrierte er sich auf die Persistenz.
Insbesondere haben sie einen neuen IAM-Benutzer erstellt und die AdministratorZugang Richtlinie, zusätzliche Zugriffsschlüssel für bestehende Benutzer generiert und Geheimnisse aus dem Secrets Manager und dem SSM Parameter Store abgerufen.
Jede Maßnahme erweiterte die Angriffsfläche des Angreifers und verringerte die Wirksamkeit der Abhilfemaßnahmen. Selbst wenn eine Berechtigung widerrufen wurde, blieben andere bestehen.
Warum das wichtig ist:
Diese Phase spiegelt einen Wandel vom Zugriff zur Absicherung wider. Der Angreifer stellte sicher, dass er auch dann die Kontrolle behielt, wenn die Verteidiger reagierten.
Auch diese Aktionen wurden über legitime APIs mit gültigen Berechtigungen durchgeführt. Der Unterschied zwischen Wartungsarbeiten und Kompromittierung liegt ausschließlich im Verhalten und im Zeitpunkt.
Phase 6: Missbrauch von Ressourcen und Externalisierung von Daten
Was ist passiert:
Der Angreifer bewegte sich auf das Ziel zu.
Sie starteten eine High-End-GPU-Instanz mit einer offenen Sicherheitsgruppe und einer exponierten JupyterLab-Schnittstelle.
Sie haben Bedrock-Modelle aufgerufen und einen EBS-Snapshot extern geteilt.
Warum das wichtig ist:
Zu diesem Zeitpunkt war der Angriff bereits erfolgreich. Diese Aktionen lassen eine klare Absicht des Angreifers erkennen: Missbrauch von Ressourcen, potenzielle Datenexfiltration und Monetarisierung.
Diese Phase entspricht den Mustern, die in unserer Podcast-Episode zum Thema wie Angreifer AWS Bedrock ins Visier nehmen, darunter LLMjacking, Kostenmissbrauch und Datenpreisgabe, sobald cloud kompromittiert sind.
„Was wäre, wenn…?“
Der dokumentierte Angriff wurde an dieser Stelle beendet, weil er beobachtet wurde, nicht weil dem Angreifer die Optionen ausgegangen waren.
Mit anhaltendem Administratorzugriff hätte der Angreifer Folgendes tun können:
- Langfristige Beständigkeit durch Vertrauensrichtlinien und kontoübergreifende Rollen
- Modifizierte CI/CD-Pipelines zum Einschleusen von Schadcode in die Produktion
- Erstellte Schatteninfrastruktur, die legitime Arbeitslasten widerspiegelte
- Führte eine stille, schrittweise Datenexfiltration mithilfe von Snapshots und Replikation durch.
- Kontinuierliche Nutzung von KI-Diensten, wobei Kostenmissbrauch in die normale Nutzung integriert wird
- In verbundene AWS-Konten oder SaaS-Plattformen verschoben
Keine dieser Aktionen erfordert zusätzliche Exploits. Sie erfordern Zeit. Acht Minuten waren nur der Einstiegspunkt.
Die dringende Notwendigkeit der Erkennung nach Kompromittierung
Wenn es zum Aufprall kommt, ist die Prävention bereits gescheitert.
Der defensive Wert verschiebt sich früher in der Angriffskette, bevor die Privilegieneskalation und die Persistenz die Kontrolle des Angreifers festigen.
Obwohl die gesamte Angriffskette lang ist, können sich Verteidiger auf eine reduzierte Anzahl kritischer Schritte entlang des Angriffsablaufs konzentrieren:
- Umfassende, schnelle dienstübergreifende Aufklärung
- Änderung einer bestehenden Lambda-Funktion
- Programmatische Erstellung von Administratorzugängen
- Einrichtung dauerhafter IAM-Identitäten
- Externalisierung von Daten durch cloud Mechanismen
Dies sind Verhaltensweisen, die in ihrer Abfolge stark von normalen Nutzungsmustern abweichen.
Die Herausforderung ist die Korrelation.
Die meisten cloud sind statisch konzipiert und haben Schwierigkeiten mit Absichten.
Bei diesem Vorfall:
- Die Anmeldedaten waren gültig.
- APIs wurden wie vorgesehen verwendet.
- Die Berechtigungen bestanden rechtmäßig.
Die einzige Anomalie war das Verhalten im Zeitverlauf.
Dies ist die Erkennungslücke, die schnell voranschreitende, KI-gestützte Angriffe ausnutzen.
Warum identitätsbasierte Verhaltenserkennung erforderlich ist
Wenn Angriffe mit maschineller Geschwindigkeit erfolgen, muss die Erkennung auf dem gleichen Niveau erfolgen.
Dies erfordert Verständnis:
- Wie sich Menschen, Maschinen und agierende Identitäten normalerweise verhalten
- Wie Dienste normalerweise genutzt werden
- Welche Handlungsabläufe sind typisch oder selten?
- Wie sich das Verhalten ändert, wenn die Kontrolle auf einen Angreifer übergeht
Die identitätszentrierte Erkennung behandelt cloud – menschliche, nicht-menschliche und agentenbasierte – als primäres Signal. Verhaltensbasierte KI modelliert, wie diese Identitäten über Dienste und Umgebungen hinweg funktionieren.
Wenn die Erkundung beschleunigt wird, wenn sich das Lambda-Verhalten ändert, wenn unerwartet Privilegien gewährt werden, werden diese Veränderungen in Echtzeit erkannt.
Diesist die einzige praktikable Möglichkeit, Angriffe zu unterbrechen, bevor die Ausweitung von Berechtigungen irreversibel wird.
Wie Vectra AI diese Art von Angriffen Vectra AI
Die Vectra AI wurde genau für diesen Problembereich entwickelt.
Durch die Analyse des Identitätsverhaltens über cloud , Netzwerkverkehr, SaaS-Aktivitäten und cloud hinweg Vectra AI Angriffe, die auf gültigen Zugriffen und Automatisierung basieren, bereits in einem frühen Stadium.
Anstatt auf Auswirkungen zu warten, konzentriert es sich auf:
- Aufklärungsmuster
- Missbrauch von Privilegien
- Seitliche Bewegung
- Datenmissbrauch
Wenn der Administratorzugriff innerhalb weniger Minuten kompromittiert werden kann, ist eine automatisierte Reaktion keine Option, sondern die einzige Möglichkeit, innerhalb des immer kleiner werdenden Zeitfensters zwischen Zugriff und Eskalation zu handeln.
Dieser Vorfall sollte die Erwartungen zurücksetzen.
Acht Minuten sind keine Ausnahme mehr. Das ist das Ergebnis von Automatisierung, wenn Identitäten missbraucht werden und Abwehrmaßnahmen auf statischen Annahmen beruhen. Die Lehre daraus ist, dass man keine Angst vor KI haben muss. Man muss sich vielmehr bewusst machen, dass Angreifer sie bereits einsetzen, um Zeitpläne zu verkürzen, Unsicherheiten zu beseitigen und Entscheidungsprozesse zu skalieren.
Verteidiger müssen entsprechend reagieren: Die Erkennung muss verhaltensbasiert sein, die Abdeckung muss identitätszentriert sein und die Reaktion muss automatisiert sein.
Denn wenn der Zugriff cloud mit KI-Geschwindigkeit erfolgt, bleibt keine Zeit mehr, um Warnmeldungen nachträglich zusammenzufügen.