Ihr AWS-Account wurde kompromittiert: Die ersten 24 Stunden

Dieser Artikel ist nicht theoretisch. Wir haben AWS-Accounts wenige Stunden nach einer Kompromittierung betreten, zugesehen, wie Angreifer GPU-Flotten fürs Krypto-Mining in einem halben Dutzend Regionen hochfuhren, und anschließend die Billing-Gespräche mit AWS durchgestanden. Das Muster ist bemerkenswert konsistent — und das Playbook, das den Schaden begrenzt, ebenso. So sollten die ersten 24 Stunden aussehen, in dieser Reihenfolge, basierend auf Incidents, die wir tatsächlich bearbeitet haben.

Wie Sie es erfahren (meist zu spät)

Fast niemand entdeckt den Einbruch selbst; entdeckt werden seine Nebenwirkungen:

• Ein Kostenanomalie-Alarm — oder schlimmer, die Monatsrechnung. Mining-Flotten zeigen sich als plötzliche EC2-/GPU-Ausgaben in Regionen, die Sie nie benutzt haben.
• Ressourcen in fremden Regionen — Angreifer nutzen gezielt Regionen, die Sie nicht beobachten (São Paulo, Osaka, Cape Town). Wenn Sie nur in Frankfurt betreiben, ist alles in ap-northeast-3 ein Warnsignal.
• GuardDuty-Findings — sofern es aktiviert war. In den meisten kompromittierten Accounts, die wir betreten, war es das nicht.
• Anträge auf Quota-Erhöhung, die Sie nie gestellt haben — Angreifer beantragen EC2- und SES-Limiterhöhungen, um ihre Operation zu skalieren. Ein unerklärter Quota-Case in Ihrer Support-Historie ist ein Kompromittierungsindikator, keine administrative Kuriosität.
• SES-Versandspitzen oder eine Sperrmitteilung — Ihr Account ist zur Spam-Infrastruktur geworden.

Die Root Cause ist nach unserer Erfahrung langweilig konsistent: ein langlebiger Access Key ist geleakt — in ein öffentliches Repo committet, in ein Image eingebacken, in ein CI-Log kopiert — oder ein IAM-User mit schwachem Passwort und ohne MFA.

Stunde 0–1: Zugriff kappen, noch nicht aufräumen

• 1. Den kompromittierten Principal identifizieren. CloudTrail → die Ressourcen, die Sie nicht erstellt haben → welcher Access Key / User / welche Rolle sie erstellt hat. Überspringen Sie das nicht: Rotieren Sie das falsche Credential, arbeitet der Angreifer weiter, während Sie sich sicher fühlen.
• 2. Das Credential unschädlich machen. Access Key deaktivieren, dann löschen. Hängen Sie dem kompromittierten User/der Rolle eine Explicit-Deny-Policy an, bevor Sie Sessions löschen — temporäre Session-Tokens überleben die Key-Deaktivierung, also ist eine Deny-Policy (oder das Widerrufen der Sessions auf der Rolle) das, was den laufenden Zugriff tatsächlich kappt.
• 3. Root absichern. Root-Passwort rotieren, MFA auf Root bestätigen, E-Mail-Weiterleitungsregeln des Root-Postfachs prüfen. Wurde Root selbst kompromittiert, ist das jetzt ein Gespräch mit dem AWS Support — eröffnen Sie sofort einen Case mit der höchsten Severity.
• 4. Beweise sichern. Löschen Sie keine CloudTrail-Logs und terminieren Sie nicht in Panik alles. Sie werden die Timeline brauchen — für die Forensik, für AWS und möglicherweise für Aufsichtsbehörden.

Stunde 1–6: Eindämmung in jeder Region

• Alle Regionen durchkämmen, nicht nur Ihre. Skripten Sie es oder nutzen Sie den Resource Explorer: EC2-Instanzen, Spot Fleets, Auto Scaling Groups, Lambda-Funktionen, ECS-Cluster, SageMaker-Notebooks — in jeder Region. Mining-Operationen, die wir aufgeräumt haben, liefen in sechs Regionen gleichzeitig; ASGs erstellen terminierte Instanzen neu, also zuerst die ASG finden und löschen.
• Persistenz jagen. Angreifer rechnen damit, dass Sie die Miner finden; sie legen sich Wege zurück hinein. Prüfen Sie auf: neue IAM-User und Access Keys, neue Rollen mit Trust Policies auf externe Accounts, veränderte Trust Relationships bestehender Rollen, neue Lambda-Funktionen mit Zeitplänen, EC2-Instanzprofile mit zusätzlichen Policies und Backdoor-Identity-Provider über OIDC/SAML.
• Prüfen, was sie angefasst haben. CloudTrail verrät, ob es reiner Ressourcenmissbrauch war (Mining, Spam) oder Datenzugriff: S3-GetObject-Stürme, extern geteilte RDS-Snapshots, aus dem Secrets Manager gelesene Secrets. Die Antwort verändert Ihre rechtlichen Pflichten.
• Quarantäne, dann Neuaufbau. Alles, was der Angreifer angefasst hat, ist nicht vertrauenswürdig. Für die Forensik snapshotten, dann aus sauberen Quellen neu aufbauen, statt laufende Systeme zu „säubern“.

