Geleakten AWS Access Key untersuchen: Schritt für Schritt

Kurzfassung. 1) Deaktivieren Sie den Schlüssel (aws iam update-access-key --status Inactive), löschen Sie ihn noch nicht. 2) Holen Sie sich jedes CloudTrail-Ereignis, bei dem userIdentity.accessKeyId dieser Schlüssel ist, von deutlich vor dem Leak bis heute. 3) Finden Sie die erste Nutzung von einer neuen IP: Das ist der Einstieg des Angreifers. 4) Listen Sie von dort aus auf, was der Schlüssel aufgelistet hat, was er angelegt hat (Benutzer, Schlüssel, Passwörter, Richtlinien, Instanzen) und welche Daten er lesen konnte. 5) Pivotieren Sie auf die IP des Angreifers, um weitere Anmeldedaten zu erwischen. Bereinigen Sie alles, was der Schlüssel angelegt hat, nicht nur den Schlüssel selbst.

Langfristige Access Keys – diejenigen, deren ID mit AKIA beginnt (Referenz der IAM-Kennungen) – laufen nicht ab. Landet einer in einem öffentlichen Repository, einem CI-Log, einer Schicht eines Docker-Images oder einem eingefügten Support-Ticket, hat jeder, der ihn findet, die Berechtigungen des zugehörigen Benutzers, bis es jemandem auffällt. Bei der Untersuchung geht es darum, die Frage „Was haben sie damit gemacht?“ so präzise zu beantworten, dass sich alles rückgängig machen lässt.

Schritt 0: deaktivieren, nicht löschen

aws iam update-access-key --user-name <user> --access-key-id AKIA... --status Inactive

Ein inaktiver Schlüssel kann sich nicht mehr authentifizieren. Wenn Sie ihn (inaktiv) behalten, statt ihn zu löschen, bleibt seine ID während der Untersuchung in IAM und im Credential-Report sichtbar. Klären Sie vor dem Deaktivieren, was den Schlüssel legitim nutzt – ein Produktionsjob, der um 3 Uhr nachts fehlschlägt, ist ein Preis, den man vorher kennen sollte, aber kein Grund zu warten.

Prüfen Sie, ob AWS bereits reagiert hat: Ist an den Benutzer die Richtlinie AWSCompromisedKeyQuarantineV3 angehängt, hat AWS die Offenlegung erkannt und einen Support-Fall eröffnet. Die Richtlinie verweigert eine Liste risikoreicher Aktionen (iam:CreateUser, iam:CreateAccessKey, ec2:RunInstances und weitere); ein Angreifer, der vor dem Anhängen aktiv war, kann dennoch Erfolg gehabt haben.

Ist der Schlüssel aus einem GitHub-Repository geleakt, ist dessen eigener Audit-Trail – wer ihn gepusht hat, wann, ob das Repository öffentlich war – eine separate Untersuchung; githubforensics.com deckt diese Seite ab.

Schritt 1: die vollständige Historie des Schlüssels beschaffen

Mit einem Trail filtern Sie die exportierten Dateien nach dem Schlüssel. Mit jq über einen Ordner mit dekomprimierten Dateien:

