In this module
NF0.4 The Investigation Methodology
You follow an investigation methodology on the endpoint — SANS IR process, NIST 800-61, or your organization's runbook. You know the value of a systematic approach: it prevents tunnel vision, ensures evidence preservation, and produces repeatable results. This sub introduces the network-specific investigation methodology that structures every paid module in this course.
Network evidence is overwhelming without methodology. A Zeek conn.log for a busy enterprise link contains millions of entries per day. A full PCAP capture is terabytes. If you start reading packets without a plan, you'll spend hours examining legitimate traffic while the attacker's C2 channel sits in the data unexamined. The investigator who opens Wireshark and starts scrolling through packets is the investigator who runs out of time before finding the evidence.
Network investigation requires a structured approach that starts with the broadest, cheapest evidence (DNS logs and connection metadata), narrows to specific sessions of interest, and only drops to packet-level analysis when the investigation question demands it. This sub introduces the six-step Network Investigation Methodology that runs through every module in this course.
Deliverable: The six-step Network Investigation Methodology — Scope → Identify → Correlate → Reconstruct → Attribute → Report — with the specific evidence sources and tools used at each step. A worked example applying the methodology to an NE incident.
Figure NF0.4 — The six-step Network Investigation Methodology. Each step uses progressively more detailed evidence sources. Steps 1-2 use metadata (fast, cheap). Steps 3-4 use cross-log correlation and PCAP (detailed, targeted). Steps 5-6 synthesize findings into attribution and reporting.
Step 1 — Scope
Define the investigation boundaries before touching any data. Without scope, you'll drown in the volume of network evidence.
Scoping establishes three parameters: the time window (when did the activity of interest occur?), the hosts involved (which IPs and hostnames are in scope?), and the indicators of compromise (IOCs) already known (domains, IPs, file hashes, certificate fingerprints).
Scoping for network investigation is tighter than for endpoint investigation because the data volumes are larger. On an endpoint, you can examine all activity for a compromised host over a 30-day window — it's manageable. On the network, all activity for a busy enterprise link over 30 days is millions of connections. You need to narrow before you search.
The scoping question framework: What triggered this investigation? (An alert, a report, a hunting finding.) Which hosts are known-affected? (From endpoint investigation, EDR telemetry, or the alert itself.) What time window covers the known activity? (From endpoint timestamps, alert timestamps, or intelligence reports.) What IOCs do you already have? (IPs, domains, file hashes from the trigger.) These four answers define your initial search space in Zeek logs.
Step 2 — Identify
Find the network sessions related to the incident. Start with the cheapest evidence — DNS and connection metadata.
Identification uses Zeek metadata to find the network activity that matters. The entry point depends on what you have from scoping. If you have an IP address, query conn.log for all connections involving that IP. If you have a domain, query dns.log for resolution records and then pivot to conn.log for the resulting connections. If you have a time window and a host, query conn.log for all external connections from that host during the window.
The key principle: start broad with metadata, then narrow. A query against conn.log for all connections from the compromised host to external IPs during the dwell time might return thousands of entries. Filter by unusual ports, high byte counts, long durations, or connections to IPs in threat intelligence feeds. The goal is to identify the specific sessions that warrant deeper analysis — not to examine every packet.
Check Suricata alerts for the same time window and hosts. Suricata may have flagged specific sessions that conn.log alone wouldn't highlight — known malware signatures, C2 beacon patterns, or exploit traffic.
Step 3 — Correlate
Connect network evidence across tools and across evidence sources. This is where Community ID and endpoint-network pivoting come together.
Correlation links evidence from different sources for the same activity. Zeek and Suricata both support Community ID — a standardized flow hash that uniquely identifies a network session. When Suricata fires an alert for "ET MALWARE Cobalt Strike" on Community ID 1:abc123..., you can find the same session in Zeek's conn.log, dns.log (the DNS query that preceded it), and ssl.log (the TLS certificate details) using the same Community ID.
Cross-source correlation extends to endpoint evidence. A Zeek conn.log entry showing a connection from 10.0.1.42 to 203.0.113.88 at 14:22:15 UTC can be correlated with a Defender XDR DeviceNetworkEvents entry for the same connection on DESKTOP-NGE042. The endpoint tells you which process made the connection (powershell.exe, svchost.exe, chrome.exe). The network tells you what the connection did (byte counts, TLS fingerprint, duration). Together, they give you the complete picture.
If you've completed the Practical IR course on this platform, you've used KQL against DeviceNetworkEvents. This course teaches you to find the same events in Zeek logs and add the network-layer context that endpoint telemetry doesn't capture.
Step 4 — Reconstruct
Build the detailed picture of what happened in the sessions you've identified. This is where PCAP and deep protocol analysis come in.
Reconstruction takes the sessions identified in steps 2-3 and examines them in detail. For unencrypted protocols, this means examining the HTTP requests and responses, extracting transferred files, and reading the application-layer content. For encrypted protocols, it means analyzing the TLS handshake (certificate details, JA3/JA4 fingerprint, cipher suite) and the connection behavior (beacon pattern, data volumes, timing).
The tools shift at this step. Steps 1-3 primarily use command-line queries against Zeek logs (zeek-cut, grep, awk, jq). Step 4 brings in Wireshark/tshark for PCAP analysis, NetworkMiner for object extraction, and protocol-specific analysis techniques covered in modules NF3-NF7.
Timeline building is the reconstruction output. You're assembling a chronological record of the attacker's network activity: first DNS query → first connection → C2 establishment → lateral movement sessions → data staging → exfiltration → detection. Each entry has a timestamp, source, destination, protocol, evidence source (which Zeek log or PCAP file), and investigative significance.
Step 5 — Attribute
Characterize the attacker's infrastructure and techniques from the network evidence. This isn't about naming the threat group — it's about understanding what they used and how.
Attribution in network forensics means mapping the attacker's infrastructure: which external IPs and domains they used, what C2 framework they deployed (identifiable from JA3/JA4 fingerprints, beacon patterns, and TLS certificates), what tools they used for lateral movement and exfiltration (identifiable from protocol behavior), and how sophisticated their operational security was.
The output is an infrastructure diagram: attacker IP A hosted the phishing page, attacker IP B ran the C2 server (Cobalt Strike, based on JA3 hash and beacon timing), attacker IP C received the exfiltrated data (rclone to Tor relay, based on user-agent and connection pattern). Each attribution carries a confidence level based on the evidence quality.
This step also identifies TTPs (Tactics, Techniques, and Procedures) from the MITRE ATT&CK framework. Network evidence maps directly to ATT&CK techniques: DNS tunneling (T1071.004), Remote Services via SSH (T1021.004), Exfiltration Over C2 Channel (T1041), Application Layer Protocol (T1071). Documenting TTPs supports threat intelligence sharing and future detection rule development.
Step 6 — Report
Document findings, evidence chain, and methodology. The report serves the CISO, legal, and your future self.
The network forensic report has three audiences. The CISO needs the executive summary: what happened, what was the impact, what's the risk. Legal needs the evidence chain: which evidence sources were examined, how they were preserved, what they showed. The SOC team needs the technical detail: specific Zeek queries, PCAP analysis results, IOCs for detection.
Every finding in the report links back to specific evidence: "Exfiltration of 12.1 GB detected" links to Zeek conn.log entry [timestamp, uid, IPs], which can be verified by anyone with access to the same data. Unreproducible findings aren't evidence.
During Step 2 of the INC-NE-2026-0418 investigation, you identify 47 external connections from IT03-NGE during the 3-day scope window. Most are to known Microsoft/Azure IPs (Office 365 traffic). Three connections stand out: repeated connections to 185.193.125.44 on port 443 with a consistent 60-second interval and low byte counts (300-500 bytes each direction). One connection to the same IP on port 443 with 12.1 GB outbound.
The repeated connections look like C2 beaconing — the consistent interval and low byte count match the pattern. The large transfer looks like exfiltration — 12.1 GB is far more than normal HTTPS browsing.
You need to decide: do you immediately pivot to the C2 investigation (characterize the beacon, identify all hosts communicating with 185.193.125.44) or do you first investigate the exfiltration (what data was in the 12.1 GB transfer)?
The methodology says: investigate the C2 channel first. The C2 channel tells you the scope of the compromise — every host beaconing to that IP is compromised. The exfiltration tells you the impact, but only for one host. Scoping the compromise first prevents you from writing a report about one host's data loss while missing three other compromised systems that are still beaconing.
Wireshark is a packet analysis tool. Network forensics is an investigation discipline. The difference is the same as the difference between opening Registry Editor and doing registry forensics — the tool provides access to the data, the methodology determines what you find.
An investigator who opens a 50 GB PCAP file in Wireshark and starts scrolling will find individual packets. An investigator who follows the methodology will start with Zeek metadata to identify the 3 sessions out of 2 million that matter, then use Wireshark to examine only those sessions. The first approach takes days and misses evidence. The second takes hours and answers the investigation question.
Wireshark appears in Step 4 of the methodology — reconstruction. It's the wrong tool for Steps 1-3. You don't read packets to scope an investigation or identify sessions of interest. You query structured metadata. PCAP is the evidence of last resort — not the starting point.
Try it: Apply the methodology to your last investigation
Setup. Think of the most recent security incident you investigated (or use INC-NE-2026-0418 if you haven't worked a real case).
Task. Walk the six steps: what was the scope? What would you identify from network evidence? What correlation opportunities existed between network and endpoint data? What reconstruction would have required PCAP? What attribution could you make from the attacker's network infrastructure? What would the network-specific findings in the report look like?
Expected result. You should be able to walk at least steps 1-3 for any incident. Steps 4-6 require network evidence that you may not have had — and that's the point. The gap between what you could have found with network evidence and what you actually found is the operational value this course builds.
Debugging branch. If you can't identify what network evidence would have been useful: go back to NF0.1's four scenarios and ask which one your incident most resembled. Was the disk encrypted (network evidence would have shown the pre-encryption activity)? Were logs cleared (Zeek would have recorded the connections)? Was the attack fileless (the C2 channel would have been visible)?
You've built the sensor and mapped the evidence landscape.
NF0 established why network evidence matters when every other source is compromised. NF1 built your Zeek + Suricata sensor with the 10 investigation query patterns. From here, every module teaches protocol-specific investigation against real attack scenarios.
- DNS deep dive (NF3) — tunnelling detection, DGA analysis, passive DNS infrastructure mapping, and the INC-NE-2026-0227 AiTM phishing DNS trail
- Protocol analysis (NF4–NF7) — HTTP/HTTPS, SMB lateral movement, SSH tunnelling, and email protocol investigation with Zeek metadata and PCAP
- Detection and hunting (NF8–NF11) — Suricata rule writing, C2 beacon detection with JA3, NetFlow analytics, and proactive network threat hunting
- NSM architecture (NF13) — production sensor deployment at 1–10 Gbps with Arkime, Security Onion, and enterprise storage planning
- INC-NE-2026-0830 capstone (NF14) — multi-stage investigation using only network evidence: phishing → domain-fronted C2 → lateral movement → DNS tunnel exfiltration
Cancel anytime