Stunde 6–24: AWS, Geld und Pflichten

• Einen Support-Case mit dem Stichwort „compromised account“ eröffnen. AWS hat dafür einen eigenen Ablauf; Trust & Safety wird eingebunden, und deren Team sieht Angreiferaktivität, die Sie nicht sehen können.
• Das Billing-Gespräch führen. AWS prüft routinemäßig Kosten aus unberechtigter Nutzung infolge einer Kompromittierung — wir haben fünfstellige und größere Incident-Rechnungen zu wesentlichen Teilen gutgeschrieben gesehen. Was hilft: Sie haben zügig erkannt und eingedämmt, Sie können die Timeline zeigen, und Sie schließen die Root Cause (danach wird gefragt). Reichen Sie es als Billing-Case mit Verweis auf den Security-Case ein; sachlich und vollständig.
• Meldepflichten prüfen. Wurde auf personenbezogene Daten zugegriffen, laufen womöglich bereits Meldefristen (72-Stunden-Regime unter der DSGVO und, in der Türkei, dem KVKK). Binden Sie früh Rechtsbeistand ein — „wir untersuchen noch“ ist eine vertretbare Zwischenantwort; Schweigen ist es nicht.
• Die Timeline schreiben, solange sie frisch ist. Erkennungszeitpunkt, Eindämmungsmaßnahmen, Beweise. Sie werden sie dreimal brauchen: für AWS, für jede Aufsichtsbehörde und für Ihr eigenes Postmortem.

Die Woche danach: Runde zwei deutlich schwerer machen

Jeder Incident, den wir bearbeitet haben, führt auf dieselbe kurze Liste zurück, also ist die Härtungsliste ebenso kurz: langlebige Access Keys eliminieren (IAM-Rollen und Identity Federation nutzen; Repos nach Secrets scannen), MFA überall erzwingen, GuardDuty und org-weites CloudTrail mit Logs in einem separaten, abgeriegelten Account aktivieren, Billing-Anomalie-Alarme mit täglichen Schwellenwerten setzen und ungenutzte Regionen per SCP sperren. Unsere 98-Punkte-AWS-Sicherheitscheckliste deckt all das in Checkbox-Form ab, und unser Incident-Response-Playbook verallgemeinert diesen Artikel über AWS hinaus.

Häufige Fragen

Erstattet AWS die Kosten eines gehackten Accounts?
Es gibt keine vertragliche Garantie, aber in der Praxis prüft AWS Kosten aus unberechtigter Nutzung Fall für Fall und schreibt häufig erhebliche Beträge gut — vorausgesetzt, Sie haben zügig eingedämmt, die Timeline dokumentiert und die Root Cause behoben. Eröffnen Sie einen Billing-Case mit Verweis auf Ihren Security-Case.

Wie kommen Angreifer hinein?
Ganz überwiegend: geleakte langlebige Access Keys (öffentliche Repos, Images, CI-Logs) und IAM-User ohne MFA. Ausgefeilte Zero-Days sind die Ausnahme; Versäumnisse bei der Credential-Hygiene sind die Regel.

Reicht es, den Access Key zu deaktivieren?
Nein. Aktive Session-Tokens können die Key-Deaktivierung überleben. Hängen Sie dem Principal eine Explicit-Deny-Policy an und widerrufen Sie aktive Sessions auf Rollen, dann rotieren Sie alles, was der Angreifer gelesen haben könnte.

Sollten wir den AWS-Account einfach schließen?
Als erste Reaktion fast nie — Sie verlieren Beweise, brechen legitime Workloads und widerrufen geleakte Credentials, die gegen andere Accounts funktionieren könnten, gar nicht wirklich. Eindämmen, untersuchen, dann entscheiden.

Fazit

Eine AWS-Kompromittierung ist überlebbar — oft mit einem erheblichen Anteil der unberechtigten Kosten gutgeschrieben —, wenn der erste Tag in der richtigen Reihenfolge abläuft: Zugriff kappen, überall eindämmen, Beweise sichern, mit AWS sprechen, dann härten. Am meisten leiden die Teams, die diese Reihenfolge um 3 Uhr nachts zum ersten Mal improvisieren.

Gerade mitten in einem Incident? Unser Security-Team fährt Notfall-Incident-Response für €15.000/Woche mit Start am selben Tag. Es brennt nicht, aber sicher fühlen Sie sich auch nicht? Das AWS Security Audit (Festpreis €8.000) findet die geleakten Keys und das fehlende MFA, bevor ein Angreifer es tut.