In this module

NF0.7 Network Architecture for Investigators

8 hours · Module 0 · Free

What you already know

You know what a VLAN is, what a firewall does, and roughly how your organization's network is segmented. This sub isn't a networking fundamentals course — it focuses on the investigative question: given the network architecture, what can your sensor see, and where are the blind spots?

Operational Objective

Your sensor can only see traffic that crosses the interface it's monitoring. A sensor on the internet egress link sees all external traffic but none of the lateral movement between internal VLANs. A sensor on the server VLAN sees server-to-server traffic but not the initial phishing click from the user VLAN. Understanding what your sensor can and can't see — based on where it sits in the architecture — prevents you from drawing wrong conclusions from incomplete evidence.

This sub covers sensor placement from an investigator's perspective: which network positions provide visibility into which attack phases, where blind spots exist, and how cloud and hybrid architectures change the visibility model.

Deliverable: The four primary sensor positions (internet egress, DMZ, core/distribution, server VLAN), the attack phases each covers, the blind spots each creates, and the cloud-specific visibility challenges.

Estimated completion: 25 minutes

Figure NF0.7 — Sensor placement in the NE network architecture. Sensor 1 (egress) sees all external traffic but misses lateral movement. Sensor 3 (core) sees inter-VLAN traffic including lateral movement. Sensor 4 (server VLAN) sees access to high-value targets. Each position provides different visibility — and leaves different blind spots.

Sensor Position 1 — Internet Egress

This is the highest-value single sensor position for most organizations. It sees every packet that enters or leaves the network.

A sensor at the internet egress point (typically a SPAN or TAP on the link between the firewall and the ISP router, or between the firewall and the core switch) captures all external communications. C2 beacons, data exfiltration, external reconnaissance, malware downloads, phishing callbacks — any attacker activity that involves the internet crosses this sensor.

The attack phases visible from the egress sensor are initial access (phishing URLs, exploit kit traffic, downloaded payloads), command and control (beacon traffic to external C2 infrastructure), and exfiltration (data transfers to external destinations). These are often the highest-priority investigation questions: how did the attacker get in, how are they maintaining access, and what did they take?

The blind spot is lateral movement. When the attacker moves from DESKTOP-NGE042 to IT03-NGE via SMB over the internal network, that traffic never crosses the egress sensor. Internal-to-internal traffic stays on the internal switching fabric. The egress sensor sees the C2 beacon from each compromised host but not the movement between them.

If you can only deploy one sensor, deploy it at the egress. The C2 and exfiltration evidence it provides is almost always the highest-priority investigation need.

Sensor Position 2 — DMZ

The DMZ sensor sees traffic to and from your internet-facing services — web applications, mail servers, VPN gateways.

A sensor in the DMZ captures traffic between the internet and your public-facing services, plus (depending on architecture) traffic between the DMZ and the internal network. This is where you see web application attacks, email-based attacks, and VPN-based initial access.

The attack phases visible are initial access via web application exploitation (SQL injection, path traversal, webshell upload) and initial access via email (phishing delivery to the mail server). The DMZ sensor also captures authentication traffic to VPN concentrators — useful when the attacker uses stolen VPN credentials for initial access.

The blind spot is the same as the egress sensor: no visibility into internal lateral movement. Additionally, a DMZ sensor may miss client-side attacks that don't touch DMZ services — a phishing link that goes directly from the user's browser to an external attacker site traverses the egress but not the DMZ.

Sensor Position 3 — Core/Distribution

The core sensor is where you see lateral movement. If your investigation involves attackers moving between internal systems, this is the sensor position that provides evidence.

A sensor on the core or distribution switch (via SPAN port) captures inter-VLAN traffic — traffic that moves between network segments. When the attacker pivots from the user VLAN to the server VLAN via SMB, when they use RDP to reach the management VLAN, when they use PsExec to deploy tools on multiple hosts — all of this crosses the core switch.

The attack phases visible are lateral movement (SMB, RDP, WinRM, SSH between internal hosts), privilege escalation (Kerberoasting traffic, LDAP queries against Active Directory), and internal reconnaissance (port scanning, service discovery). These are the attack phases that the egress sensor misses.

