Grenzen von CloudTrail: was Log-Forensik nicht zeigen kann
Was CloudTrail, VPC Flow Logs und S3-Zugriffsprotokolle nicht aufzeichnen, wo Baselines versagen und wie Sie bei fehlenden Belegen ehrliche Schlüsse ziehen.
Kurzfassung. Logs zeichnen API-Aufrufe und Netzwerk-Metadaten auf – keine Absichten, keine Nutzdaten und nicht, was innerhalb einer Instanz passiert ist. CloudTrail protokolliert Lesezugriffe auf S3-Objekte nur, wenn Datenereignisse konfiguriert waren; der Ereignisverlauf hält nur 90 Tage Management-Ereignisse vor; Flow Logs lassen DNS-Verkehr zum Amazon-Resolver und Verkehr zu den Instanz-Metadaten aus; S3-Zugriffsprotokolle werden nach dem Best-Effort-Prinzip geliefert. Erkennungen auf Basis von Baselines sind blind, wenn vor dem Vorfall keine ruhigen Tage vorliegen. Formulieren Sie Schlussfolgerungen passend zur Abdeckung: „keine Hinweise auf X in den verfügbaren Quellen, die Y abdecken“ – niemals „X ist nicht passiert“, wenn X gar nicht hätte sichtbar sein können.
Eine auf Logs gestützte Bewertung – aus einem SIEM, aus Athena-Abfragen oder aus dem Analyzer dieser Website – ist eine Aussage über die Logs, nicht über das Konto. Dieser Beitrag listet die Lücken auf, die in nahezu jeder AWS-Untersuchung auftauchen, damit sie im Bericht landen und nicht sechs Monate später als Überraschung.
Was CloudTrail nicht sieht
| Lücke | Warum | Was Sie tun können |
|---|---|---|
| Lese- und Schreibzugriffe auf S3-Objektebene | Datenereignisse sind standardmäßig aus und werden gesondert abgerechnet | Selektoren des Trails prüfen; S3-Server-Zugriffsprotokolle nutzen, falls aktiviert |
| Lambda-Aufrufe, Lesezugriffe auf DynamoDB-Items | Ebenfalls Datenereignisse | Dasselbe |
| Alles, was ohne Trail älter als 90 Tage ist | Grenze des Ereignisverlaufs | Künftig einen Trail oder CloudTrail Lake verwenden |
| Was innerhalb einer Instanz oder eines Containers lief | CloudTrail protokolliert nur die Steuerungsebene | Host-Forensik, EDR, Betriebssystem-Logs; bei EKS das Kubernetes-Audit-Log (kubernetesforensics.com) |
Die vollständigen User Data von RunInstances | Werden als <sensitiveDataRemoved> gespeichert | Von der Instanz abrufen |
| Ereignisse nicht abgedeckter Dienste oder Aktionen | Die Abdeckung variiert je nach Dienst | Von CloudTrail unterstützte Dienste |
| Reihenfolge innerhalb einer Datei | Ereignisse werden nicht geordnet ausgeliefert (CloudTrail-Konzepte) | Immer nach eventTime sortieren |
Auch die Auslieferung erfolgt nicht sofort: CloudTrail liefert in der Regel innerhalb von etwa fünf Minuten, ohne Garantie (Funktionsweise von CloudTrail). Eine Sicherung, die Sekunden nach der letzten Aktion des Angreifers erfolgt, kann diese verpassen.
Was die Netzwerk-Logs nicht sehen
VPC Flow Logs zeichnen niemals Verkehr zum Amazon-DNS-Server, zum Instanz-Metadatendienst unter 169.254.169.254, zu Time Sync, DHCP oder ARP auf (Einschränkungen). Daraus folgt:
- DNS-Tunneling über den VPC-Resolver ist unsichtbar (dafür sind die Abfrage-Logs des Route 53 Resolver die Quelle);
- der Diebstahl von Anmeldedaten einer Instanzrolle über IMDS hinterlässt keinen Flow – seine Spur, falls überhaupt vorhanden, ist die Verwendung dieser Anmeldedaten an anderer Stelle, die GuardDuty als
InstanceCredentialExfiltration-Befunde meldet; - Downloads aus S3 und anderen APIs, die aus dem Internet erfolgen, durchqueren Ihre VPC nie.
S3-Server-Zugriffsprotokolle werden nach dem Best-Effort-Prinzip ausgeliefert; laut AWS kann ein Eintrag verspätet oder gar nicht ankommen (Dokumentation). Für Volumen und Muster gut geeignet, als Beweis dafür, dass eine bestimmte Anfrage nicht stattgefunden hat, dagegen schwächer.
Blinde Flecken bei Identitäten
- Föderierte und SSO-Benutzer erscheinen als Sitzungen übernommener Rollen; wer der Mensch dahinter war, steht in den Logs des Identitätsanbieters (für Okta siehe oktaforensics.com, für Microsoft Entra ID m365forensics.com).
- Role Chaining verteilt einen Akteur auf mehrere Sitzungen; folgen Sie den
AssumeRole-Antworten undsessionContext.sessionIssuer. - AWS-Dienste, die in Ihrem Auftrag handeln, zeigen einen Dienstnamen in
sourceIPAddress; ein Angreifer, der über einen Dienst (CloudFormation, Lambda) indirekt agiert, sieht aus wie dieser Dienst. - Gemeinsam genutzter ausgehender Verkehr. Ein NAT im Büro oder der IP-Bereich eines CI-Anbieters macht Erkennungen vom Typ „neue IP“ verrauscht; ein VPN-Endpunkt, den auch der Angreifer nutzt, macht sie blind.
- Keine Geolokalisierung in den Logs. CloudTrail speichert IP-Adressen, keine Länder oder ASNs. Auch der Analyzer reichert IPs nicht an, „Anmeldung aus einem neuen Land“ wird also nicht erkannt; GuardDuty-Befunde liefern diesen Kontext, sofern verfügbar.
Wo Erkennungen versagen
Regelbasierte Erkennung, auch die des Analyzers, versagt auf vorhersehbare Weise:
- Baselines brauchen Historie. „Key von neuer IP verwendet“ und „neue Region“ vergleichen mit dem ersten Aktivitätstag in den geladenen Logs. Laden Sie nur den Tag des Vorfalls, sehen sie nichts – oder alles.
- Schwellenwerte lassen sich unterschreiten. 29 verschiedene List-Aufrufe in zehn Minuten lösen keine Regel „30 in 10 Minuten“ aus; 99 Downloads pro Stunde lösen keine Regel „100 pro Stunde“ aus. Ein geduldiger Angreifer ist schwerer zu fassen als ein skriptgesteuerter.
- Legitime Administration sieht aus wie ein Angriff. Benutzer anlegen, Richtlinien anhängen, GPU-Instanzen starten – das sind normale Aufgaben. Erkennungen geben Hinweise; Menschen bestätigen.
- Unbekannte Techniken. Regeln decken bekannte Angriffswege ab. Die Regeldatei des Analyzers listet auf, was abgedeckt ist; alles andere erfordert eine manuelle Prüfung der Rohereignisse.
Ehrliche Schlussfolgerungen formulieren
Knüpfen Sie jede Schlussfolgerung an die Abdeckung. Eine bewährte Vorlage:
Zwischen [Beginn] und [Ende] wurden die CloudTrail-Management-Ereignisse der Konten […] in allen Regionen, die S3-Datenereignisse der Buckets […] und die VPC Flow Logs der VPCs […] ausgewertet. Für die Buckets […] waren S3-Datenereignisse nicht aktiviert; für diese Buckets lässt sich der Zugriff auf Objekte nicht feststellen. In den ausgewerteten Quellen wurden keine Hinweise auf [Aktivität] gefunden.
Dokumentieren Sie außerdem: Zeitzone (UTC), Hashes der Exporte, verwendete Tools und Versionen sowie jede Lücke – gestoppte Trails, fehlende Regionen, gelöschte Log-Gruppen. Wie Sie eine vom Angreifer verursachte Lücke eingrenzen, beschreibt der Beitrag zur Umgehung von Abwehrmaßnahmen.
Die Lücken für das nächste Mal schließen
- Ein Multi-Region-Trail (oder Organisations-Trail) mit Validierung der Log-Dateien, gespeichert in einem separaten, abgeschotteten Konto.
- S3-Datenereignisse für Buckets mit sensiblen Daten, zumindest für Lesezugriffe.
- VPC Flow Logs auf jeder VPC, auch auf den Standard-VPCs in Regionen, die Sie nicht nutzen – oder eine Service Control Policy, die diese Regionen sperrt.
- GuardDuty in jeder aktivierten Region, mit Export der Befunde nach S3.
- Eine Aufbewahrungsdauer, die länger ist als die Zeit bis zur Erkennung.
Der Security Incident Response Guide von AWS behandelt die Vorbereitung ausführlich. Für die Untersuchung selbst beginnen Sie mit dem Überblick zur Incident Response bei einem kompromittierten Konto.