Module 10 · Why Network Detection Underperforms 🔒

Every attack described in this track passes through a network. In theory, defenders have complete visibility. In practice, defenders miss most attacks until well after the fact. This module closes the Network Mindset track by explaining why network detection underperforms its promise — and what the mature programs actually do.

Why this happens

Network detection is hard for structural reasons:

• Encryption dominates. ~95% of outbound traffic is HTTPS. Inline inspection requires TLS interception, which has collateral costs. Without interception, you see domain + volume + JA3 — not content.
• Volume overwhelms. Mid-size enterprise: 100s of GB of log data daily. Real attacks are 0.01% of that. Finding them requires precise queries + good detections.
• Baseline drift. “Normal” changes constantly. New SaaS integration, new vendor, new employee traveling — each shifts the distribution.
• False positives exhaust analysts. Generic rules fire on legitimate behavior; analysts disable or ignore. After a few weeks, the detection exists but nobody responds.
• Attackers blend with legitimate tools. Living-off-the-land binaries (LOLBAS) — attackers use tools already on the system. Process + connection look normal; intent is malicious.
• Time-to-detection measured in months. Industry average dwell time (M-Trends, Mandiant) was 10 days in 2023 but often extends to months for sophisticated attackers who actively avoid detection.

Modern detection stack (what actually works)

# Layer 1: Network flow / packet data
# - Zeek (formerly Bro) for protocol parsing + behavior
# - Suricata for signature-based IDS
# - Full packet capture at high-value points (egress, DMZ)

# Layer 2: Endpoint detection
# - CrowdStrike, SentinelOne, Microsoft Defender, Elastic Defend
# - Process + network + file events from every host
# - Correlates local process with outbound connection

# Layer 3: Identity + cloud
# - Entra ID / Okta / auth0 sign-in logs
# - Cloud provider audit (CloudTrail, Azure Activity, GCP)
# - SaaS API logs (GitHub, Slack, Salesforce)

# Layer 4: SIEM for correlation
# - Microsoft Sentinel / Splunk / Elastic / Chronicle
# - Detections in Sigma / KQL / SPL
# - Correlated across sources

# Layer 5: Threat intel integration
# - VirusTotal / CrowdStrike Intel / Recorded Future
# - IOC enrichment (domain reputation, IP history, file hashes)
# - TTP matching (MITRE ATT&CK mappings)

What mature detection looks like for specific attacks

Cobalt Strike C2 beacon

Beaconing pattern: periodic calls home. Detection signals:

• JA3/JA4 TLS fingerprint matches known Cobalt Strike library
• Periodic connections to a domain with regular intervals (60s ± 12s jitter)
• Domain registered within last 90 days
• Process: PowerShell, rundll32, or injected into signed binary
• Parent process: Office document (Word → rundll32 → beacon)
• EDR detection: reflective DLL injection, unbacked executable memory
• SIEM rule: Sigma rule T1071.001 Cobalt Strike beacon

Any single signal = investigate. Multiple signals correlated = high confidence.