The challenge is volume. Core switches in an enterprise environment carry all inter-VLAN traffic — legitimate file shares, printing, database connections, AD replication, DHCP, and internal web applications. The volume of legitimate internal traffic can be 10× the volume of egress traffic, requiring more sensor capacity and more storage. SPAN port capacity is also a constraint — many switches can only SPAN a limited number of ports without performance degradation.

Sensor Position 4 — Server VLAN / High-Value Targets

A targeted sensor on the server VLAN captures all access to your most sensitive systems — file servers, databases, domain controllers.

When the investigation question is "who accessed the ERP database?" or "what data was copied from the file server?", a sensor on the server VLAN provides direct evidence. It captures every SMB session to file shares, every database connection to SQL servers, and every authentication to the domain controller.

In the INC-NE-2026-0418 scenario, a sensor on the server VLAN would have captured the SMB session from IT03-NGE to FS01-NGE that mapped the share and staged the exfiltration data. The egress sensor captured the exfiltration leaving the network. The server VLAN sensor would have captured the internal data movement that preceded it.

Cloud and Hybrid Visibility

Cloud environments don't have SPAN ports. Network visibility in the cloud comes from VPC flow logs, cloud-native NSM, and cloud provider APIs — and the data model is different.

In AWS, Azure, and GCP, you can't deploy a traditional Zeek sensor that taps a physical interface. Network visibility comes from VPC Flow Logs (connection metadata similar to NetFlow), cloud WAF logs (for web application traffic), load balancer logs, and cloud-native security services (Azure Network Watcher, AWS GuardDuty, GCP Packet Mirroring).

The visibility gap in cloud environments is the lack of full PCAP and Zeek-level protocol metadata. VPC Flow Logs give you 5-tuple connection records with byte counts — roughly equivalent to NetFlow — but not protocol-level analysis (no TLS certificates, no HTTP headers, no DNS query details). Cloud environments trade sensor depth for scale and management simplicity.

For hybrid environments (on-premises AD with cloud workloads), the investigation often requires correlating on-premises Zeek data with cloud flow logs. The attacker compromises a user on-premises, obtains cloud credentials, and pivots to cloud resources. The on-premises sensor captures the credential theft traffic. The cloud flow logs capture the lateral movement to cloud workloads. Module NF13 covers hybrid NSM architecture in detail.

Guided Procedure — Map Your Sensor Visibility to Attack Phases

Step 1. Draw (or describe) your organization's network architecture with sensor positions marked.

Expected output: At minimum: internet egress, DMZ (if applicable), core/distribution, server segments, cloud environments. Mark where you currently have any network monitoring — even if it's just firewall logs.

If you don't know the architecture: Use the NE architecture from Figure NF0.7. The exercise is about understanding visibility coverage, not documenting your specific network.

Step 2. For each MITRE ATT&CK tactic (Initial Access, Execution, Persistence, Lateral Movement, Collection, Exfiltration), identify which sensor position provides visibility.

Expected output: Initial Access → egress or DMZ. Lateral Movement → core. Collection → server VLAN. Exfiltration → egress. Some tactics are visible from multiple positions. Some (execution on a single host) may not be directly visible from any network sensor.

If no sensor position covers Lateral Movement: That means you don't have a core/distribution sensor. This is the most common visibility gap in organizations that only monitor at the egress — they can detect C2 and exfiltration but can't see the attacker moving between internal systems.

Step 3. Identify the single most impactful sensor position you're currently missing.

Expected output: If you have no network monitoring: egress is the highest-value first deployment. If you have egress monitoring: core/distribution is the next priority (lateral movement visibility). The specific answer depends on your architecture and your most likely threat scenarios.

If you already have all positions covered: Check the depth. Having firewall logs at the egress is not the same as having Zeek metadata. "Covered" means you have queryable metadata with sufficient retention, not just that a device exists at that position.

Decision point

NE's network team offers you one SPAN port for your NSM sensor. You can choose: the internet egress link or the core switch. You can't do both (the sensor has one capture interface and the bandwidth of both exceeds its capacity).

