NF0.1 Why Network Evidence Matters

When Endpoint Evidence Fails

The four scenarios below are the cases where your current methodology hits a wall. They're not edge cases — they're the incidents that reach the CISO's desk because the investigation couldn't answer the critical question from endpoint evidence alone.

Every investigation starts with the same question: what happened? The endpoint tells you what happened on the system — which processes ran, which files changed, which registry keys were modified. The identity layer tells you who authenticated and what they accessed. But neither tells you what the attacker's infrastructure looked like, how much data left the network, what C2 channel maintained their access, or which external domains were involved.

The network answers those questions because the network was the medium. The attacker's commands traveled over it. The exfiltrated data traveled over it. The phishing URL resolved through it. The C2 beacon checked in through it. And unlike disk artifacts, network evidence is often recorded on a separate system — your NSM sensor, your firewall, your proxy logs — that the attacker didn't compromise and couldn't modify.

Scenario 1 — The encrypted disk

The ransomware hit FIN01-NGE at 06:00 UTC on April 18, 2026. By the time the SOC responded at 06:45, the ERP database was encrypted and the attacker's note demanded 50 BTC. The disk is useless for forensics — every file the investigator needs is behind AES-256 encryption the attacker controls.

But the network saw everything that preceded the encryption. Three days of PsExec lateral movement from IT03-NGE. The rclone binary transferring 47 GB to a Tor relay at 185.193.125.44. The Cobalt Strike beacon checking in every 60 seconds with 10% jitter to a domain-fronted HTTPS endpoint. The DNS queries that resolved the attacker's staging infrastructure. The SMB share mapping that connected the attacker to the file server where they staged the data before exfiltrating it.

The disk is gone. The network evidence reconstructs the entire three-day attack chain.

Scenario 2 — The cleared logs

The attacker ran wevtutil cl Security on every compromised host before disconnecting. The Windows Event Logs that would have shown the authentication timeline, the process creation events, the service installations — all gone. The attacker knew what the IR team would look for and deleted it.

But Zeek's conn.log recorded every TCP and UDP connection those hosts made during the attacker's dwell time. The dns.log recorded every domain resolution. The ssl.log recorded every TLS handshake, including the certificate details of the C2 server. The Suricata alerts recorded the PsExec service installation traffic pattern. None of this data was on the compromised hosts — it was on the NSM sensor, which the attacker never touched.

The logs are cleared. The network metadata tells the same story from a different angle.

Scenario 3 — The fileless attack

The attacker's entire toolkit runs in memory. A PowerShell download cradle pulls a .NET assembly directly into the CLR. No file touches the disk. No Prefetch entry. No AmCache record. No MFT entry. The EDR sees powershell.exe making network connections, but the payload is in memory — the EDR's process telemetry shows the connection but not the content.

The network shows what the EDR can't — the full URL of the download cradle, the TLS fingerprint of the C2 server, the beacon pattern that identifies the framework (Cobalt Strike's default JA3 hash is well-documented), and the data that was exfiltrated. The attacker avoided the disk. They couldn't avoid the wire.

Scenario 4 — The timeline gap

The investigation needs to answer: when did the compromise start? Disk timestamps say the first malicious file appeared on March 15. But the attacker used timestomping — the $STANDARD_INFORMATION timestamps on the malware binary were modified to match a legitimate system file from 2024. The $FILENAME timestamps in the MFT show March 15, but you can't be sure the attacker didn't manipulate those too.

The network provides an independent timeline. The dns.log shows the first DNS query to the attacker's C2 domain on March 12 — three days before the earliest disk artifact. The conn.log shows the first connection to the C2 IP on March 12 at 14:22 UTC. This timestamp came from the NSM sensor's system clock, not from the compromised host. The attacker can timestomp files on the endpoint. They can't reach back in time and modify the conn.log entry on a sensor they don't control.

Network Evidence as the Third Leg

Network forensics doesn't replace endpoint investigation — it completes it. The practitioner who can work both evidence sources reconstructs attack chains that either source alone can't reveal.

If you've worked through the Practical IR course on this platform, you've investigated incidents from the endpoint — registry artifacts, event logs, Prefetch, AmCache, KQL queries against Defender XDR telemetry. If you've worked through the Linux IR course, you've done the same from auth.log, /proc, cron, and container forensics. If you've worked through Entra ID Security, you've traced identity attacks through sign-in logs, conditional access evaluation, and OAuth consent chains.

Every one of those courses has moments where the investigation reaches a boundary: the endpoint tells you a connection was made but not what data was transferred. The sign-in log tells you the authentication happened but not what the session was used for at the network level. The event log tells you PsExec was installed but not how much data the attacker moved through the SMB share it opened.

Network forensics lives at those boundaries. When you see DeviceNetworkEvents showing a connection to an external IP in Defender XDR, this course teaches you to find that same connection in Zeek's conn.log and trace it to its DNS resolution, its TLS certificate, its data volume, and its behavioral pattern. When you see an authentication in the sign-in log, this course teaches you to find the corresponding network session and determine what the authenticated user actually did across the wire.

The investigation coverage model works like this: endpoint forensics tells you what happened on the system. Identity forensics tells you who was involved. Network forensics tells you what crossed the wire — the connections, the protocols, the data transfers, and the attacker's infrastructure. A complete investigation needs all three.

What This Course Builds

This isn't a Wireshark tutorial. The existing Wireshark skill on this platform covers display filters and basic protocol analysis. This course starts where that skill ends.

The course builds three capabilities that the existing Ridgeline content doesn't cover:

The first capability is network security monitoring architecture. Where do you place sensors to capture the traffic you need? How do you configure Zeek and Suricata to produce the logs that answer investigation questions? How much storage do you need for full-packet capture at your network's throughput? What happens when you can't decrypt TLS traffic — what can you still see? These are architectural decisions that determine whether network evidence exists when you need it. Module NF1 builds this from scratch — you'll set up a sensor VM that you use for the entire course.

The second capability is protocol-level investigation. Every paid module in this course takes a specific protocol or technique — DNS, HTTP/HTTPS, SMB, SSH, email — and teaches you to distinguish normal traffic from attack traffic. Not at the "this packet has a suspicious payload" level. At the level of: what does a normal DNS query pattern look like for this organization, and what does DNS tunneling look like in comparison? What does legitimate SMB authentication produce, and what does PsExec lateral movement produce? What does a normal TLS handshake look like, and what does a Cobalt Strike beacon's JA3 fingerprint tell you?

The third capability is network-based detection and hunting. Writing Suricata rules that detect specific attack patterns. Building hunting queries in Zeek logs that find C2 beacons by their timing characteristics. Analyzing NetFlow data for exfiltration indicators. Profiling encrypted traffic by its connection behavior when you can't read the content. These are the skills that find attacks before the incident report lands on your desk.