Netzwerk-Forensik: Angriffe im Netzwerkverkehr rekonstruieren

Nach einem Sicherheitsvorfall stellt sich die entscheidende Frage: Was ist tatsächlich passiert? Netzwerk-Forensik liefert die Antworten - aus dem Netzwerkverkehr lassen sich Angriffspfade, exfiltrierte Daten, Command-and-Control-Kommunikation und der gesamte Timeline eines Angriffs rekonstruieren.

Capture-Strategien

Wo und wie Netzwerkdaten erfassen?

1. SPAN Port / Port Mirroring:
   → Netzwerk-Switch kopiert Traffic eines oder mehrerer Ports
   → Analysesystem hängt am SPAN-Port und empfängt gespiegelten Traffic
   → Kein Eingriff in den produktiven Netzwerkfluss

   Cisco IOS Konfiguration:
   monitor session 1 source interface GigabitEthernet0/1
   monitor session 1 destination interface GigabitEthernet0/48

   Vorteil:  Einfach, kein Hardware-Eingriff
   Nachteil: Bei hohem Traffic kann SPAN-Kapazität überschritten werden
             (Switch hat Puffer-Limits → Paket-Drops möglich)

2. Network TAP (Test Access Point):
   → Physisches Gerät in Netzwerkleitung eingehängt
   → Passiv, Fehlertoleranz: TAP-Ausfall unterbricht Netzwerk NICHT
   → Kopiert 100% des Traffics (kein Paket-Drop)
   → Netzwerk-Forensik-Gold-Standard für kritische Strecken

   Produkte:
   Garland Technology: P1GCCAS (1G, copper, 4-port aggregation TAP)
   IXIA (Keysight):    TapFlow (10G, 40G, 100G)
   Datacom Systems:    SB-LW-1G (passiver optischer TAP)

3. NetFlow / IPFIX:
   → Kein vollständiger Paket-Capture, nur Metadaten (Flows)
   → Flow = 5-Tupel: Src-IP, Dst-IP, Src-Port, Dst-Port, Protokoll
   → + Bytes, Pakete, Start/End-Zeit
   → KEINE Payload-Daten (kein Inhalt, nur "wer hat mit wem kommuniziert")

   Cisco IOS NetFlow konfigurieren:
   ip flow-export destination 192.168.100.10 2055
   ip flow-export version 9
   interface GigabitEthernet0/0
    ip flow ingress
    ip flow egress

   NetFlow Collector: nfdump, ntopng, ElastiFlow (Elasticsearch), Kentik

   Vorteil:  Sehr geringer Speicherbedarf, skalierbar für 10G+
   Nachteil: Kein Payload → keine Malware-Erkennung, keine Datei-Rekonstruktion

4. SSL/TLS Inspection (für verschlüsselten Traffic):
   → Man-in-the-Middle durch eigenen Proxy (z.B. Zscaler, Palo Alto)
   → Proxy entschlüsselt, inspiziert, re-verschlüsselt
   → Datenschutz-Aspekte! Nur für Unternehmensgeräte zulässig (Aufklärung!)
   → Privater Datenverkehr: muss ausgenommen werden (Banking, Gesundheit)

Analyse-Tools

Wireshark - Der Standard für Paket-Analyse:

Grundfunktionen:
  # Capture auf Interface eth0:
  tshark -i eth0 -w capture.pcap

  # Nur bestimmte Pakete filtern:
  tshark -i eth0 -f "host 10.0.1.100 and port 443" -w filtered.pcap

  # Aus Wireshark-GUI: Capture → Interfaces → Start

Display Filter (Wireshark GUI):
  ip.addr == 10.0.1.100          → Alle Pakete von/zu dieser IP
  tcp.port == 4444               → Klassischer Metasploit-Port
  http.request.method == "POST"  → HTTP POST (Credential-Theft)
  dns.qry.name contains "evil"   → DNS-Anfragen für "evil"*
  ssl.handshake.type == 1        → TLS Client Hello (neue Verbindungen)
  frame.time >= "2026-03-03 10:00:00" → Zeitfilter

Expert-Analyse:
  Analyze → Expert Information → Zeigt Anomalien, Retransmissions, Errors
  Statistics → Protocol Hierarchy → Welche Protokolle wie viel Traffic?
  Statistics → Conversations → Top-Verbindungspaare (Exfiltration!)
  Statistics → IO Graph → Traffic-Volumen über Zeit (Data Burst!)

