Network Forensics · Rolling Thunder Security

Network forensics answers questions about traffic on the wire: who talked to whom, when, how much, and what did they say. Two data sources dominate practice: full packet captures (PCAP), which preserve every byte of every conversation, and NetFlow / IPFIX records, which summarize conversations into a compact log. Each has a use case; mature programs collect both.

PCAP vs NetFlow

PCAP — the full transcript

Captures every byte. You can re-derive any metadata and read the actual payload (when not encrypted). Tools: tcpdump, tshark, Wireshark, Zeek (formerly Bro).

Strengths:

Reconstruct files transferred over HTTP, SMB, FTP
Read DNS queries, headers, unencrypted protocols
Replay sessions for analysis
The gold standard for incident reconstruction

Weaknesses: enormous storage cost. A 10 Gbps link at line rate is over a petabyte per day. Encrypted traffic (TLS, QUIC) gives you metadata only.

NetFlow — the conversation log

For each "flow" (a unidirectional stream identified by 5-tuple: src IP, dst IP, src port, dst port, protocol), records start time, duration, byte count, packet count, TCP flags. No payload.

Strengths:

1000× smaller than PCAP for the same time window
Trivial to store at scale — months of history are practical
Good enough for who talked to whom questions
Encryption-agnostic (you weren't reading the payload anyway)

Weaknesses: no payload — can't tell you what was said, only that there was a conversation.

The practical pattern: capture NetFlow for everything; capture full PCAP at strategic chokepoints (DMZ, between subnets, in front of critical services). When investigating, start with NetFlow to scope the conversation, then pull PCAP for the specific time window once you've narrowed it down.

tcpdump and Wireshark — first commands

tcpdump captures and displays packets on the command line. Wireshark is its GUI cousin — same packet decoders, with filters and protocol analysis on top. Both speak BPF (Berkeley Packet Filter) for capture filters and Wireshark display filters for analysis.

# Capture packets on interface eth0, write to a file $ tcpdump -i eth0 -w capture.pcap # Read a capture file and apply a BPF filter $ tcpdump -r capture.pcap "host 192.0.2.5 and port 443" # Show DNS queries only, ascii-decoded $ tcpdump -r capture.pcap -A "udp port 53" # Show HTTP GET request lines $ tcpdump -r capture.pcap -A "tcp port 80" | grep "^GET" # Wireshark / tshark equivalent of the above $ tshark -r capture.pcap -Y "ip.addr == 192.0.2.5 and tcp.port == 443"

Filters worth memorizing

BPF capture filters (tcpdump) · rougher; faster

host 10.0.0.5

Traffic to or from a specific host

src 10.0.0.5

Only traffic originating from a host

port 443

Any traffic on a specific port (src or dst)

net 192.168.0.0/16

Traffic to or from a CIDR range

tcp port 80 and host 10.0.0.5

Compound: web traffic to/from a host

icmp

All ICMP (ping etc.)

not arp and not stp

Drop the broadcast noise

Wireshark display filters · richer; protocol-aware

ip.addr == 10.0.0.5

Host filter (note: == not =)

tcp.port == 443

TCP port

http.request.method == "GET"

HTTP GET requests only

http.response.code >= 400

HTTP errors

dns.qry.name contains "evil"

DNS queries containing a substring

tls.handshake.extensions_server_name == "github.com"

SNI — tells you the destination of a TLS session even when encrypted

tcp.flags.syn == 1 and tcp.flags.ack == 0

SYN packets only — useful for portscan detection

frame.time >= "2026-06-05 09:00:00"

Time window filter

What you can see in encrypted traffic

Most traffic in 2026 is TLS-encrypted; you cannot read the payload. You can still see a lot of metadata:

SNI (Server Name Indication) in the TLS ClientHello tells you which hostname the client wanted to reach. ESNI/ECH encrypted SNI is rolling out slowly; in most environments, SNI is still visible.
JA3 / JA4 fingerprints hash the TLS handshake characteristics. They identify the client library (Chrome, Firefox, curl, Python requests, the malware family Cobalt Strike). Surprisingly powerful for malware identification.
Timing and volume — bytes-per-second, request rate, conversation duration. Anomalies often shout in patterns alone.
DNS queries — unless DoH/DoT, the queries themselves are unencrypted at the network layer and tell you where clients are going.
Certificate details (issuer, validity, SAN list) when first presented — identifies the server, sometimes the operator.

Zeek (formerly Bro) is the network forensics tool worth knowing about. It reads packets but writes structured logs: one line per HTTP request, one per DNS query, one per TLS handshake, one per file transfer. The result is a forensic timeline that's 100× smaller than PCAP and 10× richer than NetFlow. Most modern SOCs run Zeek alongside their other sensors.

The five Ws

When you analyze a network conversation in an investigation, you're answering five questions:

Who — source IP, destination IP, with hostname resolution where possible.
What — protocol (HTTP, SSH, SMB), and where possible, application-layer specifics (URL, file name).
When — first/last packet timestamps, duration.
Where — geographic / organizational origin via IP geolocation and WHOIS.
How much — byte counts in each direction, packet counts, average rate.

An exfiltration conversation looks unusual on every dimension: a long-running session, asymmetric bytes (much more out than in), at an odd hour, to an unfamiliar destination, over a non-standard protocol or port. The five Ws make those anomalies visible.

The point

Network forensics has two tiers of evidence. PCAP gives you everything but doesn't scale. NetFlow scales effortlessly but only gives you metadata. Real programs collect both, layered, with the metadata always available and the full packets preserved where the cost is justified.

The actual skill is reading the data. tcpdump, tshark, Wireshark, Zeek — the tools are easy to install and free. The judgment of what to look for in a forensic packet capture is what your DFIR coursework will build, and it builds on the vocabulary on this page.

References

Formatted in APA 7.

Claise, B., Trammell, B., & Aitken, P. (Eds.). (2013). Specification of the IP Flow Information Export (IPFIX) protocol (Request for Comments No. 7011). Internet Engineering Task Force. https://datatracker.ietf.org/doc/html/rfc7011
Davidoff, S., & Ham, J. (2012). Network forensics: Tracking hackers through cyberspace. Prentice Hall.
Wireshark Foundation. (n.d.). Wireshark user's guide. https://www.wireshark.org/docs/wsug_html_chunked/
Zeek Project. (n.d.). Zeek: An open source network security monitoring tool. https://zeek.org/