CloudTrail-, VPC-Flow- und S3-Logs für Forensik exportieren

Kurzfassung. Erst sammeln, dann analysieren. Die beste Quelle für CloudTrail ist der S3-Bucket des Trails (AWSLogs/<account-id>/CloudTrail/<region>/YYYY/MM/DD/*.json.gz): Kopieren Sie ihn mit aws s3 sync und lassen Sie die Dateien komprimiert und unverändert. Kein Trail vorhanden? Laden Sie den Ereignisverlauf pro Region herunter – 90 Tage, nur Management-Ereignisse. Sichern Sie danach VPC Flow Logs, S3-Server-Zugriffsprotokolle, GuardDuty-Befunde und den IAM-Credential-Report. Nehmen Sie auch einige ruhige Tage vor dem Vorfall mit: Baselines brauchen sie.

Angreifer mit Administratorrechten löschen Trails und Detektoren. Aufbewahrungseinstellungen lassen Objekte stillschweigend verfallen. Der Ereignisverlauf wird nach 90 Tagen überschrieben. Das Nützlichste, was Sie in der ersten Stunde eines AWS-Vorfalls tun können, ist, eine Kopie der Beweise an einen Ort zu bringen, den der Angreifer nicht erreicht – bevor irgendjemand mit dem „Aufräumen“ beginnt.

Bevor Sie anfangen: Umfang und ein sicheres Ziel

Zeitfenster. Von einigen Tagen vor dem ersten verdächtigen Ereignis bis heute. Erkennungen, die mit dem Normalverhalten vergleichen (die üblichen IP-Adressen eines Schlüssels, die Regionen, die Sie normalerweise nutzen), brauchen diese ruhige Phase.
Konten und Regionen. Organisations-Trails legen alle Konten in einem einzigen Bucket ab; Trails für ein einzelnes Konto können pro Region angelegt sein. Listen Sie sie mit aws cloudtrail describe-trails --include-shadow-trails auf.
Anmeldedaten für die Sammlung. Verwenden Sie einen Principal, den der Angreifer nicht angefasst hat, idealerweise eine dedizierte Rolle mit reinem Lesezugriff. Sammeln Sie nicht mit dem kompromittierten Schlüssel.
Ziel. Eine lokale verschlüsselte Festplatte oder ein separates Konto. Halten Sie für die Fallakte die SHA-256-Hashes aller heruntergeladenen Dateien fest.

1. CloudTrail aus dem S3-Bucket des Trails (beste Quelle)

Ein CloudTrail-Trail liefert gzip-komprimierte JSON-Dateien nach S3, laut AWS-Beschreibung der Funktionsweise von CloudTrail etwa alle fünf Minuten. Die Struktur der Objektschlüssel ist vorhersehbar:

s3://<bucket>/[<prefix>/]AWSLogs/[<org-id>/]<account-id>/CloudTrail/<region>/YYYY/MM/DD/<account>_CloudTrail_<region>_<timestamp>_<id>.json.gz

Kopieren Sie das benötigte Zeitfenster:

aws s3 sync s3://<bucket>/AWSLogs/<account-id>/CloudTrail/ ./cloudtrail \
  --exclude "*" --include "*/2026/09/1*"

Erfahrungen aus der Praxis:

Lassen Sie die .json.gz-Dateien, wie sie sind. Wer sie neu komprimiert oder zusammenführt, verliert die Dateinamen, die Region und Lieferzeitpunkt enthalten.
Digest-Dateien unter CloudTrail-Digest/ sind signierte Hash-Ketten, keine Ereignisse. Bewahren Sie sie für die Fallakte auf – mit ihnen lässt sich die Integritätsprüfung der Logdateien durchführen –, Analysetools überspringen sie jedoch.
Datenereignisse (S3 GetObject, Lambda Invoke…) landen in denselben Dateien, sofern der Trail dafür konfiguriert war. Standardmäßig werden sie nicht protokolliert (AWS-Dokumentation); prüfen Sie also die Event Selectors des Trails, um zu wissen, was Sie überhaupt erwarten können.
CloudTrail-Insights-Ereignisse liegen, sofern aktiviert, unter einem separaten Präfix CloudTrail-Insight/.

2. CloudTrail-Ereignisverlauf (kein Trail konfiguriert)

Jedes Konto hat einen Ereignisverlauf: die Management-Ereignisse der letzten 90 Tage, pro Region, ohne Datenereignisse. Das ist besser als nichts und unabhängig von Trails – ein Angreifer, der einen Trail löscht, entfernt ihn also nicht.

Konsole: CloudTrail → Event history, in jeder Region den voreingestellten Read-only-Filter entfernen, den Zeitraum wählen, dann Download events → JSON (bevorzugt) oder CSV. Ein einzelner Download umfasst bis zu 200.000 Ereignisse.
CLI, pro Region:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws cloudtrail lookup-events --region "$r" \
    --start-time 2026-09-01T00:00:00Z --output json > "events-$r.json"
done

lookup-events gibt jedes Ereignis als JSON-String im Feld CloudTrailEvent zurück; bewahren Sie die Ausgabe unverändert auf, Analysetools parsen sie.

3. CloudTrail Lake

Wenn Sie einen Event Data Store haben, fragen Sie ihn ab und speichern Sie die Ergebnisse in S3:

SELECT eventJson FROM <event-data-store-id>
WHERE eventTime > '2026-09-01 00:00:00'

Wenn Sie die vollständige Spalte eventJson auswählen, bleibt jedes Feld erhalten. Flache Spaltenauswahlen genügen für einen schnellen Überblick, verlieren aber verschachtelte Felder wie requestParameters.

4. VPC Flow Logs

VPC Flow Logs werden nach S3, in CloudWatch Logs oder an Firehose geliefert.

S3: AWSLogs/<account-id>/vpcflowlogs/<region>/YYYY/MM/DD/*.log.gz. Synchronisieren Sie das Präfix wie bei CloudTrail. Die Klartext-Auslieferung enthält eine Kopfzeile mit den Feldnamen; behalten Sie sie, denn benutzerdefinierte Formate ändern die Reihenfolge der Spalten. Parquet ist ebenfalls eine Auslieferungsoption, wird aber nicht von jedem Tool gelesen.
CloudWatch Logs: Legen Sie eine Exportaufgabe nach S3 an (aws logs create-export-task) oder blättern Sie für ein enges Zeitfenster mit aws logs filter-log-events durch die Einträge.

Flow Logs zeichnen Metadaten auf (Adressen, Ports, Bytes, Accept/Reject), keine Nutzdaten. Der Beitrag zur Analyse von VPC Flow Logs erklärt, was sich damit beweisen lässt.

5. S3-Server-Zugriffsprotokolle

Wenn die Server-Zugriffsprotokollierung für den relevanten Bucket aktiviert war, liegen die Logs im konfigurierten Ziel-Bucket und -Präfix:

aws s3 sync s3://<log-bucket>/<prefix>/ ./s3-access

Die Objekte haben keine Dateiendung und enthalten eine durch Leerzeichen getrennte Zeile pro Anfrage. Die Zustellung erfolgt nach dem Best-Effort-Prinzip: AWS garantiert laut Dokumentation weder Vollständigkeit noch Rechtzeitigkeit. Nutzen Sie sie zusammen mit CloudTrail-Datenereignissen, wenn beide vorhanden sind.

6. GuardDuty-Befunde

GuardDuty bewahrt Befunde 90 Tage lang auf; ein S3-Veröffentlichungsziel hält sie länger vor (Dokumentation zum Export). Exportieren Sie sie früh – einen Detektor zu löschen, ist ein gängiger Schritt von Angreifern.

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty list-findings --detector-id "$DET" --query 'FindingIds' --output text \
  | xargs -n 50 aws guardduty get-findings --detector-id "$DET" --finding-ids > findings.json

Wiederholen Sie das in jeder Region, in der GuardDuty aktiviert ist.

7. IAM-Credential-Report

Der Credential-Report listet jeden Benutzer mit Status von Passwort, MFA und Access Keys auf, einschließlich der Daten der letzten Nutzung. IAM erzeugt höchstens einen Report alle vier Stunden (Dokumentation).

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csv

Checkliste

Quelle	Wo	Kritische Aufbewahrung	Priorität
CloudTrail-Trail	S3-Bucket `AWSLogs/…/CloudTrail/`	Lifecycle-Regeln des Buckets	1
Ereignisverlauf	Konsole / `lookup-events`, pro Region	90 Tage	1, falls kein Trail
GuardDuty-Befunde	`get-findings` oder S3-Export	90 Tage in GuardDuty	2
Credential-Report	IAM	Momentaufnahme des aktuellen Stands	2
S3-Datenereignisse	Dieselben Trail-Dateien	Nur wenn konfiguriert	2
S3-Server-Zugriffsprotokolle	Ziel-Bucket	Lifecycle des Buckets	3
VPC Flow Logs	S3 / CloudWatch Logs	Aufbewahrung der Log-Gruppe	3

Nächster Schritt

Sobald alles gesammelt ist, legen Sie es auf einmal im Analysetool im Browser ab: Trail-Ordner, Ereignisverlauf als JSON oder CSV, Lake-CSV, Flow Logs, Zugriffsprotokolle, Befunde und der Credential-Report werden automatisch erkannt, und nichts verlässt Ihren Rechner. Der Leitfaden zur CloudTrail-Log-Analyse zeigt, wie Sie die Ergebnisse lesen, und der Überblick zur Incident Response ordnet die Sammlung in den übergeordneten Eindämmungsplan ein.