Netzwerk-Forensik: Angriffe im Netzwerkverkehr rekonstruieren

After a security incident, the crucial question arises: What actually happened? Network forensics provides the answers—by analyzing network traffic, it is possible to reconstruct attack paths, exfiltrated data, command-and-control communications, and the entire timeline of an attack.

Capture Strategies

Where and how should network data be captured?

1. SPAN Port / Port Mirroring:
   → Network switch copies traffic from one or more ports
   → Analysis system connects to the SPAN port and receives mirrored traffic
   → No interference with the production network flow

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

   Advantage:  Simple, no hardware intervention
   Disadvantage: SPAN capacity may be exceeded during high traffic
             (Switch has buffer limits → packet drops possible)

2. Network TAP (Test Access Point):
   → Physical device inserted into the network cable
   → Passive, fault tolerance: TAP failure does NOT interrupt the network
   → Copies 100% of traffic (no packet loss)
   → Network forensics gold standard for critical links

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

3. NetFlow / IPFIX:
   → No full packet capture, only metadata (flows)
   → Flow = 5-tuple: Src-IP, Dst-IP, Src-Port, Dst-Port, Protocol
   → + Bytes, packets, start/end time
   → NO payload data (no content, only "who communicated with whom")

   Configure Cisco IOS NetFlow:
   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

   Advantage:  Very low storage requirements, scalable for 10G+
   Disadvantage: No payload → no malware detection, no file reconstruction

4. SSL/TLS Inspection (for encrypted traffic):
   → Man-in-the-middle via own proxy (e.g., Zscaler, Palo Alto)
   → Proxy decrypts, inspects, re-encrypts
   → Data protection considerations! Permitted only for corporate devices (clear communication required!)
   → Private traffic: must be excluded (banking, healthcare)

Analysis Tools

Wireshark - The standard for packet analysis:

Basic functions:
  # Capture on interface eth0:
  tshark -i eth0 -w capture.pcap

  # Filter only specific packets:
  tshark -i eth0 -f "host 10.0.1.100 and port 443" -w filtered.pcap

  # From the Wireshark GUI: Capture → Interfaces → Start

Display Filters (Wireshark GUI):
  ip.addr == 10.0.1.100          → All packets to/from this IP
  tcp.port == 4444               → Classic Metasploit port
  http.request.method == "POST"  → HTTP POST (credential theft)
  dns.qry.name contains "evil"   → DNS queries for "evil"*
  ssl.handshake.type == 1        → TLS Client Hello (new connections)
  frame.time >= "2026-03-03 10:00:00" → Time filter

Expert analysis:
  Analyze → Expert Information → Shows anomalies, retransmissions, errors
  Statistics → Protocol Hierarchy → Which protocols generate how much traffic?
  Statistics → Conversations → Top connection pairs (exfiltration!)
  Statistics → IO Graph → Traffic volume over time (data bursts!)

---

Zeek (formerly Bro) - Network protocol analysis:

→ Generates structured logs from network data
→ No UI, only log files (conn.log, dns.log, http.log, ssl.log, etc.)
→ Script-based for custom detection rules
→ Industry standard for SIEM integration

Relevant Zeek logs:
  conn.log:   every TCP/UDP connection (duration, bytes, state)
  dns.log:    all DNS queries (domain, response, TTL)
  http.log:   HTTP requests (URI, User-Agent, Referer, Status)
  ssl.log:    TLS handshakes (Certificate, Version, Cipher Suite)
  files.log:  transferred files (Hash, Type, Size)
  smtp.log:   email connections (From, To, Subject)
  weird.log:  Anomalies and protocol violations

Zeek analysis (shell):
  # All DNS queries to unknown domains:
  cat dns.log | zeek-cut query | sort | uniq -c | sort -rn | head -50

  # HTTP connections with unusual user-agent:
  cat http.log | zeek-cut host user_agent | grep -v "Mozilla\|curl\|Python"

  # Connections with high data transfer (exfiltration?):
  cat conn.log | zeek-cut id.orig_h id.resp_h resp_bytes | awk '$3 > 10000000' | sort -k3 -rn

---

Suricata - IDS/IPS with forensic capabilities:

→ Rule-based detection of attack patterns in traffic
→ Eve JSON log format for SIEM integration
→ Can also be operated as an IPS (inline mode)

Analyze alert log:
  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
  }'