---

Zeek (ehemals Bro) - Netzwerk-Protokoll-Analyse:

→ Generiert strukturierte Logs aus Netzwerkdaten
→ Keine UI, sondern Logfiles (conn.log, dns.log, http.log, ssl.log, etc.)
→ Skriptbasiert für eigene Erkennungsregeln
→ Industriestandard für SIEM-Integration

Relevante Zeek-Logs:
  conn.log:   jede TCP/UDP-Verbindung (Dauer, Bytes, State)
  dns.log:    alle DNS-Anfragen (Domain, Response, TTL)
  http.log:   HTTP-Requests (URI, User-Agent, Referer, Status)
  ssl.log:    TLS-Handshakes (Certificate, Version, Cipher Suite)
  files.log:  übertragene Dateien (Hash, Typ, Größe)
  smtp.log:   E-Mail-Verbindungen (From, To, Betreff)
  weird.log:  Anomalien und Protokollverletzungen

Zeek Auswertung (shell):
  # Alle DNS-Anfragen an unbekannte Domains:
  cat dns.log | zeek-cut query | sort | uniq -c | sort -rn | head -50

  # HTTP-Verbindungen mit ungewöhnlichem User-Agent:
  cat http.log | zeek-cut host user_agent | grep -v "Mozilla\|curl\|Python"

  # Verbindungen mit hohem Datentransfer (Exfiltration?):
  cat conn.log | zeek-cut id.orig_h id.resp_h resp_bytes | awk '$3 > 10000000' | sort -k3 -rn

---

Suricata - IDS/IPS mit Forensik-Funktionen:

→ Regelbasierte Erkennung von Angriffsmustern im Traffic
→ Eve JSON Log-Format für SIEM-Integration
→ Kann auch als IPS (Inline Mode) betrieben werden

Alert Log auswerten:
  cat /var/log/suricata/eve.json | jq 'select(.event_type == "alert") | {
    timestamp: .timestamp,
    src: .src_ip,
    dst: .dest_ip,
    signature: .alert.signature,
    severity: .alert.severity
  }'

Eigene Regeln für Incident Response:
  # Erkennung von Metasploit Meterpreter (typischer Pen-Test, aber auch real!):
  alert tcp any any -> $HOME_NET any (
    msg:"Meterpreter Staging Detected";
    content:"|fc e8 82 00 00 00|";  # Meterpreter Shellcode Signatur
    classtype:trojan-activity;
    sid:9001001; rev:1;
  )

  # Erkennung von Cobalt Strike Beacon:
  alert http $HOME_NET any -> any any (
    msg:"Cobalt Strike Beacon Checkin";
    content:"GET";
    http_method;
    content:".beacon";
    http_uri;
    classtype:command-and-control;
    sid:9001002; rev:1;
  )

Typische Angriffssignaturen im Traffic

Was im Netzwerktraffic auf Angriff hinweist:

1. Command-and-Control (C2) Kommunikation:

   DNS-Beaconing:
   → Malware fragt regelmäßig (alle 30-300 Sekunden) dieselbe Domain
   → Domain oft algorithmisch generiert (DGA): x7k2m.evil.com
   Erkennung:
     → Hohe Frequenz DNS-Anfragen an gleiche Domain
     → Lange Subdomains (>50 Zeichen): a7f3k2m...evil.com (DNS Tunneling!)
     → NXDOMAIN-Flut (Malware versucht viele Domains bis eine antwortet)

   HTTP/HTTPS Beaconing:
   → Regelmäßige HTTP GET-Anfragen (alle paar Minuten, gleicher User-Agent)
   → Timing ist auffällig: genau 5.000ms ± wenig Jitter = Malware!
   Zeek Erkennung:
     cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p duration | \
       awk '$3 == 80 && $4 < 1.0' | sort | uniq -c

