Network Forensics Guide: Capture and Analyse Traffic

Network evidence is the one record of an intrusion that the attacker does not control on the compromised host, yet most organisations discover during an incident that they kept too little of it, for too short a time, in a form nobody can search. Edge appliances that cannot run EDR, log wiping on servers and encrypted command and control all push investigators back to what crossed the wire. This guide covers the evidence sources (full packet capture, network security monitoring logs, flow records and device logs), how to design capture and retention, how to analyse traffic with Zeek, Suricata and Arkime, how to keep the evidence defensible, and how to measure the capability. It is for DFIR analysts, network security engineers and SOC leads who need network evidence that answers questions after the fact.

Key takeaways

Layer your evidence. Keep a short window of full packets, a longer window of protocol metadata and the longest window of flow records, because each answers different questions at different cost.
Metadata solves most cases. Connection, DNS, TLS and HTTP logs from a network security monitor answer who talked to whom, when and how much, long after packets have rolled off disk.
Encryption changes the question, not the value. With TLS 1.3 and encrypted DNS you analyse timing, volume, certificates, fingerprints and destinations rather than content.
Sensors must see the right traffic. East-west, cloud and remote access paths are where attackers move, and the places most often left unmonitored.
Integrity and time matter as much as content. Hash exported packets, synchronise sensor clocks and record chain of custody so findings stand up in a review, insurance claim or court.

What network forensics covers

NIST SP 800-86 treats network traffic as one of four major data source groups alongside files, operating systems and applications, and lists firewalls and routers, packet sniffers and protocol analysers, intrusion detection systems, remote access servers, security event management software and network forensic analysis tools as sources. RFC 3227 places remote logging and monitoring data below memory and disk in the order of volatility, but on a busy link a ring buffer of packets can be overwritten in hours, so in practice network evidence must be preserved as soon as an incident is declared.

Network forensics differs from network monitoring in purpose rather than tooling. Monitoring asks "is something bad happening now?"; forensics asks "what exactly happened, from when, and how far did it go?" The same sensors serve both if retention and integrity are designed for the second question. See the Network Monitoring and Packet Capture Guide and the NDR Guide for the detection side.

Evidence sources compared

Source	What it records	Typical retention	Best for	Limits
Full packet capture (PCAP or pcapng)	Every byte of selected traffic	Days, sized by disk	Reconstructing sessions and files, proving exactly what was sent, extracting payloads for analysis	Storage cost; encrypted content unreadable without keys
NSM protocol logs (for example Zeek)	Connections, DNS queries, HTTP requests, TLS handshakes, certificates, files seen, SMB, Kerberos, SSH	Months	Scoping, timelines, hunting across long periods	Only what the analysers parse; gaps if packets were dropped
IDS alerts and EVE records (for example Suricata)	Signature matches, flows, protocol transactions, file info, anomalies	Months	Known-bad detection with context, alert-triggered packet logging	Signature coverage; volume needs tuning
Flow records (NetFlow v9, IPFIX, cloud flow logs)	Five-tuple, byte and packet counts, timestamps	Months to a year or more	Lateral movement and exfiltration volume, cheap long-term baseline	No content or application detail; sampling hides small flows
Device logs (firewall, proxy, VPN, DNS resolver, load balancer)	Allowed and denied connections, user and URL, VPN sessions, resolutions	Per log policy	Attribution to users and accounts, egress and remote access	Vendor formats; edge devices may be the compromised asset

IPFIX is specified in RFC 7011 (an Internet Standard) and runs over SCTP, TCP or UDP; its version number is the NetFlow v9 number incremented by one, which reflects its lineage. Cloud providers expose their own flow logs; see the Cloud Forensics Guide.

Designing capture and retention

Sensor placement

Internet egress and ingress: behind the perimeter firewall or proxy, where command and control and exfiltration leave the network.
Remote access and edge devices: on the inside interface of VPN concentrators and other appliances. These devices often cannot run EDR, so network evidence is frequently the only independent record. See the Edge Device Security Guide.
Core and data centre east-west: between user segments and server or domain controller segments, where SMB, RPC, Kerberos and remote management traffic show lateral movement.
Cloud: in AWS, VPC Traffic Mirroring copies traffic from an elastic network interface to a target (an instance, a Network Load Balancer fleet or a Gateway Load Balancer fleet with a UDP listener), with filters to choose traffic and optional packet truncation. Sessions are charged hourly until deleted, even if the source is stopped, so manage them as part of the capability.

Retention tiers and sizing

The Arkime documentation estimates that uncompressed traffic at 1 Gbps uses about 11 TB per day, and that session metadata (SPI data) needs roughly 5% of the PCAP storage for the same period. That arithmetic is why full packet retention is usually measured in days and metadata in months.

