Was macht Analyse von Netzwerkverkehr für Sicherheitsvorfälle?
Wann verwenden
- SIEM-Alarme über anomale Netzwerkverkehrsmuster, die eine tiefergehende Untersuchung erfordern
- C2-Beaconing wird vermutet und muss durch paketbasierte Analyse bestätigt werden
- Datenexfiltrationsvolumen oder -ziel müssen aus Netzwerkbeweisen quantifiziert werden
- Laterale Bewegung zwischen Systemen muss anhand von Netzwerkverbindungen zurückverfolgt werden
- IDS/IPS-Alarm erfordert eine Validierung auf Paketebene zur Bestätigung oder Widerlegung
Nicht verwenden für hostbasierte forensische Analysen (Prozessausführung, Dateisystemartefakte); stattdessen Endpunkt-Forensik-Werkzeuge nutzen.
Voraussetzungen
- Infrastruktur für vollständige Paketerfassung (PCAP) oder bedarfsgesteuerte Erfassungsfunktion (Netzwerk-Tap, SPAN-Port)
- Wireshark auf der Analyse-Workstation installiert mit Kenntnissen geeigneter Display-Filter
- Zeek (ehemals Bro) zur Generierung von Netzwerkmetadaten (conn.log, dns.log, http.log, ssl.log) bereitgestellt
- NetFlow/IPFIX-Erfassung von Netzwerkgeräten für die Analyse von Verkehrsflüssen
- Netzwerkarchitekturdiagramm mit VLAN-Layout, Firewall-Platzierung und Überwachungspunkten
- Threat-Intelligence-Feeds zur Korrelation beobachteter Netzwerkindikatoren
Arbeitsablauf
Schritt 1: Netzwerkverkehr erfassen oder beziehen
Besorgen Sie die relevanten Verkehrsdaten für die Untersuchung:
Live-Erfassung (falls der Vorfall aktiv ist):
# Erfassung auf bestimmter Schnittstelle gefiltert nach Host
tcpdump -i eth0 -w capture.pcap host 10.1.5.42
# Erfassung von C2-Verkehr zu bestimmter externer IP
tcpdump -i eth0 -w c2_traffic.pcap host 185.220.101.42
# Erfassung mit Rotation (1 GB-Dateien, 10 behalten)
tcpdump -i eth0 -w capture_%Y%m%d%H%M.pcap -C 1000 -W 10
Aus bestehender Infrastruktur:
- PCAP aus der vollständigen Paketerfassungsappliance exportieren (Arkime/Moloch, ExtraHop, Corelight)
- Zeek-Logs aus dem Zeek-Cluster für den Untersuchungszeitraum abrufen
- NetFlow-Daten von Netzwerkgeräten für die allgemeine Verkehrsanalyse exportieren
Schritt 2: C2-Kommunikation identifizieren
Erkennen Sie Muster der Kommando- und Kontrollkommunikation:
Beaconing-Erkennung (Zeek conn.log):
# Extraktion von Verbindungen zu externen IPs mit regelmäßigen Intervallen
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p duration orig_bytes resp_bytes \
| awk '$4 ~ /^185\.220/' | sort -t. -k1,1n -k2,2n
Wireshark-Beacon-Analyse:
# Filter für Verkehr zu vermuteter C2-IP
ip.addr == 185.220.101.42
# HTTPS-Verkehr zu nicht standardmäßigen Ports filtern
tcp.port != 443 && ssl
# DNS-Abfragen nach verdächtigen Domänen filtern
dns.qry.name contains "evil" or dns.qry.name matches "^[a-z0-9]{32}\."
# HTTP-POST (häufige C2-Check-in-Methode) filtern
http.request.method == "POST" && ip.dst == 185.220.101.42
Zu identifizierende Beaconing-Merkmale:
- Regelmäßige Zeitintervalle zwischen Verbindungen (z. B. alle 60 Sekunden mit 10-15% Jitter)
- Konsistente Paketgrößen bei Anfragen und Antworten
- HTTPS zu externen IPs, die nicht mit legitimen CDNs oder Diensten verbunden sind
- DNS-Abfragen mit hochgradig entropischen Subdomänen (Hinweis auf DNS-Tunneling)
Schritt 3: Analyse von Lateraler Bewegung
Verfolgen Sie die Bewegung des Angreifers zwischen internen Systemen:
Wichtige Protokolle zur Erkennung lateraler Bewegung:
═══════════════════════════════════════════════════════
SMB (TCP 445): PsExec, Dateifreigabezugriff, Ransomware-Ausbreitung
RDP (TCP 3389): Remotedesktopsitzungen
WinRM (TCP 5985): PowerShell-Remoting
WMI (TCP 135): Remote-Befehlsausführung
SSH (TCP 22): Laterale Bewegung bei Linux
DCE/RPC (TCP 135): DCOM-basierte laterale Bewegung
Wireshark-Filter für Laterale Bewegung:
# SMB laterale Bewegung
smb2 && ip.src == 10.1.5.42 && ip.dst != 10.1.5.42
# RDP-Verbindungen vom kompromittierten Host
tcp.dstport == 3389 && ip.src == 10.1.5.42
# Kerberos-Ticket-Anfragen (potenzielles Pass-the-Ticket)
kerberos.msg_type == 12 && ip.src == 10.1.5.42
# NTLM-Authentifizierung (potenzielles Pass-the-Hash)
ntlmssp.auth.username && ip.src == 10.1.5.42
Schritt 4: Erkennung von Datenexfiltration
Identifizieren Sie unbefugte Datenübertragungen, die das Netzwerk verlassen:
# Identifizieren großer ausgehender Übertragungen im Zeek conn.log
cat conn.log | zeek-cut ts id.orig_h id.resp_h id.resp_p orig_bytes \
| awk '$5 > 100000000' | sort -t$'\t' -k5 -rn
# DNS-Tunneling-Erkennung (hohes Volumen an TXT-Abfragen)
cat dns.log | zeek-cut query qtype | grep TXT | cut -f1 \
| rev | cut -d. -f1,2 | rev | sort | uniq -c | sort -rn | head
# Ungewöhnliche Protokollnutzung (ICMP-Tunneling, DNS über HTTPS)
cat conn.log | zeek-cut proto id.resp_p orig_bytes | awk '$1 == "icmp" && $3 > 1000'
Wireshark-Exfiltrationsfilter:
# Große HTTP-POST-Uploads
http.request.method == "POST" && tcp.len > 10000
# FTP-Datenübertragungen
ftp-data && ip.src == 10.0.0.0/8
# DNS mit großen TXT-Antworten (Tunneling)
dns.resp.type == 16 && dns.resp.len > 200
Schritt 5: IOCs extrahieren und korrelieren
Gewinnen Sie netzwerkbasierte Indikatoren aus der Verkehrsanalyse:
- Externe IP-Adressen, die von kompromittierten Hosts kontaktiert wurden
- Domänen, die während des Vorfallszeitraums per DNS aufgelöst wurden
- URLs, die per HTTP/HTTPS aufgerufen wurden (wenn SSL-Inspektion vorhanden)
- TLS-Zertifikatsdetails (Subject, Issuer, Seriennummer, JA3/JA3S-Hashes)
- User-Agent-Strings aus HTTP-Anfragen
- Dateiübertragungen, die in PCAP erfasst wurden (Extrahieren mittels Wireshark-Objekt-Export)
Schritt 6: Netzwerkforensische Ergebnisse dokumentieren
Fassen Sie die Analyse in einem strukturierten Bericht mit Beweisverweisen zusammen:
- Referenzieren Sie spezifische PCAP-Dateien, Rahmennummern und Zeitstempel für jeden Befund
- Fügen Sie Paketaufzeichnungen von Schlüsselbeweisen als Screenshots oder exportierte PDFs bei
- Ordnen Sie Netzwerkaktivitäten dem Vorfallszeitplan zu
- Korrelieren Sie Netzwerkbefunde mit hostbasierten Beweisen aus der Endpunktforensik
Schlüsselkonzepte
| Begriff | Definition |
|---|---|
| PCAP (Packet Capture) | Dateiformat, das rohe Netzwerkpakete speichert, die von einer Netzwerkschnittstelle erfasst wurden, für die Offline-Analyse |
| Beaconing | Regelmäßige, periodische Netzwerkverbindungen von einem kompromittierten Host zu einem C2-Server, erkennbar an konsistenten Zeitintervallen |
| JA3/JA3S | TLS-Client- und Server-Fingerprinting-Methode basierend auf den ClientHello- und ServerHello-Parametern; einzigartig pro Anwendung |
| NetFlow/IPFIX | Netzwerkverkehrsmetadaten (Quelle, Ziel, Ports, Bytes, Dauer), die von Routern und Switches ohne vollständige Paketerfassung gesammelt werden |
| DNS-Tunneling | Technik, die Daten in DNS-Abfragen und -Antworten kodiert, um Daten zu exfiltrieren oder C2 über das DNS-Protokoll aufrechtzuerhalten |
| Netzwerk-Tap | Hardwaregerät, das eine exakte Kopie des Netzwerkverkehrs zur Überwachung erstellt, ohne die Netzwerkleistung zu beeinträchtigen |
| Zeek-Logs | Strukturierte Metadaten-Logs, die vom Zeek-Netzwerkanalyse-Framework generiert werden und Verbindungen, DNS, HTTP, SSL und mehr abdecken |
Werkzeuge und Systeme
- Wireshark: Open-Source-Paketanalysator zur tiefgehenden Inspektion von Netzwerkprotokollen auf Paketebene
- Zeek (ehemals Bro): Netzwerkanalyse-Framework, das strukturierte Metadaten-Logs aus Live- oder aufgezeichnetem Verkehr generiert
- Arkime (ehemals Moloch): Open-Source-Plattform zur vollständigen Paketerfassung und -suche für groß angelegte Netzwerkforensik
- NetworkMiner: Netzwerkforensisches Analysetool zum Extrahieren von Dateien, Bildern und Anmeldeinformationen aus PCAP-Dateien
- RITA (Real Intelligence Threat Analytics): Open-Source-Tool zur Beacon-Erkennung und DNS-Tunneling-Analyse für Zeek-Logs
Häufige Szenarien
Szenario: Bestätigung von C2-Beaconing und Quantifizierung der Exfiltration
Kontext: EDR erkennt einen verdächtigen Prozess auf einer Workstation, kann aber das Volumen der exfiltrierten Daten nicht bestimmen. Das Netzwerkteam stellt PCAP aus der vollständigen Paketerfassungsappliance für den Vorfallszeitraum bereit.
Vorgehen:
- Filtern Sie PCAP auf Verkehr vom kompromittierten Host zu externen Zielen
- Identifizieren Sie den C2-Kanal durch Analyse der Verbindungszeitmuster (Beacon-Erkennung)
- Extrahieren Sie TLS-Zertifikat und JA3-Hash aus der C2-Verbindung zur IOC-Generierung
- Berechnen Sie die Gesamtzahl der Bytes, die während der Vorfallsdauer an die C2-Infrastruktur übertragen wurden
- Prüfen Sie auf weitere Exfiltrationskanäle (DNS-Tunneling, Cloud-Speicher-Uploads)
- Extrahieren Sie alle unverschlüsselten Dateien, die mit der Wireshark-Objekt-Export-Funktion übertragen wurden
Stolperfallen:
- Analyse nur von HTTP-Verkehr, wenn C2 über HTTPS ohne SSL-Inspektion läuft
- DNS-Tunneling wird übersehen, weil das Datenvolumen pro Abfrage gering ist (aber insgesamt über die Zeit signifikant)
- Keine Korrelation von Netzwerk-Zeitstempeln mit Endpunkt-Zeitstempeln (Zeitzonenkonflikte)
- Übersehen legitimer Cloud-Dienste, die für die Exfiltration missbraucht werden (OneDrive, Google Drive, Dropbox)
Ausgabeformat
NETZWERKVERKEHRSANALYSE-BERICHT
=================================
Vorfall: INC-2025-1547
Analyst: [Name]
Erfassungsquelle: Arkime vollständige Paketerfassung
Analysezeitraum: 2025-11-15 14:00 UTC - 2025-11-15 18:00 UTC
Gesamte PCAP-Größe: 4,7 GB
C2-KOMMUNIKATION
Quelle: 10.1.5.42 (WKSTN-042)
Ziel: 185.220.101.42:443 (HTTPS)
Beacon-Intervall: 60 Sekunden ± 12 % Jitter
Sitzungen: 237 Verbindungen über 4 Stunden
JA3-Hash: a0e9f5d64349fb13191bc781f81f42e1
TLS-Zertifikat: CN=update.evil[.]com (selbstsigniert)
Gesendete Daten: 147 MB (ausgehend)
Empfangene Daten: 2,3 MB (eingehend - Befehle)
LATERALE BEWEGUNG
10.1.5.42 → 10.1.10.15 (SMB, TCP 445) - 14:35 UTC
10.1.5.42 → 10.1.10.20 (RDP, TCP 3389) - 14:42 UTC
10.1.5.42 → 10.1.1.5 (LDAP, TCP 389) - 15:10 UTC
EXFILTRATIONSZUSAMMENFASSUNG
Protokoll: HTTPS zum C2-Server
Volumen: 147 MB ausgehend
Dauer: 14:23 UTC - 18:00 UTC
Extrahierte Dateien: [Liste, falls aus unverschlüsselten Kanälen wiederherstellbar]
DNS-ANALYSE
Verdächtige Abfragen: 0 DNS-Tunneling-Indikatoren
DGA-Erkennung: 0 algorithmisch generierte Domänen
BEWEISREFERENZEN
PCAP-Datei: INC-2025-1547_capture.pcap (SHA-256: ...)
Zeek-Logs: /logs/zeek/2025-11-15/ (conn.log, ssl.log, dns.log)