03 — Dynamic forward -D

Learning objectives

• Stand up a loopback SOCKS -D listener and send one approved tool through it.
• Contrast when -L is still better; call out DNS local vs via proxy.

Intuition

-D is a general door through B — powerful, easier to over-reach than -L.

Class reminder

-D has no host:port target — only a local SOCKS port. Apps must speak SOCKS (or use a SOCKS-aware wrapper). FAQ: whiteboard FAQ.

Practitioner

Goal: SOCKS proxy on A; B becomes the exit for approved app traffic.

Shape: Listener on A; B dials whatever the SOCKS client asks for (still authorize destinations).

Pattern

ssh -N -o ExitOnForwardFailure=yes \
  -D 127.0.0.1:1080 user@B

Then point one tool through SOCKS (browser proxy, or proxychains to a single allowed host:port). Do not treat "scan the subnet" as a tunnel test.

Teach the contrast with -L

DNS callout (say once)

Ask: does the client resolve names locally or through the proxy? Wrong answer here causes "works in browser, fails in tool" confusion. Confirm in your tool's SOCKS/DNS settings before the next lab.

Hop chain (why dynamic matters)

1. App on your laptop → 127.0.0.1:SOCKS_PORT
2. SOCKS listener on A — binds local loopback (ssh -N -D 127.0.0.1:port …)
3. SSH to jumpbox :22 — encrypted control channel (no shell with -N)
4. Jumpbox dials whatever host:port each SOCKS request named

ssh -N -D 127.0.0.1:1080 user@JUMPBOX

Whole point: one local SOCKS door; no fixed target:port in the flag.

Checkpoint

• lsof -nP -iTCP:1080 -sTCP:LISTEN on A
• One approved host:port via SOCKS succeeds
• Friends can say when they'd still pick -L instead

Evidence: artifacts/evidence/03-D-check.md.

Cite: [S-PC-01], [S-OSS-01], Academy pivoting module [S-HTB-ACAD-01].

Deep dive

SOCKS5 vs SOCKS4 and DNS: wrong setting looks like "tunnel broken" when it is name resolution [S-OSS-01 | medium | derived].

Check

One approved host:port via SOCKS; friends state when they'd still use -L.