Network forensics: packet captures, flow data and logs

Sources of network evidence

Hosts can be wiped or lied to, but the network sees traffic from the outside. Network forensics uses that view to answer questions such as: which machine first contacted the attacker’s server, what was sent out, and which other hosts were touched?

• Full packet capture (PCAP): complete copies of packets, taken from a span port or network tap.
• Flow records: NetFlow or IPFIX (IP Flow Information Export) summaries of each conversation: addresses, ports, protocol, start time, bytes and packets.
• Logs: firewall allow and deny records, web proxy logs, DNS query logs, VPN and DHCP (Dynamic Host Configuration Protocol) logs that map IP addresses to devices and users.
• Network security monitoring output: Zeek produces detailed protocol logs (connections, DNS, HTTP, TLS) and Suricata produces intrusion detection alerts.

Capturing and filtering traffic

For a short, targeted capture on a network you manage, tcpdump writes to a file you can later open in Wireshark. Rotate files so the disk does not fill, and hash each file once it closes:

sudo tcpdump -i eth0 -nn -s 0 -w /cases/cap-%Y%m%d-%H%M.pcap -G 900 host 192.168.10.25
sha256sum /cases/cap-*.pcap > /cases/pcap-hashes.txt

In Wireshark, display filters help you narrow the data:

ip.addr == 192.168.10.25 && dns
http.request.method == "POST"
tls.handshake.extensions_server_name contains "example.com"
tcp.flags.syn == 1 && tcp.flags.ack == 0

Only capture traffic on networks you own or are authorised to monitor. Packet captures can contain personal data, so store and delete them according to your organisation’s policy and data protection law.

Working with encrypted traffic

Most web and application traffic now uses Transport Layer Security (TLS), so you usually cannot read payloads. You still learn a lot from metadata:

Where policy allows, a TLS inspection proxy can decrypt business traffic, and its logs become another evidence source.

Reconstructing events

Start with what you know: a suspicious host and a rough time window. Use flow data or Zeek connection logs to see every peer it talked to. Use DHCP and VPN logs to tie IP addresses to devices and users at that moment, because addresses change. Then pull packets for the few interesting sessions and follow the stream. Place everything on a timeline in UTC.

Common problems are clocks that disagree between devices (fix with NTP and note any offset), network address translation hiding the real internal host, and capture points that miss traffic, such as east-west traffic between virtual machines on the same host.

Tip: keep flow data for months even if you only keep packets for days. Many breaches are discovered weeks later, and flows are often the only record left.