AWS Incident Response: kompromittiertes Konto untersuchen

Kurzfassung. Behandeln Sie „unser AWS-Konto ist kompromittiert“ als zwei parallel laufende Aufgaben: die Blutung stoppen (die Anmeldedaten des Angreifers deaktivieren, alles beenden, was er gestartet hat) und die Logs sichern und auswerten (zuerst CloudTrail, dann S3-Datenereignisse oder Zugriffsprotokolle, VPC Flow Logs, GuardDuty-Befunde und den IAM-Credential-Report). Grenzen Sie ein, bevor Sie aufräumen: Jeder IAM-Benutzer, jeder Schlüssel, jede Rollen-Vertrauensstellung und jede Instanz, die der Angreifer angelegt hat, muss gefunden werden – sonst schließen Sie den Einstiegspunkt und lassen die Hintertür offen. Die übrigen Beiträge dieser Serie gehen jeden Schritt im Detail durch.

Die meisten AWS-Vorfälle, die ich sehe, beginnen nicht mit einer Zero-Day-Lücke. Sie beginnen mit Anmeldedaten: einem Access Key, der in ein Repository committet wurde, einem Schlüssel, der in CI-Logs liegen geblieben ist, einem Konsolenpasswort ohne MFA oder einer Rolle, die zu vielen vertraut. Was danach folgt, ist erstaunlich gleichförmig: prüfen, ob der Schlüssel funktioniert, Ressourcen auflisten, sich einen Weg zurück ins Konto schaffen, die Verteidiger blind machen, dann Daten abziehen oder Rechenleistung verbrennen. Diese Gleichförmigkeit ist eine gute Nachricht für Responder, denn jeder Schritt hinterlässt einen bestimmten API-Aufruf in CloudTrail.

Minute null: Anzeichen für ein kompromittiertes AWS-Konto

Ausgelöst wird die Untersuchung meist durch eines dieser Signale:

AWS dokumentiert die GuardDuty-Befundtypen für IAM und veröffentlicht eine verwaltete Richtlinie, AWSCompromisedKeyQuarantineV3, die AWS an einen IAM-Benutzer anhängen kann, dessen Schlüssel es für offengelegt hält. Finden Sie diese Richtlinie an einem Benutzer, ist das Leak bestätigt: Entfernen Sie sie nicht, und folgen Sie dem Support-Fall.

Die erste Stunde: eindämmen, ohne Beweise zu vernichten

Eindämmung und Beweissicherung ziehen nur dann in entgegengesetzte Richtungen, wenn man unsauber arbeitet. Diese Reihenfolge hat sich bewährt:

1. Sichern Sie die Logs, auf die Sie angewiesen sind. Laden Sie die CloudTrail-Objekte für den Zeitraum aus dem Bucket des Trails herunter, exportieren Sie die GuardDuty-Befunde und erzeugen Sie den IAM-Credential-Report. Hat der Angreifer Administratorrechte, kann er Trails und Detektoren löschen; der Ereignisverlauf bewahrt Management-Ereignisse nur 90 Tage pro Region auf. Die Anleitung zum Log-Export enthält die genauen Befehle.
2. Deaktivieren Sie die Anmeldedaten, von denen Sie wissen, dass sie kompromittiert sind. Für den Schlüssel eines IAM-Benutzers: aws iam update-access-key --status Inactive. Für eine Rollensitzung nutzen Sie in der IAM-Konsole „Revoke active sessions“, das eine Deny-Regel für alle bis jetzt ausgestellten Tokens hinzufügt (AWS-Dokumentation).
3. Löschen Sie nichts, was Sie noch nicht untersucht haben. Wer einen vom Angreifer angelegten Benutzer löscht, löscht auch dessen Inline-Richtlinien und Schlüssel – und die wollen Sie in der Fallakte haben. Erst lösen, deaktivieren, und nach der Eingrenzung löschen.
4. Stoppen Sie die Kostenblutung. Erstellen Sie Snapshots nicht autorisierter Instanzen und stoppen oder beenden Sie sie – in jeder Region.
5. Eröffnen Sie einen Support-Fall bei AWS. Sowohl die re:Post-Empfehlungen zu nicht autorisierten Aktivitäten als auch das Playbook für kompromittierte Anmeldedaten von aws-samples empfehlen, AWS früh zu informieren.

