NF0.2 The Five Network Evidence Types

Type 1 — Full Packet Capture (PCAP)

Full PCAP is the gold standard — and the most expensive. It captures every byte that crosses the sensor, giving you the ability to reconstruct anything that happened on the wire. Understanding when you need it and when you don't saves you from drowning in storage costs.

Full-packet capture records the complete content of every network frame — headers, payloads, and all protocol layers from Ethernet through the application layer. A PCAP file is a forensic image of the network, the same way a disk image is a forensic image of a drive. You can replay it, re-analyze it with different tools, extract files from it, and examine individual packets in detail.

The investigation value is unmatched. Need to extract the malware binary the attacker downloaded? It's in the PCAP. Need to see the exact HTTP POST that exfiltrated credentials? It's in the PCAP. Need to reconstruct a chat session the attacker had over IRC? It's in the PCAP. Any analysis you can do at the network level, you can do from PCAP — because PCAP is the raw data that every other evidence type is derived from.

The cost is equally unmatched. At a sustained 1 Gbps average throughput — common for a medium enterprise with 500-1000 users — full-packet capture generates approximately 10 TB per day. At 10 Gbps, it's 100 TB per day. Storage at that scale is expensive, and retention is measured in days to weeks, not months. Most organizations that run full-packet capture do it on specific segments (the DMZ, the internet egress point, the server VLAN) rather than everywhere, and they retain it for 3-7 days before the rolling capture overwrites the oldest data.

The critical constraint with PCAP is timing. If the attacker exfiltrated data 10 days ago and your PCAP retention is 7 days, the evidence is gone. PCAP answers any question you can think of — but only for the time window you still have. This is why Zeek metadata and DNS logs (which are small enough to retain for months) are often more operationally useful than PCAP for investigations that start days or weeks after the initial compromise.

There's a second constraint that matters increasingly in 2026: encryption. If the traffic is TLS-encrypted and you don't have the session keys, the PCAP shows you the TLS handshake (certificate, cipher suite, JA3 fingerprint) but not the application-layer content. You can see that DESKTOP-NGE042 connected to 203.0.113.88 on port 443 and transferred 2.3 GB, but you can't see the HTTP requests or the file contents. Module NF4 covers encrypted traffic investigation — what you can still see and what you can't.

Tools: tcpdump and dumpcap for capture, Wireshark and tshark for analysis, Arkime for enterprise-scale indexing and search.

Type 2 — Zeek Metadata Logs

Zeek is the evidence source you'll use most in this course. It gives you structured, queryable logs that answer 90% of investigation questions at 1% of the storage cost of full PCAP. If you deploy one network forensics tool, make it Zeek.

Zeek (formerly Bro) is a network security monitor that observes traffic and produces structured logs describing what it saw. Unlike PCAP, which records the raw bytes, Zeek parses the traffic at the application layer and produces human-readable logs organized by protocol and connection.