Custom rules for incident response:
  # Detection of Metasploit Meterpreter (typical pen test, but also real!):
  alert tcp any any -> $HOME_NET any (
    msg:"Meterpreter Staging Detected";
    content:"|fc e8 82 00 00 00|";  # Meterpreter shellcode signature
    classtype:trojan-activity;
    sid:9001001; rev:1;
  )

  # Detection of 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;
  )

Typical attack signatures in traffic

What indicates an attack in network traffic:

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

   DNS beaconing:
   → Malware regularly queries (every 30–300 seconds) the same domain
   → Domain often algorithmically generated (DGA): x7k2m.evil.com
   Detection:
     → High frequency of DNS requests to the same domain
     → Long subdomains (>50 characters): a7f3k2m...evil.com (DNS tunneling!)
     → NXDOMAIN flood (Malware tries many domains until one responds)

   HTTP/HTTPS Beaconing:
   → Regular HTTP GET requests (every few minutes, same user-agent)
   → Timing is suspicious: exactly 5,000 ms ± little jitter = malware!
   Zeek detection:
     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 on the network:
   SMB scan: Port scan (Nmap pattern: SYN, no connection) on port 445
   Network scan indicators:
   → One source IP → many destination IPs in the same /24 subnet
   → Rapidly in succession (< 1 second per target)
   → Zeek conn.log: many connections, state "S0" (SYN, no SYN-ACK)

   Pass-the-Hash / SMB Login:
   → EventID 4624 + LogonType 3 + NTLM (not Kerberos)
   → On the network: SMB traffic from workstation to workstation on port 445

3. Data Exfiltration:
   HTTP POST Uploads:
   → Large HTTP POST to unknown external IP
   → No known cloud storage pattern

   DNS tunneling:
   → Very long DNS queries (Base64 data in subdomain)
   → Suspicious: TXT record queries with long payloads
   Detection:
     cat dns.log | zeek-cut query | awk 'length($1) > 50' | head -20

   Unusual Protocols:
   → ICMP tunnels: Ping packets with unusually large payloads
   → IRC over unusual ports (legacy C2)

4. Malware Communication:
   Self-signed certificates to external destinations:
   → TLS to external IP with self-signed certificate → Suspicious (C2)
   Zeek:
     cat ssl.log | zeek-cut id.orig_h id.resp_h cert.subject cert.issuer | \
       awk '$3 == $4'  # Subject == Issuer = Self-Signed

Preservation of Evidence According to ISO/IEC 27037

Network Forensics in a Legal Context:

ISO/IEC 27037: Guidelines for the Identification, Collection,
               Acquisition, and Preservation of Digital Evidence

Basic Principles:
  1. Relevance:    Collect only forensically relevant data
  2. Reliability: Process must be reproducible and documented
  3. Sufficiency: Sufficient evidence for proof

Chain of Custody:
  □ Who initiated the capture? (Name, role)
  □ When? (UTC timestamp!)
  □ Where? (Network point, device, configuration)
  □ Which tools? (Wireshark version X.Y, Zeek version X.Y)
  □ Hash of the capture file? (SHA-256 immediately after creation!)
  □ Disclosed to whom, when?

Back up PCAP file:
  sha256sum capture.pcap > capture.pcap.sha256
  # Save to a write-protected medium
  # If legally relevant: digital signature

What NOT to do:
  → Save PCAP to the affected system (contamination!)
  → "Clean up" or edit traffic (loss of integrity)
  → Analyze third-party systems without authorization (CRIMINAL OFFENSE!)

GDPR considerations in network forensics:
  → Network data often contains personal data
  → Use capture data only for defined purposes (incident response)
  → Define retention period (typically max. 3–6 months after incident)
  → Inform employee representatives when workplace traffic is analyzed

---

Forensic toolkit for network analysis:

Capture:
  Wireshark + tshark       → Standard, GUI + CLI
  tcpdump                  → CLI, resource-efficient
  NetworkMiner             → Windows-based, file reconstruction

Analysis:
  Zeek                     → Protocol analysis, log files
  Suricata                 → Rule-based detection
  Arkime (formerly Moloch)   → Full-packet-capture platform, web GUI
  Elastic Security + Packetbeat → SIEM integration

NetFlow analysis:
  ntopng                   → Real-time traffic analysis
  nfdump + nfcapd          → Command-line NetFlow analysis
  ElastiFlow               → Elasticsearch-based

Specialized tools:
  NetworkMiner             → Automatic file reconstruction from PCAP
  xplico                   → Network forensics framework (web GUI)
  CapLoader                → Visualization and filtering of large PCAPs