Eingrenzung: den Angriff in CloudTrail lesen

Eingrenzen heißt, vier Fragen zu beantworten, jede mit einem eigenen Pivot in CloudTrail:

• Welche Anmeldedaten kamen zuerst ins Spiel? Pivotieren Sie auf userIdentity.accessKeyId und sourceIPAddress. Ein langfristiger Access Key (Präfix AKIA), der plötzlich von einer Adresse außerhalb seiner Historie verwendet wird, ist das klassische Muster eines geleakten Schlüssels. Beginnen Sie mit der Untersuchung eines geleakten Access Keys.
• Was hat der Angreifer erfahren? Ein GetCallerIdentity-Aufruf, gefolgt von Dutzenden List*-, Describe*- und Get*-Aufrufen innerhalb weniger Minuten, oft mit AccessDenied-Fehlern, ist Enumeration.
• Was hat er angelegt? CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, UpdateAssumeRolePolicy, neue SAML-/OIDC-Anbieter, Schlüsselpaare, Lambda-Funktionen. Der Beitrag zu IAM-Persistenz behandelt jeden einzelnen davon.
• Worauf hat er zugegriffen? Lesezugriffe auf S3-Objekte (nur sichtbar mit Datenereignissen oder Server-Zugriffsprotokollen), mit anderen Konten geteilte Snapshots, ausgelesene Secrets, gestartete Instanzen.

Der Beitrag über CloudTrail-Ereignisse, die jeder Responder kennen sollte, liefert die vollständige Liste mit MITRE-ATT&CK-Zuordnung. Ziel in dieser Phase ist eine Zeitleiste: jede Aktion des Angreifers in der richtigen Reihenfolge, mit dem jeweiligen Principal, Schlüssel, der IP-Adresse und der betroffenen Ressource.

Die Pivots, auf die es ankommt

Führen Sie Ihre Pivots so lange fort, bis sie keine neuen Entitäten mehr liefern. Die IP des Angreifers führt Sie zu einem zweiten Schlüssel, der zweite Schlüssel zu einem Benutzer, der Benutzer zu einer Rolle, die er übernommen hat.

Eingrenzung über CloudTrail hinaus

CloudTrail-Management-Ereignisse sagen Ihnen, was konfiguriert wurde. Sie sagen Ihnen nicht, welche Objekte gelesen wurden oder wie viele Bytes eine VPC verlassen haben. Dafür brauchen Sie Belege auf S3-Datenebene und die Analyse von VPC Flow Logs. Waren diese Quellen nie aktiviert, schreiben Sie das so in den Bericht, statt zu folgern, dass nichts abgeflossen ist – die Grenzen einer reinen Log-Untersuchung sollten Sie lesen, bevor Sie irgendein Fazit formulieren.

War der Einstiegspunkt gar kein AWS-Schlüssel, sondern eine föderierte Identität, beginnen die Belege beim Identitätsanbieter: Eine über Okta erfolgte Anmeldung untersuchen Sie besser mit oktaforensics.com, einen aus einem Repository geleakten Schlüssel mit githubforensics.com. Bei kompromittierten EKS-Workloads ist das Kubernetes-Audit-Log genauso wichtig wie CloudTrail (kubernetesforensics.com).

Beseitigung: jeden Brückenkopf entfernen

Sobald die Zeitleiste steht, räumen Sie in dieser Reihenfolge auf:

