Network Forensics: PCAP Analysis Lab

From Live Capture to Static Evidence

The Linux roadmap's networking lesson covered live tcpdump capture. This lab goes the other direction: analyzing an already-captured .pcap file after the fact — the standard workflow when investigating an incident from previously collected network evidence, in Wireshark, the standard GUI tool for this work.

Display Filters: Isolating the Signal

A raw PCAP from a busy network can contain hundreds of thousands of packets. Wireshark's display filter syntax narrows this down to exactly what matters:

Follow TCP Stream: Reconstructing the Conversation

Individual packets are hard to read in isolation. Wireshark's "Follow TCP Stream" feature reassembles every packet belonging to one TCP conversation into readable order — turning a scattered sequence of raw segments into the actual HTTP request/response, plaintext credentials, or command-and-control traffic exchanged between two hosts.

Beaconing: Spotting Periodic C2 Check-Ins

Command-and-control malware frequently "beacons" — checking in with its controller at regular intervals to fetch new instructions. In a PCAP, this shows up as connections to the same external host at suspiciously regular time intervals (e.g. exactly every 60 seconds), often with near-identical packet sizes each time. Statistics > Conversations in Wireshark, sorted by frequency and interval, is a fast way to spot this pattern against a large capture.

DNS Tunneling: Exfiltration Hidden in Plain Sight

DNS is rarely blocked by outbound firewalls, which makes it an attractive covert channel. DNS tunneling encodes data (often base32/base64) into subdomain labels of queries to an attacker-controlled domain:

d29ybGQgc2VjcmV0cw.exfil.attacker-domain.com

Indicators include: abnormally long subdomain labels, unusually high query volume to one domain, or queries for record types (e.g. TXT) more consistent with data transfer than name resolution.

Extracting IOCs for Detection

A network forensics investigation's actual deliverable is usually a set of concrete Indicators of Compromise: the C2 server's IP address, the malicious domain name, any file hashes for payloads observed being transferred, and specific beacon intervals or user-agent strings — these feed directly into the Sigma rules and SIEM correlation logic from the Blue Team Detection Engineering lesson.

Common Pitfalls

• Trying to manually review every packet in a large capture instead of filtering down to what's relevant first
• Missing beaconing because it was checked visually rather than sorted/aggregated by interval and destination
• Assuming DNS traffic is inherently safe to ignore, when it's one of the most common covert exfiltration channels precisely because it's rarely blocked
• Extracting an IOC but never feeding it forward into an actual detection rule, wasting the investigation's most actionable output