VPC Flow Logs analysieren: Exfiltration und Krypto-Mining

Kurzfassung. Flow Logs sind Netzwerk-Metadaten: wer mit wem gesprochen hat, auf welchem Port, mit wie vielen Bytes, akzeptiert oder abgelehnt – pro Netzwerkschnittstelle und über ein bis zehn Minuten aggregiert. In einer Untersuchung lohnen sich drei Fragen: Wie viele Bytes haben eine private Adresse in Richtung jedes öffentlichen Ziels verlassen (Exfiltration)? Welche Instanzen halten langlebige Verbindungen zu Pool-typischen Ports (Mining)? Welche externen Adressen haben SSH/RDP erfolgreich erreicht (Zugriff)? Flow Logs enthalten keine Nutzdaten, keine DNS-Anfragen an den Amazon-Resolver und keinen Verkehr zu den Instanz-Metadaten; S3-Downloads aus dem Internet durchqueren Ihre VPC ohnehin nie.

CloudTrail sagt Ihnen, was konfiguriert wurde. VPC Flow Logs sagen Ihnen, was die Ressourcen danach im Netzwerk getan haben. Wenn ein Angreifer auf einer Instanz landet – über einen gestohlenen Schlüssel, eine verwundbare Anwendung oder eine selbst gestartete Instanz –, sind die Flow Logs oft die einzige Aufzeichnung darüber, wohin die Daten gegangen sind.

Der Standarddatensatz

Das Standardformat ist Version 2 (AWS-Dokumentation):

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 111122223333 eni-0f9e8d7c6b5a40000 10.20.1.11 192.0.2.150 40000 3333 6 42 8123 1789379520 1789379579 ACCEPT OK

Benutzerdefinierte Formate können vpc-id, instance-id, tcp-flags, pkt-srcaddr / pkt-dstaddr (die ursprünglichen Adressen hinter NAT oder sekundären IPs), flow-direction und traffic-path ergänzen. Wenn Sie Dateien aus S3 erhalten, benennt die erste Zeile die Felder – behalten Sie sie, denn die Spaltenreihenfolge hängt von dem Format ab, das beim Anlegen des Flow Logs gewählt wurde.

Frage 1: Sind Daten abgeflossen?

Filtern Sie auf ACCEPT-Datensätze mit privater Quelle (RFC 1918) und öffentlichem Ziel und summieren Sie bytes pro Paar aus Quelle und Ziel über das gesamte Zeitfenster des Vorfalls. Exfiltration ist eine Frage des Volumens, und dieses Volumen verteilt sich auf viele Datensätze, weil jeder höchstens zehn Minuten abdeckt (bei Nitro-Instanzen eine Minute oder weniger).

Worauf Sie achten sollten:

• ein einzelnes öffentliches Ziel, das Gigabytes von einer Instanz empfängt, die normalerweise nur mit einer Datenbank und einem Load Balancer spricht;
• Übertragungen zu ungewöhnlichen Uhrzeiten oder solche, die wenige Minuten nach einer SSH-Sitzung des Angreifers beginnen;
• Ziele bei Hosting-Anbietern statt bei Ihren bekannten Partnern.

Prüfen Sie dann, was es sonst erklären könnte: Backups zu einem externen Dienst, Software-Updates, ein Origin-Pull eines CDN. Die Zuordnung ist MITRE ATT&CK T1048 Exfiltration Over Alternative Protocol – das Protokoll selbst ist für Flow Logs unsichtbar, sichtbar sind nur Volumen und Ports.

Frage 2: Läuft irgendwo ein Miner?

Mining-Verkehr ist das Gegenteil von Exfiltration: klein, gleichmäßig, endlos. Anzeichen:

• jede im Rahmen des Vorfalls gestartete Instanz hält eine ACCEPT-Verbindung zu denselben ein oder zwei öffentlichen Adressen;
• Zielports, die von Mining-Pools genutzt werden (3333, 4444, 5555, 7777, 14444 und ähnliche);
• Minute für Minute ähnliche Byte-Mengen, in beide Richtungen.

Es gibt Pools, die auf 443 lauschen – der Port allein ist also kein Beweis; die Regelmäßigkeit und der zeitliche Bezug zu den RunInstances-Ereignissen sind es. Siehe Incident Response bei Krypto-Mining.

