~/tutorials/039-the-tunnel-is-the-operation.md

039: The tunnel is the operation

You are inside the first machine. The thing you want is on the second network, behind it. Almost every real engagement lives here for most of its hours, and the exploit that got you in is by then the smallest part of the story.

This lesson is the one to read slowly. It doubles the patience of the tier: the three tunnel shapes, each one run, each answer read, and then the reason the whole operation is downstream of this one command. The apparatus page called the proxy and the chain carries every command here with its full explanation, the three-network lab, and the timing receipts. This page teaches the thinking. That page pays the means.

The picture, before any command

Three networks, and you are holding the first one.

Yours. The attacker box, your keyboard, your tools. Nothing to compromise here, this seat is the one you own.

The hop network. The first machine. This is the box lesson 034's shell landed on. It has two faces: one facing you, one facing deeper in. It can reach places you cannot, and that reach is the only reason it matters.

The far network. Machines that answer the hop and have never heard of you. No route from your box reaches them. The packet you want to send has no path, and the rest of this lesson is about giving it one.

Draw it before you type it. Yours on the left, the hop in the middle, the far network on the right, and an arrow through the hop. Every command in this lesson is one sentence about that arrow.

The three shapes

Port forward. One door

The simplest move. You want one port on one far machine, and you want it on your own desktop, as if the far machine were local.

$ ssh -L 3389:10.10.20.15:3389 user@first-hop

Read it left to right, because every part answers a question you will ask again in different clothes. -L says local forward. The first 3389 is the door on your own box, localhost 3389. The 10.10.20.15:3389 is the real target, and here is the part beginners get wrong: that address is resolved by the hop, not by you. You cannot reach 10.10.20.15. The hop can. So the hop resolves it, connects to it, and carries your traffic the last leg.

The consequence: the target address can be a name only the hop's dns knows, or an address on an interface you have no route to. The door works because the hop does the reaching.

Keep the ssh session open. The door lives exactly as long as the session does. Close the laptop lid, the door dies. That fragility is not a flaw to engineer around in the lab, it is the thing to feel once, so that on a real engagement you know what you are holding.

Then use the door:

$ rdesktop 127.0.0.1:3389

You are now rdp'd into a machine your own network cannot see. The door turned far into local, which is the whole trick.

Dynamic. The door that becomes a corridor

One port forward serves one port. A real far network has dozens of machines and hundreds of ports, and forwarding them one at a time is a row of doors where you wanted a corridor.

$ ssh -D 1080 user@first-hop

-D says dynamic. That single port, localhost 1080, is now a socks proxy: any program that speaks socks hands its connections to this port, and ssh answers each one by asking the hop to reach the destination. The corridor reaches everything the hop reaches.

But programs must be told. Most tools do not read proxy settings from the air. Two ways to tell them:

$ proxychains nmap -sT -Pn 10.10.20.0/24
$ curl --socks5 127.0.0.1:1080 http://10.10.20.15/

The first is the wrapper, which forces a third party program through the corridor. The second is the flag, for the tools that already speak socks. Both live in the same truth: the destination is now a thing the hop resolves, not you.

nmap over socks needs its two flags, and the reasons are the lesson. -sT because the socks protocol carries full tcp connections, not half open syn packets, so nmap must do the boring connect scan instead of the fast syn scan. -Pn because the ping probe would have to travel the corridor too and answers nothing, so skip discovery and just try the connection. Half of nmap's speed and stealth options are syn-shaped and die at a proxy, which is a fact about the tunnel shaping the toolset, the first of many.

Reverse. The door that opens outward

The first two shapes run from your side. The third runs from inside.

$ ssh -R 8080:localhost:80 you@your-box

Typed on the hop. You are the far machine now. ssh -R tells your box: open port 8080 on yourself, and anything that arrives there, send it to me, the machine typing. The 8080 on your box becomes a door into the hop's localhost 80.

The subtlety that makes this shape hard: your box must be reachable from the hop. On a lab bench with a cloud host, it is. Inside a real network behind NAT and egress filters, it may not be, and that is why teams carry a cloud host with a listener, or a domain fronted redirector, or any of the shapes whose only job is to be reachable. Your lab uses the cloud host from lesson 031 for exactly this.

One warning before you fire it. A reverse tunnel is an outbound connection from the target network to yours. In the lab that is safe by construction. On a real engagement it is the single most monitored event class there is, and the honest operator asks, before typing, whether the scope letter covers traffic that leaves the target network.

Why the tunnel is the whole operation

Because everything after it happens through it. Scanning through a socks proxy is slower, and the numbers are on the apparatus page, timed on a real lab. Tools break on proxies and must be replaced or wrapped. Nmap loses half its capability over tcp and tells you so, which is why the lines above use -sT and -Pn. The operation's pace, toolset, and noise floor are all set by the tunnel, hours before any target sees a packet.

The exploit is a moment. The tunnel is the posture you hold for days. Plan the second with more care than the first.

Honest limits

A tunnel multiplies what you can reach. It does not multiply what you may reach. Scope that names the first host does not name the second network, and the moment your pivot touches a machine outside the letter, the word for what you are doing changed while you were typing. The rule that opened this tier holds at every hop: your machines, or somebody's written word, checked again at each boundary you cross.

Try it

1. Build the three network lab. The full build, three docker networks and a hop container wired into two of them, is the apparatus page the proxy and the chain, and every command there runs as printed.
2. Walk one port forward through the hop. Then stand up the socks corridor and scan the far network through it, and use the door on a service that answers.
3. Measure it. Time the same scan direct against through tunnel. The ratio is the fact you will remember when a client asks why the assessment takes days. The apparatus page carries the timing receipts from the lab, so you can compare your numbers against ours before you trust your own.