Warmup Guide — Network Attacks, Protocols, Pivoting, and the Telemetry That Catches Them

Zero-to-principal primer for Phase 03. It builds every concept the phase depends on from first principles: the OSI / TCP-IP model and what each layer reveals; DNS end to end (recursion, records, DNS as recon and as a covert channel); the SMB / NTLM / Kerberos transports; reconnaissance and the legal line; scanning theory (TCP states, SYN scan, rate vs stealth); pivoting and tunneling (SOCKS, local/remote/dynamic forwarding) modeled as reachability over a graph; network segmentation (VLANs, ACLs, zero-trust, microsegmentation); egress filtering and allow-listing; and the network telemetry (netflow, DNS logs, proxy logs, Zeek, Suricata) that detects each. It assumes only that you can write software and have read Phase 00's authorization boundary. By the end you can read any network move through the attacker's and the defender's eyes at once.

Safety frame (not optional). This is the network attacker's playbook taught for authorized emulation and defense. Everything here reasons over synthetic metadata; every offensive concept ends in its detection / segmentation control. The difference between a red teamer and a criminal is authorization and intent, not knowledge (Phase 00). Nothing here scans, tunnels through, or touches a host you do not own.

Table of Contents

• Chapter 1: The OSI / TCP-IP Model — What Each Layer Reveals
• Chapter 2: DNS — Resolution, Records, Recon, and the Covert Channel
• Chapter 3: SMB, NTLM, and Kerberos Transports
• Chapter 4: Reconnaissance — Passive vs Active, and the Legal Line
• Chapter 5: Scanning Theory — TCP States, SYN Scans, Rate vs Stealth
• Chapter 6: Lateral Movement as Reachability Over a Graph
• Chapter 7: Pivoting and Tunneling — SOCKS, Port-Forwarding, chisel/ligolo
• Chapter 8: Network Segmentation — VLANs, ACLs, Zero-Trust, Microsegmentation
• Chapter 9: Egress Filtering and Allow-Listing
• Chapter 10: Network Telemetry — Netflow, DNS, Proxy, Zeek, Suricata
• Lab Walkthrough Guidance
• Success Criteria
• Common Mistakes and OPSEC Failures
• Interview Q&A
• References

Chapter 1: The OSI / TCP-IP Model — What Each Layer Reveals

Zero background. When one computer talks to another, the message is wrapped in layers, like an envelope inside an envelope inside an envelope. Each layer adds its own header so a different piece of networking equipment can do its job and hand the rest along. The OSI model names seven such layers; the TCP/IP model (the one the internet actually runs) collapses them into four. You do not need to worship the seven-layer chart, but you must internalize one idea: every layer is both a thing an attacker learns from and a thing a defender can watch.

What it is. Here is the practical stack, top (application) to bottom (wire), with the attacker/defender view fused:

Why it exists. Layering lets each part of the network evolve independently — you can swap Wi-Fi for Ethernet (L2) without rewriting HTTP (L7). For us, layering is a map of information: a question like "what hosts exist?" is answered at L3; "what services run?" at L4; "what are they actually doing?" at L7. Knowing the layer tells you both how to learn the answer and which sensor will see you ask.

Under the hood — encapsulation. A single HTTPS request to erp.meridian.example is wrapped like this on the wire (each layer prepends a header):

[ Ethernet header | IP header | TCP header | TLS record | HTTP request ] payload
   src/dst MAC       src/dst IP   src/dst    encrypted    GET /...
   (L2)              (L3)         port (L4)  (L6/7)        (L7, if no TLS)

A defender's sensor reads exactly the layers it sits at. A netflow collector sees the IP/TCP headers (who, to whom, which port, how many bytes, how long) but not the HTTP body. A proxy terminates TLS and sees the URL and headers. Zeek parses all the layers it can and writes one log per protocol. This is why "the attacker hid in TLS" and "the SOC still caught the beacon in netflow" are both true at once: encryption hides L7, not L3/L4 metadata.

Telemetry it emits. Every layer leaves a record (right-hand column above). The principal-level habit is to ask, for any action: which layer does this touch, and therefore which log will it appear in? A DNS tunnel hides in L7 DNS but screams in L7 DNS logs (volume, entropy). A port scan hides nothing at L4 — it is loud in netflow by construction.

How a defender detects it. The defender instruments per layer: ARP/switch monitoring (L2), flow records (L3/L4), proxy + DNS + Zeek protocol logs (L7). The art is correlation across layers — a single L7 DNS anomaly is noise; a DNS anomaly plus an L4 beacon plus an L3 connection to a rare destination is an incident.

Engagement significance. In Operation Cedar Lattice, you will reason at every layer: ARP for on-segment positioning (L2), IP/port reachability for the pivot graph (L3/L4), DNS/HTTP/SMB for recon and C2 (L7). The pivot map (Lab 01) is fundamentally an L3/L4 reachability model; the egress policy (Lab 02) is an L3/L4/L7 filter.

Common misconception. "TLS makes traffic invisible." No — TLS encrypts the L7 content, not the L3/L4 metadata (who, whom, port, size, timing) or the TLS handshake fingerprint (JA3/JA4, SNI). Most network detection lives in exactly the metadata TLS does not hide.

Chapter 2: DNS — Resolution, Records, Recon, and the Covert Channel

Zero background. Computers route by IP address (192.0.2.10), but humans use names (erp.meridian.example). DNS (the Domain Name System) is the distributed phone book that turns a name into an address. It is the single most important protocol in this phase because it is used three completely different ways: as the plumbing every connection needs, as a reconnaissance source, and as a covert channel — and it is one of the richest detection surfaces a defender has.

What it is — resolution end to end. When a host resolves erp.meridian.example:

