Skip to content
[menu][close]

FOUNDRYNETNo. 001SEPTEMBER 2026PROVENANCE

Packet Capture as Evidence: Chain of Custody for pcap Files

A packet capture is only as believable as the record of how it was taken and kept. This page covers the capture points, the pcap and pcapng formats, the hashes and the custody record that turn a trace into evidence.

On this page

01 What a packet capture proves

A packet capture is a file of frames copied off a link, each stamped with the time the capturing host saw it. It is the most detailed record a network can produce, so people reach for it in a dispute. It settles one only if the other side can trust it was taken where you say, when you say, and is unchanged since.

The trust does not come from the file. Any pcap can be edited in minutes and the result looks like the original. It comes from the procedure around the file: a documented capture point, a known clock, a hash computed at once, and a chain of custody record naming every hand the file passed through. This page in the wire-level provenance reference sets out that procedure. The same logic applies to keeping access logs admissible, but a capture is larger and easier to alter.

02 Capture points: SPAN, TAP and the host itself

Where the copy is made decides what the capture shows. A SPAN or mirror port copies traffic from one or more switch ports to a monitoring port. Under load the mirror drops frames silently, and the gap looks like the traffic never existed. The mirror port configuration and its limits page covers oversubscription; a SPAN capture proves what the mirror delivered, not everything that crossed the link.

A passive TAP splits the physical signal and passes every frame, including errored ones, to the monitor. It cannot drop, though the capture host behind it can. A capture on the server itself with tcpdump shows that host's view only: what its NIC handed up after offload work, nothing the switch never sent it. Sampled sources such as sFlow counters and packet samples are not captures; one frame in a thousand cannot prove absence.

Each capture point proves a different scope. Write the scope into the custody record.
Capture pointWhat it provesLoss behaviourEvidence note
SPAN or mirror portTraffic the switch copied to the monitor portDrops silently when oversubscribed; not countedRecord the mirror config and source port counters
Passive TAPEvery frame on the physical link, both directionsNone at the TAP; possible on the capture NIC or diskRecord the capture tool's drop summary
Host with tcpdumpWhat that host's kernel saw on that interfaceKernel drops reported at exit; offloads may merge framesNote offload settings; one endpoint's view only

03 pcap and pcapng: what the file records about itself

Classic pcap, the libpcap format, has a 24-byte header carrying magic, version, link type and snapshot length, then per-packet records. It stores one interface, one link type and no comments.

pcapng, specified in draft-ietf-opsawg-pcapng on the IETF datatracker, is block based. The Section Header Block records the capturing hardware, OS and application (shb_hardware, shb_os, shb_userappl). Each Interface Description Block names the interface (if_name), the filter (if_filter) and the timestamp resolution (if_tsresol), so a reader knows whether stamps are microseconds or nanoseconds; any block can carry an opt_comment. Wireshark's user guide states that Wireshark 1.8 and later save pcapng by default and warns that other formats can lose comments, name resolution and timestamp resolution. For evidence, keep the file in pcapng: the metadata is part of the record.

pcapng file structurePCAPNG FILE STRUCTURE05Comments on any block04Interface Statistics Block: drops, start, end03Enhanced Packet Blocks: timestamp, lengths, bytes02Interface Description Block: name, filter, tsresol01Section Header Block: hardware, OS, applicationpcapng file structurePCAPNG FILE STRUCTURE05Comments on any block04Interface Statistics Block: drops,start, end03Enhanced Packet Blocks: timestamp,lengths, bytes02Interface Description Block: name,filter, tsresol01Section Header Block: hardware, OS,application
The statistics block records interface drop counts that a reviewer will ask about.

04 What makes a packet capture believable later

NIST SP 800-86, the Guide to Integrating Forensic Techniques into Incident Response, sets the rule for collected data: document the collection, compute a message digest, keep a chain of custody from then on. For a packet capture the items are these.

Capture point. The switch, port or TAP, the capture host interface, and the mirror configuration in force. Clock source. The host that stamps packets must be disciplined by NTP or PTP; record the server and the offset. Filter and snaplen. A BPF filter such as host 198.51.100.7 and port 443 is legitimate, but the record must say what was excluded. The tcpdump manual gives the default snapshot length as 262144 bytes; a shorter -s truncates payloads and must be written down. Hash. A SHA-256 digest over the closed file, before any copy. Custody record. Who took it, when, on what host, every transfer, where it rests. Storage. Write-once media with access logged.

Taking, hashing and recording a capture
$ chronyc tracking | grep -E 'Reference|System time'
System time     : 0.000041 seconds fast of NTP time
$ sudo tcpdump -i eth1 -s 0 --time-stamp-precision=nano \
    -w /cap/dispute-4471-eth1.pcapng 'host 198.51.100.7 and port 443'
