AWS Incident Response: vom geleakten Key zum Krypto-Mining

Fiktives Szenario. Alles in diesem Beitrag – das Unternehmen, die Personen, das Konto 111122223333, die Schlüssel, der Bucket – ist erfunden. Die IP-Adressen stammen aus den Dokumentationsbereichen nach RFC 5737. Es handelt sich um die Daten hinter der Schaltfläche Beispiel ausprobieren im Analyzer, sodass Sie jeden Schritt nachvollziehen können.

Kurzfassung. Am fiktiven 14. September 2026 wird der Access Key des Entwicklers dev-marco von einem VPS aus verwendet, auf dem Kali Linux läuft. Innerhalb von 48 Minuten prüft der Angreifer den Schlüssel, erkundet das Konto, legt einen Administrator-Benutzer backup-admin mit eigenem Schlüssel und Konsolenpasswort an, löscht GuardDuty in zwei Regionen, lädt 320 Objekte aus acme-customer-exports herunter und startet acht GPU-Instanzen in ap-southeast-1, die für einen Pool minen. Die Logs zeigen all das. Die Bewertung lautet Anzeichen einer Kompromittierung, und die Liste der Bereinigungsschritte muss zwei Schlüssel, einen Benutzer, eine Richtlinie, zwei Detektoren, acht Instanzen und eine Prüfung der Meldepflichten abdecken.

Die Belege

Das Beispiel-ZIP bildet echte Exporte nach:

Vier ruhige Tage (10. bis 13. September) liefern die Baseline: ops-julia meldet sich mit MFA von der Büroadresse 198.51.100.24 an der Konsole an; dev-marco nutzt die CLI mit seinem langfristigen Schlüssel von derselben Adresse; eine ECS-Task-Rolle wird täglich übernommen.

Zeitleiste (UTC, 14. September 2026)

Der Credential-Report ergänzt einen Befund zur Sicherheitslage: backup-admin hat ein Konsolenpasswort, aber kein MFA.

Wie die Untersuchung verläuft

1. Die Bewertung. Dreiundzwanzig Befunde, mehrere davon mit hohem Schweregrad und mit Signalen auf Angreiferseite (Zugriffsanomalie, Umgehung von Abwehrmaßnahmen, Exfiltration, Auswirkung): Die Bewertung lautet „Anzeichen einer Kompromittierung“. Als Hauptgründe werden der offensive User-Agent, der von einer neuen IP verwendete Schlüssel, die Administratorrichtlinie, der für einen anderen Benutzer erstellte Schlüssel und die beiden GuardDuty-Löschungen aufgeführt.

2. Der Einstiegspunkt. Pivotieren Sie im Tab „Entitäten“ auf AKIA3EXAMPLEMARCO123: vier Tage lang 198.51.100.24 mit einer macOS-CLI, dann ab 09:02 203.0.113.77 mit einer Kali-Build-Kennung. Der allererste Aufruf von der neuen Adresse ist GetCallerIdentity – der Lehrbuch-Auftakt bei einem geleakten Access Key. Wie der Schlüssel geleakt ist (laut Szenario über ein öffentliches Repository), liegt außerhalb der AWS-Logs.

3. Der zweite Schlüssel. Pivotieren Sie auf 203.0.113.77: Neben dem Schlüssel von dev-marco hat diese Adresse AKIA3EXAMPLEBKUP4567 verwendet, den um 09:09:05 für backup-admin erzeugten Schlüssel. Ab 09:12 nutzt der Angreifer den geleakten Schlüssel nie wieder. Nur den Schlüssel von dev-marco zu deaktivieren, hätte nichts geändert. Das ist das Muster der IAM-Persistenz in seiner einfachsten Form.

4. Umgehung von Abwehrmaßnahmen. Beide Detektoren werden innerhalb einer Minute gelöscht, drei Minuten nachdem die Backdoor existiert. CloudTrail selbst bleibt aktiv – kein StopLogging –, weshalb der Rest der Geschichte sichtbar ist. Die GuardDuty-Befunde überleben nur, weil sie zuvor exportiert worden waren; siehe den Beitrag zur Umgehung von Abwehrmaßnahmen.

5. Die Daten. 320 GetObject in 21 Minuten, von einem Principal auf einem Bucket, doppelt belegt: in den CloudTrail-Datenereignissen und in den Server-Zugriffsprotokollen. Die Objektschlüssel (exports/2026/customers/customers-0001.csv.gz bis -0320) bilden das Inventar für die Meldung. Beachten Sie, dass die VPC Flow Logs hier nichts zeigen: Der Download lief über das Internet von S3 zum Host des Angreifers und nie durch die VPC – genau die Grenze, die im Beitrag über Belege für S3-Datenexfiltration beschrieben ist.

6. Die Kosten. Eine Region ohne Aktivität während der Baseline, eine Kontingenterhöhung, ein Schlüsselpaar, SSH offen für die ganze Welt und acht GPU-Instanzen; ab 09:52 sprechen deren Schnittstellen jede Minute mit einer einzigen Adresse auf Pool-Ports. Der Beitrag zu Krypto-Mining behandelt diese Phase.

7. Die Konsolensitzung. Um 09:50 meldet sich der Angreifer ohne MFA als backup-admin an. Alles, was ab dann in der Konsole geschieht, würde mit sessionCredentialFromConsole erscheinen; in diesem Datensatz endet die Geschichte mit dieser Sitzung.

Die daraus erzeugte Liste der Bereinigungsschritte

Eindämmung zuerst, mit den Werten aus den Logs:

1. Deaktivieren Sie AKIA3EXAMPLEMARCO123 und AKIA3EXAMPLEBKUP4567; ersetzen Sie den Schlüssel von dev-marco und entfernen Sie ihn aus dem Repository.
2. Sichern und löschen Sie anschließend backup-admin (Richtlinie, Schlüssel, Login-Profil).
3. Lösen Sie AdministratorAccess von backup-admin und prüfen Sie, wer diese Richtlinie sonst noch hat.
4. Blockieren Sie API-Aufrufe von 203.0.113.77, solange die Untersuchung läuft.
5. Erstellen Sie einen Snapshot einer Instanz, beenden Sie die acht Instanzen in ap-southeast-1 und prüfen Sie jede andere Region; löschen Sie das Schlüsselpaar ops-maint und die offene Sicherheitsgruppe; ziehen Sie die Kontingentanfrage L-417A185B zurück.
6. Aktivieren Sie GuardDuty in us-east-1 und eu-west-1 wieder (idealerweise überall).
7. Behandeln Sie acme-customer-exports als exfiltriert: Listen Sie die 320 Objekte auf und prüfen Sie die Meldepflichten.
8. Eröffnen Sie einen Fall beim AWS Support wegen der unbefugten Nutzung.

Was dieses Beispiel nicht zeigt

Echte Vorfälle sind unordentlicher: laute CI-Rollen, mehrere Angreifer-IPs, Role Chaining, Aktivität verteilt über Wochen und Logs, die genau dort fehlen, wo Sie sie brauchen. Das Beispiel ist bewusst sauber gehalten, damit die Methode sichtbar wird. Lesen Sie den Beitrag über die Grenzen einer rein logbasierten Untersuchung, bevor Sie echte Daten mit derselben Gewissheit bewerten, und folgen Sie für den Ablauf der Schritt-für-Schritt-Anleitung zur CloudTrail-Log-Analyse.