A practical PCAP triage checklist

Good triage reduces a large capture to a defensible scope: where it was recorded, what time it covers, which systems dominate it, and which symptoms deserve packet-level investigation.

1. Preserve the original and its context

Before filtering, splitting or converting anything, keep an untouched copy. Record the capture point, interface, collection filter, start time, time zone, snap length and whether hardware offload was enabled. Without that context, an apparently missing packet may be a capture limitation rather than a network failure.

Create a hash if the capture is evidence or will be shared between investigators:

sha256sum incident.pcapng

Work from a copy and avoid distributing a capture casually. Packet payloads can contain credentials, session data, internal hostnames and personal information.

2. Check whether the capture is usable

Start with file metadata rather than assumptions. Wireshark's capinfos reports format, packet count, duration, data rate, snap length and interface information:

capinfos incident.pcapng

Check for a suspiciously short duration, truncated packets, unexpected interfaces, implausible timestamps or a collection rate that could have overwhelmed the capture host or SPAN port. A cleanly readable file can still be incomplete.

3. Establish the traffic baseline

Answer five questions before chasing individual packets:

1. How long does the capture run, and are there quiet gaps?
2. Which protocols account for most packets and bytes?
3. Which source and destination addresses are most active?
4. Which endpoint pairs dominate the conversations?
5. Which DNS names, HTTP hosts and TLS server names are visible?

Useful tshark summaries include:

tshark -r incident.pcapng -q -z io,phs
tshark -r incident.pcapng -q -z endpoints,ip
tshark -r incident.pcapng -q -z conv,tcp

High volume is not automatically suspicious. Backups, software distribution, telemetry and video can dominate a healthy network. Compare results with the purpose of the segment and the reported incident window.

4. Look for symptoms, not verdicts

Use broad checks to form hypotheses:

• Name resolution: repeated queries, NXDOMAIN responses, long response times or unexpected resolvers.
• TCP health: retransmissions, duplicate acknowledgements, resets, incomplete handshakes and zero-window advertisements.
• Traffic shape: bursts, periodic connections, unusual destination concentration or a new high-volume endpoint.
• Application clues: clear-text HTTP error codes, unfamiliar hostnames, visible TLS SNI and certificate metadata.
• Layer 2: ARP changes, floods or duplicate address symptoms when the capture point can see them.

Then narrow by time, endpoint and conversation. A global count cannot explain causality. Inspect packets immediately before and after the event, and compare both directions of the flow.

5. Separate observations from conclusions

A useful incident note distinguishes three things:

• Observed: “The capture contains 18 client retransmissions between 14:02:11 and 14:02:14.”
• Inferred: “Loss or severe reordering on the path after this capture point is plausible.”
• Needed next: “Collect a synchronized server-side capture and interface counters.”

This wording prevents a heuristic, an Expert Information entry or a dashboard count from being mistaken for proof.

Manual method vs PCAPNG Analyzer