How to read a DDoS PCAP file:
step by step with Wireshark

Back to Blog

Opening the PCAP

You have a .pcap or .pcapng file from an attack. Maybe you captured it yourself with tcpdump. Maybe Flowtriq generated it automatically when detection triggered. Either way, the first step is to open it in Wireshark and take stock of what you are working with.

Launch Wireshark and drag the file onto the main window, or use File > Open. Before you start scrolling through packets, check three things in the status bar at the bottom of the window:

• Packet count. A capture with 50,000+ packets in a few seconds is already a strong indicator of a flood. Normal server traffic rarely exceeds a few hundred packets per second on a single interface.
• Capture duration. Look at the timestamps of the first and last packet. A 10-second capture with 200,000 packets means you were seeing 20,000 pps. That is well into DDoS territory for most servers.
• File size. A 50 MB PCAP from 10 seconds of traffic implies roughly 40 Mbps of bandwidth. PCAPs are not compressed by default, so the file size closely approximates the actual wire bytes captured.

You can also check these details programmatically with capinfos, a tool that ships with Wireshark:

$ capinfos attack.pcap
File name:           attack.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
Packet size limit,    file hdr, 65535 bytes
Number of packets:   187432
File size:           214 MB
Data size:           211 MB
Capture duration:    12.847 seconds
First packet time:   2026-03-14 22:31:05.123456
Last packet time:    2026-03-14 22:31:17.970812
Data byte rate:      16 MBps
Data bit rate:       131 Mbps
Average packet size: 1128 bytes
Average packet rate: 14587 packets/sec

This output alone tells you a lot. In this example, 187,000 packets in 13 seconds at 131 Mbps is a clear volumetric attack. The average packet size of 1,128 bytes suggests large packets, which is typical of amplification floods. Now let's dig deeper.

Step 1: Protocol Hierarchy Statistics

Go to Statistics > Protocol Hierarchy in Wireshark. This view breaks down all traffic in the capture by protocol, showing the percentage of packets and bytes for each layer.

On a normal server, you would expect a mix of protocols: TCP making up 60-80% of traffic (HTTP, HTTPS, SSH), some UDP for DNS queries, maybe a bit of ICMP. The distribution reflects the services the server is running.

During a DDoS attack, the protocol hierarchy becomes heavily skewed. Here is what to look for:

• 98% UDP with almost no TCP: you are looking at a volumetric UDP flood. If the UDP traffic breaks down further into DNS, NTP, or SSDP, it is an amplification attack using those protocols as reflectors.
• 95%+ TCP with almost all SYN flags: this is a SYN flood. The protocol hierarchy will show TCP but very little HTTP or TLS because the connections never complete.
• High percentage of GRE (IP protocol 47): GRE floods are used to bypass simple UDP/TCP filters. If you see significant GRE traffic on a server that does not use tunneling, it is almost certainly attack traffic.
• Mixed protocols in unusual ratios: multi-vector attacks combine several flood types simultaneously. The protocol hierarchy will show an unnatural spread across UDP, TCP, ICMP, and possibly GRE.

The tshark equivalent for scripting:

$ tshark -r attack.pcap -z io,phs -q

Step 2: Conversations View

Navigate to Statistics > Conversations and select the IPv4 tab. This shows every unique source-destination IP pair in the capture, along with packet counts, byte counts, and duration for each conversation.

Click the Packets column header to sort by packet count descending. In an attack PCAP, the pattern is unmistakable: your server's IP address will appear as the destination in the vast majority of conversations. The top talkers on the source side are either attack sources (in a direct flood) or reflectors (in an amplification attack).

Key things to extract from the Conversations view:

• Number of unique source IPs. Hundreds or thousands of sources sending to a single destination is a textbook DDoS signature.
• Traffic asymmetry. In amplification attacks, you will see massive inbound traffic from sources but zero outbound traffic to them. Your server never requested anything from these IPs.
• Top source IPs. In an amplification attack, the heaviest sources are open resolvers or misconfigured servers. In a botnet attack, the sources are compromised devices. Either way, noting the top 10-20 sources helps your ISP build initial filters quickly.

To extract the top 20 source IPs with tshark:

$ tshark -r attack.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -20

For a quick count of unique sources:

$ tshark -r attack.pcap -T fields -e ip.src | sort -u | wc -l

Step 3: I/O Graph

Go to Statistics > I/O Graphs. This plots packets per second (or bits per second) over the duration of the capture. Change the Y axis to "Packets" and set the interval to 1 second for a clear view.

The I/O Graph reveals the temporal characteristics of the attack:

• Ramp-up pattern. Does the attack start suddenly at full volume, or does it gradually increase? A sudden spike suggests a botnet receiving a coordinated command. A gradual ramp suggests an amplification attack where reflectors respond at different speeds.
• Duration and waves. Some attacks are continuous. Others come in waves with pauses between them, which is a common pattern for attackers testing your defenses or rotating attack vectors.
• Attack cessation. If the capture includes the end of the attack, the drop-off pattern can indicate whether mitigation was effective (sharp drop) or the attacker simply stopped (gradual decline).