Tier	Example retention target	Sizing driver	Cost control
Full packets	3 to 14 days on critical links	Sustained throughput times days	Exclude bulk backup and streaming traffic; truncate or stop capturing TLS sessions after the handshake; capture only alert-linked flows on less critical links
Protocol metadata	90 to 400 days	Connections per second and protocols logged	Compress, tier to cheaper storage, drop noisy low-value logs
Flow records	Up to 13 months or longer	Flows per second	Aggregate; keep unsampled on key links
Exported case evidence	Case lifetime plus legal retention	Size of extracts	Export only relevant flows, hash and store immutably

Retention targets should come from your dwell-time reality and legal requirements rather than a default. If investigations routinely start weeks after intrusion, a seven-day packet buffer is only useful for live incidents, and metadata retention carries the historical burden. See the Log Management and Retention Guide.

Capture configuration that matters later

Suricata conditional packet logging: the pcap-log output supports a ring buffer (limit per file and max-files), lz4 compression, and a conditional setting of all, alerts or tag so that only alerted or tagged flows are kept where full capture is too expensive. It is disabled by default.
Community ID: enable the Community ID flow hash in both Zeek and Suricata (in Suricata the community-id option defaults to false, and the seed must match across all sensors). It turns a pivot between tools into a string match.
Arkime retention: Arkime deletes old PCAP automatically as disk fills, but session metadata in OpenSearch or Elasticsearch is not expired automatically and needs a lifecycle policy. Deleting one does not delete the other, so track both against your retention policy.
Capture loss: monitor dropped packets at the sensor and missed bytes in the analysers. Zeek's capture_loss.log and the missed_bytes field in conn.log show where analysis is unreliable.

Analysing network evidence

Start from metadata, then go to packets

Zeek writes one log per protocol and links them with a connection uid; files seen in traffic get a fuid in files.log tied back to the connection. The conn.log fields carry most of the first-pass analysis.

Zeek conn.log field or value	Meaning (from the Zeek source)	Forensic use
`conn_state` S0	Connection attempt seen, no reply	Scanning or blocked beaconing
`conn_state` SF	Normal establishment and termination	Completed sessions to check for volume and duration
`conn_state` REJ	Connection attempt rejected	Port sweeps against internal hosts
`conn_state` OTH	No SYN seen, midstream traffic	Long-lived sessions predating capture, or asymmetric routing
`history`	Letters for SYN, SYN-ACK, data, FIN, RST and gaps; upper case from originator, lower case from responder	Reconstructing who started and who ended a session
`orig_bytes` / `resp_bytes`	Payload bytes sent by each side	Outbound-heavy sessions suggest exfiltration
`missed_bytes`	Bytes missed in content gaps, representative of packet loss	Flags where protocol analysis may be incomplete
`local_orig` / `local_resp`	Whether each side is in `Site::local_nets`	Quick internal versus external filter (empty unless local networks are defined)

Questions, evidence and techniques

Question	Where to look	ATT&CK technique
How did they get in?	HTTP and TLS logs and packets to the exposed service around first activity	T1190 Exploit Public-Facing Application
Is there beaconing?	Regular intervals and consistent sizes in conn.log to the same destination; JA4 or JA3 fingerprints in TLS logs	T1071.001 Web Protocols, T1573 Encrypted Channel
Is DNS being abused?	Long or high-entropy query names, high query volume to one domain, TXT-heavy responses in dns.log	T1071.004 DNS
Is traffic hidden inside another protocol?	Protocol mismatches in Zeek's analyzer and weird logs, services on unexpected ports	T1572 Protocol Tunneling, T1571 Non-Standard Port
Did they move laterally?	SMB, DCE-RPC, Kerberos, NTLM and RDP logs between workstations and servers	T1021.002 SMB/Windows Admin Shares
What left the network and how much?	Outbound byte totals per destination from conn.log and flows; files.log; proxy logs	T1041 Exfiltration Over C2 Channel, T1048 Exfiltration Over Alternative Protocol
Was traffic intercepted or relayed?	ARP and DHCP anomalies, certificate changes in x509 logs, proxies in the path	T1557 Adversary-in-the-Middle, T1090 Proxy

Working with encrypted traffic

Handshake metadata: server name, certificate subject and issuer, validity dates and fingerprints remain visible in many TLS sessions and are logged by Zeek (ssl.log, x509.log) and Suricata (tls events). Encrypted Client Hello, where used, hides the server name.
Fingerprints: the JA4+ suite (FoxIO) defines client, server, HTTP, certificate, SSH and TCP fingerprints for grouping tooling across IP changes. Check the licence terms of each method before building it into products.
Decryption where lawful and designed: TLS inspection proxies and server-side key logging can make content available, but must be agreed with legal, privacy and system owners in advance, never improvised during an incident.
Endpoint correlation: pair network findings with EDR process telemetry to tie a flow to a process and user. See the Endpoint Security Guide.

A defensible collection procedure