The egress link gives you all external traffic — C2, exfiltration, initial access. You'll see every attacker communication with external infrastructure. You won't see lateral movement between internal VLANs.

The core switch gives you inter-VLAN traffic — lateral movement, internal reconnaissance, access to high-value targets. You'll see the attacker moving between systems. You won't see their C2 channel or exfiltration to external IPs (those cross the egress, not the core, in NE's architecture).

The right answer for most organizations is the egress. C2 detection and exfiltration measurement are higher-priority investigation questions than lateral movement visibility, because C2 tells you the compromise is active and exfiltration tells you the impact. Lateral movement can often be reconstructed from endpoint evidence (authentication logs, process creation events) — but C2 and exfiltration evidence only exist on the network.

Compliance Myth: "Our cloud provider handles network security, so we don't need visibility into cloud traffic"

Cloud providers secure the infrastructure — the hypervisor, the physical network, the storage backend. They don't secure your workloads' network behavior. If an attacker compromises a cloud VM and uses it to exfiltrate data from a cloud database, the cloud provider's security controls don't detect or prevent the application-layer attack. Your VPC flow logs might show the connection, but without Zeek-level metadata, you won't see the protocol details.

The shared responsibility model means cloud network investigation is your responsibility. Cloud provider security features (GuardDuty, Defender for Cloud, Security Command Center) are valuable alert sources — but they don't replace the investigation capability that Zeek metadata provides for on-premises networks. Cloud NSM requires different tooling (VPC flow logs, cloud WAF logs, packet mirroring where available), but the investigation methodology is the same.

NF0.8 — Northgate Engineering Scenarios. You understand where to place sensors and what they see. NF0.8 introduces the five Northgate Engineering incidents that thread through this course — each designed to teach specific network investigation techniques.

Try it: Identify your blind spots

Setup. Use the NE architecture (or your own) with the sensor positions from the guided procedure.

Task. List three attack scenarios and determine whether your current sensor coverage would detect each: (1) An attacker phishes a user, downloads a RAT, and exfiltrates data to an external server. (2) An attacker with valid VPN credentials moves laterally from a compromised workstation to the domain controller. (3) An attacker compromises a cloud VM and exfiltrates data from a cloud database to an external storage bucket.

Expected result. Scenario 1 is visible from the egress sensor (phishing URL, RAT download, exfiltration). Scenario 2 requires a core sensor (VPN entry is visible at egress, but the lateral movement to the DC is internal). Scenario 3 requires cloud flow logs or cloud-native NSM (the traffic may never cross the on-premises network).

Debugging branch. If all three scenarios are visible: check whether "visible" means "visible in metadata that's retained long enough." Having a sensor that could see the traffic isn't the same as having the data stored when you need it.

Checkpoint — before moving on

1. Name the four primary sensor positions and state which attack phase each provides the best visibility for. (§ Sensor Positions 1-4)

2. Explain the egress sensor's blind spot and why lateral movement requires a core/distribution sensor. (§ Position 1 and Position 3)

3. Describe the visibility difference between on-premises NSM and cloud network monitoring. (§ Cloud and Hybrid Visibility)

Operational Artifact — Sensor Placement Decision Matrix

First sensor deployment (no existing NSM): Deploy at internet egress. This covers C2 detection, exfiltration measurement, and initial access investigation — the three highest-priority use cases. Storage: estimate 10-15 GB/day of Zeek metadata per Gbps of monitored traffic.

Second sensor deployment (egress covered): Deploy at core/distribution switch. This adds lateral movement visibility — the primary blind spot of egress-only monitoring. Storage requirement depends on internal traffic volume, which may exceed external traffic by 5-10×.

Third sensor deployment (egress + core): Deploy at server VLAN or high-value target segment. This provides targeted visibility into access to your most sensitive systems. Consider DMZ monitoring as an alternative if web application attacks are a primary concern.

Cloud environments: Enable VPC flow logs and cloud-native security services as minimum coverage. Consider cloud packet mirroring (where available) for Zeek-level protocol visibility. Integrate cloud logs with on-premises NSM data for hybrid investigations.

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

Unlock the full course with Premium See Full Syllabus

Cancel anytime

← Previous Next →