You can add multiple graph lines with different display filters to separate attack traffic from legitimate traffic. For example, add one line for udp and another for tcp to see how the UDP flood relates to your normal TCP traffic.

The tshark equivalent to get packets per second over time:

$ tshark -r attack.pcap -z io,stat,1 -q

This outputs a table with one row per second showing the packet count and byte count for each interval.

Step 4: Display Filters for Common DDoS Types

Wireshark display filters let you isolate specific attack traffic from the rest of the capture. Here are the essential filters for the most common DDoS attack types.

SYN Flood

A SYN flood sends massive numbers of TCP SYN packets without completing the three-way handshake. Filter for SYN packets that do not have the ACK flag set:

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

If this filter matches 90%+ of your TCP traffic, you have a SYN flood. Check the source port distribution: random source ports suggest spoofed traffic, while a consistent source port suggests a single tool or botnet.

UDP Flood

A generic UDP flood sends junk UDP packets to random or specific ports. To see UDP traffic that is not legitimate DNS:

udp && !dns

If you want to isolate UDP traffic to a specific destination port (for example, your game server on port 27015):

udp.dstport==27015

DNS Amplification

DNS amplification attacks abuse open DNS resolvers. The attack traffic consists of large DNS response packets that your server never requested. Filter for DNS responses larger than 512 bytes:

dns.flags.response==1 && udp.length > 512

Large DNS responses (often 2000-4000 bytes) from hundreds of different source IPs on port 53 is the signature of DNS amplification. The responses typically contain ANY or DNSSEC records that produce the largest possible reply.

NTP Amplification

NTP amplification exploits the monlist command on misconfigured NTP servers. Filter for NTP traffic from source port 123:

ntp && udp.srcport==123

NTP amplification responses are large (up to 482 bytes per response packet) and arrive in bursts from each reflector. The amplification factor can reach 556x, making this one of the most powerful reflection vectors.

Memcached Amplification

Memcached amplification uses exposed memcached servers on UDP port 11211. This vector has an amplification factor of up to 51,000x:

udp.port==11211

Memcached responses can be enormous, sometimes producing multiple fragmented UDP packets per reflected request. If you see traffic on port 11211, check the packet sizes. Legitimate memcached traffic (if any exists on your network) uses much smaller packets.

GRE Flood

GRE (Generic Routing Encapsulation) floods use IP protocol 47. This type of flood is harder to filter at the application layer because GRE is an IP-layer protocol:

ip.proto==47

If your server does not use GRE tunneling (most do not), any GRE traffic is suspicious. GRE floods are often used in combination with other vectors as part of a multi-vector attack.

Step 5: Expert Information

Go to Analyze > Expert Information in Wireshark. This feature highlights protocol anomalies and errors that are common during DDoS attacks.

Look for these indicators:

• TCP Retransmissions (Warning). A high number of retransmissions means your server is trying to respond to connections but the replies are being lost because the link is saturated. This confirms that the attack is affecting legitimate traffic.
• TCP Zero Window (Warning). This means your server's receive buffer is full and it is telling senders to stop transmitting. During a DDoS, this happens because the kernel is overwhelmed processing attack packets.
• TCP RST floods (Note). Large numbers of RST (reset) packets can indicate that your server is rejecting connections it cannot handle, or that the attacker is sending RST packets to tear down legitimate connections.
• Malformed packets (Error). Some attack tools generate packets with invalid headers or checksums. Wireshark flags these as malformed. A spike in malformed packets is a strong DDoS indicator.
• TCP Out-of-Order (Warning). Network congestion caused by the attack leads to packet reordering. A sudden increase in out-of-order segments correlates with attack onset.

Expert Information provides a severity-sorted summary that you can include in reports. The count of warnings and errors gives a quantitative measure of the attack's impact on your server's ability to handle legitimate traffic.

Step 6: tshark Command-Line Equivalents

Everything you can do in Wireshark's GUI can be automated with tshark on the command line. This is essential for scripting, cron jobs, and processing PCAPs on headless servers where you cannot run a GUI.

Here are the tshark equivalents for each analysis step:

Protocol Hierarchy

$ tshark -r attack.pcap -z io,phs -q

Top Source IPs (Conversations)

$ tshark -r attack.pcap -z conv,ip -q

I/O Statistics (1-second intervals)

$ tshark -r attack.pcap -z io,stat,1 -q

Count SYN Flood Packets

$ tshark -r attack.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" | wc -l

Count UDP Flood Packets (excluding DNS)

$ tshark -r attack.pcap -Y "udp && !dns" | wc -l

Count DNS Amplification Packets

$ tshark -r attack.pcap -Y "dns.flags.response==1 && udp.length > 512" | wc -l

Count NTP Amplification Packets

$ tshark -r attack.pcap -Y "ntp && udp.srcport==123" | wc -l

Count Memcached Packets

$ tshark -r attack.pcap -Y "udp.port==11211" | wc -l

Count GRE Flood Packets

$ tshark -r attack.pcap -Y "ip.proto==47" | wc -l

