Monday, November 2, 2026
No menu items!
Google search engine
HomeIncident ResponseNetwork Forensics: The Packets Never Lie (But They Do Obfuscate)

Network Forensics: The Packets Never Lie (But They Do Obfuscate)

Category: Incident Response

Tags: network-forensics, pcap, wireshark, zeek, netflow


Host-based forensics tells you what happened on a machine. Network forensics tells you what happened between machines -- and in an enterprise incident involving lateral movement, data exfiltration, and command-and-control traffic, the network is often the only place where the full picture exists.

This article covers the practical workflow for network forensic analysis -- from packet capture and PCAP analysis through Zeek log mining, beaconing detection, and encrypted traffic fingerprinting. Because while attackers can wipe logs and timestomp files, they cannot un-send a packet.


Packet Capture

Before analysing network evidence, it needs to exist. Full packet capture (FPC) is the gold standard, but even metadata-only sources like NetFlow provide valuable forensic context.

Linux Capture with tcpdump

# Capture all traffic on an interface (full packets)
tcpdump -i eth0 -s 0 -w /cases/capture.pcap

# Capture with rotation (100MB files, keep 10)
tcpdump -i eth0 -w /cases/capture-%Y%m%d-%H%M.pcap -G 3600 -C 100 -W 10

# Capture specific host and port
tcpdump -i eth0 host 192.168.1.100 -w /cases/host.pcap
tcpdump -i eth0 'src 10.0.0.0/8 and dst port 53' -w /cases/dns.pcap

Windows Capture (No Install Required)

REM netsh trace -- built into Windows, no additional tools needed
netsh trace start capture=yes tracefile=C:\cases\capture.etl maxsize=500
netsh trace stop

REM Convert ETL to PCAPNG
etl2pcapng.exe C:\cases\capture.etl C:\cases\capture.pcapng

REM pktmon (Windows 10 2004+ and Server 2022+)
pktmon start --etw -f C:\cases\capture.etl
pktmon stop
pktmon pcapng C:\cases\capture.etl -o C:\cases\capture.pcapng

Most responders do not realise that Windows has built-in packet capture. netsh trace and pktmon require no installation, no driver loading, and no administrative exceptions -- which matters considerably when the security team needs a capture from a locked-down production server at 2am.


tshark -- Command-Line PCAP Analysis

Wireshark's command-line counterpart is essential for batch processing, scripting, and analysing captures too large for the GUI.

Extracting Key Information

# HTTP requests -- source IP, host, URI
tshark -r capture.pcap -Y "http.request" \
    -T fields -e ip.src -e http.host -e http.request.uri

# DNS queries and responses
tshark -r capture.pcap -Y "dns.qry.name" \
    -T fields -e ip.src -e dns.qry.name -e dns.a

# TLS Server Name Indication (SNI) -- what domains were accessed over HTTPS
tshark -r capture.pcap -Y "tls.handshake.extensions_server_name" \
    -T fields -e ip.dst -e tls.handshake.extensions_server_name

# Connection summary
tshark -r capture.pcap -q -z conv,tcp
tshark -r capture.pcap -q -z conv,ip

# Protocol hierarchy -- what's in this capture?
tshark -r capture.pcap -q -z io,phs

File Extraction

# Extract HTTP objects (downloaded files)
tshark -r capture.pcap --export-objects http,/cases/http_objects/

# Extract SMB objects (file transfers over shares)
tshark -r capture.pcap --export-objects smb,/cases/smb_objects/

# Extract email attachments
tshark -r capture.pcap --export-objects imf,/cases/email_objects/

Export to CSV for Analysis

tshark -r capture.pcap -T fields -E header=y -E separator=, \
    -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e frame.len \
    > /cases/packets.csv

Wireshark Analysis Workflow

For interactive analysis, Wireshark remains the tool of choice. The key is knowing which statistics views and filters to use.

Essential Statistics Views

Menu Path What It Shows
Statistics -> Conversations Top talkers -- identify the loudest hosts
Statistics -> Endpoints All unique hosts in the capture
Statistics -> Protocol Hierarchy Traffic breakdown by protocol
Statistics -> I/O Graphs Traffic volume over time -- essential for beaconing detection
Analyze -> Expert Information Errors, warnings, and anomalies Wireshark has detected

Forensic Hunting Filters

# Beaconing -- SYN packets to a specific destination
ip.dst == SUSPECT_IP && tcp.flags.syn == 1 && tcp.flags.ack == 0

# Large outbound transfers (potential exfiltration)
tcp.len > 1000 && !(ip.dst == 10.0.0.0/8) && !(ip.dst == 172.16.0.0/12)

# DNS tunnelling indicators (long subdomain names)
dns.qry.name.len > 50

# Cleartext credentials
ftp.request.command == "PASS"
http.authbasic

# Self-signed or unusual TLS certificates
tls.handshake.type == 11

# Non-standard ports (HTTP on port 8443, SSH on port 2222)
tcp.port == 8443 || tcp.port == 4444 || tcp.port == 1337

Zeek Log Analysis

Zeek (formerly Bro) processes PCAPs into structured log files that are far more efficient to query than raw packets. Where Wireshark shows every packet, Zeek shows connections, sessions, and extracted metadata.

Processing a PCAP

zeek -r /cases/capture.pcap local

This generates structured log files: conn.log, dns.log, http.log, ssl.log, files.log, notice.log, and more.

Core Log Analysis

# conn.log -- all connections with duration and byte counts
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto service duration orig_bytes resp_bytes

# Long-duration connections (potential C2 channels)
cat conn.log | zeek-cut id.orig_h id.resp_h duration | awk '$3 > 3600'