^C
31842 packets captured, 0 dropped by kernel
$ sha256sum /cap/dispute-4471-eth1.pcapng | tee /cap/dispute-4471-eth1.sha256
9f3a...c41e  /cap/dispute-4471-eth1.pcapng
$ chmod 0440 /cap/dispute-4471-eth1.pcapng*
$ head -5 /cap/dispute-4471-custody.txt
file:      dispute-4471-eth1.pcapng  sha256: 9f3a...c41e
taken by:  M. Okafor  host: cap01.example.net  iface: eth1 (TAP on core-sw2 gi1/0/12)
window:    2026-09-22 01:58:20Z to 02:41:07Z  clock: ntp1.example.net +41us  drops: 0
2026-09-22 02:44Z  copied to WORM bucket evidence/4471/  M. Okafor  hash verified

Every custody line ends with hash verified, meaning the receiver recomputed the digest and matched it. A transfer without a verification is a gap in the chain.

05 Worked example: preserving a capture for one dispute

A payment gateway, reached from a balancer at 203.0.113.20, claims that a batch of authorisation requests on the night of 22 September arrived with malformed bodies. The application team says they left the balancer intact. The difference between layer 4 and layer 7 balancing matters here: a layer 7 balancer rewrites the request, so the capture must sit on its server side.

The operator places a TAP on the balancer's outbound link, checks the capture host's NTP offset (41 microseconds), then starts tcpdump with a filter for the gateway address and port at the default snaplen. The capture runs 43 minutes with zero kernel drops. She computes SHA-256 at once, sets both files read-only, and writes the custody record with the TAP location, the VIP and pool, the filter and the offset. The file goes to a write-once bucket the same hour, hashed on arrival; legal recomputes it the next day.

The capture proves the bytes that crossed that link in that window, stamped within tens of microseconds of UTC. It does not prove what the gateway did after its own edge, or whether an earlier batch was affected. The custody record says both. Proving TLS body contents needs a key log kept under the same custody rules, a separate decision.

06 Procedure: from capture to sealed evidence

  1. Choose and document the capture point

    Decide between TAP, SPAN and host capture by what must be proved. Write down the switch, port, mirror session or TAP position, and the capture interface.

  2. Check the clock before starting

    Confirm the capture host is synchronised (chronyc tracking or ntpq -p) and record the reference server and offset. Use nanosecond precision where the interface supports it.

  3. Run the capture with explicit parameters

    Use -w to a pcapng file, state the snaplen with -s, apply the narrowest filter that still answers the question, and keep the exit summary of packets dropped.

  4. Hash the moment the file closes

    Run sha256sum before any copy, write the digest to a sidecar file, and set both read-only. The digest is the identity of the evidence; a different digest is a different file.

  5. Write the custody record and seal the file

    One entry for the capture, then one line per transfer or access: UTC time, person, action, hash verified. Copy to write-once storage, verify the hash on arrival, and work from copies only.

07 Pitfalls that break a capture as evidence

  • Editing the original to remove noise. Filtering with editcap or Wireshark and saving over the file breaks the chain. Filter a copy, hash it, and record it as derived.
  • Trusting a SPAN under load. A mirror port on a busy switch drops without counting, so a gap in the capture is indistinguishable from a gap in the traffic. Use a TAP when absence is what you must prove.
  • Converting pcapng to pcap for convenience. The conversion drops comments, interface descriptions, drop statistics and nanosecond resolution. Keep the original format.
  • Hashing after the copy. A digest computed on the archive copy proves only that the copy has not changed since. Compute it on the capture host at close, before the file moves.

A capture is one of three evidence sources this lane treats together: reconstructing an incident from captures, flow records and logs shows how the three corroborate each other, and a clock hierarchy the capture host and the switches share is what lets a pcap timestamp be lined up against a syslog line.

08 Questions

Which hash should I use for a packet capture?

SHA-256. It ships as sha256sum and in every forensic tool, and NIST SP 800-86 calls for a message digest computed at collection. Record it in a sidecar file and in the custody record, and recompute it at every hand-off instead of trusting the previous line.

Is pcap or pcapng better for evidence?

pcapng. The draft-ietf-opsawg-pcapng format records the capture hardware, OS and application, the interface name, the filter, the timestamp resolution and drop counts, all of which a reviewer will ask about. Classic pcap stores only the frames and their timestamps, nothing about how they were taken.

Does a capture from a mirror port prove a packet was never sent?

No. A SPAN session drops silently when the monitor port is oversubscribed, so a missing packet may have crossed the link and never been copied. To prove absence you need a TAP and a capture host with zero reported drops.

What goes in a chain of custody record?

The file name and SHA-256, who took the capture, host and interface, capture point, start and end in UTC, clock source and offset, filter and snaplen, drop count, then one line per transfer or access with date, person and confirmation that the hash was verified.

How long should I keep the original?

As long as the dispute or retention policy requires, and longer than any derived copy. The original is the only file whose hash matches the custody record from its first line; once it is gone, every analysis rests on copies that cannot be traced back.

A packet capture with a documented capture point, a checked clock, a SHA-256 digest at close and an unbroken chain of custody is evidence. Without those four it is a claim the other side is free to dispute.