The core logs you'll work with throughout this course are conn.log, which records every TCP and UDP connection with source/destination IPs, ports, duration, byte counts, and connection state. Every connection the sensor sees gets a conn.log entry — this is your baseline for "what communicated with what." Then there's dns.log, recording every DNS query and response with the query name, query type, response code, and answers. This is the starting point for nearly every investigation. Zeek also produces http.log (HTTP requests and responses with method, host, URI, user-agent, response code), ssl.log (TLS handshake details including certificates, JA3 hashes, and server name indication), files.log (files observed in network traffic with hashes, MIME types, and sizes), smtp.log (email message metadata), smb_files.log and smb_mapping.log (SMB share access and file operations), ssh.log (SSH connection details including authentication results), and notice.log (Zeek's built-in detection findings).

The investigation value of Zeek logs comes from their structure and queryability. A conn.log entry tells you the five-tuple (src IP, src port, dst IP, dst port, protocol), when the connection started, how long it lasted, how many bytes each side sent, and how the connection ended. You can query this with command-line tools (zeek-cut, grep, awk) or ingest it into a SIEM. Finding all connections from a compromised host to external IPs during a specific time window is a one-line query.

Storage is the operational advantage. Zeek metadata for a 1 Gbps link produces roughly 10-15 GB per day — about 1% of what full PCAP would require. You can retain Zeek logs for months at reasonable cost, which means when an investigation starts three weeks after the initial compromise, the Zeek logs are still there. The PCAP probably isn't.

The limitation is that Zeek doesn't retain the raw packet content. If you need to extract a file the attacker downloaded, you need PCAP (or you can configure Zeek to extract files, but this increases storage significantly). If you need to see the exact payload of an HTTP POST, you need PCAP. Zeek tells you what happened at the protocol level — it doesn't give you the raw bytes.

Tools: Zeek for generation, zeek-cut for field extraction, jq for JSON-format logs, any SIEM for ingestion and querying.

Type 3 — IDS/IPS Alerts (Suricata)

Suricata alerts tell you that something matched a known-bad signature. They're fast, specific, and high-confidence for known attacks. They're also blind to anything that doesn't match a rule.

Suricata is a signature-based intrusion detection system (IDS) that inspects network traffic against a library of rules and generates alerts when traffic matches a known malicious pattern. A rule might match a specific HTTP user-agent string used by a malware family, a DNS query to a known C2 domain, a file hash of a known malicious binary, or a specific byte sequence in a network payload.

The investigation value is speed and specificity. When Suricata fires an alert, it tells you exactly which rule matched, what traffic triggered it, and what the rule was designed to detect. An alert for "ET MALWARE Cobalt Strike Beacon Activity" gives you immediate context — you know the attack framework, the technique, and the urgency. You don't need to analyze the traffic yourself to determine what it is.

Suricata integrates with Zeek through Community ID — a standardized hash that identifies the same network flow across different tools. When Suricata fires an alert on a connection, the Community ID lets you find the same connection in Zeek's conn.log, dns.log, and ssl.log for additional context. This correlation is fundamental to the investigation methodology in this course — Suricata tells you something bad happened, Zeek tells you everything else about the same session.

The limitation is coverage. Suricata only detects what it has a rule for. A novel attack technique, a custom C2 protocol, or a zero-day exploit that doesn't match any existing signature passes through Suricata undetected. This is why Suricata and Zeek work as a pair — Suricata catches known-bad, Zeek provides the data to hunt for unknown-bad.

Rule management is an operational concern. The Emerging Threats (ET) ruleset provides community-maintained rules that cover a wide range of threats. Organizations add custom rules for their specific environment. Rules need regular updates (suricata-update), performance tuning, and false positive management — all covered in NF8.

Tools: Suricata for detection, suricata-update for rule management, EVE JSON output for SIEM integration.

Type 4 — NetFlow and IPFIX

NetFlow tells you who talked to whom, for how long, and how much data was transferred — without any packet content. It's the evidence source that scales to the largest networks and answers exfiltration volume questions when PCAP isn't available.

NetFlow (Cisco) and IPFIX (the IETF standard) are flow-based records exported by routers, switches, and firewalls. A flow record captures the source and destination IP, source and destination port, protocol, byte count, packet count, start time, end time, and TCP flags — but no payload content. It's the network equivalent of phone metadata: you know who called whom, when, and for how long, but not what was said.

The investigation value is scale and retention. NetFlow records are tiny — a few hundred bytes per flow. A 10 Gbps enterprise link might generate 1-2 GB of NetFlow data per day, compared to 100 TB of PCAP. You can retain NetFlow for months or years at trivial cost. When the investigation question is "how much data left the network last Tuesday?" or "which internal hosts communicated with this IP over the past 6 months?" — NetFlow answers it.

Beaconing detection is a particularly strong use case for NetFlow. C2 beacons produce regular, periodic connections — every 60 seconds, every 5 minutes — with consistent packet sizes. These patterns are visible in flow data without needing to inspect the payload. Module NF10 covers beacon detection methodology using flow analytics.

The limitation is content blindness. NetFlow tells you that DESKTOP-NGE042 sent 500 MB to 203.0.113.88 over port 443. It doesn't tell you whether that was a legitimate cloud backup, a software update, or data exfiltration. You need Zeek metadata or PCAP to determine what the traffic actually was.

Cloud environments provide their own flow-log equivalent — AWS VPC Flow Logs, Azure NSG Flow Logs, GCP VPC Flow Logs. These capture similar metadata for cloud workloads and are often the only network evidence available in cloud-native environments where you can't deploy a packet capture sensor.

Tools: nfdump, SiLK, ntopng for analysis. Router/switch configuration for export. Cloud provider consoles for VPC flow logs.

Type 5 — DNS Logs

DNS is the evidence source you always start with. Every network communication begins with a DNS query, and DNS logs are available in almost every environment — even ones without dedicated network security monitoring.

DNS logs record every name resolution request and response that crosses the sensor or resolver. A DNS log entry captures the query name (what domain was looked up), the query type (A, AAAA, CNAME, MX, TXT, etc.), the response code (NOERROR, NXDOMAIN, SERVFAIL), the answers (IP addresses, CNAME targets), and the TTL.

The investigation value is universality. The attacker's C2 domain had to be resolved before the first connection was made. The phishing URL had to be resolved before the user clicked it. The exfiltration endpoint had to be resolved before data was transferred. DNS is the first step in almost every attack chain, and DNS logs capture it.

DNS-specific investigations are a major topic in this course. Module NF3 is devoted entirely to DNS analytics: tunneling detection (attackers encoding data in DNS queries to exfiltrate through DNS), passive DNS analysis (building a historical picture of domain-to-IP mappings), domain generation algorithm (DGA) detection, and the challenges that DNS-over-HTTPS and DNS-over-TLS create for investigators.

DNS logs can come from multiple sources: Zeek's dns.log (captured at the sensor), your organization's DNS resolver logs (Windows DNS, BIND, Unbound), or cloud DNS analytics (Route 53 query logs, Azure DNS analytics). Each captures DNS from a different vantage point — the sensor sees queries on the wire, the resolver sees queries from clients, cloud DNS sees queries for your hosted zones.

The limitation is scope — DNS tells you what was resolved but not what happened after the connection was established. Seeing a DNS query for microsft-verify[.]com tells you the phishing domain was resolved. You need conn.log or PCAP to see what happened in the connection that followed.

Tools: Zeek dns.log, DNS resolver logging, passive DNS databases (passivedns, Farsight DNSDB for commercial investigations).