Expert Information Summary

$ tshark -r attack.pcap -z expert -q

You can combine these commands into a shell script that processes any PCAP and generates a structured summary report:

#!/bin/bash
# ddos-pcap-report.sh - Quick DDoS PCAP analysis
PCAP="$1"

echo "=== PCAP Summary ==="
capinfos "$PCAP" 2>/dev/null | grep -E "Number of packets|File size|Capture duration|Data bit rate"

echo ""
echo "=== Protocol Hierarchy ==="
tshark -r "$PCAP" -z io,phs -q 2>/dev/null

echo ""
echo "=== Unique Source IPs ==="
echo "Count: $(tshark -r "$PCAP" -T fields -e ip.src 2>/dev/null | sort -u | wc -l)"

echo ""
echo "=== Top 10 Source IPs ==="
tshark -r "$PCAP" -T fields -e ip.src 2>/dev/null | sort | uniq -c | sort -rn | head -10

echo ""
echo "=== Attack Vector Counts ==="
echo "SYN flood:    $(tshark -r "$PCAP" -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' 2>/dev/null | wc -l)"
echo "UDP flood:    $(tshark -r "$PCAP" -Y 'udp && !dns' 2>/dev/null | wc -l)"
echo "DNS amp:      $(tshark -r "$PCAP" -Y 'dns.flags.response==1 && udp.length > 512' 2>/dev/null | wc -l)"
echo "NTP amp:      $(tshark -r "$PCAP" -Y 'ntp && udp.srcport==123' 2>/dev/null | wc -l)"
echo "Memcached:    $(tshark -r "$PCAP" -Y 'udp.port==11211' 2>/dev/null | wc -l)"
echo "GRE flood:    $(tshark -r "$PCAP" -Y 'ip.proto==47' 2>/dev/null | wc -l)"

Save that script, make it executable with chmod +x ddos-pcap-report.sh, and run it against any PCAP file: ./ddos-pcap-report.sh attack.pcap.

Step 7: Extracting Evidence for Your ISP

When you send a PCAP to your ISP or upstream provider, they do not want your entire 500 MB capture. They want a clean, filtered file that contains only the attack traffic, ideally under 10 MB. Here is how to create one.

Create a Filtered PCAP

Use tshark or Wireshark's File > Export Specified Packets to write a new PCAP containing only the attack packets. For a DNS amplification attack:

$ tshark -r full-capture.pcap -Y "dns.flags.response==1 && udp.length > 512" -w attack-only.pcap

For a SYN flood:

$ tshark -r full-capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -w syn-flood.pcap

If the filtered file is still too large, limit it to the first 1000 packets:

$ tshark -r full-capture.pcap -Y "dns.flags.response==1 && udp.length > 512" -c 1000 -w attack-sample.pcap

Generate a Text Summary

Many ISPs prefer a text summary alongside the PCAP. Include these details in your support ticket or email:

1. Target IP address and port (if applicable)
2. Attack type identified from your analysis (e.g., "DNS amplification via open resolvers")
3. Peak bandwidth in Mbps or Gbps (from capinfos or I/O Graph)
4. Peak packet rate in pps (from I/O Graph)
5. Number of unique source IPs
6. Top 10 source IPs by packet count
7. Attack start time in UTC
8. Your requested mitigation action (null-route, rate-limit, scrubbing center)

The more structured and precise your report, the faster your ISP can implement filters. Vague reports like "we are getting attacked" result in back-and-forth emails that waste critical time during an active incident.

Always use UTC timestamps in your ISP communication. Your server might be in US-East, the ISP's NOC might be in Europe, and the attack traffic might originate from Asia. UTC removes all ambiguity.

How Flowtriq Automates PCAP Analysis

Every step in this tutorial is something that Flowtriq performs automatically when it detects an attack on your network. Here is what happens behind the scenes:

• Continuous rolling buffer. Flowtriq maintains a pre-attack PCAP buffer in memory on every monitored node. When detection triggers, the capture already includes packets from before the threshold was crossed, giving you the baseline and ramp-up phases automatically.
• Automatic protocol classification. The incident detail page in the Flowtriq dashboard shows protocol breakdown, top source IPs, packet size distribution, and bandwidth graphs without any manual Wireshark analysis.
• One-click PCAP download. Every incident in the dashboard includes a download button for the raw PCAP file. You can open it in Wireshark for deeper analysis or forward it directly to your ISP.
• Pre-formatted incident reports. Flowtriq's alert notifications include a structured summary with attack type, bandwidth, packet rate, source count, and timestamps. This is exactly the information your ISP needs, generated automatically.
• API access for automation. Use the Flowtriq API to programmatically fetch PCAPs and incident data. Build integrations that attach evidence to PagerDuty incidents, Jira tickets, or automated ISP notification emails.

Instead of scrambling to start a tcpdump during an attack (when your server may already be unreachable), Flowtriq ensures you always have forensic evidence ready. The PCAP is captured at the detection point, before mitigation changes the traffic pattern, giving you the cleanest possible snapshot of the attack.

Back to Blog

Related Articles