PCAP analysis for
DDoS forensics

Back to Blog

What PCAPs Are and Why They Matter

A PCAP (Packet Capture) file is a binary recording of raw network packets as they appeared on the wire. Each packet in the file includes the full header (Ethernet, IP, TCP/UDP/ICMP) and optionally a portion of the payload, along with a precise timestamp indicating when the packet was captured. The PCAP format (and its successor PCAPNG) is the universal standard for packet-level forensic data, readable by Wireshark, tcpdump, tshark, Zeek, and every major network analysis tool.

For DDoS forensics, PCAPs are irreplaceable because they contain the ground truth of what happened. Flow data (NetFlow, sFlow) provides aggregated summaries. Kernel counters tell you rates and totals. But only a PCAP shows you the exact packets: the specific source IPs, the precise TCP flags, the packet sizes, the protocol headers, and the timing relationships between packets. When you need to prove to your ISP that you are under attack, identify the amplification vector, or reconstruct the exact sequence of events during an incident, the PCAP is the evidence.

Capturing Packets During an Attack

The challenge with PCAP capture during a DDoS attack is scale. A 1 Gbps flood generates roughly 80,000 to 1,500,000 packets per second depending on packet size. Capturing all of those to disk requires significant I/O bandwidth and storage. A full capture at 1 Gbps produces roughly 7.5 GB of PCAP data per minute. At 10 Gbps, that is 75 GB per minute.

In practice, you do not need to capture every packet. A representative sample of 10 to 30 seconds of attack traffic is sufficient for forensic analysis. The key is to start the capture early, ideally within the first seconds of the attack, and to use appropriate filters to limit the capture to relevant traffic.

# Capture 30 seconds of inbound traffic on eth0, limit to 256 bytes per packet
tcpdump -i eth0 -c 500000 -s 256 -w /tmp/attack-capture.pcap 'inbound'

# Capture only UDP traffic on a specific port (common for amplification attacks)
tcpdump -i eth0 -c 100000 -s 128 -w /tmp/udp-flood.pcap 'udp and dst port 80'

# Capture SYN packets only (for SYN flood analysis)
tcpdump -i eth0 -c 200000 -s 96 -w /tmp/syn-flood.pcap 'tcp[tcpflags] & tcp-syn != 0'

# Ring buffer: continuously capture, keeping only the last 100MB
# Useful for retroactive analysis when you do not know an attack is coming
tcpdump -i eth0 -s 256 -W 5 -C 20 -w /tmp/rolling-capture.pcap

The -s flag (snap length) is important. Setting it to 96 or 128 bytes captures the full IP and TCP/UDP headers without recording application payloads, which dramatically reduces file size while preserving all the information needed for DDoS forensics. For most DDoS attack types, the headers alone tell the complete story.

Analyzing PCAP Data

Once you have a PCAP file, the analysis follows a systematic process. Start with the high-level statistics to understand the attack profile, then drill into specific patterns.

Source IP analysis reveals the attack's origin characteristics. During a spoofed flood, you will see thousands or tens of thousands of unique source IPs, each responsible for only a handful of packets. During a botnet attack, you will see a smaller number of sources (hundreds to low thousands), each sending many packets. This distinction matters because spoofed attacks cannot be blocked by source IP, while botnet attacks can be partially mitigated with IP-based filtering.

# Count unique source IPs in a PCAP
tshark -r attack-capture.pcap -T fields -e ip.src | sort -u | wc -l

# Top 20 source IPs by packet count
tshark -r attack-capture.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -20

# Protocol distribution
tshark -r attack-capture.pcap -z io,phs -q

# Packet size distribution (reveals amplification patterns)
tshark -r attack-capture.pcap -T fields -e frame.len | sort -n | uniq -c | sort -rn | head -10

Protocol analysis identifies the attack vector. UDP packets from port 53 with large response payloads indicate DNS amplification. UDP packets from port 123 with 468-byte payloads indicate NTP monlist amplification. TCP packets with only the SYN flag set from diverse sources indicate a SYN flood. The protocol breakdown combined with packet sizes creates a fingerprint that maps directly to known attack vectors.

Packet size distribution is a particularly useful signal. Legitimate traffic produces a diverse mix of packet sizes. Attack traffic tends to be uniform. A UDP flood might show 90% of packets at exactly 1400 bytes. A SYN flood shows packets clustered around 60 to 80 bytes (minimum TCP SYN with options). This uniformity is a strong indicator that the traffic is tool-generated rather than organic.

Reconstructing Attack Timelines

A PCAP-based timeline reconstruction answers the critical questions: when did the attack start, how did it ramp up, were there multiple phases or vectors, and when did it stop? Each packet in the PCAP has a microsecond-precision timestamp, which lets you build an accurate second-by-second (or sub-second) timeline of the attack.

In Wireshark, the I/O Graphs feature (Statistics > I/O Graphs) is the fastest way to visualize the timeline. Create separate graph lines for each protocol (TCP, UDP, ICMP) with display filters, and you can see exactly when each attack vector started and stopped. Multi-vector attacks often show a pattern: a UDP flood begins first to saturate bandwidth, followed by a SYN flood to exhaust server resources, followed by an HTTP flood to target the application. The timeline reveals this sequencing clearly.

# Generate a per-second packet rate timeline with tshark
tshark -r attack-capture.pcap -q -z io,stat,1

# Per-second timeline filtered by protocol
tshark -r attack-capture.pcap -q -z io,stat,1,"udp","tcp","icmp"

# Identify the exact start time of the attack
# Look for the first second where PPS exceeds your baseline
tshark -r attack-capture.pcap -q -z io,stat,1 | head -30

The timeline is essential for incident reports, post-mortem reviews, and communication with upstream providers. When you tell your ISP "we were hit with a DNS amplification attack starting at 14:32:07 UTC, peaking at 4.2 Gbps at 14:32:41, transitioning to a SYN flood at 14:33:12, and ending at 14:47:03," that level of precision comes directly from PCAP analysis and demonstrates the kind of evidence that accelerates response from upstream providers.

Using PCAP Evidence for Incident Response

PCAP evidence serves multiple purposes in the incident response lifecycle. During the active incident, a quick analysis of the first few seconds of capture tells you the attack vector, which determines the appropriate mitigation strategy. A UDP amplification attack needs upstream filtering or scrubbing. A SYN flood can be partially handled with local SYN cookies and conntrack tuning. An HTTP flood requires application-layer rate limiting or WAF rules.

After the incident, the PCAP provides the data for your post-mortem report. It answers how long the attack lasted, what vectors were used, how traffic volumes changed over time, which source IPs or ASNs were involved, and whether the attack targeted specific services or ports. This information feeds into your defense improvements: tighter baseline thresholds, new auto-mitigation rules, updated escalation policies, and upstream provider coordination.

For compliance and legal purposes, PCAPs serve as forensic evidence. PCI DSS, SOC 2, and DORA frameworks require documented incident response procedures with evidence. A PCAP file with a cryptographic hash provides tamper-evident proof of what happened during an incident. Flowtriq automatically captures PCAPs during detected incidents, stores them with the incident record, and makes them available for download and analysis directly from the dashboard.

Back to Blog

Related Articles