client ── "A erp.meridian.example?" ──► recursive resolver (the host's configured DNS server)
                                          │  (cache miss → it does the walking:)
                                          ├─► root server      → "ask the .example TLD servers"
                                          ├─► .example TLD      → "ask meridian.example's name servers"
                                          └─► meridian.example  → "erp = 192.0.2.10"  (authoritative)
client ◄──────────── "erp.meridian.example = 192.0.2.10" ───────┘

The recursive resolver does the legwork and caches the answer for its TTL (time-to-live). The authoritative servers are the source of truth for a zone. This recursion is the mechanism a tunnel abuses (below).

Record types you must know:

Why it exists. A flat global host table cannot scale; DNS distributes authority (each org runs its own zone) and caches aggressively. That distribution and caching are exactly what make DNS a useful recon source (anyone can query public records) and a stealthy channel (queries traverse the org's own resolver out to the internet by design).

Under the hood — DNS as reconnaissance (passive, mostly legal). You can learn a great deal about Meridian without touching its hosts, by querying public DNS and aggregators:

• Subdomain enumeration — vpn., mail., dev., erp. reveal the attack surface.
• Passive DNS — historical name→IP mappings from third-party datasets (no query to the target).
• Certificate transparency — every TLS cert is logged publicly; CT logs leak subdomains.
• MX / TXT — mail infra and the SPF/DKIM/DMARC posture that Phase 10 phishing depends on.

A zone transfer (AXFR) — asking an authoritative server to dump the entire zone — is the loud, active version; a misconfigured server that answers AXFR to anyone hands over the whole map. That crosses from passive observation into interaction (Chapter 4).

Under the hood — DNS as a covert channel (tunneling / C2). Because a host's DNS queries are allowed out by default (almost every egress policy permits udp/53 or DNS over the resolver), DNS becomes an exfiltration and command channel. The trick: encode data into the name being queried.

exfil:  base32(secret-chunk-1).tunnel.attacker.example   →  resolver  →  attacker's authoritative NS
        base32(secret-chunk-2).tunnel.attacker.example       (logs each label = receives the data)
C2:     the attacker's NS answers with TXT/CNAME records that encode commands back to the implant

Each query smuggles a few bytes in the subdomain label; the attacker controls the authoritative name server for attacker.example, so it receives every label and answers with instructions. This is slow and chatty but works through almost any firewall — which is exactly why it is detectable.

Telemetry it emits. DNS tunneling and DNS recon leave a loud signature:

• Query volume — a host making thousands of DNS queries to one zone is abnormal.
• Name entropy / length — base32-encoded labels look random and are long; legitimate names are short and dictionary-like. High Shannon entropy per label is a strong signal.
• Record-type mix — heavy TXT / NULL / CNAME traffic to one domain is unusual.
• NXDOMAIN bursts — domain-generation-algorithm (DGA) C2 produces many failed lookups.
• Many unique subdomains under one parent — the tunnel's signature.

How a defender detects it. Zeek's dns.log (every query, response, record type, length) feeds a detection: alert on per-host query rate to a single zone, mean label entropy above a threshold, unusual record-type ratios, and unique-subdomain count. The control is to force all DNS through the enterprise resolver, log it, and block direct udp/53 egress — so there is no path to an external authoritative server except through a sensor.

Engagement significance. DNS is the egress channel of last resort and the recon source of first resort. In Operation Cedar Lattice you map Meridian's external surface via DNS/CT (Phase 03 recon), and the C2 phase (Phase 08) returns to DNS as a channel — both ending in the DNS-entropy detection.

Common misconceptions. "DNS is just name lookups, low risk." DNS is a bidirectional, allowed-out, loggable channel — high recon value and a real covert channel. "If I tunnel over DNS I am invisible." DNS tunneling is one of the most detectable channels because the encoded names are statistically obvious; it trades reachability for stealth.

Chapter 3: SMB, NTLM, and Kerberos Transports

Zero background. Inside a Windows enterprise like Meridian's, hosts share files, run remote administration, and authenticate users constantly. SMB (Server Message Block) is the file/IPC protocol; NTLM and Kerberos are the two authentication protocols those services use. You will meet these in depth in Phase 05 (Active Directory); here you learn just enough to recognize each on the wire and in the logs — because lateral movement rides on them.

What they are.

• SMB (tcp/445) — file shares, named pipes, remote service control. It is the transport for many remote-execution and lateral-movement techniques (admin shares, service creation, named-pipe C2).
• NTLM — a challenge/response authentication protocol. The server sends a challenge; the client proves it knows the password hash by responding. Crucially, NTLM authentication can be relayed: if an attacker can make a victim authenticate to them, they can forward that authentication to a third server and act as the victim.
• Kerberos (tcp/88) — a ticket-based authentication protocol. A client gets a TGT (ticket-granting ticket) from the KDC (the domain controller), then exchanges it for service tickets (TGS) to specific services. Service tickets are encrypted with the service account's key — which is what makes Kerberoasting possible (crack the ticket offline to recover a weak service password).

Why they exist. Enterprises need single sign-on and centralized identity. Kerberos provides it properly (mutual auth, time-bounded tickets, no password on the wire). NTLM is the older fallback, still everywhere, and weaker — which is why so many attacks target it.

Under the hood — what each looks like (the parts that matter here):

NTLM relay:        victim ──auth──► attacker (poses as a server)
                                    attacker ──relays the auth──► target server  → acts as victim
                   trigger: LLMNR/NBT-NS poisoning, or "coerced auth" (force victim to authenticate)

Kerberoast:        attacker ──"give me a TGS for service X"──► KDC
                   KDC returns a TGS encrypted with service X's account key
                   attacker cracks it OFFLINE → recovers service X's password

These are deep Phase-05 topics. The Phase-03 takeaway is the network/transport shape: NTLM relay needs the attacker on-path or able to coerce auth (an L2/L3 position — segmentation matters); Kerberoasting is a normal-looking tcp/88 exchange whose tell is the encryption type (a flood of RC4 TGS-REQ/TGS-REP) in the logs.

Telemetry it emits.

• SMB lateral movement → Windows logon EID 4624 type 3 (network logon), SMB session telemetry, Zeek smb/dce_rpc logs, named-pipe creation.
• NTLM relay / poisoning → LLMNR/NBT-NS responder traffic on the segment (L2/L3), unusual authentications from one source to many targets.
• Kerberoast → EID 4769 (TGS requested) with RC4 encryption type and many services from one user in a short window.

How a defender detects it. Disable LLMNR/NBT-NS (removes the relay trigger); require SMB signing (breaks relay); alert on 4769 RC4 bursts; segment so an attacker cannot reach the broadcast domain to poison it. The network-layer control here is segmentation (Chapter 8): a relay/poisoning attack needs reachability to its victims.

Engagement significance. Lateral movement in Meridian's Windows estate (Phase 05) is built on these transports. Phase 03's contribution is the reachability and segmentation that decide whether the attacker can even reach the hosts to ride SMB/NTLM/Kerberos at all — which is exactly what Labs 01–02 model.

Common misconception. "Kerberos is unbreakable, so the network is safe." Kerberos is strong, but weak service-account passwords are crackable offline from a normal ticket request, and NTLM (still enabled almost everywhere) is relayable. The protocol is not the whole story; the configuration and the network position are.

Chapter 4: Reconnaissance — Passive vs Active, and the Legal Line

Zero background. Before attacking anything, you learn about it. Reconnaissance is that learning. There are two kinds, and the difference between them is not academic — it is the legal and authorization boundary that separates security research from an offense.

What it is.

• Passive reconnaissance — learning without interacting with the target's systems. You query public, third-party data: DNS records, certificate-transparency logs, passive-DNS datasets, WHOIS, search engines, leaked-credential dumps, the target's own public website, employees' public profiles (OSINT). The target's servers never receive a packet from you.
• Active reconnaissance — interacting with the target's systems: port scanning, banner grabbing, zone transfers, probing a login page, vulnerability scanning. The target receives your traffic and could log it.

Why the distinction matters. Passive recon is generally lawful and OPSEC-quiet (no traffic to the target). Active recon touches systems you may not be authorized to touch — and in most jurisdictions, unauthorized interaction with a computer system is a crime regardless of intent (unauthorized-access statutes). The line is not "did I cause harm"; it is "did I have authorization to interact."

The authorization line (the Phase 00 rule, restated for the network).

PASSIVE (public data, no target traffic)        →  generally fine; still record scope and purpose
ACTIVE (packets hit the target's systems)        →  ONLY with written authorization
                                                    (signed engagement / ROE, a CTF, a VRP with
                                                     safe-harbor scope) OR a system you own

You never scan a host "because it is reachable." Reachability is not authorization. Before any active recon you must name the owner, scope, methods, rate limits, time window, stop conditions, and deconfliction contact (Phase 00). In Operation Cedar Lattice, that authorization is the engagement contract with Meridian; in this repo, all labs are synthetic, so there is no target to scan at all.

Under the hood — what good passive recon yields. From public DNS + CT + WHOIS + OSINT you can often reconstruct most of an org's external surface: subdomains (vpn., mail., dev.), IP ranges, mail and SaaS providers, the email-auth posture, technology fingerprints, and likely usernames — all without sending the target a single packet.

Telemetry it emits. Passive recon emits nothing the target can see (that is the point) — but it leaves traces in the third-party services you query, and active recon emits plenty: scan traffic in the target's netflow, failed logins, IDS alerts, and AXFR attempts in DNS logs.

How a defender detects it. A defender cannot detect passive recon directly, so they reduce attack-surface exposure (minimize public records, monitor CT logs for lookalike domains, watch for their brand in leak datasets). Active recon they detect with scan-detection analytics (Chapter 5) and AXFR-attempt logging.

Engagement significance. Phase 03's external-recon step against Meridian is passive-first: build the surface map from public data, then do authorized active scanning to confirm reachability — and every active step is paired with its scan-detection so you can tell Meridian what their sensors should have seen.

Common misconception. "It's just a port scan, that's not illegal." Unauthorized scanning of systems you do not own can be unlawful and is, at minimum, a scope violation. Authorization — not the benignity of the technique — is the line.

Chapter 5: Scanning Theory — TCP States, SYN Scans, Rate vs Stealth

Zero background. To know which services exist on a host, you probe its ports. A port is open, closed, or filtered. Scanning is the systematic discovery of that state across hosts and ports. To understand scanning you must understand the TCP connection state machine, because scans are clever manipulations of it.

What it is — the TCP three-way handshake. A normal TCP connection opens like this:

client ──SYN──►        server      "I want to connect"
client ◄─SYN/ACK─       server      "ok, here's my sequence" (port is OPEN and listening)
client ──ACK──►        server      "great, connected"        (full connection established)

If the port is closed, the server replies RST (reset). If a firewall filters the port, the client gets nothing (the SYN is dropped) — so "no answer" means filtered.

Why a SYN scan ("half-open"). A full connect scan completes the handshake (SYN → SYN/ACK → ACK), which the application accepts and logs. A SYN scan sends the SYN, reads the reply, and then sends RST instead of ACK — it never completes the connection:

SYN scan:   scanner ──SYN──► port
            port ◄─SYN/ACK─ scanner   → OPEN   (scanner replies RST, tears down before connecting)
            port ◄──RST───  scanner   → CLOSED
            port  (no reply)          → FILTERED

Because the connection never fully opens, the application often never logs it (only the network stack saw it), and it is faster. That is the classic "stealth" rationale — but "the app didn't log it" is not "nobody saw it" (below).

Why rate vs stealth is a real tradeoff. You can scan fast (thousands of packets per second, like masscan) or slow and randomized. The tradeoff:

There is no "invisible" scan. A scan is, by definition, one source touching many destinations/ports in a short window — which is a shape in netflow that no payload trick hides. Stealth scanning manages how loud, not whether.

Under the hood — scan types in one table:

Telemetry it emits. A scan is loud at L3/L4: in netflow it is a fan-out — one source IP, many destination IPs and/or many destination ports, many tiny flows, often with high RST or no-response ratios. IDS (Suricata) has explicit scan-detection rules; Zeek's conn.log plus a scan-detection script flags it.

How a defender detects it. Threshold on connections-per-source-per-window across distinct destinations/ports; alert on high RST ratios and SYN-without-completion. The control is deny-by-default segmentation (Chapter 8): if the scanner can only reach its own segment, the scan reveals nothing valuable, and the cross-segment scan attempt is itself an alert.

Engagement significance. In Phase 03 you scan Meridian's authorized scope to confirm reachability for the pivot map — and you pair every scan with its netflow/IDS detection so Meridian learns where their scan-detection failed. The rate-vs-stealth choice is an OPSEC decision recorded in the run sheet.

Common misconception. "A SYN scan is undetectable." It avoids application logging, not network detection. The netflow fan-out is the signature; "stealth" scanning only changes how quickly you cross a threshold.

Chapter 6: Lateral Movement as Reachability Over a Graph

Zero background. One foothold is never the goal. Lateral movement is spreading from the first compromised host toward the objective (the database, the domain controller, the backup server). The key mental shift in this phase: lateral movement is a graph problem.

What it is. Model the network as a directed graph:

• Nodes are hosts (and, in richer models, identities/credentials).
• A directed edge A -> B means an attacker who controls A can reach B — because A and B are network-adjacent and the attacker holds the credential or route that enables the hop (an open firewall path plus a reused local-admin password, a stored SSH key, a SOCKS proxy through a multi-homed host).

   [vpn] ──► [jumphost] ──► [fileserver] ──► [erp_db]
                  │
                  └────────► [appserver] ──► [dc]

Why model it as a graph. Three questions fall straight out of graph theory, and they are exactly the Lab-01 API:

1. Blast radius — what can I reach from the foothold? A breadth-first search from start gives the reachable set. (reachable(graph, start).)
2. The best route — what is the cheapest path to the target? Put a cost on each edge (detection-risk + effort) and run Dijkstra. The cheapest path is the quietest, not the fewest-hops. (shortest_path(graph, start, target).)
3. The choke point — which single host, if removed, disconnects the foothold from the target? Those are the articulation points / dominators — remove each candidate and re-test reachability. (choke_points(graph, start, target).)

Under the hood — why offense and defense are the same algorithm. The attacker runs the BFS/Dijkstra to find a path. The defender runs the same search to find the cut: the choke point is the host whose every-path-passes-through property makes it the highest-leverage place to segment or harden. BloodHound (offense) and attack-path analysis (defense) are one algorithm — and so is Lab 01.

attacker view:  "BFS from foothold → I reach the dc via jumphost→appserver"
defender view:  "remove appserver → the dc is no longer reachable → appserver is a choke point → segment it"
SAME GRAPH, SAME SEARCH, opposite goal.

Why cost matters. A real operator does not take the shortest path; they take the quietest path that reaches the goal. Encoding detection-risk as edge cost (a monitored noisy SMB-admin hop costs more than a quiet allow-listed SSH hop) makes Dijkstra return the route an OPSEC-disciplined attacker actually uses — which is also the route a defender most wants to instrument.

Telemetry it emits. Lateral movement is east-west traffic — internal host-to-host flows on service ports (445, 3389, 5985, 22). In a normally hub-and-spoke network (clients talk to servers, not to each other), a host suddenly initiating connections to many internal peers is a netflow anomaly. Authentication telemetry (EID 4624 type 3) corroborates it.

How a defender detects it. East-west netflow analytics (a workstation that starts behaving like a scanner/jump host), lateral-movement analytics on logon events, and — structurally — segmentation so most hops are simply impossible. The choke point is the defender's deliverable: cut it.

Engagement significance. The internal pivot map of Meridian is precisely this graph. Lab 01 builds the planner; the map plus the choke-point list is the Phase 03 portfolio artifact; Lab 02 turns the choke point into the firewall rule.

Common misconception. "Reachability is a list of hosts." Reachability without the path, the cost, and the choke point is half the answer. The graph — not the list — is what lets you both attack and defend.

Chapter 7: Pivoting and Tunneling — SOCKS, Port-Forwarding, chisel/ligolo

Zero background. The attacker's machine usually cannot directly reach the deep internal segments — that is the whole point of segmentation. A pivot is the technique that borrows a compromised host's network position to reach further. Tunneling is the mechanism that carries the pivot's traffic. In graph terms: a pivot adds an edge to the reachability graph.

What it is — the three forwards. Using SSH (the canonical example; the same concepts apply to chisel, ligolo, Meterpreter, etc.):

What is a SOCKS proxy. SOCKS (RFC 1928) is a simple protocol where a client says "connect me to host:port" and the proxy makes the connection on its behalf, then relays bytes both ways. A dynamic SOCKS pivot means: I run a SOCKS server on (or tunneled from) the compromised pivot, point my tools at it (proxychains nmap, a browser, my scanner), and every connection now originates from the pivot's network position. In graph terms, the SOCKS pivot gives my machine all the pivot's outgoing edges.

my box ──(encrypted tunnel)──► [pivot, multi-homed] ──► internal segment (192.168.50.0/24)
   proxychains/SOCKS                 the pivot makes the real connection; I just relay through it
   ⇒ graph effect: add edges (my_box → everything the pivot can reach)

What chisel / ligolo are (conceptually). When SSH is not available, operators use purpose-built tunnelers:

• chisel — a fast TCP/UDP tunnel over HTTP/WebSocket; useful when only web ports egress. It builds the same local/remote/SOCKS forwards over an HTTP-looking channel.
• ligolo-ng — creates a TUN interface so the operator's box routes into the target segment as if natively connected (no proxychains needency); very clean, very effective.

In this repo these are concepts only — Lab 01 models the reachability a pivot creates; it does not build a tunnel. On the owned range (HITCHHIKER'S GUIDE) you stand up a real pivot to observe its telemetry, never against anything you do not own.

Why it exists / why it works. Segmentation blocks direct paths but usually allows a compromised internal host to talk to its neighbors (that is its job). The pivot inherits that allowed position. The defense is therefore not "block the tunnel protocol" (it hides in HTTP/SSH) but segment so the pivot host itself cannot reach much, and detect the pivot's traffic shape.

Telemetry it emits — a pivot is loud if you know the shape. A SOCKS/tunnel pivot has a recognizable signature:

• One internal host becomes a connection hub — many outbound connections to many internal peers from a host that normally talks to few. (East-west netflow fan-out — same shape as a scan.)
• Long-lived connections — the tunnel itself is a persistent connection (often to the operator's box or C2), unlike normal short request/response flows.
• Multiplexing — many logical streams over one transport; byte counts and timing look unlike a normal single application.
• chisel/ligolo over HTTP — "HTTP" connections that are long-lived, high-volume, and bidirectional, unlike real web browsing (a JA3/JA4 and behavioral mismatch).

How a defender detects it. Zeek conn.log + netflow analytics: flag internal hosts whose connection fan-out or long-lived-connection count spikes; flag "HTTP" sessions whose duration/volume profile is unlike browsing; correlate with the egress channel (Chapter 9). The structural control is segmentation + egress filtering so the pivot has few edges to inherit and no clean way home.

Engagement significance. The foothold-VPN-to-internal-pivot step of Operation Cedar Lattice is this chapter. Lab 01 plans which pivot edge buys the most reachability (and the cheapest path it enables); the HITCHHIKER'S GUIDE builds one on the owned range and watches the netflow it makes.

Common misconceptions. "A tunnel inside TLS/HTTP is invisible." The content is hidden; the behavioral shape (long-lived, high-volume, fan-out, multiplexed) is not. "Pivoting is exotic hacking." Pivoting is ordinary graph traversal — a pivot just adds edges; the cleverness is OPSEC, not magic.

Chapter 8: Network Segmentation — VLANs, ACLs, Zero-Trust, Microsegmentation

Zero background. A flat network — where every host can reach every other host — is an attacker's dream: one foothold reaches everything (the graph is fully connected). Segmentation is the practice of breaking that graph into zones so a compromise in one zone cannot freely reach another. It is the single most important structural network control against lateral movement.

What it is — the toolbox, coarse to fine:

Why it exists. Segmentation directly attacks the lateral-movement graph from Chapter 6: every deny rule removes edges. A well-segmented network is a graph where the foothold's reachable set is small and every path to the crown jewels passes through a few choke points you have hardened and instrumented. The goal is to make the attacker's BFS return almost nothing.

Under the hood — segmentation as graph surgery. Recall Lab 01: the choke point is the node whose removal disconnects foothold from target. A segmentation policy is the act of removing that node's edges with an ACL. Lab 02's blocks_path literally checks whether the firewall ruleset denies a hop on a proposed lateral path — i.e. whether the segmentation policy cut the edge.

flat network:        foothold reaches EVERYTHING (one big connected component)
segmented network:   foothold ──► its zone only ──[choke: jump host, ACL-controlled]──► server zone
                     every cross-zone hop must pass an explicit allow rule (deny-by-default)

Zero-trust, precisely. Zero-trust (NIST SP 800-207) drops the assumption that "inside the perimeter = trusted." Every access is authenticated, authorized, and encrypted per request, regardless of network location. In graph terms, an edge no longer exists just because two hosts are adjacent — it exists only when this identity is authorized for this resource right now. That collapses the attacker's inherited reachability dramatically.

Telemetry it emits. Segmentation itself is a control, but it produces detection value: every denied cross-zone flow is an alert-worthy event (someone tried a hop the policy forbids). A spike in denied flows from one host is a strong lateral-movement signal.

How a defender detects (and verifies) it. Beyond logging denies, you verify effective state: actually test that the path is blocked (Lab 02's blocks_path, and on the range, an authorized probe that confirms the hop fails). Intended config is not effective config — a rule can exist and be shadowed by an earlier any-any allow.

Engagement significance. The Phase 03 deliverable includes the segmentation policy that breaks Meridian's foothold-to-crown-jewel path. The choke points from Lab 01 become the deny rules in Lab 02; blocks_path proves the path is closed and that legitimate traffic still flows (regression).

Common misconceptions. "We have VLANs, so we're segmented." VLANs separate broadcast domains but do nothing without ACLs between them — inter-VLAN routing can leave the graph fully connected. "Internal traffic is trusted." That assumption is exactly what zero-trust deletes; flat-internal trust is how one phish becomes domain-wide compromise.

Chapter 9: Egress Filtering and Allow-Listing

Zero background. Segmentation (Chapter 8) controls internal (east-west) movement. Egress filtering controls outbound (north-south) traffic — what the inside is allowed to send to the internet. It is the control that catches the attacker's lifeline: command-and-control and exfiltration both have to leave the network.

What it is. Most networks allow almost anything outbound ("the inside is trusted to reach the internet"). Egress filtering inverts that to deny-by-default outbound, allowing only an explicit allow-list: outbound DNS to the enterprise resolver, web traffic to tcp/80/tcp/443 through a logging proxy, and specific business destinations. Everything else is denied and logged.

Why it exists. Every C2 channel and every exfil path is outbound. If the only way out is a logged proxy on standard ports, then:

• A beacon to tcp/4444 on a random internet host is denied and alerted — it had nowhere to go.
• A beacon hiding in tcp/443 must go through the proxy, where its destination, volume, periodicity, and TLS fingerprint are logged and analyzable.
• DNS tunneling has to use the enterprise resolver (logged for entropy/volume) because direct udp/53 egress is blocked.

Egress filtering does not stop a determined attacker from finding a channel — but it forces them onto a small set of monitored paths, which is exactly what turns C2 from invisible into detectable. This is the highest-leverage north-south network control.

Under the hood — the over-permissive rules an analyzer flags (Lab 02). The classic holes:

allow any  any        any        →  "any-any" — the entire egress policy is a no-op
allow user internet   4444/tcp   →  broad egress on a non-standard port — textbook C2 channel
allow dmz  internet   any        →  egress on ANY port to the internet — exfil channel wide open
allow srv  internet   443/tcp    →  FINE (standard egress; still route via proxy + log)

Lab 02's over_permissive flags the first three; egress_findings recommends the tightened allow-list (pin egress to tcp/443,tcp/80,udp/53 via the proxy; deny + log the rest).

Telemetry it emits. Egress filtering produces three high-value signals: (1) denied egress events (a host tried to reach the internet on a forbidden port — investigate); (2) proxy logs of all allowed web egress (destination, bytes, frequency — the beacon-detection substrate); (3) DNS logs from the forced resolver (the tunnel-detection substrate).

How a defender detects what gets through. Even with egress on tcp/443 only, the behavioral signals remain: beacon periodicity (regular call-home intervals), long-lived/high-volume flows to rare destinations, JA3/JA4 TLS fingerprints that match known tooling, DNS entropy/volume (Chapter 2). These are the Chapter-10 detections.

Engagement significance. The Phase 03 deliverable's egress allow-list is what would have caught FIN-LATTICE's beacon. The C2 phase (Phase 08) returns here: the malleable profile is designed to blend into allowed egress, and the detection is exactly the proxy/DNS/JA3 analytics this chapter sets up.

Common misconceptions. "We have a firewall, so egress is controlled." A firewall with allow any any outbound controls nothing. "Blocking outbound breaks everything." A correct allow-list permits all legitimate business egress; what breaks is the attacker's odd-port beacon — which is the point.

Chapter 10: Network Telemetry — Netflow, DNS, Proxy, Zeek, Suricata

Zero background. Everything in this phase ends here: the sensors that turn an attacker's network moves into detectable events. You cannot pair an offensive technique with its detection if you do not know what each sensor records.

The four sensor families.

Under the hood — what each detection actually measures.

• Scan in netflow: one source, many distinct destinations/ports, many tiny flows, high RST or no-response ratio, all in a short window. Threshold on distinct-destinations-per-source-per-minute.
• Lateral movement in netflow: a host whose east-west connection fan-out spikes (a workstation that starts initiating to many internal peers) — the Chapter-6 anomaly.
• Beacon in netflow/proxy: periodicity — regularly-spaced connections to one destination (compute inter-arrival times; low variance = beacon), often small request / variable response, to a rare destination. Jitter in the malleable profile widens the variance to evade this — so you also use destination rarity and JA3/JA4.
• DNS tunnel in DNS logs: high per-host query rate to one zone; high mean label entropy (encoded data looks random); long names; unusual record-type mix (TXT/NULL); many unique subdomains.
• TLS fingerprint: JA3/JA4 hashes the TLS client-hello parameters; tooling often has a stable, recognizable fingerprint even inside encrypted tcp/443.

Zeek concretely. Zeek passively parses traffic into logs you can detect on:

conn.log   one line per connection: hosts, ports, proto, duration, bytes  → scans, beacons, lateral, pivots
dns.log    every DNS query/response, query length, record type            → tunneling, DGA, AXFR
http.log   requests, hosts, user-agents, status                            → web C2, odd user-agents
ssl.log    TLS handshakes, SNI, JA3/JA4                                    → fingerprinted tooling in 443
notice.log Zeek scripts raise notices (e.g. scan detected)                 → packaged detections

Suricata concretely. A signature/protocol IDS: rules match known-bad patterns (e.g. a scan signature, a known C2 user-agent, a protocol anomaly) and emit alerts. Complementary to Zeek's behavioral logs — signatures catch the known, Zeek's metadata catches the novel.

How to think about it (the Pyramid of Pain, network edition). Blocking an IP or hash costs the adversary minutes. Detecting a TTP — the shape of a scan, a pivot's fan-out, a beacon's periodicity, a tunnel's entropy — costs them a redesign. Aim your detections at the behavioral shape, not the throwaway indicator.

How a defender operationalizes it. Collect netflow at the segment boundaries and the egress edge; force DNS through the logged resolver; force web egress through the logged proxy; run Zeek on the span ports and Suricata on the perimeter; write detections on shape (rate, fan-out, periodicity, entropy, rarity) and corroborate across sensors.

Engagement significance. This chapter is the detection half of the entire phase. Every Phase-03 offensive step — recon, scan, pivot, DNS tunnel, beacon, exfil — maps to one or more rows above, and the Phase-03 portfolio artifact's network-detection matrix is exactly that mapping. The labs encode the controls (Lab 02's egress allow-list) whose purpose is to funnel traffic into these sensors.

Common misconceptions. "Encryption blinds the sensors." It blinds L7 content parsing, not L3/L4 metadata, timing, volume, JA3/JA4, or DNS. "One alert is a detection." Robust network detection is correlation across netflow + DNS + proxy + Zeek; any single signal is noise.

Lab Walkthrough Guidance

Tackle the two labs in order — they compose into one attacker-and-defender story over the same graph.

Lab 01 — Pivot / Attack-Path Planner (Chapters 6–7). Implement in this order:

1. Graph.nodes() — the set of all node names (warm-up; you need it for choke points).
2. reachable(graph, start, exclude=None) — BFS the blast radius. Get the exclude semantics right: it drops every edge touching the excluded host, and exclude == start returns empty. This one function powers everything else.
3. reaches / reachable_targets — thin wrappers over reachable.
4. shortest_path — Dijkstra over edge cost. Push the node name into the heap tuple so ties break deterministically; return (path, total_cost); start == target is ((start,), 0).
5. choke_points — for each candidate host (not start/target), re-run reachable with that host excluded; if the target becomes unreachable, it is a choke point. Sort the output.

Then read the tests: shortest_path must pick the cheapest, not fewest-hop route; the DC's choke points include the app server (only path) but the ERP database's do not (it has a second path). That contrast is the whole lesson.

Lab 02 — Segmentation & Egress Analyzer (Chapters 8–9). Implement in this order:

1. flow_permitted — deny-by-default, first-match-wins; wildcards (any/*) match anything; no match means denied. This is the firewall's core decision; everything builds on it.
2. over_permissive — flag any-any, broad-egress (internet on a non-standard/wildcard port), and wildcard-port. Return index-ordered {index, rule, reason}.
3. blocks_path / first_blocked_hop — a path is blocked iff any hop is not permitted.
4. egress_findings — turn the over-permissive egress rules into allow-list recommendations.

The composition test is the payoff: the segmented ruleset permits Lab 01's designed pivot path but blocks the direct shortcut, and removing one allow rule breaks the path at a specific hop — that is segmentation turning a choke point into a control.

Success Criteria

You have understood this phase — not just passed the tests — when you can, without notes:

• Name, for each network layer, what an attacker learns and which sensor sees it.
• Explain DNS resolution and articulate DNS-as-recon, DNS-as-tunnel, and DNS-as-detection, including exactly what you measure to catch a tunnel (entropy, volume, record mix, unique subdomains).
• Walk the TCP handshake and state machine and explain why a SYN scan avoids app logging but not netflow detection, and why rate-vs-stealth is a real OPSEC tradeoff with no "invisible" option.
• Explain why lateral movement, a pivot, and a defender's choke-point analysis are the same graph, and compute reachability, the cheapest path, and the choke point by hand on a small graph.
• Distinguish local/remote/dynamic forwarding and explain a SOCKS pivot as "inheriting the pivot's edges," and name the netflow/Zeek shape that catches it.
• Design a segmentation + egress policy that breaks a given lateral path, and verify it blocks the path while legitimate traffic still flows.
• Pair every offensive step in the phase with a concrete network detection on shape (rate, fan-out, periodicity, entropy, rarity), not a throwaway indicator.
• State the passive/active recon boundary and the authorization line precisely.

Common Mistakes and OPSEC Failures

• Scanning at full rate. A full-rate scan is a netflow fan-out that any IDS flags instantly. Choose the rate deliberately and record it in the run sheet; there is no invisible scan.
• Treating a SYN scan as undetectable. It dodges application logs, not network detection.
• Crossing the recon authorization line. Passive OSINT is not active scanning. Never touch a host because it is reachable; the boundary is written authorization. (In this repo: all data is synthetic.)
• Forgetting a pivot is loud. A SOCKS/tunnel pivot makes one internal host a connection hub with long-lived, multiplexed, high-fan-out traffic — a textbook detection you must account for.
• Tunneling over DNS and assuming stealth. DNS tunneling is among the most detectable channels; the encoded names are statistically obvious.
• Building C2 over broad egress. An odd-port beacon dies the moment egress is deny-by-default; even a 443 beacon is logged by the proxy. Assume the egress edge is instrumented.
• Mapping reachability as a list. Without the path, the cost, and the choke point, you cannot attack or defend. The graph is the deliverable.
• Claiming segmentation from VLANs alone. VLANs without inter-VLAN ACLs leave the graph connected. Verify effective state, not intended config.
• Skipping the detection pairing. A pivot map without its netflow/DNS/proxy/Zeek detection fails this track's bar — the detection is what makes the offensive knowledge a defensible asset.

Interview Q&A

Q1. Walk the TCP three-way handshake and the state machine. Why does a SYN scan work, what does it leave half-open, and how does a defender detect it? A connection opens SYN → SYN/ACK → ACK; the endpoints move through LISTEN, SYN-SENT/SYN-RECEIVED, ESTABLISHED. A SYN scan sends the SYN and reads the reply — SYN/ACK means open, RST means closed, silence means filtered — but then sends RST instead of ACK, so the connection never reaches ESTABLISHED. Because the application's accept() never fires, the app often does not log it; that is the "stealth." But the network stack and any flow collector did see it: a SYN scan is a netflow fan-out — one source, many destinations/ports, tiny flows, high RST/no-response ratio in a short window — which is exactly what scan-detection thresholds and Suricata rules catch. So "stealth" means not application-logged, not undetectable; the rate-vs-stealth choice only changes how fast you cross the threshold.

Q2. Explain DNS resolution. How is DNS used for recon, as a covert C2/tunnel, and as a detection surface — and what exactly do you measure to catch a tunnel? A client asks its recursive resolver, which walks root → TLD → authoritative servers (caching by TTL) to return the record. Recon: public DNS + certificate-transparency + passive-DNS reveal subdomains, mail/SaaS infra, and email-auth posture without touching the target; a misconfigured AXFR dumps the whole zone. Covert channel: because DNS egress is allowed by default and queries traverse the org's resolver to any authoritative server, an attacker encodes data into subdomain labels (base32(chunk).tunnel.attacker.example); they own that authoritative NS, so they receive every label and answer with TXT/CNAME commands — slow but firewall-piercing. Detection: measure per-host query volume to one zone, mean label entropy (encoded labels look random), name length, record-type mix (TXT/NULL heavy), NXDOMAIN bursts (DGA), and unique-subdomain count — from Zeek dns.log. The control is to force DNS through the logged enterprise resolver and block direct udp/53 egress, so there is no path to an external NS that bypasses a sensor.

Q3. What is a pivot? Compare local, remote, and dynamic forwarding, and explain why a pivot is "just reachability over a graph." How does each appear in netflow? A pivot borrows a compromised host's network position to reach segments my own box cannot. Local forward: bind a port on my box that tunnels to one service reachable from the pivot. Remote forward: bind a port on the pivot that tunnels back to my tooling (e.g. a route home for C2). Dynamic (SOCKS): the pivot becomes a SOCKS proxy and any tool routes any connection through it — graph-wise, my box inherits all the pivot's outgoing edges. So a pivot is literally adding edges to the reachability graph; lateral movement is graph traversal. In netflow, a SOCKS/tunnel pivot turns one internal host into a connection hub — high east-west fan-out, long-lived multiplexed connections, byte/timing profiles unlike normal apps; chisel/ligolo over HTTP shows up as long-lived high-volume "web" sessions unlike real browsing. The structural defense is segmentation (give the pivot few edges to inherit) plus egress filtering (deny it a clean way home).

Q4. Given a foothold and a target, how do you find the quietest path, and how does a defender find the choke point? Why are those the same algorithm? Model hosts as nodes and "attacker-traversable hop" as directed edges, each weighted by detection-risk + effort. The quietest path is Dijkstra over those costs — not the fewest hops, the least noise. The defender runs the same search: a choke point is a host whose removal makes the target unreachable (re-run reachability with each candidate excluded; it is an articulation point / dominator). Offense finds the path; defense finds the cut; both are BFS/Dijkstra over one graph — which is why BloodHound and attack-path analysis are one algorithm, and why a pivot planner is also a segmentation-planning tool (exactly Lab 01).

Q5. Design the segmentation and egress filtering that stops a lateral path from a VPN foothold to a database. What does deny-by-default egress + an allow-list actually buy you? Segment east-west: put the VPN, DMZ, user, and server zones in separate segments with deny-by-default inter-zone ACLs; allow only the specific designed flows (VPN→DMZ:443, DMZ→server:1521). The choke point from the attack graph (the jump host / app tier) becomes the ACL boundary, and you verify blocks_path denies the direct VPN→server:1521 shortcut while the designed path still works. North-south: deny-by-default egress, allowing only DNS to the resolver and web to 443/80 through a logging proxy. That buys you the detection surface: an odd-port beacon (4444) is denied and alerted; a 443 beacon must traverse the proxy (logged destination/volume/periodicity/JA3); DNS tunneling must use the logged resolver. You have not made C2 impossible — you have forced it onto a few monitored paths, which is what makes it detectable.

Q6. What does SMB/NTLM authentication look like on the wire and in the logs, and what makes a relay or coerced auth detectable? SMB runs on tcp/445; lateral movement over it shows as network logons (EID 4624 type 3), SMB session/named-pipe telemetry, and Zeek smb/dce_rpc logs. NTLM is challenge/response and relayable: if an attacker can coerce a victim to authenticate to them (LLMNR/NBT-NS poisoning, or a coercion technique), they forward that auth to a third server. The tells: LLMNR/NBT-NS responder traffic on the segment, one source authenticating to many targets, and the relay's lateral logons. Defenses: disable LLMNR/NBT-NS (removes the trigger), require SMB signing (breaks relay), and segment so the attacker cannot reach the broadcast domain to poison it — the network-position control is the root fix.

Q7. You suspect C2 in a netflow + DNS + proxy dataset but have no malware sample. What do you hunt, and which signal costs the adversary the most to evade? Hunt on behavioral shape, not indicators: beacon periodicity (low-variance inter-arrival times to one destination), long-lived / high-volume flows to rare destinations, JA3/JA4 TLS fingerprints matching tooling, DNS entropy/volume for tunneling, and east-west fan-out for the pivot that feeds the beacon. On the Pyramid of Pain, blocking the C2 IP/domain costs minutes (they rotate it); detecting the TTP — the beaconing shape, the tunnel's entropy, the pivot's fan-out — costs them a redesign. So prioritize the behavioral detections; corroborate across sensors (a single signal is noise). Jitter widens periodicity variance, so lean on destination rarity + fingerprint + volume together.

Q8. What is the difference between passive and active reconnaissance, and where exactly is the line? Passive recon uses third-party/public data (DNS, CT logs, passive-DNS, WHOIS, OSINT) and never sends the target a packet — generally lawful and invisible to the target. Active recon (port scanning, banner grabbing, AXFR, probing logins) interacts with the target's systems, which they can log — and which, without authorization, is a crime in most jurisdictions regardless of intent. The line is authorization to interact, not whether harm occurred: you never scan a host because it is reachable. Authorized active recon requires a named owner, scope, methods, rate, window, stop conditions, and a deconfliction contact (Phase 00). In this repo there is no target at all — every lab is synthetic metadata.

References

Primary protocol sources

• Kozierok, The TCP/IP Guide — the protocol reference for this phase.
• RFC 1034 / 1035 — DNS concepts and implementation (https://www.rfc-editor.org/rfc/rfc1035).
• RFC 9293 — TCP (https://www.rfc-editor.org/rfc/rfc9293).
• RFC 826 — ARP (https://www.rfc-editor.org/rfc/rfc826).
• RFC 9110 — HTTP semantics (https://www.rfc-editor.org/rfc/rfc9110).
• RFC 4120 — Kerberos V5 (https://www.rfc-editor.org/rfc/rfc4120).
• RFC 1928 — SOCKS protocol version 5 (https://www.rfc-editor.org/rfc/rfc1928).
• Microsoft [MS-SMB2] and [MS-NLMP] (NTLM) protocol specifications.

ATT&CK network techniques

• Discovery: Network Service Discovery (T1046), Remote System Discovery (T1018).
• Lateral Movement: Remote Services (T1021); Use Alternate Authentication Material (T1550).
• Command and Control: Application-Layer Protocol (T1071), Non-Standard Port (T1571), Protocol Tunneling (T1572), Proxy — Internal/External (T1090).
• Exfiltration: Exfiltration Over C2 Channel (T1041), Exfiltration Over Alternative Protocol (T1048).
• Adversary-in-the-Middle (T1557): LLMNR/NBT-NS Poisoning (T1557.001), ARP Cache Poisoning (T1557.002).

Detection and defensive sources

• Zeek documentation — conn, dns, http, ssl, notice logs and the scripting framework (https://docs.zeek.org).
• Suricata documentation — rules and protocol detection (https://docs.suricata.io).
• NIST SP 800-207 — Zero Trust Architecture.
• MITRE D3FEND — the defensive technique mapping (Network Traffic Analysis, Network Isolation).
• David Bianco, The Pyramid of Pain — choosing detections by cost-to-adversary.
• Talks and write-ups on DNS-tunneling detection (entropy/volume) and netflow-based lateral-movement hunting (east-west fan-out, beacon periodicity, JA3/JA4).

(Phase 00 owns the authorization boundary; Phase 05 goes deep on SMB/NTLM/Kerberos; Phase 08 returns to the C2 channel and the proxy/DNS/JA3 detections this phase sets up.)