CloudTrail-Log-Analyse: eine Schritt-für-Schritt-Anleitung

Kurzfassung. Sammeln Sie die Exporte, legen Sie alle im Analysetool ab und arbeiten Sie dann in dieser Reihenfolge: Bewertung und Abdeckung (was das Tool sehen konnte und was nicht) → Befunde (jeden anhand seiner Belegzeilen bestätigen) → Pivots auf Entitäten (jeder Schlüssel, jede IP und jeder Principal, den der Angreifer berührt hat) → Zeitleiste (die Geschichte in der richtigen Reihenfolge) → Bereinigung (Eindämmung zuerst). Planen Sie für einen typischen Vorfall mit geleaktem Schlüssel 30 bis 60 Minuten ein. Alles läuft lokal in WebAssembly; kein Log verlässt Ihren Browser.

Diese Anleitung verwendet AWS Forensics, weil diese Website es bereitstellt, die Methode ist aber dieselbe, womit auch immer Sie arbeiten – Athena, CloudTrail Lake, ein SIEM oder jq. Die Fragen ändern sich nicht; nur die Geschwindigkeit, mit der Sie sie beantworten.

Schritt 1 – Exporte sammeln

Besorgen Sie die CloudTrail-Dateien für das Zeitfenster des Vorfalls plus zwei bis drei ruhige Tage davor. Zwei Erkennungen – „Langfristiger Access Key von neuer IP-Adresse verwendet“ und „Aktivität in einer bisher ungenutzten Region“ – vergleichen mit dem ersten Aktivitätstag in den Logs; ohne Baseline haben sie also nichts, womit sie vergleichen könnten. Das Tool warnt Sie, wenn weniger als zwei Tage CloudTrail geladen sind.

Ergänzen Sie, was Sie sonst noch haben:

• VPC Flow Logs (Exfiltration über das Netzwerk, Mining-Traffic)
• S3-Server-Zugriffsprotokolle oder CloudTrail-S3-Datenereignisse (Lesezugriffe auf Objekte)
• GuardDuty-Befunde als JSON
• Den IAM-Credential-Report (MFA, Root-Keys, während des Vorfalls angelegte Benutzer)

Die Anleitung zum Export enthält die Befehle für jede Quelle.

Schritt 2 – Alles auf einmal laden

Wählen Sie auf der Startseite über „Dateien auswählen“ oder „Ordner auswählen“ Ihre Exporte aus, oder legen Sie sie per Drag-and-drop ab. Unverändert akzeptiert werden:

ZIP-Archive (auch verschachtelte) und gzip werden als Stream dekomprimiert, sodass Exporte von mehreren Gigabyte nicht in den Arbeitsspeicher passen müssen. Digest-Dateien werden erkannt und übersprungen. Der Tab Dateien listet jede Datei mit dem erkannten Format auf, und ein Abschnitt „Nicht analysierte Dateien“ erklärt alles, was übersprungen wurde – ein ALB-Log, ein Flow Log im Parquet-Format, eine abgeschnittene gzip-Datei.

Wenn Sie zuerst üben möchten, klicken Sie auf Beispiel ausprobieren: Damit wird ein synthetischer Export eines fiktiven Vorfalls geladen, der klar als solcher gekennzeichnet ist.

Schritt 3 – Bewertung und Hinweise zur Abdeckung lesen

Die Bewertung hat drei Stufen:

• Anzeichen einer Kompromittierung – mindestens ein kritischer Befund oder zwei Befunde mit hohem Schweregrad, darunter mindestens ein Signal auf Angreiferseite (Zugriffsanomalie, Erkundung, Umgehung von Abwehrmaßnahmen, Exfiltration, Auswirkung oder ein GuardDuty-Befund).
• Verdächtige Aktivität — Prüfung erforderlich – ein beliebiger Befund mit hohem oder mittlerem Schweregrad oder mehrere niedrige.
• Keine Anzeichen einer Kompromittierung in diesen Logs – keine Erkennung hat angeschlagen.

Konfigurationsbefunde aus dem Credential-Report (Root-Keys, Benutzer ohne MFA) werden angezeigt, fließen aber nicht in die Bewertung ein: Sie beschreiben die Sicherheitslage, keine Aktivität.

Lesen Sie danach den Block Abdeckung. „Keine S3-Datenereignisse oder S3-Zugriffsprotokolle“ bedeutet, dass sich Datendiebstahl aus Buckets nicht bewerten lässt – nicht, dass er nicht stattgefunden hat. Eine Bewertung ohne Anzeichen einer Kompromittierung mit drei Abdeckungswarnungen ist eine schwache Aussage; halten Sie das in Ihren Notizen fest. Der Beitrag zu den Grenzen geht weiter ins Detail.

Schritt 4 – Jeden Befund anhand seiner Belege bestätigen

Jeder Befund zeigt seinen Schweregrad, die MITRE-ATT&CK-Techniken, die extrahierten Parameter (Schlüssel, Principal, IP, Bucket, Region…), den Zeitraum und die Belegereignisse. Öffnen Sie mindestens beim ersten und beim letzten Belegereignis den Originaleintrag.

