SECURITY5. Februar 2026

KI hilft Hackern: In 10 Minuten zum AWS-Admin

Ein stilisiertes Bild zeigt das AWS-Logo im Fokus, umgeben von einem Zielkreuz. Über dem Logo schwebt ein grafisches Element, das Künstliche Intelligenz symbolisiert. Eine Stoppuhr verdeutlicht die schnelle Zeitspanne, in der Hacker Zugriff
SymbolbildChatGPT

Am 28. November 2025 beobachtete das Sysdig Threat Research Team (TRT) eine offensive Cloud-Operation, die auf eine AWS-Umgebung abzielte und bei der die Angreifer in weniger als zehn Minuten vom ersten Zugriff zu Administratorrechten gelangten.

Der höchst ungewöhnliche Angriff zeichnete sich nicht nur durch seine Geschwindigkeit aus, sondern auch durch mehrere Indikatoren, die darauf hindeuten, dass die Angreifer während der gesamten Operation große Sprachmodelle (LLMs) einsetzten, um die Erkundung zu automatisieren, bösartigen Code zu generieren und Entscheidungen in Echtzeit zu treffen.

Die Angreifer verschafften sich zunächst Zugriff auf das AWS-Konto des Opfers über Anmeldedaten, die sie in öffentlichen Simple Storage Service (S3)-Buckets gefunden hatten. Anschließend erweiterten sie die eigenen Berechtigungen schnell durch die Injektion von Lambda-Funktionscode, bewegten sich lateral über 19 verschiedene AWS-Prinzipale, missbrauchten Amazon Bedrock für LLM-Jacking und starteten GPU-Instanzen für das Modelltraining.

Diebstahl von Anmeldedaten aus öffentlichen S3-Buckets

Der Angreifer drang mithilfe gültiger Test-Anmeldedaten, die er aus öffentlichen S3-Buckets gestohlen hatte, in die Umgebungen der Opfer ein. Diese Buckets enthielten RAG-Daten (Retrieval-Augmented Generation) für KI-Modelle, und die kompromittierten Anmeldedaten eines IAM-Accounts (Identity and Access Management), der über mehrere Lese- und Schreibberechtigungen für AWS Lambda und eingeschränkte Berechtigungen für AWS Bedrock verfügte.

Das kompromittierte AWS-Konto war ein Unterkonto innerhalb einer Organisation. Die Angreifer unternahmen mehrere Versuche, verschiedene Rollen zu übernehmen, darunter auch kontoübergreifende Rollen. Wenn ein Endbenutzer ein AWS-Mitgliedskonto in einer Organisation erstellt, wird in diesem Mitgliedskonto eine Standardrolle namens „OrganizationAccountAccessRole“ generiert. Dadurch können autorisierte IAM-Accounts im Verwaltungskonto diese Rolle übernehmen und Administratorzugriff auf dieses Konto erhalten.

Die Angreifer übernahmen im Zuge ihrer Attacke in unter zehn Minuten sechs verschiedene IAM-Accounts in 14 verschiedenen Sitzungen. Insgesamt waren 19 eindeutige AWS-Principals von dem Angriff betroffen.“

Datenerfassung und –exfiltration

Mithilfe des neu erstellten Admin-Benutzers sammelten die Angreifer Daten aus mehreren Diensten:

  • Geheimnisse aus Secrets Manager:
  • SSM-Parameter aus EC2 Systems Manager
  • CloudWatch-Protokolle
  • Quellcode der Lambda-Funktion
  • Interne Daten aus S3-Buckets
  • CloudTrail-Ereignisse
Der Code demonstriert eine AWS Lambda-Funktion, die Benutzerinformationen und Zugriffsrechte aus dem AWS IAM abruft. Zudem wird ein neuer Zugriffsschlüssel für einen Benutzer erstellt. Die Funktion nutzt die Boto3-Bibliothek zur Interaktion mit AWS-Diensten.
Der Code zeigt die finale Version, die vom Angreifer hochgeladen wurde: Er demonstriert eine AWS Lambda-Funktion, die Benutzerinformationen und Zugriffsrechte aus dem AWS IAM abruft. Zudem wird ein neuer Zugriffsschlüssel für einen Benutzer erstellt.Sysdig

Über den Diebstahl von Ressourcendaten hinaus listeten sie über den bösartigen Admin-Benutzer die Ergebnisse des IAM Access Analyzer auf. Access Analyzer liefert drei Arten von Ergebnissen: Externe Zugriffsergebnisse zeigen Ressourcen, auf die außerhalb der Vertrauenszone zugegriffen werden kann; interne Zugriffsergebnisse zeigen mögliche Zugriffspfade zwischen IAM-Accounts/Rollen und bestimmten Ressourcen auf; und Ergebnisse zu ungenutzten Zugriffen liefern Informationen über ungenutzte Rollen, Berechtigungen und Anmeldedaten. Für Angreifer sind dies wertvolle Informationen, um die Umgebung zu verstehen und zusätzliche Angriffspfade zu identifizieren.