2. Lateral Movement im Netz:
   SMB-Scan: Portscan (Nmap-Pattern: SYN, keine Verbindung) auf Port 445
   Netscan Zeichen:
   → Eine Source-IP → viele Destination-IPs im selben /24-Subnetz
   → Kurz aufeinander (< 1 Sekunde pro Ziel)
   → Zeek conn.log: viele Verbindungen, state "S0" (SYN, kein SYN-ACK)

   Pass-the-Hash / SMB-Login:
   → EventID 4624 + LogonType 3 + NTLM (nicht Kerberos)
   → Im Netz: SMB-Traffic von Workstation zu Workstation auf Port 445

3. Daten-Exfiltration:
   HTTP POST-Uploads:
   → Großes HTTP POST zu unbekannter externer IP
   → Kein bekanntes Cloud-Storage-Muster

   DNS-Tunneling:
   → Sehr lange DNS-Abfragen (Base64 Daten in Subdomain)
   → Verdächtig: TXT-Record-Anfragen mit langen Payloads
   Erkennung:
     cat dns.log | zeek-cut query | awk 'length($1) > 50' | head -20

   Ungewöhnliche Protokolle:
   → ICMP-Tunnel: Ping-Pakete mit ungewöhnlich großer Payload
   → IRC über ungewöhnliche Ports (Legacy-C2)

4. Malware-Kommunikation:
   Selfsigned Zertifikate nach extern:
   → TLS zu externer IP mit Self-Signed-Cert → Verdächtig (C2)
   Zeek:
     cat ssl.log | zeek-cut id.orig_h id.resp_h cert.subject cert.issuer | \
       awk '$3 == $4'  # Subject == Issuer = Self-Signed

Beweissicherung nach ISO/IEC 27037

Netzwerk-Forensik im Rechtlichen Kontext:

ISO/IEC 27037: Richtlinien für Identifizierung, Sammlung,
               Akquisition und Erhalt digitaler Beweise

Grundprinzipien:
  1. Relevanz:    Nur forensisch relevante Daten erheben
  2. Zuverlässigkeit: Prozess muss reproduzierbar und dokumentiert sein
  3. Ausreichend: Genug Beweise für Beweisführung

Chain of Custody (Beweiskette):
  □ Wer hat Capture gestartet? (Name, Funktion)
  □ Wann? (UTC-Timestamp!)
  □ Wo? (Netzwerkpunkt, Gerät, Konfiguration)
  □ Welche Tools? (Wireshark Version X.Y, Zeek Version X.Y)
  □ Hash der Capture-Datei? (SHA-256 sofort nach Erstellung!)
  □ Weitergabe an wen, wann?

PCAP-Datei sichern:
  sha256sum capture.pcap > capture.pcap.sha256
  # Sichern auf Write-Protected Medium
  # Bei gerichtlicher Relevanz: digitale Signatur

Was NICHT tun:
  → PCAP auf betroffenen System speichern (Kontamination!)
  → Traffic "bereinigen" oder schneiden (Integritätsverlust)
  → Ohne Autorisierung fremde Systeme analysieren (STRAFBAR!)

DSGVO-Aspekte bei Netzwerk-Forensik:
  → Netzwerkdaten enthalten oft personenbezogene Daten
  → Capture-Daten nur für definierten Zweck (Incident Response) verwenden
  → Aufbewahrungsfrist definieren (i.d.R. max. 3-6 Monate nach Vorfall)
  → Mitarbeitervertretung informieren wenn Arbeitsplatz-Traffic analysiert wird

---

Forensik-Toolkit für Netzwerk-Analyse:

Capture:
  Wireshark + tshark       → Standard, GUI + CLI
  tcpdump                  → CLI, ressourcenschonend
  NetworkMiner             → Windows-basiert, Dateirekonstruktion

Analyse:
  Zeek                     → Protokoll-Analyse, Logfiles
  Suricata                 → Regelbasierte Erkennung
  Arkime (früher Moloch)   → Full-Packet-Capture-Plattform, Web-GUI
  Elastic Security + Packetbeat → SIEM-Integration

NetFlow-Analyse:
  ntopng                   → Echtzeit-Traffic-Analyse
  nfdump + nfcapd          → Commandline NetFlow-Analyse
  ElastiFlow               → Elasticsearch-basiert

Spezialtools:
  NetworkMiner             → Automatische Rekonstruktion von Dateien aus PCAP
  xplico                   → Netzwerkforensik-Framework (Web-GUI)
  CapLoader                → Visualisierung und Filterung großer PCAPs