Network Forensics: Provenance of Captures, Flows and Logs

01 /What network forensics reconstructs

Network forensics is the work of answering, after the fact, what happened on a network: which host talked to which, when, for how long, carrying how much, and what a firewall or resolver did about it. The raw material is whatever was being recorded before there was a question.

NIST SP 800-86 sets the frame: a four-phase process of collection, examination, analysis and reporting, applied to data sources that include network traffic. Its chain of custody rules separate a finding from an anecdote. This page in the lane on evidence-grade records at the edge treats each network source as an artefact with a provenance of its own.

02 /Three evidence sources and where each comes from

Full packet captures are copies of every frame on a segment, written by a capture host fed from a tap or a mirror port feeding a capture appliance. The provenance questions are which segment, which direction, and whether the mirror dropped frames under load. Timestamps come from the capture host's clock.

Flow and sample records are summaries produced by the forwarding device itself. NetFlow and IPFIX, the latter defined in RFC 7011, export one record per flow: the five-tuple, start and end times, packet and byte counts, interface indices and flags. sFlow, documented in RFC 3176 for version 4, exports the first bytes of one packet in N plus interface counters. A flow record is an exact count; a sample is an estimate with a header attached. Both commonly travel by UDP, and RFC 7011 notes that UDP export must be provisioned to avoid congestion loss.

Syslog and device logs record decisions and state changes: a firewall allowing a session, a resolver answering a query, a switch learning a MAC address. RFC 5424 defines the message format. A log line is the device's own account of what it did; NIST SP 800-92 covers how such logs are collected, protected and retained.

$ nfdump -r nfcapd.202609221410 'src ip 192.0.2.44 and dst port 443' -o line
2026-09-22 14:10:07.412  318.660  TCP    192.0.2.44:51822 -> 203.0.113.9:443    41210  61.2 M
$ grep '192.0.2.44:51822' /srv/logs/fw-edge-1/2026-09-22.log
<134>1 2026-09-22T14:10:07.398Z fw-edge-1 fw 2210 CONN [meta seq="88213"] allow tcp 192.0.2.44:51822 -> 203.0.113.9:443 rule=web-out
<134>1 2026-09-22T14:15:26.071Z fw-edge-1 fw 2210 CONN [meta seq="88790"] close tcp 192.0.2.44:51822 -> 203.0.113.9:443 bytes_out=64163840 bytes_in=921004

The records agree on the five-tuple, the start time to within 14 ms, and the duration; the firewall counts slightly more bytes because it includes headers the exporter strips. Agreement between independent producers is what makes either one evidence.

03 /How captures, flows and logs corroborate each other

Each source was written by a different device, with a different clock, for a different purpose. That independence is the point: a forged log line has to match a flow record from a separate exporter before it survives scrutiny, and a flow with no matching log line means the log was lost, the device never saw the traffic, or the record is wrong.

Work from the cheapest, longest-retained source inward: logs and flows narrow the window, and a capture, if one exists for that segment and window, says what the bytes were. The account of how sFlow sampling is configured on a switch explains why a sampled source can bound volume but never prove a packet's absence.

04 /Building a timeline on synchronised clocks

A timeline orders events from every source on one axis, which only works if every clock agrees. SP 800-86 states that correlating an event among multiple network traffic sources is easier and more effective if the clocks are in sync, and recommends NTP on all systems. A capture host 40 seconds fast places a packet after the log line that records its consequence.

Record each source's clock offset at acquisition: query the device for its time alongside a trusted reference and note the difference. Convert every timestamp to UTC with fractional seconds. Apply offsets as corrections in the case notes, never by editing the evidence files. A device with no time source gives relative order only.

05 /Evidence handling: acquire, preserve, document, analyse on copies

SP 800-86 describes handling steps that apply to any data source. Acquire with a documented method. Verify integrity by computing a message digest of the original and the copy and comparing them. Keep a master copy untouched and work on copies. Maintain a chain of custody: who handled which item, when, and why. Decide before collection begins whether the evidence may be needed for legal or disciplinary use.

Network records are usually already copies: a pcap on a capture host, a flow file on a collector, a log on a syslog server. Provenance therefore starts at the collector, whose clock, retention settings and access controls have to be shown to be sound. The mechanisms in hash chaining and signing for retained logs exist for this reason and apply equally to flow files, which are rarely protected at all.

06 /Worked example: a suspected data exfiltration

A partner reports that a document only your organisation held has appeared elsewhere. Did it leave over the network, from which host, when, and to where? There is no capture on the workstation VLAN. There are IPFIX records from the core, sFlow at 1 in 512 from the access switches, and syslog from the firewall, resolver and DHCP server, all kept for 90 days.

A flow query for outbound sessions above 20 MB in the previous fortnight returns eleven, ten to known backup and update destinations. The eleventh is the record shown above: 61 MB from 192.0.2.44 to 203.0.113.9 on port 443 over 319 seconds on 22 September. The firewall log corroborates the session, the byte count and the rule that allowed it. The resolver log shows the same host querying a name that answered 203.0.113.9 one second before the flow began. The DHCP log binds 192.0.2.44 to a MAC address leased since 08:52, and an sFlow sample from the access switch at 14:12 carries that MAC as source on port 1/1/17.

What the evidence proves: a specific workstation, on a specific switch port, sent 61 MB to that address in that window, and the firewall permitted it. What it does not prove: the content. The session was TLS; without a capture, and without the keys even with one, the bytes are opaque. The 61 MB is consistent with the file's size plus overhead, which is suggestive and no more; the report says so. Host forensics on the workstation comes next; the network evidence has narrowed it to one machine and one five-minute window.

07 /Pitfalls: gaps, clocks and self-serving records

• Treating a sample as a count. An sFlow stream at 1 in 512 with no packets for a host does not show the host was silent; a short flow can pass between samples. Samples estimate, flows count, captures prove.
• Trusting timestamps without recording offsets. Note each device's offset against a reference at acquisition and correct in the notes, never in the files.
• Losing the export. A congested link between exporter and collector silently drops UDP export records, and the gap looks like an absence of traffic. Check exporter sequence numbers for holes before reading anything into a quiet period.
• Investigating with the suspect's records. A log server the person under review could write to is a weak witness. Show in the custody record that the collector was not reachable by the accounts in question, or say plainly that it could not be.

The individual sources have their own pages here: taking and preserving a pcap with a custody record covers the capture side, a syslog pipeline whose lines can be trusted later covers the log side, and both assume time from an authenticated NTP source.

Network forensics depends on records made before anyone needed them and on handling that keeps their provenance intact. Keep flows and logs long, captures where they matter, clocks in sync, and a digest and custody entry for every file from acquisition onward.