Wiz: KI-Agenten führen inzwischen komplette Cloud-Angriffe in Maschinengeschwindigkeit aus

KI-Agenten steuern die gesamte Operation

Laut Wiz beobachtet das CIRT in jüngsten Untersuchungen einen klaren Trend: KI-gestützte Angriffe nehmen zu. Bei mehreren Einbrüchen habe das KI-Agentensystem einen menschlichen Angreifer nicht bloß unterstützt. Nach Angaben von Wiz führte es die gesamte Operation selbst durch. Es fand Einstiegspunkte, griff Zugangsdaten ab, wechselte zwischen Plattformen und reparierte unterwegs seine eigenen Skripte.

Wiz bezeichnet diese Angriffe als „laut", schnell und auf jeder Ebene des Cloud-Stacks präsent. Das Problem für die Verteidiger sei nicht, dass die Angriffe unsichtbar wären, so das Unternehmen. Ihre Spuren verteilten sich auf Identitätsanbieter, Cloud-Control-Planes, CI/CD-Systeme und Workload-Logs, und kein einzelner Alarm erzähle die ganze Geschichte.

Acht Merkmale, die sie auszeichnen

Wiz zufolge verbinden KI-Agenten Maschinentempo mit kontextbezogenem Schlussfolgern. Das unterscheide sie von Skripten, die vorprogrammierte Schritte abarbeiten, und von menschlichen Angreifern, die langsam und nacheinander vorgehen. Über mehrere Untersuchungen hinweg nennt das CIRT eine Reihe wiederkehrender Merkmale:

• Operatives Tempo: Hunderte oder Tausende Aktionen pro Stunde, über lange Zeiträume ohne Pausen oder erkennbare Arbeitszeitmuster.
• Gleichzeitige Aktivität auf mehreren Plattformen: Eine Aufgabe listet Cloud-Ressourcen auf, während andere Kubernetes-Workloads bereitstellen, CI/CD-Pipelines anlegen oder Datenbanken abfragen, alles von derselben Quelle im selben Zeitfenster.
• Versiertheit über Plattformen hinweg: Der Agent nutzt die nativen APIs und Werkzeuge von Cloud-Anbietern, Container-Orchestrierung, CI/CD-Systemen, Datenbanken, Identitätsanbietern und Message Queues.
• Verkettung von Zugangsdaten: Jede Zugangsberechtigung wird zum Sprungbrett. Wiz nennt als Beispiel ein Kubernetes-Service-Account-Token, das zu einem Cloud-Service-Account führt, dann zu einem CI/CD-System und schließlich zu vollem Administratorzugriff.
• Schnelles Ausprobieren: Schlägt ein Versuch fehl, liest der Agent die Fehlermeldung, schreibt sein Skript um und versucht es innerhalb von Minuten erneut.
• Benennung nach Sicherheitstests: Ressourcen und Payloads tragen Bezeichnungen wie pentest, probe, recon, redteam und exfil. Wiz geht davon aus, dass diese Tarnung die Aktivität wahrscheinlich als autorisierten Test erscheinen lässt und so die Sicherheitsvorkehrungen des KI-Modells praktisch umgeht.
• Numerische Aufgabenkennungen: Dieselbe Zahl taucht häufig in zusammengehörigen Artefakten auf, und bei Wiederholungen kommt ein Buchstabensuffix wie -b, -c oder -d hinzu. Laut Wiz handelt es sich offenbar um interne Task-IDs.
• Muster generierten Codes: Der sichergestellte Code enthält beschreibende Kopfzeilen, nummerierte Schritt-für-Schritt-Kommentare und Hilfsfunktionen, die in Dutzenden Payloads wiederverwendet werden.

Ein Multi-Cloud-Einbruch im Detail

Der von Wiz geschilderte Fall betraf eine Organisation mit einer großen Multi-Cloud-Umgebung. Der Agent arbeitete von mehreren vom Angreifer kontrollierten IP-Adressen aus und bewegte sich durch Cloud-Anbieter, Kubernetes-Cluster, CI/CD- und GitOps-Pipelines, den Identitätsanbieter, das Secrets-Management, Data Warehouses und interne Anwendungen.