1. Jeden während des Vorfalls angelegten Access Key deaktivieren und dann löschen.
2. Vom Angreifer angelegte IAM-Benutzer (nach Sicherung ihrer Richtlinien), Login-Profile und MFA-Geräte löschen.
3. Während des Vorfalls vergebene Administratorrichtlinien lösen; prüfen, wer sie sonst noch hat.
4. Änderungen an Vertrauensrichtlinien von Rollen zurücknehmen und unbekannte Identitätsanbieter löschen.
5. Öffentliche Lambda-Berechtigungen, Function URLs ohne Authentifizierung, EC2-Schlüsselpaare und geänderte User Data entfernen.
6. CloudTrail, GuardDuty, Config und jeden Sicherheitsdienst, den der Angreifer deaktiviert hat, wieder aktivieren – in jeder Region.
7. Jedes Secret rotieren, das der Angreifer lesen konnte.

Wenn Sie AWS Organizations nutzen, erwägen Sie eine Service Control Policy, die ungenutzte Regionen sperrt: Damit nehmen Sie dem Angreifer sein liebstes Versteck.

Wie das Tool hier hineinpasst

AWS Forensics führt diesen Eingrenzungsschritt in Ihrem Browser aus. Legen Sie die exportierten CloudTrail-Dateien ab (dazu Flow Logs, S3-Zugriffsprotokolle, GuardDuty-Befunde und den Credential-Report, falls vorhanden), und Sie erhalten eine Bewertung – „Keine Anzeichen einer Kompromittierung in diesen Logs“, „Verdächtige Aktivität — Prüfung erforderlich“ oder „Anzeichen einer Kompromittierung“ – mit den Befunden, den Belegzeilen hinter jedem einzelnen, einer Zeitleiste und einer Checkliste zur Bereinigung, bei der die Eindämmung zuerst kommt. Es wird nichts hochgeladen. Die Schritt-für-Schritt-Anleitung zur Analyse zeigt den Ablauf, und der Durchgang durch einen fiktiven Vorfall spielt ihn mit den Beispieldaten von Anfang bis Ende durch.

Die Bewertung ist eine Triage-Hilfe, kein Ergebnis. Sie ist nur so gut wie die Logs, die Sie ihr geben, und jeder Befund zeigt seine Belege, damit Sie ihn bestätigen oder verwerfen können.

FAQ

Woran erkenne ich, dass mein AWS-Konto kompromittiert wurde?

Suchen Sie in CloudTrail nach API-Aufrufen, die Sie niemandem zuordnen können: ein langfristiger Access Key, der von einer unbekannten IP-Adresse aus verwendet wird, IAM-Benutzer oder Schlüssel, die niemand angelegt hat, deaktiviertes GuardDuty oder CloudTrail, Instanzen in Regionen, die Sie nie nutzen, oder Massen-Downloads aus S3. Ein Kostensprung auf der Rechnung oder ein GuardDuty-Befund ist oft das erste sichtbare Anzeichen.

Sollte ich den kompromittierten Access Key sofort löschen?

Deaktivieren Sie ihn zuerst, statt ihn zu löschen. Ein inaktiver Schlüssel kann keine Anfragen mehr signieren, existiert aber weiterhin, was die Untersuchung einfach hält. Löschen Sie ihn erst, wenn Sie eingegrenzt haben, was er getan hat, und ihn überall ersetzt haben, wo er legitim genutzt wurde.

Muss ich AWS kontaktieren?

AWS bittet Kunden, bei Verdacht auf kompromittierte Anmeldedaten einen Support-Fall zu eröffnen; das ist auch der Weg für Fragen zu nicht autorisierten Kosten. Der Support-Fall ersetzt nicht Ihre eigene Untersuchung von CloudTrail.

Weiterführende Literatur

• AWS Security Incident Response Guide – der IR-Prozess von AWS selbst.
• Remediating potentially compromised AWS credentials – GuardDuty-Dokumentation.
• Incident response guide for AWS CloudTrail investigations – AWS Security Blog.
• MITRE ATT&CK IaaS matrix – die Techniken, auf die sich diese Serie bezieht.