Top PCAP Analysis Solutions for Network Forensics

The top PCAP analysis solutions for network forensics are Wireshark and TShark for exact packet reconstruction, Zeek for structured timelines, Suricata for offline detection leads, NetworkMiner for artifact recovery, Arkime or Security Onion for retrieving the right PCAP from retained traffic, and PacketSafari for turning a selected capture into a packet-grounded report. No single tool answers every forensic question, so choose by the question the case must answer.
This guide stays inside the PCAP. For the wider stack, including sensors and NDR platforms, see our network forensics tools guide.
Forensic questions and the solutions that answer them
| Forensic question | Best first solution | Confirm with | Typical limit |
|---|---|---|---|
| What happened? | Suricata and Zeek run offline | Wireshark on the flagged sessions | Detectors only see what their rules and scripts look for |
| When did it happen, in what order? | Zeek conn.log and protocol logs | Wireshark frame times | Clock skew between capture points |
| What files or objects moved? | NetworkMiner, Wireshark Export Objects, Zeek file extraction | Hashes and malware analysis in a sandbox | Encrypted or partial transfers cannot be fully rebuilt |
| Was data exfiltrated? | Zeek byte counts, TShark conversation statistics | Wireshark on the largest outbound sessions | Volume alone does not prove what the data was |
| Did the attacker move laterally? | Zeek SMB, DCE-RPC, Kerberos, and RDP logs | Wireshark on authentication and file operations | The capture point may not see east-west traffic |
| Can we defend the conclusion? | PacketSafari Verification and Final Report | Wireshark review of each cited frame | Only the supplied packets and coverage can be cited |
What happened: start with a wide pass
Run detectors over the whole capture before reading individual packets. That gives you a list of leads and a map of the traffic.
mkdir -p suricata-out
suricata -r incident.pcap -l ./suricata-out
zeek -C -r incident.pcap local
Suricata writes alerts and protocol events to EVE JSON. Zeek writes connection, DNS, HTTP, TLS, SMB, and file logs that share a connection identifier. Treat both outputs as selectors. The forensic answer comes from the packets behind them.
PacketSafari Triage performs a similar capture-wide pass with its own Triage Modules, then hands bounded evidence to the Agent. It is useful when the analyst would otherwise spend hours correlating logs and streams by hand.
Timeline: put events in order
A forensic timeline is the backbone of the report. Zeek's conn.log gives one row per connection with a start time, duration, and byte counts:
zeek-cut -d ts id.orig_h id.resp_h id.resp_p service duration orig_bytes resp_bytes < conn.log \
| grep 10.0.0.25 | sort
Add DNS lookups, TLS server names, HTTP requests, and SMB actions from the matching logs. Then confirm the decisive rows in Wireshark, because a log row is an interpretation and the frame time is the evidence.
Record the time zone and the capture clock source. When you combine captures from several sensors with mergecap, any skew between them can reorder events. Note the skew in the report rather than silently correcting it.
Artifacts: reconstruct what moved
For cleartext protocols, Wireshark's File > Export Objects recovers HTTP, SMB, TFTP, and other supported objects. NetworkMiner reassembles files, certificates, images, and host details into a browsable view, which is often faster for artifact-heavy cases. Zeek can extract files during processing with its file analysis framework.
For each recovered object, record:
- the source flow, direction, and frame range
- a SHA-256 hash of the extracted file
- whether the reconstruction is complete or partial
- the protocol used to transfer it
Analyze extracted files only in an approved sandbox. A malicious hash shows what the object is; it does not prove that the receiving host executed it.
Exfiltration: measure, then explain
Start with volume by direction:
tshark -r incident.pcap -q -z conv,tcp
zeek-cut id.orig_h id.resp_h id.resp_p orig_bytes resp_bytes < conn.log | sort -k4 -nr | head -20
Large outbound sessions to unfamiliar destinations are leads. To support an exfiltration finding, you also need context: what the host did before the transfer, which protocol carried it, whether the destination is a known service the organization uses, and whether the content is visible. Over TLS without authorized secrets, the PCAP may support "about 2 GB left this host over an encrypted session to this address" but not "these files were stolen." Say exactly that.
Lateral movement: follow authentication and file operations
East-west movement usually shows a sequence: directory lookup, authentication, a remote service such as SMB, WinRM, or RDP, a file operation or remote call, and then new activity from the contacted host. Zeek's smb_mapping.log, smb_files.log, dce_rpc.log, kerberos.log, and rdp.log give that sequence in structured form. Wireshark confirms the exact share names, file names, and RPC calls.
Check the capture point first. An internet edge capture rarely sees host-to-host SMB on the same subnet, and absence of lateral traffic in that capture proves nothing. The sibling cheat sheet on how to find malicious traffic in PCAPs lists filters for SMB, RDP, and related protocols.
Reporting: make every claim reviewable
A forensic report should let a second analyst reach the same conclusion from the same capture. Include:
- the question the investigation answered
- the capture source, time window, vantage point, and known gaps
- the conclusion, stated at the strength the evidence supports: supported, suspicious but unverified, inconclusive, or not observed in the capture
- a timeline where each row cites frames or a reproducible filter
- alternatives considered and why they were rejected
- what the capture cannot show, and which other evidence source would close the gap
PacketSafari structures its output this way. The Preliminary Report is tested by Verification against exact packets, and the Final Report keeps the evidence, alternatives, and explicit coverage together. Analysts can still open any cited frame in Wireshark. Our packet evidence verification standard explains the handoff in more detail.
Chain-of-custody basics for PCAP evidence
This is practical handling guidance, not legal advice. If the case may reach court, regulators, or an insurer, follow your organization's evidence procedures and counsel.
- Hash on receipt. Record a SHA-256 of the original file before anything else touches it.
sha256sum incident.pcap > incident.pcap.sha256
capinfos incident.pcap > incident.pcap.capinfos.txt
- Work on copies. Keep the original read-only in controlled storage.
- Hash every derivative. Time slices from
editcap -A ... -B ..., merged files frommergecap, filtered exports, and anonymized copies are new files. Record how each was produced and hash it. - Record provenance. Note who captured the traffic, where, with which tool and settings, and how it was transferred to you.
- Log access. Keep a simple record of who handled the evidence and when.
- Share derivatives, not originals. When a vendor or third party needs to see the traffic, a pseudonymized sibling capture from Anoncap can preserve diagnostic structure while reducing exposure of identifiers.
How to evaluate PCAP forensics solutions
Test each candidate on a capture you understand, ideally one with a known incident and a known benign lookalike:
- Does it read your capture formats and sizes without silent truncation?
- Can every finding be traced to exact frames?
- Does it report coverage, gaps, and encrypted boundaries?
- Can a second analyst reproduce the result?
- Does the output fit your case system and report template?
For a selected incident capture, try PacketSafari Analyzer next to Wireshark and compare the time to a reviewable answer. For analysts building a full toolkit, the companion guide to network forensics software for security analysts recommends stacks by team size.
