Die Sicherheitsforensiker von Sysdig (Sysdig TRT) haben eine offensive Cloud-Operation enttarnt, die auf eine AWS-Umgebung abzielte und bei der die Angreifer in weniger als zehn Minuten vom ersten Zugriff zu Administratorrechten gelangten. Der 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.
Das Sysdig TRT analysierte die gesamte Angriffskette, identifizierte Erkennungsmöglichkeiten und stellte Empfehlungen zur Schadensbegrenzung zusammen. Die Ergebnisse sind hier detailliert aufgeführt.
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.
Laterale Bewegung im Anschluss an die Infiltration
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
Ü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
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.
Da LLMs immer ausgefeilter werden, werden Angriffe dieser Art wahrscheinlich häufiger vorkommen. Die in dieser Operation beobachteten Halluzinationen werden dafür seltener werden, da offensive Akteure ihre Genauigkeit und ihr Bewusstsein für Zielumgebungen verbessern. Unternehmen müssen der Laufzeiterkennung und der Durchsetzung von Mindestprivilegien Priorität einräumen, um sich schnell gegen diese sich beschleunigende Bedrohungslage zu verteidigen.