Für den ersten Zugriff prüfte der Akteur mehrere aus dem Internet erreichbare Dienste. Er sendete Exploit-Payloads für bekannte Schwachstellen, versuchte anonymen Zugriff auf Cloud-Speicher und arbeitete sich durch die API eines exponierten internen Entwicklerwerkzeugs, wo er versuchte, ein Administratorkonto anzulegen, und eine Testdatei mit dem Präfix pentest hochlud. Ein bestätigter Einstiegspunkt war eine Java-Schwachstelle für Remote Code Execution in einer exponierten Kafka-UI-Instanz, gefolgt von der Installation von Malware und einem C2-Kanal. Wiz zufolge suchte der Agent auch nach dem erfolgreichen Fußfassen weiter nach alternativen Einstiegspunkten. Dieselbe Quell-IP-Adresse wurde im gleichen Zeitraum beim Scannen von mehr als 600 weiteren Wiz-Kundenumgebungen beobachtet, was laut Wiz zu einer breit angelegten, opportunistischen Automatisierung passt.

Nachdem er Code ausführen konnte, verfolgte der Agent nahezu gleichzeitig drei Ziele. Er installierte Backdoors und C2-Agenten in mehreren Pods über mehrere Cluster hinweg. Er extrahierte eingebundene Kubernetes-Service-Account-Tokens, durchsuchte Umgebungsvariablen nach Zeichenfolgen wie token, secret, key und pass und fragte den Instance Metadata Service nach den Cloud-Zugangsdaten des Knotens ab. Zudem scannte er interne Message Broker, Schema-Registries und Datenbanken, um herauszufinden, was aus dem Netzwerk des Pods erreichbar war.

Cloud-Control-Plane und Identitätsanbieter

Die abgegriffenen Zugangsdaten wurden zum Hauptweg in die Cloud-Control-Plane. Der Agent war sowohl in GCP als auch in AWS aktiv, und zwar in einem Tempo, dem laut Wiz kein Mensch gewachsen wäre. In GCP machte er aus einem Service-Account mit Berechtigung zur Token-Erstellung eine automatisierte Maschine zur Ausstellung von Zugangsdaten, die Credentials für Dutzende Identitäten erzeugte. Außerdem durchsuchte er Container-Registries in einer Dauerschleife, versuchte, Datenbankeinträge abzuziehen, und stellte öffentlich erreichbare Cloud-Run-Dienste mit dem Präfix pentest- bereit.

In AWS nutzte er Systems Manager, um Befehle auf mehreren Instanzen auszuführen, versuchte Datenbankverbindungen aufzubauen, bewegte sich per SSH lateral und bereitete die Exfiltration in einen Bucket namens pentest-<task_id> vor. Für Persistenz über Kontogrenzen hinweg legte er einen IAM-Benutzer mit dem Präfix probe an und übernahm damit die OrganizationAccountAccessRole, wodurch er administrativen Zugriff auf Mitgliedskonten der AWS Organization erlangte.

Der Agent baute sich auch eine eigene Identität auf. Mit einem kompromittierten Administrator-API-Schlüssel des Identitätsanbieters legte er einen Benutzer mit dem Präfix pentest an, setzte dessen Passwort, aktivierte ihn und fügte ihn der Administratorengruppe hinzu. Als der Identitätsanbieter Fehler zurückgab, behob der Agent jeden einzelnen davon direkt vor Ort.

Was das für Sicherheitsteams bedeutet

Wiz versteht den Beitrag als Leitfaden, um Angreifer in Maschinengeschwindigkeit zu erkennen, und beschreibt, was Teams brauchen, um sie aufzuspüren und darauf zu reagieren. Die hervorgehobenen Signale sind praxisnah: sehr hohe Aktionsraten ohne Pausen, parallele Aktivität auf mehreren Plattformen von einer Quelle, Bezeichnungen aus dem Sicherheitstest-Umfeld an Ressourcen, numerische Task-IDs und stark kommentierter, generierter Code.

Da sich jede dieser Spuren in einem anderen System befindet, zeigt der Fall, dass Verteidiger Identitäts-, Cloud-, CI/CD- und Workload-Logs miteinander korrelieren müssen, statt sich auf einen einzelnen Alarm zu verlassen.