# dns.log -- every DNS query
cat dns.log | zeek-cut query answers qtype_name
# Unique domains queried
cat dns.log | zeek-cut query | sort -u
# Long DNS names (tunnelling indicator)
cat dns.log | zeek-cut query | awk 'length > 50'
# TXT record queries (often used for exfiltration)
cat dns.log | zeek-cut query qtype_name | grep TXT

# http.log -- HTTP transactions
cat http.log | zeek-cut id.orig_h host uri method status_code
# Unusual user agents
cat http.log | zeek-cut user_agent | sort | uniq -c | sort -rn

# ssl.log -- TLS connections
cat ssl.log | zeek-cut id.resp_h server_name issuer subject validation_status
# Self-signed certificates
cat ssl.log | zeek-cut server_name validation_status | grep "self signed"

# files.log -- extracted file metadata with hashes
cat files.log | zeek-cut filename mime_type md5 sha1 total_bytes
# Find transferred executables
cat files.log | zeek-cut filename mime_type | grep -i "executable\|x-dosexec"

Beaconing Detection

Command-and-control traffic typically beacons at regular intervals -- a compromised host checking in with the C2 server every 30 seconds, every 5 minutes, or every hour. Detecting this regularity is one of the most reliable methods for finding C2 channels.

Manual Beaconing Analysis

# Extract connection timestamps to a suspicious host
cat conn.log | zeek-cut id.orig_h id.resp_h ts | \
    grep "SUSPECT_IP" | awk '{print $3}' | sort -n | \
    awk 'NR>1{print $1-prev} {prev=$1}'

If the intervals are consistent (within 10% jitter), the traffic is almost certainly automated. Human browsing does not produce connections at exactly 60-second intervals for eight hours straight.

What to Look For

Indicator Significance
Regular connection intervals Automated beaconing (C2)
Consistent payload sizes Heartbeat check-ins with no real data
HTTPS to an IP address (no domain) Avoiding DNS-based detection
Long-lived connections with minimal data Keep-alive tunnel
Connections outside business hours Attacker in a different timezone

I/O Graphs in Wireshark

Set up an I/O graph filtered to the suspicious destination IP, with a 60-second interval. Beaconing appears as a regular pulse -- evenly spaced vertical bars that look nothing like normal user traffic.


DNS Forensics

DNS is forensically valuable because every domain lookup leaves a trace, DNS is rarely encrypted in enterprise environments, and attackers must resolve domains before they can reach their infrastructure.

DNS Tunnelling Detection

DNS tunnelling encodes data in DNS queries and responses -- typically using long subdomain labels and TXT records.

# Domains with unusually long queries
tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name | \
    awk -F. '{print $(NF-1)"."$NF}' | sort | uniq -c | sort -rn | head -20

# Query type distribution (high TXT/NULL count is suspicious)
tshark -r capture.pcap -Y "dns.flags.response == 0" -T fields \
    -e dns.qry.type | sort | uniq -c | sort -rn

Indicators of DNS tunnelling: high volume of unique subdomains under a single domain, encoded-looking labels (base64, hex), excessive TXT or NULL record queries, and a high query rate to a single domain.


Encrypted Traffic Fingerprinting

When traffic is encrypted (and most C2 traffic is), you cannot read the content -- but you can fingerprint the TLS handshake.

JA3/JA3S Hashes

JA3 creates a fingerprint from the TLS Client Hello parameters (TLS version, cipher suites, extensions). The same application produces the same JA3 hash regardless of destination.

# Known malicious JA3 hashes
# Cobalt Strike:  72a589da586844d7f0818ce684948eea
# Metasploit:     5d65ea3fb1d4aa7d826733d2f2cbbb1d
# Trickbot:       6734f37431670b3ab4292b8f60f29984

# Extract JA3 hashes from Zeek ssl.log
cat ssl.log | zeek-cut ja3 server_name | sort | uniq -c | sort -rn

JA4 Fingerprinting

JA4 is the successor to JA3 with more granular fingerprinting:

# Install Zeek JA4 package
zkg install ja4
zeek -r capture.pcap local ja4
cat ssl.log | zeek-cut ja4 server_name

A JA3 or JA4 hash that matches a known C2 framework is a strong indicator -- but not definitive, as legitimate applications can produce the same hash. Cross-reference with other indicators before concluding.


Suricata Alert Integration

Running Suricata against a PCAP applies thousands of IDS signatures and provides a fast initial triage.

# Process PCAP with Suricata
suricata -r /cases/capture.pcap -l /cases/suricata_logs/

# Parse alerts from eve.json
cat /cases/suricata_logs/eve.json | \
    jq 'select(.event_type=="alert") | {timestamp, src_ip, dest_ip, signature: .alert.signature}'

# Alert summary
cat /cases/suricata_logs/eve.json | \
    jq -r 'select(.event_type=="alert") | .alert.signature' | sort | uniq -c | sort -rn

Investigation Checklist

A structured approach ensures thorough network forensic analysis:

  1. Protocol hierarchy -- what protocols are present? Anything unexpected?
  2. Conversations -- top talkers, unexpected external IPs
  3. DNS analysis -- unusual queries, tunnelling indicators, DGA domains
  4. HTTP/TLS -- suspicious user agents, beaconing intervals, self-signed certificates
  5. File extraction -- executables, scripts, and documents transferred
  6. Timeline correlation -- align network events with host artifacts
  7. IOC extraction -- IPs, domains, hashes, JA3 fingerprints for threat intelligence sharing

  8. What's Next in the Series

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

- Advertisment -
Google search engine

Most Popular

Recent Comments