Frage 3: Wer ist hineingekommen?

Eingehende ACCEPT-Einträge auf 22 oder 3389 von öffentlichen Adressen zu einer Instanz zeigen, welche externen Hosts einen Shell-Port erreicht haben. Eine Flut von REJECT-Einträgen deutet auf Scans hin; ein einzelnes ACCEPT von derselben Adresse, die später in CloudTrail als Quelle von API-Aufrufen auftaucht, verknüpft die beiden Quellen miteinander.

Schnittstellen den Instanzen zuordnen

Flow Logs nennen Netzwerkschnittstellen, keine Instanzen. So verknüpfen Sie einen Flow mit dem Geschehen in CloudTrail:

1. Nehmen Sie die interface-id aus den verdächtigen Datensätzen.
2. Schlagen Sie sie mit aws ec2 describe-network-interfaces --network-interface-ids eni-… nach; die Antwort liefert die angehängte Instanz und deren private Adressen – sofern die Instanz noch existiert.
3. Wurde sie beendet, suchen Sie in CloudTrail nach der RunInstances-Antwort, die diese Schnittstellen-ID oder private Adresse enthält; die Antwort führt für jede gestartete Instanz ein networkInterfaceSet auf.
4. Pivotieren Sie von der Instanz auf den Principal, der sie gestartet hat, und auf ihr Instanzprofil.

Nehmen Sie instance-id in benutzerdefinierte Flow-Log-Formate auf, wenn Sie neue anlegen: Das erspart Ihnen diesen Schritt beim nächsten Vorfall.

Was Flow Logs Ihnen nie zeigen

Laut der AWS-Liste der Einschränkungen von Flow Logs wird Folgendes nicht protokolliert:

• Verkehr zum Amazon-DNS-Server (also keine Sicht auf DNS-Exfiltration über den VPC-Resolver – nutzen Sie dafür die Abfrage-Logs des Route 53 Resolver);
• Verkehr zu 169.254.169.254 (Instanz-Metadaten – Diebstahl von Anmeldedaten über IMDS hinterlässt keinen Flow);
• Amazon Time Sync, DHCP, Windows-Lizenzaktivierung, ARP sowie Verkehr zur reservierten Adresse des Standard-VPC-Routers;
• gespiegelter Verkehr auf der Quellseite.

Außerdem gilt: Flow Logs wirken erst ab ihrer Erstellung, lassen sich nicht bearbeiten (ein neues Format erfordert ein neues Flow Log), können unter Last Datensätze überspringen (SKIPDATA) und sehen keine Downloads aus S3 oder anderen AWS-APIs, die aus dem Internet erfolgen – diese gelangen nie in Ihre VPC. Für S3 brauchen Sie Datenereignisse oder Server-Zugriffsprotokolle.

Fallen in den Daten

• Zwei Datensätze pro Verbindung. Einer pro Richtung und Schnittstelle; zählen Sie Bytes nicht doppelt, wenn Sie beide aufsummieren.
• NAT-Gateways. Hinter einem NAT-Gateway zeigen die Flows der Instanz die Schnittstelle des NAT; verwenden Sie pkt-srcaddr / pkt-dstaddr, sofern das Format sie enthält.
• Zeitfenster. start/end begrenzen das Aggregationsfenster, nicht die TCP-Sitzung.
• Standard-VPC in ungenutzten Regionen. Angreifer starten ihre Instanzen genau dort, weil dort niemand Flow Logs aktiviert hat. Fehlende Logs bedeuten nicht fehlenden Verkehr.

Im Analyzer

AWS Forensics liest Flow Logs im Standard- und im benutzerdefinierten Format (berücksichtigt die Kopfzeile und die pkt-*addr-Felder, überspringt NODATA/SKIPDATA) und markiert mehr als 1 GiB akzeptierten Verkehr von einer privaten Adresse zu einem einzelnen Internet-Host sowie akzeptierte ausgehende Verbindungen zu bekannten Mining-Pool-Ports, jeweils mit Schnittstellen und Zielen als Parametern. Belege aus den Flow Logs landen auf derselben Zeitleiste wie CloudTrail, sodass SSH-Verbindung, RunInstances-Aufruf und erste Pool-Verbindung direkt untereinanderstehen. Wie Sie die Logs sammeln, beschreibt die Anleitung zum Export der AWS-Logs.