Pivoting and Tunneling Part 6: Defense in Depth — Segmentation, Egress Filtering, and Catching a Pivot on a Fortinet Fabric

Lab-only note: closing out the same simulated CONTOSO.LOCAL lab used throughout this series. Authorised testing only — everything below is either attacker technique for defensive understanding or direct configuration guidance.

The full chain, told once, start to finish

Pulling every part of this series into one narrative, the way an actual engagement (or an actual incident) would read:

1. Foothold. The Impacket Deep Dive series established a shell on WKS01 as j.reyes and, further down that series, domain admin via a full Kerberos attack chain. That series never needed to leave the corporate segment WKS01 sits on — DC01 and FS01 were both directly reachable.
2. The wall. FIN-DB01, holding the payroll database, sits in 10.10.40.0/24, a segment the firewall policy permits exactly one host into: FS01, on port 1433 only. Domain admin on the corporate segment doesn’t grant a route into a differently-firewalled VLAN — segmentation did exactly what it was supposed to do.
3. Single pivot. Part 1 covered SSH forwarding as the baseline; Part 2 and Part 3 built a real tunnel to FS01 using Chisel and ligolo-ng, verified against the actual current binaries rather than assumed syntax.
4. The packet-level tax. Part 4 showed why that tunnel silently stalls on large transfers unless the effective MTU is measured and the MSS clamped — a detail most pivoting write-ups skip entirely.
5. Double pivot. Part 5 chained a second tunnel through the first to actually cross into 10.10.40.0/24 and reach FIN-DB01, at which point the rest of the Impacket toolkit — secretsdump.py, mssqlclient.py — applies exactly as it would on a directly reachable host.

Every individual step in that chain is well-documented elsewhere. What the segmentation boundary in this lab actually bought the defender wasn’t “impossible to cross” — it was friction, and more importantly, more chances to get caught. Two additional tunnels, each with independent detection signals, an MTU problem that risks the attacker’s own transfer silently failing, and a chain of internal-to-internal connections that a single well-instrumented fabric can see end to end. That’s what segmentation is actually for once you accept that a sufficiently persistent attacker can eventually cross most single boundaries: not a wall, a toll each hop has to pay.

Hardening checklist, mapped to what this series actually demonstrated

1. Internal segmentation firewalling, not just perimeter. The 10.10.40.0/24 policy in this lab (permit FS01 only, port 1433 only) is the right shape — the fix isn’t the policy, it’s making sure every internal boundary gets this treatment rather than a flat internal network with only the perimeter firewalled. On a FortiGate fabric this is the same VDOM/internal-segmentation-firewall pattern covered in One Box, Many Firewalls: FortiGate VDOMs — treat sensitive internal segments (finance, HR, anything with regulatory scope) as their own security domain with explicit, logged inter-VDOM policy, not an implicit-allow internal zone.

2. Default-deny egress, evaluated per host role. Neither Chisel nor ligolo-ng needs anything exotic outbound — Chisel specifically because it looks like ordinary HTTPS. The control that actually matters is asking, per host role, “does this specific server or workstation have any legitimate reason to make new, arbitrary outbound connections to the internet,” and answering “no” by default for anything that isn’t a user workstation or a system with a documented external dependency. A file server like FS01 making an outbound connection to an unfamiliar internet host is exactly the kind of policy violation a default-deny egress rule set, rather than a default-permit-with-exceptions one, catches immediately.

3. TLS inspection on the fabric that carries this traffic. Chisel and ligolo-ng both ride inside TLS, and both — per Parts 2 and 3 — default to self-signed certificates unless an operator deliberately dresses the connection up. Full SSL/TLS deep inspection (rather than certificate-inspection-only mode) on the FortiGate edge, applied at minimum to egress from server-role VLANs, catches the self-signed-default configuration described in Part 2’s detection table cold, and gets meaningfully harder for an attacker to evade without either compromising a real internal CA or accepting a much noisier operational footprint.

4. Flow-level monitoring for internal-to-internal anomalies, not just perimeter alerts. Part 5’s double-pivot detection story depends entirely on catching FS01 talking to WKS01 — an internal-to-internal connection that never crosses a perimeter firewall log at all. This is squarely what FortiAnalyzer and FortiMonitor for SD-WAN SLA observability’s flow collection is built to surface: baseline which hosts normally talk to which, and alert on new, sustained, internal sessions between roles that have no documented reason to communicate.

5. Zero-trust posture over implicit network trust. The single biggest reason this entire six-part chain worked at all is that reaching FS01 from WKS01 was assumed trustworthy because both sit on the same corporate segment. Zero Trust Meets the Overlay makes the broader case for this, and it applies directly here: identity- and posture-based access control between WKS01 and FS01 — rather than “same VLAN, therefore trusted” — would have required the attacker to present valid credentials and a healthy device posture at every hop, not just the first one.

Detection cheat sheet

Series step	What to look for	Where it shows up
SSH -R/-D (Part 1)	Outbound SSH from a host with no operational reason to run one; unusual local SOCKS listeners	Host-based EDR, auth logs
Chisel (Part 2)	Long-lived HTTPS connection, ~25s keepalive cadence, self-signed cert on 443, JA3 mismatch	TLS-inspecting firewall, NetFlow session duration
ligolo-ng (Part 3)	New TLS connection to an unfamiliar host on an arbitrary port; nmap --unprivileged scan pattern from an internal host	Flow monitoring, IDS on unusual scan behaviour
MTU/PMTUD (Part 4)	Not itself a detection signal — but repeated small-MSS retransmissions on an otherwise unremarkable connection can indicate active pivot traffic under load	Packet capture, if already under investigation
Double pivot (Part 5)	Internal-to-internal connection between hosts/roles with no documented relationship	NetFlow/IPFIX baseline deviation
Full chain	Sequence of the above across multiple hosts within a short window	SIEM correlation across the fabric, not single-host alerting

None of these are exotic — every one of them is a flow-, certificate-, or baseline-level signal rather than a payload signature, which is exactly consistent with everything else this site has argued about detecting living-off-the-land technique: you catch behaviour, not bytes.

Where this fits

This closes the loop back to the Impacket Deep Dive series’s own closing post, Defense in Depth and Detection — that post covered detecting the AD-side techniques; this one covers what happens once an attacker who’s already inside starts looking for what segmentation is hiding. Between the two, the full path from initial foothold to a defended, segmented finance system is documented end to end, offense and defense both, which is the whole premise this site keeps coming back to: understanding the thief properly is what makes the fence worth building.