NF0.10 What Network Forensics Cannot Do — Honest Limits

Gap 1 — Network evidence doesn't tell you what ran on the host

The network sees what left the host and what came back. It does not see what happened between — the process that launched, the registry key the malware wrote, the scheduled task it set, the DLL it loaded into a legitimate process. When the question is "what executed on this system," network evidence is supporting material at best.

Consider a ransomware case where you have full PCAP of the attacker's C2 channel. You can reconstruct the beacon timing, identify the Cobalt Strike JA3 fingerprint, map the domain-fronting infrastructure. What you cannot reconstruct is the sequence of powershell.exe spawns, the exact command line the attacker used to disable Defender, the registry key they added for persistence, or the exact moment the encryption process started.

Endpoint evidence fills this gap. Defender XDR's DeviceProcessEvents table, Sysmon Event ID 1, or EDR process-tree captures all record exactly what executed, when, and with what parameters. Network evidence tells you the attacker was in the house; endpoint evidence tells you which rooms they searched. An IR report that describes the attack without process-level detail leaves the board asking "but what did they actually do on the machines" — a question the network alone cannot answer.

The practical consequence for the investigator. When you're brought into an incident where the key question is process execution, privilege escalation, or host-local activity, pull endpoint evidence first. Use network evidence to confirm what happened externally (the C2 channel existed, the exfiltration traversed the wire) but let the endpoint evidence answer the host-level questions. Leading with network evidence for a host-execution question costs investigation time and often misses the answer.

Gap 2 — TLS shields the payload, not the metadata

TLS is the internet's default encryption. It protects HTTP request bodies, response payloads, and application-layer data. The network investigator sees everything about the connection — timing, size distribution, certificate, fingerprint — but not what was sent or received inside it. Without TLS inspection, a significant fraction of modern C2 and exfiltration is opaque to network-only investigation.

What you can see in an HTTPS session. Source and destination IP and port. TLS version and cipher suite. Server Name Indication (SNI) from the ClientHello. Certificate chain and issuer. JA3/JA4 client fingerprint. Connection duration. Bytes transferred each way. Packet-size distribution over time.

What you cannot see. The HTTP method (GET, POST, PUT). The URI path. Request and response headers. Request body (including credential submissions, file uploads, API requests). Response body (including extracted data, command output, exfiltrated files). Cookie values. Session tokens.

The consequence for investigation. If an attacker exfiltrates 2GB of engineering files over an HTTPS POST to a legitimate-looking cloud storage service, the network shows you the connection, the timing, the volume, and the destination — but not the file names, not the content, not the authorization headers that would identify which account did the upload. For high-sensitivity cases (legal proceedings, customer-data breaches, intellectual-property theft), the network evidence establishes that something happened but cannot establish what was taken.

TLS inspection (covered in NF4.7) closes this gap at the cost of architectural complexity and privacy tradeoffs. For environments without TLS inspection, endpoint evidence fills the gap — Defender XDR's DeviceNetworkEvents combined with process-level file-access logs shows the exfiltration from the host perspective even when the wire-level content is encrypted. A network-only investigator who ignores Gap 2 will overstate confidence about what was exfiltrated.

Gap 3 — Identity and intent live above the network layer

Network evidence shows you the connection. Identity evidence shows you who authenticated as whom to establish that connection. For authentication-scope investigations — account compromise, credential theft, privilege abuse, insider threat — identity logs are the primary source, and network evidence is supplementary.

In an M365 tenant compromise, the network sees the TLS connection to login.microsoftonline.com. It doesn't tell you which user completed MFA, whether the session was interactive or service-principal, which conditional-access policies fired, whether the sign-in risk score elevated, or which OAuth scopes were granted. Entra sign-in logs answer those questions directly — and the network connection, by itself, tells you almost nothing about the identity layer.

This is the reason NF14's capstone (INC-NE-2026-0830) includes the cautious framing around identity continuity across the MFA reset. Even when the investigation is explicitly network-only because Defender XDR is unavailable, the report has to acknowledge that identity-scope claims (the pre-reset and post-reset activity is the same actor) rest partly on inference from network indicators and partly on evidence thread analysis that identity logs would have made direct. An honest investigation flags what the evidence can and cannot establish, and identity is the gap most commonly over-claimed by network-only investigators.

