S3-Datenexfiltration erkennen: was die Logs beweisen können

Kurzfassung. Die Frage „Haben sie die Daten mitgenommen?“ lässt sich für S3-Objekte nur beantworten, wenn CloudTrail-S3-Datenereignisse oder S3-Server-Zugriffsprotokolle vor dem Vorfall aktiviert waren. Mit ihnen gilt: GetObject pro Principal, Bucket und Stunde zählen, bytesTransferredOut bzw. Bytes Sent aufsummieren und die Objektschlüssel auflisten. Ohne sie können Sie zeigen, dass der Angreifer lesen konnte (Berechtigungen, ListBuckets; auch ListObjects ist ein Datenereignis) und ob ein Bucket öffentlich gemacht oder ein Snapshot geteilt wurde (Management-Ereignisse) – aber nicht, welche Objekte abgeflossen sind. Prüfen Sie außerdem die Kanäle, die ganz ohne Download auskommen: öffentliche Richtlinien, ACLs, geteilte EBS-/RDS-Snapshots und AMIs.

Datendiebstahl ist die Frage, die Juristen, Kunden und Aufsichtsbehörden als Erstes stellen – und genau dort kommt es am stärksten auf die Log-Abdeckung an. Dieser Beitrag zeigt, was jede AWS-Log-Quelle über Exfiltration aus S3 und über Snapshots beweisen kann und wie Sie ehrlich berichten, wenn sie es nicht kann.

Zwei Quellen für Objektlesezugriffe

Ideal ist beides: CloudTrail liefert eine verlässliche Identität, die Zugriffsprotokolle eine unabhängige zweite Aufzeichnung. Eine der beiden Quellen reicht aber aus, um die Frage zu beantworten.

CloudTrail-Datenereignisse auswerten

Ein Datenereignis für einen Objektlesezugriff sieht so aus (gekürzt):

{
  "eventSource": "s3.amazonaws.com",
  "eventName": "GetObject",
  "eventCategory": "Data",
  "userIdentity": {"arn": "arn:aws:iam::111122223333:user/backup-admin", "accessKeyId": "AKIA..."},
  "sourceIPAddress": "203.0.113.77",
  "requestParameters": {"bucketName": "acme-customer-exports", "key": "exports/customers-0001.csv.gz"},
  "additionalEventData": {"bytesTransferredOut": 12345678}
}

Die Fragen und wie Sie sie beantworten:

• Wie viele Objekte? Zählen Sie die unterschiedlichen Werte von requestParameters.key pro Principal und Bucket.
• Wie viele Daten? Summieren Sie bytesTransferredOut. Teilweise Lesezugriffe (Range Requests) zählen mit ihren tatsächlich übertragenen Bytes.
• Welche Objekte? Die Liste der Schlüssel ist Ihr Inventar für die Meldung. Exportieren Sie sie.
• Von wo? sourceIPAddress und userAgent: Ein boto3-Client auf einem VPS, der 300 Objekte in 20 Minuten abruft, ist nicht Ihr Backup-Job.
• Was geschah vor den Lesezugriffen? ListObjects / ListObjectsV2 (ebenfalls Datenereignisse) sowie die Management-Ereignisse ListBuckets, GetBucketPolicy, GetBucketAcl und GetBucketLocation desselben Principals.

Die Zuordnung ist MITRE ATT&CK T1530 Data from Cloud Storage.

S3-Server-Zugriffsprotokolle auswerten

Server-Zugriffsprotokolle enthalten eine Zeile pro Anfrage; relevant sind hier Bucket, Zeit, Remote-IP, Anfragender, Operation, Schlüssel, HTTP-Status und gesendete Bytes (Log-Format).

79a59df9... acme-customer-exports [14/Sep/2026:09:15:04 +0000] 203.0.113.77
arn:aws:iam::111122223333:user/backup-admin 3E57427F3EXAMPLE REST.GET.OBJECT
exports/2026/customers/customers-0001.csv.gz "GET /exports/... HTTP/1.1" 200 - 12345678 ...

(Zur besseren Lesbarkeit umbrochen; jeder Eintrag steht in einer einzigen Zeile.)

Filtern Sie auf REST.GET.OBJECT mit Status 200 oder 206 und gruppieren Sie nach Anfragendem und Bucket. Ein Anfragender - bedeutet eine anonyme Anfrage – erwartbar bei einem öffentlichen Website-Bucket, bei allem anderen ein Datenleck.

Exfiltration ohne Downloads

Einige der wirksamsten Formen von Datendiebstahl in AWS erzeugen in Ihrem Konto nie ein GetObject, weil der Angreifer die Daten erreichbar macht und sie von anderswo kopiert. Das alles sind Management-Ereignisse und damit auch ohne Datenereignisse sichtbar:

Ein geteilter Snapshot bedeutet, dass die Daten ohne weitere Spur in Ihrem Konto in das Konto des Angreifers kopiert werden können. Behandeln Sie seinen Inhalt als offengelegt.

Wenn Sie keine der beiden Quellen haben

Formulieren Sie im Bericht präzise. Belegen können Sie:

• welche Principals berechtigt waren, welche Buckets zu lesen (IAM-Richtlinien, Bucket-Richtlinien);
• ob der Angreifer Buckets aufgelistet oder Bucket-Richtlinien gelesen hat (Management-Ereignisse);
• ob ein Bucket öffentlich gemacht oder ein Snapshot geteilt wurde;
• ob Netzwerkflüsse Ihrer Instanzen große ausgehende Übertragungen zeigen (Analyse von VPC Flow Logs) – hilfreich bei Daten, die auf EC2 zwischengelagert wurden, nicht aber bei direkten S3-Downloads, die Ihre VPC gar nicht durchlaufen.

Sie können nicht behaupten, dass Objekte nicht gelesen wurden. „Keine Hinweise auf Zugriffe“ ist nur dann aussagekräftig, wenn es solche Hinweise überhaupt hätte geben können. Wie Sie das formulieren, beschreibt der Beitrag über die Grenzen der Log-Forensik.

Die Meldefrist läuft

Sind möglicherweise personenbezogene Daten betroffen, beginnen gesetzliche Fristen mit dem Bekanntwerden zu laufen, nicht erst mit dem Abschluss der Untersuchung – nach der DSGVO sind es 72 Stunden für die Meldung an die Aufsichtsbehörde (Artikel 33). Binden Sie Ihren Datenschutzbeauftragten früh ein und übergeben Sie ihm die Objektliste, sobald sie vorliegt.

Im Analyzer

AWS Forensics markiert Massen-Downloads aus beiden Quellen (100 oder mehr Objekte aus einem Bucket durch einen Principal innerhalb einer Stunde), anonyme Downloads von öffentlichen Adressen, öffentliche Bucket-Richtlinien und ACLs, entferntes Block Public Access, mit anderen Konten geteilte Snapshots oder AMIs sowie massenhaftes Auslesen von Secrets. Die Hinweise unter „Abdeckung“ sagen ausdrücklich, wenn weder Datenereignisse noch Zugriffsprotokolle bereitgestellt wurden. Pivotieren Sie im Tab „Entitäten“ auf den Bucket, um jede Anfrage an ihn aus beiden Quellen zu sehen. Den Gesamtzusammenhang liefert der Überblick zur Incident Response bei einem kompromittierten Konto.