Network Forensics Mindset
Network forensics answers the question: "What happened on the wire?" Before touching a single packet, you need a mental model of what kinds of evidence exist, what each kind can and cannot tell you, and how to structure an investigation that produces defensible conclusions. This chapter builds that foundation.
An alert fires: GuardDuty detected a known C2 IP communicating with an EC2 instance. Management wants to know: Was data exfiltrated? How long has this been going on? What else did the attacker access? You have VPC Flow Logs from the last 90 days, Zeek conn.log from the last 30 days, and 7 days of full PCAP from an Arkime deployment. Each evidence source answers different questions. Knowing which to reach for first — and what each source cannot tell you — determines how fast you get answers.
The Network Evidence Hierarchy
Network Evidence Types — Richness vs Retention Trade-off ═══════════════════════════════════════════════════════════════════ Most detail Hardest to retain ↑ ↑ │ Full Packet Capture (PCAP) │ ├── Every byte of every packet, including payload │ ├── Reconstruct file transfers, credentials, commands │ ├── Ground truth for all other evidence │ └── Typical retention: 1–7 days (1 Gbps = ~4 TB/day) │ │ Application-layer logs (Zeek, proxy, DNS resolver) │ ├── Layer 7 fields: HTTP host/URI/UA, DNS query/answer, TLS SNI │ ├── File hashes (Zeek files.log), certificate subjects (x509.log) │ ├── No payload reconstruction, but all metadata │ └── Typical retention: 30–90 days │ │ Flow records (NetFlow, IPFIX, VPC Flow Logs) │ ├── 5-tuple + timestamps + byte/packet counts + TCP flags │ ├── No application layer, no payload, no L7 decoding │ ├── Who talked to whom, when, for how long, how much data │ └── Typical retention: 90–365 days │ ↓ Firewall / NAT logs (connection-level) Least detail Easiest to retain ├── Source/dest IP, port, action (ACCEPT/DROP), interface └── Typically only allowed connections are logged Key insight: each layer answers different questions. Full PCAP answers "what did they do?" Flow records answer "who talked to whom and when?" You need BOTH for a complete investigation.
Full packet capture is the only network evidence type that lets you reconstruct exact application-layer behavior: what file was transferred, what credentials were sent, what commands the attacker typed in a reverse shell. Everything else — flow records, Zeek logs, IDS alerts — is derived from PCAP at collection time. If your flow records say a host exfiltrated 100 MB to an external IP, you can only know what those 100 MB contained if you have the PCAP. But at 1 Gbps line rate, full PCAP costs ~4 TB/day in storage. Most environments can afford 7 days. The art of network forensics is knowing when you need the PCAP and getting to it before it rolls over.
What Network Evidence Can and Cannot Prove
| Question | Full PCAP | Zeek/NDR logs | Flow records |
|---|---|---|---|
| Was data exfiltrated? | Yes — reconstruct exact files transferred | Partial — file hashes and MIME types if unencrypted | Volume only — "100 MB outbound" but not content |
| What C2 domain was used? | Yes — DNS query in packet, TLS SNI | Yes — dns.log and ssl.log | No — only destination IP, not hostname |
| Was traffic encrypted? | Yes — TLS handshake visible | Yes — ssl.log records cipher/version | No — only port 443, not whether TLS was used |
| How long was C2 active? | Limited by retention (days) | Yes — conn.log duration field | Yes — session start/end timestamps (90+ days) |
| Was there lateral movement? | Yes — full SMB/RDP session content | Yes — smb_files.log, kerberos.log | Partial — new internal connections detectable |
| Which user authenticated? | Yes — NTLM/Kerberos username in packet | Yes — kerberos.log client field | No — only IP addresses |
| Beaconing pattern? | Yes — sub-second precision | Yes — conn.log timestamps | Yes — flow start times (limited precision) |
The Network Forensics Investigation Workflow
Network Forensics Investigation Phases ═══════════════════════════════════════════════════════════════════ Phase 1: Triage (answer: "is this real and how bad?") ├── Review the triggering alert: what IOC, what confidence ├── Check flow records for the suspicious IP: first seen, total volume ├── Check NDR/Zeek logs: what protocol, what application layer └── Decision: escalate to full investigation or close Phase 2: Scope (answer: "what hosts, what time window?") ├── Expand the IOC to find all hosts communicating with it ├── Check for lateral movement from the initial host ├── Establish the earliest evidence timestamp └── Identify: which PCAP archives cover this window? Phase 3: Deep Analysis (answer: "what exactly happened?") ├── Load PCAP into Wireshark / Arkime ├── Reconstruct each session: C2 beaconing, file transfers, commands ├── Extract artifacts: malware samples, credentials, staging commands └── Build a second-precision timeline of attacker actions Phase 4: Reporting (answer: "what do we say?") ├── Document evidence chain: what tool, which file, which timestamp ├── Map to MITRE ATT&CK techniques ├── Produce IOC list (IPs, domains, JA3, certificate fingerprints) └── Recommend containment actions with evidence basis Key principle: start wide (flow records, 90 days) and narrow to PCAP only for the specific time window and hosts you've scoped. Full PCAP analysis of irrelevant traffic is wasted time and rolling-window risk.
Network forensics tells you behaviors: what protocol they used, what data they moved, when they checked in. It almost never tells you who the attacker is — IP addresses are trivially proxied, TLS certificates are generated in seconds, and tool fingerprints are spoofed by skilled operators. Keep this scope clearly in mind during an investigation. Your job in the network forensics phase is to answer: what happened, when did it start, what did they access, and what did they take. Attribution is a separate discipline that uses network evidence as one input alongside endpoint telemetry, threat intelligence, and TTPs.
Critical Limitations to State in Every Report
| Limitation | Why it matters | How to note it |
|---|---|---|
| Encrypted traffic | TLS payload is unreadable without keys — file content, credentials, commands unknown | "Traffic to [IP] was TLS-encrypted. Payload content could not be analyzed. Volume and timing were analyzed." |
| PCAP retention gap | Attack may predate your full-packet retention window | "PCAP available from [date]. Earlier activity assessed from flow records only — application-layer details unavailable for earlier period." |
| NAT / shared IP | A single external IP seen in logs may be a Tor exit, VPN, or CDN shared by many users | "Destination IP is a known Tor exit node. This IP is shared by thousands of users; traffic to this IP is suspicious but not definitively malicious based on IP alone." |
| Clock skew between hosts | Multi-host correlation off by seconds or minutes | Document NTP status of capture host; note skew estimate in timeline construction |
Q & A
Q: Which evidence source should I start with when I get a new network alert?
Start with flow records or NDR metadata, not PCAP. Flow records and Zeek logs cover the longest time window and let you scope the incident cheaply before committing to full PCAP analysis. Specifically: (1) Check how long the IOC has been seen — flow records at 90 days cover what PCAP at 7 days cannot. (2) Check all hosts communicating with the IOC — your initial alert may be one of twenty affected hosts. (3) Estimate the data volume transferred — if flow records show 1 MB total over 30 days, this may be C2 check-ins without exfiltration. (4) Only then pull PCAP — load the specific time window for the specific host(s) you've identified. This prevents spending 3 hours analyzing PCAP for a host that turned out to be irrelevant to the compromise.