Freeze the window. When an incident is declared, stop ring buffers from overwriting the relevant period: copy the PCAP files for the affected window and relevant sensors to evidence storage, and extend metadata retention for the case.
Record sensor context. Note sensor name, interface, tap or SPAN source, capture filter, software versions and any known capture loss for the period.
Check time. Confirm sensor clocks against a trusted NTP source and record any offset. RFC 3227 asks for UTC or local time to be stated in notes with any clock difference.
Extract narrowly, keep the original. Export the flows of interest for analysis, but preserve the original files unchanged. Analysis tools work on copies.
Hash and log custody. Hash every exported file (SHA-256) at collection and on each transfer, and keep a chain of custody record of who handled it, when, where it was stored and how it moved.
Collect device logs from outside the device. Pull firewall, VPN and proxy logs from the central log platform rather than only from an appliance that may be compromised or may have been wiped.
Feed findings back. Turn indicators into Suricata rules, Zeek intelligence entries and SIEM searches, and hunt across the full metadata retention period. See the Threat Hunting Guide.

Rolling out the capability: start with one egress sensor running Zeek and Suricata in detection-only mode, prove retention and search, add east-west and remote access sensors, then add full packet capture on the links that matter most. Test with a scheduled exercise that asks a real question ("which hosts talked to this IP last month?") and time the answer. If a sensor degrades production (a SPAN port oversubscribed, a mirroring session costing more than planned), remove it from the path and fall back to flow logs while you resize.

Where identity fits

Network evidence becomes most useful when flows map to accounts. VPN, proxy and Kerberos logs connect an IP address at a time to a user or service account, and Zeek's NTLM, Kerberos and SSH logs show which accounts authenticated where. Cleartext or weakly protected credentials seen in traffic (basic authentication, API keys in URLs or headers on internal HTTP) are themselves a finding: they must be rotated, and the systems sending them fixed. The packet store also holds those secrets, which is one more reason to restrict and audit access to it. In the Ivanti Connect Secure exploitation in 2024, attackers captured credentials at the gateway and moved into internal networks; the page's lessons include off-box logging and network monitoring around such appliances, because the appliance's own integrity checking could not be relied on. See the Identity Incident Response Playbook.

Detection and measurement

Visibility coverage: percentage of internet egress points, remote access gateways and critical server segments with a working sensor.
Capture health: packet drop rate per sensor and the share of connections with non-zero missed_bytes; alert when either rises.
Retention achieved versus target: actual days of packets, metadata and flows available per tier, measured weekly, not assumed.
Time to answer: minutes to answer a standard scoping question across the full metadata window during exercises.
Evidence freeze time: time from incident declaration to relevant PCAP being preserved before overwrite.
Findings yield: share of incidents where network evidence established initial access, scope or exfiltration volume.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	DE.CM-01	Networks and network services are monitored to find potentially adverse events
NIST CSF 2.0	RS.AN-03, RS.AN-07	Root cause analysis; incident data collected with integrity and provenance preserved
NIST CSF 2.0	RS.AN-08	Magnitude estimated and validated, for example exfiltration volume
NIST SP 800-53 Rev. 5	SI-4, SI-4(4)	System monitoring, including inbound and outbound communications traffic
NIST SP 800-53 Rev. 5	AU-8, AU-9, AU-11	Time stamps, protection of audit information and retention
NIST SP 800-53 Rev. 5	IR-4	Incident handling, including analysis
MITRE D3FEND	D3-NTA, D3-PMAD, D3-DNSTA, D3-PCA, D3-FC	Network traffic analysis, protocol metadata anomaly detection, DNS traffic analysis, passive certificate analysis, file carving

Common failure patterns

Packets roll off before anyone asks: a ring buffer of a few days is overwritten while the incident is being triaged. Make "freeze network evidence" an early step in the incident response plan.
Only the perimeter is watched: lateral movement over SMB and RPC between internal segments is invisible because sensors sit only at egress.
Edge appliance logs kept only on the appliance: when the VPN gateway is the compromised device, its local logs cannot be trusted or have been cleared. Forward them off the box.
Silent capture loss: an oversubscribed SPAN port drops packets under load, and analysis conclusions ("no exfiltration seen") are drawn from incomplete data.
Unsynchronised clocks: sensor, firewall and endpoint times disagree by minutes, so timelines contradict each other and correlation fails.
Metadata never expired or never kept: Arkime or SIEM indices fill up and crash, or retention was never configured, leaving either an outage or a gap.

Practitioner checklist

Map egress, remote access, east-west and cloud traffic paths, and record which have sensors and which do not.
Run Zeek and Suricata (or equivalents) with Community ID enabled and a shared seed across all sensors.
Set retention targets per tier (packets, metadata, flows) from dwell-time data and legal advice, and measure achieved retention weekly.
Configure conditional packet logging for alerted flows where full capture is too costly.
Synchronise all sensors and network devices to a trusted time source and monitor drift.
Add an evidence freeze step (preserve PCAP, extend metadata retention) to incident response playbooks.
Hash and record chain of custody for every exported capture, and restrict packet store access to named analysts.
Forward edge device, VPN and proxy logs to central storage the devices cannot alter.
Monitor packet drop and missed bytes and treat sustained loss as an incident for the capability.
Exercise the capability quarterly with a real scoping question and time the answer.

Network Forensics Guide: Capturing and Analysing Network Evidence