Fragen, die Sie bei jedem Befund stellen sollten:

1. Wer? userIdentity.arn und userIdentity.accessKeyId. Ist das ein Mensch, eine CI-Rolle, ein AWS-Dienst?
2. Von wo? sourceIPAddress und userAgent. Unternehmens-Internetausgang, ein CI-Runner, ein VPS?
3. War es erfolgreich? Ein fehlender errorCode bedeutet Erfolg; AccessDenied bedeutet, dass der Versuch gescheitert ist.
4. Gibt es ein Change-Ticket? Administrationsarbeit sieht aus wie die Arbeit eines Angreifers. Fragen Sie die Person, die im Ereignis genannt ist.

Erkennungen weisen auf etwas hin; sie beweisen nichts. Ein Befund „GPU-Instanzen gestartet“ im Konto eines ML-Teams ist ein ganz normaler Dienstag. Derselbe Befund von einem Schlüssel, der gestern noch auf einem Laptop in Lyon war und heute auf einem VPS, ist ein Vorfall.

Schritt 5 – Zur Eingrenzung auf Entitäten pivotieren

Der Tab Entitäten listet jeden Principal, jeden Access Key, jede IP-Adresse, Region, Ressource und jeden User-Agent in den Logs auf – mit Anzahl der Ereignisse, Fehlern, erstem und letztem Auftreten und dem, womit die jeweilige Entität zusammen gesehen wurde. Entitäten, die in Befunden vorkommen, sind markiert.

Die Schleife zur Eingrenzung:

1. Auf den geleakten Schlüssel pivotieren → jede IP notieren, von der er verwendet wurde.
2. Auf jede IP des Angreifers pivotieren → jeden anderen Schlüssel oder Principal notieren, der von dort verwendet wurde.
3. Auf jeden neuen Principal pivotieren (ein vom Angreifer angelegter Benutzer, eine von ihm übernommene Rolle) → notieren, was er getan hat.
4. Wiederholen, bis keine neue Entität mehr auftaucht.

So finden Sie den zweiten Access Key, den der Angreifer für seinen Backdoor-Benutzer erzeugt hat und den Ihnen die Aktivität des ersten Schlüssels allein nicht zeigen würde. Die Untersuchung eines geleakten Access Keys wendet diese Schleife im Detail an.

Schritt 6 – Die Zeitleiste erstellen

Der Tab Zeitleiste ordnet die Belegereignisse aller Befunde chronologisch (bis zu sechs pro Befund). Der Tab Ereignisse enthält den vollständigen Datensatz mit Filtern – Quelle, „Nur in Befunden“, „Nur Fehler“, „Nur Schreibzugriffe“ – und einem Umschalter zwischen UTC und lokaler Zeit. Klicken Sie auf eine beliebige Zeile, um den Originaleintrag zu sehen.

Für die Fallakte:

• CSV-Export der gefilterten Ereignisse (Zellen, die als Tabellenformeln interpretiert werden könnten, werden neutralisiert);
• JSON-Bericht mit Bewertung, Befunden, Belegen und Statistiken.

Schreiben Sie die Darstellung des Ablaufs in UTC und bewahren Sie die Original-Exporte daneben auf.

Schritt 7 – Die Checkliste zur Bereinigung abarbeiten

Der Tab Bereinigung führt die Bereinigungsschritte aller Befunde zusammen, Eindämmung zuerst, mit den tatsächlichen Werten eingesetzt: der zu deaktivierende Schlüssel, der zu löschende Benutzer, die Region, in der GuardDuty wieder aktiviert werden muss. Haken Sie erledigte Punkte ab (der Status bleibt nur auf der Seite gespeichert).

Stellen Sie vor jedem Löschen sicher, dass Sie gesichert haben, was Sie als Beweismittel brauchen: Inline-Richtlinien von Backdoor-Benutzern, die User Data geänderter Instanzen, einen Snapshot der Instanzen des Angreifers. Folgen Sie für den restlichen Prozess dann dem Security Incident Response Guide von AWS.

Häufige Fallstricke

• Ereignisverlauf nur aus einer Region. Der Ereignisverlauf ist regionsbezogen; Angreifer mögen die Regionen, die Sie nie öffnen.
• Keine Baseline. Wer nur den Tag des Vorfalls lädt, macht die Erkennungen für neue IP-Adressen und neue Regionen blind.
• Der sourceIPAddress von AWS-Diensten vertrauen. Handelt ein Dienst in Ihrem Auftrag, enthält das Feld einen Dienstnamen wie ec2.amazonaws.com, keine IP.
• Beim ersten Schlüssel aufhören. Der erste Schlüssel zeigt, wie sie hereingekommen sind, nicht alles, was sie in der Hand haben.

Verwandte Beiträge

• CloudTrail-Ereignisse, die jeder Responder kennen sollte
• Durchgang durch einen fiktiven Vorfall: vom geleakten Schlüssel zum Krypto-Mining
• AWS Incident Response: ein kompromittiertes Konto untersuchen