Port forwarding is a pivoting technique that allows network packets to be relayed from a port to another. The tunnel can be setup between two controlled and connected machines, hence allowing a bridge between a network and another. That concept is similar to PAT (Port Address Translation), an extension of NAT (Network Address Translation) that allows multiple devices on a LAN to be mapped to a single public IP address by assigning addresses to ports numbers.
This technique is useful when an attacker wants to stay under the radar or when access to a service is limited to a specific network.
There are multiple types of port forwarding used during penetration testing engagements.
Local port forwarding: access a port that only a remote machine can communicate with (e.g. "firewalled" network, internal localhost network).
Remote port forwarding: access an attacker's service (from the attacker's machine's networks) from a remote workstation that can't access those networks directly.
Dynamic port forwarding: tunnel the whole attacker's network traffic (instead of only one port) through a remote machine. Explained in SOCKS proxy.
Reverse dynamic port forwarding: tunnel the whole network traffic from a remote machine through the attacker's machine. Explained in SOCKS proxy.
Port forwarding can be set up in many different ways.
One of the most easy is by relying on SSH however, it requires to have an SSH server running on the controlled machine and a valid account. The tester needs to open an SSH connection to the machine that should be turned into a SOCKS proxy, and supply
-L option for a local port forwarding, along with the ports and addresses to bind
-R option for a remote port forwarding, along with the ports and addresses to bind
The command can also be used with
-N option to make sure no command gets executed after the SSH session is opened.
# Local port forwardingssh -N -L $LOCAL_ADDRESS:$LOCAL_PORT:$REMOTE_ADDRESS:$REMOTE_PORT [email protected]# Remote port forwardingssh -N -R $REMOTE_ADDRESS:$REMOTE_PORT:$LOCAL_ADDRESS:$LOCAL_PORT [email protected]
Once the ssh command exits successful (or once a session opens) the tester can then proceed to use the tunnel.
In the following example (real-world badly secured network), let's assume the remote attacker wants to access a internal workstation's web service (i.e. localhost), and that the attackers controls multiple machines that can bridge the multiple networks at play.
This setup allows the attackers to connect to the workstation web-service on port
80/TCP by targeting port
1111/TCP on his own machine. His machine will forward the communication to pivot1's port
2222/TCP. Pivot1 will forward to pivot2's
3333/TCP. Pivot2 will forward to workstation's
In the following example (real-world badly secured network), let's assume the remote attacker wants a target workstation to connect back to him with a reverse shell, and that the attackers controls multiple machines that can bridge the multiple networks at play. There are multiple scenarios where using a combination of remote port forwarding would be interesting or even required.
the attacker wants to stay stealthy by using multiple specific hops to make the traffic legitimate-looking (workstation communicates with an internal server, an internal server communicates with a DMZed server, a DMZed server communicates with a remote client)
the target workstation doesn't have access to the remote attacker's network (i.e. to the Internet)
This setup allows the target workstation to communicate with the attacker's port
1111/TCP by targeting pivot2 on port
3333/TCP. Pivot2 will forward the communication to pivot1's port
2222/TCP which will itself forward to attacker's port