LLMjacking über Amazon Bedrock

LLMjacking, das erstmals im Mai 2024 vom Sysdig TRT identifiziert wurde, ist eine Attacke, bei der ein Angreifer einen Teil des Cloud-Kontos des Opfers kompromittiert, um Zugriff auf Cloud-gehostete LLMs zu erhalten.

Da das AWS-Konto des Opfers Daten und Spuren aktiver KI-Nutzung enthielt, verlagerten die Angreifer ihren Fokus schnell auf Amazon Bedrock. Nach der Aufzählung sowohl der benutzerdefinierten als auch der Basis-Modelle überprüfte man, ob für das Konto die Protokollierung von Modellaufrufen aktiviert war. Nachdem man sich vergewissert hatte, dass die Protokollierung deaktiviert war, riefen die Angreifer mehrere KI-Modelle auf.

Techniken zur Umgehung von Abwehrmaßnahmen

Die Angreifer setzten mehrere Techniken ein, um einer Entdeckung zu entgehen und die Ermittlungen zu erschweren. Sie verwendeten ein IP-Rotator-Tool, um die Quell-IP-Adresse für jede Anfrage zu ändern und so Sicherheitsmaßnahmen zu umgehen, die auf der Korrelation von Vorgängen derselben IP-Adresse basieren.

Wie bereits erwähnt, verteilten sie die Vorgänge auf 19 verschiedene Principals, wodurch sich ihre Chancen auf einen dauerhaften Zugriff erhöhten. In einigen Fällen übernahmen sie eine Rolle nur, um eine andere Rolle zu übernehmen, ein Konzept, das als Rollenverkettung bekannt ist.

Empfehlungen zur Risikominderung bei AWS-Konten

Unternehmen sollten die folgenden Kontrollen implementieren, um sich gegen ähnliche Angriffe zu schützen:

Das Prinzip der geringsten Berechtigungen auf alle IAM-Accounts und -Rollen anwenden, einschließlich der von Lambda-Funktionen verwendeten Ausführungsrollen. Eine zu freizügige Ausführungsrolle ermöglichte es den Angreifern, die eigenen Berechtigungen in diesem Angriff zu erweitern.

Einschränkungen der Berechtigungen „UpdateFunctionConfiguration” und „PassRole” sorgfältig vornehmen. Angreifer könnten versuchen, die Ausführungsrolle einer Lambda-Funktion durch eine Rolle mit höheren Berechtigungen zu ersetzen, wofür beide Berechtigungen erforderlich sind.
Die Berechtigungen „UpdateFunctionCode” auf bestimmte Funktionen beschränken und nur Prinzipalen zuweisen, die tatsächlich Code-Bereitstellungsfunktionen benötigen.

Die Versionsverwaltung für Lambda-Funktionen aktivieren, um unveränderliche Aufzeichnungen des zu jedem Zeitpunkt ausgeführten Codes zu führen. Funktionsaliase verwenden, um auf bestimmte Versionen zu verweisen, sodass ein Angreifer sowohl den Code ändern als auch den Alias aktualisieren muss, um die Produktion zu beeinflussen.

S3-Buckets mit sensiblen Daten sollten nicht öffentlich zugänglich sein, einschließlich RAG-Daten und KI-Modellartefakten.

Modellaufrufprotokollierung für Amazon Bedrock aktivieren, um unbefugte Nutzung zu erkennen.
Auf IAM Access Analyzer-Enumeration achten, da diese Angreifern wertvolle Aufklärungsdaten über Ihre Umgebung liefert.

Fazit

Dieser Angriff zeichnet sich durch seine Geschwindigkeit, Effektivität und starke Anzeichen für eine KI-gestützte Ausführung aus. Der Angreifer erlangte innerhalb von weniger als 10 Minuten Administratorrechte, kompromittierte 19 verschiedene AWS-Prinzipale und missbrauchte sowohl Bedrock-Modelle als auch GPU-Rechenressourcen. Der LLM-generierte Code mit serbischen Kommentaren, halluzinierten AWS-Konto-IDs und nicht existierenden GitHub-Repository-Referenzen deutet allesamt auf KI-gestützte Offensivoperationen hin.

Weitere Informationen zum Angriff veröffentlicht das Sysdig Threat Research Team (TRT) hier.aj

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert