Einzelner Angreifer kompromittiert AWS in 72 Stunden mit Agentic AI

Jeder Platform-Lead, der schon einmal eine Cloud-Incident-Bridge geleitet hat, kennt das Bild eines dreitägigen War Rooms: IAM-Logs ziehen, Keys rotieren, über den Blast Radius streiten, Kaffee bestellen. Stellen Sie sich nun vor, dass der Angreifer auf der anderen Seite die gesamte Kampagne innerhalb desselben Zeitfensters abschließt – allein, mit einem LLM, das die schwere Arbeit übernimmt. Genau dieses Szenario hat Sygnia soeben beschrieben, und es sollte jede Annahme hinter aktuellen AWS-Incident-Playbooks neu ausrichten.

Ein einzelner, finanziell motivierter Akteur kompromittierte eine große AWS-Umgebung in etwa 72 Stunden und erpresste ein namentlich nicht genanntes globales Unternehmen. Kein Zero-Day, kein Insider, keine Gruppe. Nur verkettete Schwachstellen und Agentic AI.

Was geschah

Wie Dark Reading berichtete, veröffentlichte Sygnia diese Woche eine Untersuchung, die einen finanziell motivierten Einbruch beschreibt, bei dem Agentic-AI-Workflows eingesetzt wurden, um „Opferaufklärung, Angriffswerkzeugentwicklung, Befehlsstrukturierung und umgebungsspezifische Anpassung zu beschleunigen." Ziel war ein großer AWS-Kunde. Das Ergebnis war Erpressung.

Der erste Zugang war unspektakulär. Der Angreifer erlangte einen AWS-Access-Key über eine Schwachstelle in einer Internetanwendung. Von dort an hörte das Unspektakuläre auf. Dieser einzelne Key wurde durch vier parallele Workflows geleitet, die auf systematischen Secrets-Diebstahl, Backdoor-Erstellung und Datenexfiltration abzielten. Jede neu gewonnene Zugangsinformation wurde erneut durch dieselben vier Workflows geführt, wodurch der Zugang sich kontinuierlich erweiterte.

Sygnias Einschätzung lautet, dass der Einbruch „keine einzelne Fehlkonfiguration ausgenutzt" hat. Stattdessen wurden Schwachstellen über Anwendungsdienste, AWS-Ressourcen, Quellcode-Repositories, CI/CD-Pipelines, Laufzeitkomponenten und Datenspeicher hinweg verkettet. Credential-Erkennung, Secrets-Harvesting, Cloud-Enumeration, Missbrauch von Deployment-Pipelines, Laufzeitmodifikation, Datenbankzugriff und operationale Störungen fanden parallel statt, nicht sequenziell.

Um eine Zahlung zu erzwingen, führte der Angreifer reversible Impact-Aktionen als Demonstration seiner Fähigkeiten durch: Zugang zu S3-Buckets verweigern, ECS-Services oder Container auf null Kapazität drosseln, ACL-Regeln zur Blockierung des Netzwerkzugangs erstellen und SQS-Queues leeren. Reversibel, aber lautstark. Die Botschaft an das Opfer war eindeutig: Jetzt zahlen, sonst ist die nächste Runde destruktiv.

Die Forscher kamen durch die Analyse von Angreifer-Skripten, Berichtsartefakten und der schieren Parallelität der Operation zur KI-unterstützten Schlussfolgerung. Wie Sygnia es formulierte: Dies war Arbeit, die Wochen hätte dauern sollen und von einer einzigen Person auf drei Tage komprimiert wurde.

Technische Anatomie

Entfernt man das KI-Framing, ist das Handwerk für jeden vertraut, der Cloud-Einbrüche gegen MITRE ATT&CK kartiert hat. Erster Zugang über eine exponierte Web-App. Credential-Zugriff. Erkundung. Laterale Bewegung durch CI/CD. Persistenz via Backdoors. Impact via Service-Störung. Nichts davon ist neu.

Was neu ist, sind das Tempo und der Verzweigungsfaktor. Ein menschlicher Red Teamer, der allein arbeitet, wählt einen Pfad, testet ihn, geht zurück, wenn er scheitert, und macht weiter. Ein agentischer Workflow muss nicht wählen. Er kann vier Workflows gegen denselben Access-Key starten, Outputs parallel auswerten und Skripte spontan an das anpassen, was er in der Umgebung vorfindet. Sygnia hob ausdrücklich die „umgebungsspezifische Anpassung" hervor – das ist der Teil, der früher erfahrene Operatoren erforderte, die Logs lasen und Payloads manuell neu schrieben.

Das Muster der verketteten Schwachstellen ist ebenfalls bedeutsam. Die meisten Cloud-Erkennungen reagieren noch immer auf Einzelsignal-Anomalien: ein Impossible-Travel-Login, eine ungewöhnliche IAM-Richtlinienänderung, ein S3-Bucket, der öffentlich wird. Detection Engineering geht davon aus, dass die Aktionen eines Angreifers durch Minuten oder Stunden getrennt sind, weil ein Mensch zwischen den Schritten denkt. Wenn ein LLM die Kampagne orchestriert, können Credential-Harvest, Pipeline-Missbrauch und Data-Staging innerhalb desselben Alert-Fensters stattfinden – Korrelationslogik, die zeitliche Abstände erwartet, übersieht die Geschichte.

Die Impact-Aktionen verdienen besondere Aufmerksamkeit. ECS Desired Count auf null setzen, SQS-Queues leeren, Deny-ACLs auf Subnetze anwenden: Das sind alles legitime Betriebsbefehle. Sie liegen innerhalb der normalen API-Oberfläche. Sie lösen keine Malware-Signatur aus. Sie sehen nur in der Aggregation böswillig aus – und nur dann, wenn jemand das Aggregat beobachtet.

Avi Dayan, VP of Incident Response bei Sygnia, brachte den operativen Punkt gegenüber Dark Reading unmissverständlich auf den Punkt: „Wenn ein KI-Tool einen Breakout ausführen oder Daten in unter einer Minute exfiltrieren kann, wird ein Sicherheitsteam, das sich auf menschliche Triage von SIEM-Alerts verlässt, immer verlieren." Er argumentiert, MTTD und MTTR müssten „deutlich sinken", wenn LLMs im Spiel sind. Meine Einschätzung: Die meisten SOCs, die ich in iGaming und Fintech erlebt habe, arbeiten mit Triage-Zyklen von 15 bis 45 Minuten für Cloud-Alerts. Das liegt bereits außerhalb des Fensters, das Dayan beschreibt.

Wer ist betroffen

Jedes Team, das eine große AWS-Umgebung mit einer internetexponierten Anwendungsschicht betreibt, ist im Scope, aber einige Kategorien sind stärker gefährdet als andere. iGaming-Betreiber, Zahlungsabwickler und Krypto-Börsen teilen dasselbe unbequeme Profil: weitläufige AWS-Konten, aggressives CI/CD, hochwertige Datenspeicher und ein Geschäft, das S3-Ausfälle oder SQS-Purges zu Stoßzeiten buchstäblich nicht tolerieren kann. Die von Sygnia beschriebene Drucktaktik – reversible Impact-Aktionen als Erpressungsmittel – trifft am härtesten Unternehmen, bei denen eine Stunde Ausfallzeit im sechsstelligen Bereich gemessen wird.

Fintech-Plattformen haben ein zusätzliches Problem. Regulierungsbehörden interessiert es nicht, ob Ihr S3-Bucket von einem Bedrohungsakteur oder von Ihrem eigenen Team gesperrt wurde. Ein Vertraulichkeits- oder Verfügbarkeitsvorfall ist unter den meisten europäischen Rahmenwerken dennoch ein meldepflichtiges Ereignis. Incident-Response-Teams, mit denen ich zusammengearbeitet habe, sind bereits damit beschäftigt, mit der DORA-nahen Beweiserhebung Schritt zu halten. Kommt dazu ein Angreifer, der Wochen an Aktivität auf 72 Stunden komprimiert, wird die forensische Zeitlinie im Nachhinein nahezu unmöglich zu rekonstruieren.

Ad-Tech- und datenlastige SaaS-Betreiber befinden sich in einem anderen Schmerzbereich. Exfiltration ist die primäre Bedrohung, und Sygnia beschreibt systematische Exfiltration als einen der vier Workflows. Wenn Ihr Geschäftsmodell auf proprietären Datensätzen oder First-Party-Audience-Daten basiert, hat ein Angreifer, der Daten in einem kontinuierlichen Vorgang enumerieren, bereitstellen und abziehen kann, die Annahme gebrochen, dass Exfiltration langsam genug ist, um sie im laufenden Betrieb zu erkennen.

Die unbequeme Erkenntnis: Dieser Angriff kam von einer einzigen Person. Kein Nationalstaat, keine Ransomware-Gruppe mit Personalabteilung. Wenn die Hürde für dieses Playbook nun „Zugang zu einem leistungsfähigen LLM und moderates AWS-Wissen" lautet, hat sich die Anzahl realistischer Angreifer um eine Größenordnung erhöht. Jedes mittelständische Unternehmen, das davon ausging, zu uninteressant für eine gezielte Kampagne zu sein, muss diese Rechnung neu anstellen.

Playbook für Sicherheitsteams

Sygnias eigene Empfehlungen sind der richtige Ausgangspunkt: umfassende Sichtbarkeit über Assets und Identitäten aufrechterhalten, Identitätssicherheitskontrollen stärken, Cloud- und Entwicklungsumgebungen absichern, mehrschichtige Abwehrkontrollen implementieren, kritische Erkennungs- und Reaktionsprozesse automatisieren und vordefinierte Eindämmungsverfahren etablieren, die unmittelbar nach Identifizierung bösartiger Aktivitäten ausgeführt werden. Lesen Sie den letzten Punkt zweimal. „Unmittelbar" bedeutet keinen menschlichen Genehmigungsschritt für die erste Eindämmungsmaßnahme.

Konkrete Maßnahmen für diese Woche:

• Jede internetexponierte Anwendung auf Pfade prüfen, über die ein AWS-Access-Key durchsickern könnte. Der erste Zugang in diesem Fall war ein Key, der über eine Web-App-Schwachstelle exponiert wurde – das entspricht direkt den Kategorien im OWASP Top Ten. Nehmen Sie an, dass jeder langlebige statische AWS-Key, der vom Edge aus erreichbar ist, bereits kompromittiert ist.
• Langlebige Keys wo möglich abschaffen. Auf kurzlebige Zugangsdaten über IAM Roles Anywhere, IRSA oder Workload Identity Federation umstellen. Wenn ein Key nicht existieren kann, kann er auch nicht exfiltriert werden.
• CI/CD als erstklassige Angriffsfläche instrumentieren. Pipeline-Missbrauch war eine der verketteten Schwachstellen. Build-Runner wie Produktionssysteme behandeln und jeden Credential-Abruf protokollieren.
• Erkennungen für aggregierte Impact-Aktionen schreiben, nicht nur für Einzelereignisse. Eine IAM-Richtlinienänderung plus ein ECS-Scale-to-Zero plus ein SQS-Purge innerhalb derselben Stunde ist eine Kampagnensignatur, keine drei separaten Tickets.
• Eindämmung vorab autorisieren. Wenn Ihr Runbook sagt „On-Call benachrichtigen, dann IAM-User deaktivieren", streichen Sie den Zwischenschritt für hochkonfidente Signale. Dayans Sub-Minuten-Argument ist das vollständige Plädoyer.
• Das Erpressungsszenario gezielt üben. Das Szenario durchspielen, in dem jemand Ihre S3-Buckets sperrt und Krypto verlangt. Recht, Kommunikation und Engineering brauchen alle Muskelgedächtnis.

Nichts davon ist exotisch. Es ist die langweilige Version von Cloud-Sicherheit, richtig umgesetzt. Das Problem ist, dass „richtig" nun eine viel kürzere Frist hat.

Wichtigste Erkenntnisse

• Ein einzelner Angreifer kompromittierte laut Sygnia eine große AWS-Umgebung in etwa 72 Stunden mithilfe von Agentic-AI-Workflows und erpresste erfolgreich ein globales Unternehmen.
• Der Einbruch verkettete Schwachstellen über Apps, AWS-Ressourcen, Source-Repos, CI/CD, Laufzeit und Datenspeicher hinweg, anstatt eine einzige Fehlkonfiguration auszunutzen.
• Reversible Impact-Aktionen (S3-Sperren, ECS-Scale-to-Zero, ACL-Blockierungen, SQS-Purges) wurden als Erpressungsmittel eingesetzt, ohne Malware-Signaturen auszulösen.
• MTTD- und MTTR-Fenster, die auf menschlicher Triage von SIEM-Alerts beruhen, sind strukturell zu langsam, wenn LLMs die Angriffsseite orchestrieren.
• Prioritäre Abwehrmaßnahmen: langlebige AWS-Keys eliminieren, CI/CD absichern, aggregierte Impact-Signale korrelieren und Eindämmungsmaßnahmen vorab autorisieren.