The compensating evidence source is Entra (or equivalent identity platform) sign-in and audit logs. For privilege-abuse cases, the identity system's native telemetry is primary; network evidence supports the timeline but does not establish the identity-layer claims.

Gap 4 — Host-local activity leaves no network footprint

Some attack techniques operate entirely inside the host — no network traffic, no external communication, nothing for the sensor to see. For these techniques, network evidence is not just incomplete, it's irrelevant.

Examples. A local privilege-escalation via token manipulation — the attacker already has code execution as a low-privilege user, they inject into or impersonate a higher-privilege process, no packets cross the sensor. A disk-based persistence mechanism that waits for reboot — no network activity during the setup. A rootkit that hooks kernel callbacks to hide its presence — all the interesting work is in-kernel. A data-at-rest theft where the attacker copies files to a USB device or burns them to a DVD — no network involvement at all.

For these cases, endpoint forensics and memory forensics are the primary sources. The network investigator needs to recognize when the question is host-local so they can correctly scope their contribution to the investigation — "the network evidence is consistent with the endpoint findings but cannot independently establish the host-local chain" is an honest framing that supports the investigation rather than over-extending network evidence.

The corollary. If an attacker's entire operation is host-local, a network-only investigation will miss the attack entirely. The mitigation isn't better network forensics — it's layered evidence sources so the host-local activity gets caught by endpoint or memory investigation even when the network layer is silent.

Gap 5 — In-memory state doesn't transit the wire

Memory-resident attacks — reflective DLL loading, process injection, Cobalt Strike's sleep-mask obfuscation, Mimikatz credential extraction from LSASS — leave specific artefacts in RAM that never appear on the wire. Credentials held in memory, injected code regions, hidden kernel structures: all invisible to network sensors.

The practical example. Mimikatz extracts cached credentials from LSASS.EXE memory on a compromised workstation. The attacker then uses those credentials in a subsequent authentication, which is visible on the network (Kerberos ticket request, or NTLM challenge-response). But the extraction itself — the moment the credentials were stolen — produces no network traffic. If the investigator only has network evidence, they can establish that the stolen credentials were used but not when or how they were stolen.

Memory forensics (covered in Ridgeline's Applied Memory Forensics course) fills this gap. A memory capture preserves the in-RAM state at the moment of capture — injected code regions, process handles, cached credentials, kernel structures. Combined with network evidence of subsequent authentication, memory forensics establishes the full credential-theft chain. Without memory evidence, the network-only investigator has to infer the extraction from the subsequent use, which is weaker evidence and more vulnerable to alternative explanations.

The structural limit — visibility is an architecture decision, not an investigation one

The five gaps above are about what network evidence intrinsically cannot see. There's a sixth limit that's different in kind: network evidence only exists where sensors were deployed and only for as long as retention policy kept it. This is a property of the architecture, not the evidence type, but it shapes every investigation.

If your sensor was deployed at the internet perimeter but not at the DMZ boundary, and the attack pivoted laterally from the DMZ to internal systems without crossing the perimeter, you have no network evidence of the lateral movement. If your perimeter sensor captured the traffic but your retention policy rotated the PCAP after 7 days and the incident is investigated at day 14, the PCAP is gone.

These aren't gaps in what network evidence can see — they're gaps in what your specific deployment actually saw and retained. They compound the intrinsic gaps: a network-only investigator with a limited sensor deployment has both the five technique-level gaps AND the architectural gaps from their specific NSM posture. When scoping what network evidence can contribute to an investigation, always check the sensor map against the incident's geography and the retention policy against the incident's timeline before committing to a network-led approach.

NF13 covers this in depth — sensor placement, capture scaling, retention planning. For NF0 the takeaway is simpler: when you pitch network evidence as the investigation backbone, you're implicitly pitching the architecture that produces it. Network-led investigation without the underlying NSM architecture is a house built on sand.