zcat cloudtrail/**/*.json.gz | jq -c '.Records[]
  | select(.userIdentity.accessKeyId == "AKIA...")
  | [.eventTime, .sourceIPAddress, .eventSource, .eventName, (.errorCode // "")]'

Ohne Trail unterstützt der Ereignisverlauf eine Suche nach Schlüssel (pro Region):

aws cloudtrail lookup-events --region us-east-1 \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...

Die Spalten access_key_1_last_used_date, _region und _service des Credential-Reports eignen sich für eine schnelle Plausibilitätsprüfung, erfassen aber nur die erste Nutzung in jedem 15-Minuten-Intervall (IAM-Dokumentation). Maßgeblich ist CloudTrail.

Schritt 2: die erste bösartige Nutzung finden

Gruppieren Sie die Ereignisse des Schlüssels nach sourceIPAddress und userAgent. Legitime Nutzung bildet Cluster: der Internet-Ausgang des Büros, der Adressbereich eines CI-Runners, die CLI-Version des Entwicklers. Der Angreifer zeigt sich durch:

• eine neue Adresse (oft ein VPS oder Hosting-Anbieter),
• einen anderen User-Agent – ein anderes Betriebssystem, ein älteres SDK, manchmal ein verräterisches Detail wie eine Kali-Build-Kennung,
• einen GetCallerIdentity-Aufruf als allererste Anfrage. Er benötigt keine Berechtigungen (STS-API-Referenz) und ist damit die universelle Prüfung „Funktioniert dieser Schlüssel, und wem gehört er?“.

Die Erkennung „Langfristiger Access Key von neuer IP-Adresse verwendet“ des Analysetools automatisiert das: Sie lernt die Adressen des Schlüssels während seines ersten Tages in den Logs und markiert spätere Nutzung von einer öffentlichen Adresse außerhalb dieser Menge. Ihr Wert hängt von der Baseline ab, laden Sie also einige Tage vor dem vermuteten Leak mit.

Schritt 3: Was hat er aufgelistet?

Angreifer kartieren Berechtigungen schnell. In CloudTrail zeigt sich das als Salve aus Dutzenden verschiedener List*-, Describe*- und Get*-Aufrufe über IAM, S3, EC2, Lambda, Secrets Manager und andere Dienste innerhalb weniger Minuten, häufig durchsetzt mit AccessDenied-Fehlern, wo dem Schlüssel die Rechte fehlen. GetAccountAuthorizationDetails ist ein besonders lohnendes Ziel: Der Aufruf liefert jeden Benutzer, jede Rolle, Gruppe und Richtlinie auf einmal.

Fehlgeschlagene Aufrufe sind wichtig: Sie zeigen, was der Angreifer wollte, und damit, was Sie als Nächstes schützen müssen.

Schritt 4: Was hat er angelegt?

Hier scheitern Untersuchungen am häufigsten. Suchen Sie nach jedem erfolgreichen Schreibzugriff:

• CreateUser, CreateLoginProfile, CreateAccessKey (vor allem für einen anderen Benutzer), AttachUserPolicy / PutUserPolicy mit Administratorrechten;
• UpdateAssumeRolePolicy, CreateSAMLProvider, CreateOpenIDConnectProvider;
• RunInstances, CreateKeyPair, ImportKeyPair, AuthorizeSecurityGroupIngress;
• CreateFunction, AddPermission, CreateFunctionUrlConfig.

Die responseElements von CreateAccessKey enthalten die ID des neuen Schlüssels – Ihr nächster Pivot. Der Beitrag zu IAM-Persistenz und Rechteausweitung beschreibt jede einzelne Technik.

Schritt 5: Welche Daten konnte er erreichen?

Management-Ereignisse zeigen ListBuckets und GetBucketPolicy, aber keine Lesezugriffe auf Objekte. Um zu wissen, ob Objekte heruntergeladen wurden, brauchen Sie S3-Datenereignisse oder Server-Zugriffsprotokolle; siehe Belege für S3-Datenexfiltration. Prüfen Sie außerdem GetSecretValue, GetParametersByPath, ModifySnapshotAttribute (Teilen eines Snapshots mit einem anderen Konto) und GetPasswordData.

Schritt 6: auf die IP des Angreifers pivotieren

Pivotieren Sie über alle Principals hinweg auf jede Adresse des Angreifers. Häufig finden Sie so den neuen Schlüssel des Backdoor-Benutzers, eine Konsolenanmeldung eines angelegten Benutzers oder eine übernommene Rollensitzung – Aktivität, die die ID des geleakten Schlüssels nicht mehr trägt.

Checkliste zur Bereinigung bei einem geleakten Schlüssel

1. Geleakter Schlüssel: jetzt inaktiv, nach der Eingrenzung gelöscht; aus Code, CI-Variablen, Images und Historie entfernen.
2. Jeder während des Vorfalls angelegte Schlüssel: deaktivieren, dann löschen.
3. Vom Angreifer angelegte oder angehängte Benutzer, Login-Profile, Gruppenmitgliedschaften und Richtlinien: sichern, dann entfernen.
4. Geänderte Vertrauensrichtlinien von Rollen und Identitätsanbieter: zurücksetzen.
5. Instanzen, Schlüsselpaare, Regeln von Sicherheitsgruppen, Lambda-Funktionen in allen Regionen: bei Bedarf Snapshot erstellen, dann entfernen.
6. Vom Angreifer gelesene Secrets: rotieren.
7. Deaktivierte Protokollierungs- und Erkennungsdienste: wieder aktivieren (Beitrag zur Umgehung von Abwehrmaßnahmen).

Legen Sie die CloudTrail-Historie des Schlüssels im Analysetool ab, um diese Liste mit den tatsächlichen Schlüssel-IDs, Benutzern und Regionen aus Ihren Logs vorausgefüllt zu erhalten. Für die kontoweite Sicht kehren Sie zum Überblick zur AWS Incident Response zurück.

FAQ

Kann ich sehen, welche IP-Adressen einen geleakten AWS Access Key verwendet haben?

Ja. Jedes CloudTrail-Ereignis, das mit dem Schlüssel signiert wurde, enthält ihn in userIdentity.accessKeyId und die Adresse des Aufrufers in sourceIPAddress. Filtern Sie auf den Schlüssel und listen Sie die unterschiedlichen Adressen auf; ohne Trail funktioniert der Ereignisverlauf für die Management-Ereignisse der letzten 90 Tage.

Ist ein GetCallerIdentity-Aufruf ein Beweis dafür, dass ein Schlüssel gestohlen wurde?

Nein. Die AWS CLI und die SDKs rufen ihn routinemäßig auf, und er benötigt keinerlei Berechtigungen. Aussagekräftig wird er, wenn er der erste Aufruf von einer Adresse ist, die der Schlüssel nie zuvor genutzt hat – vor allem, wenn innerhalb weniger Minuten eine Enumeration folgt.

Stoppt das Deaktivieren des Schlüssels den Angreifer?

Es stoppt diesen einen Schlüssel. Es stoppt nicht die Anmeldedaten, die der Angreifer damit angelegt hat: weitere Access Keys, Konsolenpasswörter, Benutzer, geänderte Rollen-Vertrauensstellungen. Diese finden Sie, indem Sie die Aktivität des Schlüssels in CloudTrail eingrenzen.

Weiterführende Literatur

• Remediating potentially compromised AWS credentials
• Compromised IAM credentials playbook (aws-samples)
• Incident response guide for AWS CloudTrail investigations, part 2