Reading PCAPs

Capturing: tcpdump basics

Before reading a pcap, you have to make one. tcpdump is the canonical command-line capture tool. The basic invocations every network analyst memorizes:

Two flags you'll always want: -n disables DNS reverse lookups (massive speedup; you don't want capture analysis to chase DNS), and -w writes to a file. -r reads one back.

BPF: the filter language

BPF (Berkeley Packet Filter) is a tiny domain-specific language for selecting packets. It's compiled into kernel bytecode for speed — the kernel evaluates the filter on every packet at line rate. Mastering BPF is half of capture work.

BPF filters apply at capture time. Wireshark's display filters (covered in the next page) apply at display time and use a different syntax. Don't confuse them.

Anatomy of one packet

An HTTP GET request travelling over IPv4 + TCP + Ethernet is a single frame on the wire with four nested headers.

A real capture, narrated

Here's tcpdump output of a TCP three-way handshake followed by a quick HTTP GET. Reading skills first; we'll deconstruct line by line.

Five lines tell the entire story:

• Line 1 · SYN. 10.0.0.50:51382 initiates a connection to 93.184.216.34:80. The TCP flag is S — SYN, the synchronize bit. Sequence number 1872334801 is the client's starting ISN (Initial Sequence Number).
• Line 2 · SYN+ACK. The server responds. Flags S. mean SYN+ACK (the dot is shorthand for ACK in tcpdump). The server's ack 1872334802 = client's seq + 1, confirming receipt.
• Line 3 · ACK. Client acknowledges. Flags are just the dot (ACK alone). The three-way handshake is complete; the connection is established. Total elapsed: 19 milliseconds.
• Line 4 · Data: HTTP request. Client sends 77 bytes of payload. Flags include P (push). tcpdump recognizes the HTTP and decodes the request line: GET / HTTP/1.1.
• Line 5 · Data: HTTP response. Server sends 1,348 bytes. HTTP/1.1 200 OK — the response code and headers. The full body might follow in additional segments.

What captures tell you

• Latency. Compare SYN to SYN+ACK timestamps. That gap is RTT — round-trip time. Useful for diagnosing slow services.
• Retransmissions. Same sequence number sent twice = retransmit. High retransmit rate = lossy path, congestion, or duplex mismatch.
• Connection failures. SYN with no SYN+ACK = port closed or firewall dropping. RST in response to SYN = port closed but reachable. SYN with SYN+ACK but no ACK = client gave up (firewall or routing problem).
• Suspicious patterns. A single source IP sending SYNs to many destinations is a port scan. SYNs to a single port across many destinations is a sweep. SYN with non-standard flags (e.g. just FIN, or all flags set) is a stealth scan or fuzzing.
• Data exfiltration. Sustained outbound traffic at odd hours, to unfamiliar destinations, especially to non-business ports.
• Beaconing. Regular small outbound connections at fixed intervals (every 30s, every 5m) = malware checking in with C2.

tshark: tcpdump with display filters

tshark is the command-line version of Wireshark. It uses Wireshark's dissector library, so it knows hundreds of protocols natively — HTTP, DNS, SMB, RDP, Kerberos, MQTT, you name it.

For incident response, tshark is usually faster than opening Wireshark — you can pipeline it with grep/awk/sort/uniq to answer specific questions in seconds.

Why captures are both gold and poison

For sharing with vendors or external researchers, tcprewrite can anonymize IPs and MACs in a pcap. There are also tools (pcapfix, tcpdump --print-data) that let you strip payload bytes while preserving headers — useful when you only need metadata.