SSH Tunneling / Port Forwarding / Pivoting for Internal Pentesting

When performing internal pentesting, it is usual to ask the customer to connect an AWS instance to their network. That instance has a virtual machine with Kali Linux installed. From there we can perform the internal pentesting, either a network pentesting or a pentesting of an internal web page of the customer. There are also cases where the customer is provided with a pentester laptop that connects to their internal network.

Either way, we can use SSH tunnels to route all our traffic through that instance.

Summary

X.X.X.206 > Our local IP Address

X.X.X.58 > AWS Instance IP Address

X.X.X.0 > Kali VM inside AWS Instance IP Address

X.X.X.30 > Internal Website IP Address

Inital SSH Connection with PuTTY

You can connect to the AWS instance from Windows using PuTTY, to check that you have access:

The instance will have your public SSH key added, so you will be able to log in with your SSH private key. Remember that you need to use a .ppk file. You can convert it using PuTTYgen:

When you have it configured, press the “Open” button and you will get access to the AWS instance:

Now we have to connect to the Kali VM that is inside the laptop/AWS (remember to use the port 2222):

We can check that we have connectivity to the target website from here:

In this scenario, we need to connect to the Kali VM inside the AWS instance to get access to the client’s website. We cannot access to the client’s website from the AWS instance.

We could start testing from this Kali VM, but if it’s terrible to work from here. In my opinion the best way to work is to create a SSH tunnel. We can create one tunnel from our local VM to the AWS instance and another one from the AWS instance to the kali vm:

Tunnel from our local VM to the AWS instance:

• In our local vm run:

ssh -D 9876 -f -N <username>@<laptop/aws ip> -i <path to ssh private key>

We have now access to the AWS instance, but this is not enough because we cannot reach the client’s web server from here. We have to chain two SOCKS proxies so we can get access.

Tunnel from the AWS instance to the kali vm:

• In the AWS instance:

ssh -D 9999 -f -N root@127.0.0.1 -p 2222

Please have a look at this piece of art so you can have a graphic understanding. This is what we have now:

Proxychains

Now we can use proxychains to route all our tools using the socks tunnel that we have created.

Install the tool if you don’t have it and edit /etc/proxychains4.conf adding these two lines at the end:

socks4 127.0.0.1 9876socks4 127.0.0.1 9999

This way all the traffic will go first through the AWS Service using the first tunnel, and then to the internal Kali VM using the second one.

Now we can run any tool using proxychains from our local vm:

You can run any tool like gobuster, dirb, nikto, whatweb, nessus, wpscan… just add proxychains4 before the command. -q is to run it quietly, and -f is to use the config file that we edited before.

You can run Firefox so you can see the website from your local VM:

As you can see all the traffic is going through the kali VM, so if we search our IP in google it shows that it is .0

This works with any tool… Except with BurpSuite. For BurpSuite you won’t be able to run it through proxychains due to compatibility problems with chromium.

Running Burpsuite through the tunnels

BurpSuite allows to configure a socks server to redirect the traffic in User Options. Open BurpSuite (without proxychains) and go to User Options:

If you add the first tunnel to the SOCKS Proxy section, you will be able to reach the AWS instance. But BurpSuite does not have the option to chain two SOCKS proxies, so we cannot reach the internal Kali VM.

But there is a fix for this. I was able to solve this issue by adding a local port forwarding from the AWS instance:

ssh root@127.0.0.1 -N -f -L 7890:X.X.X.30:443 -p 2222

This way when we visit localhost:7890, we will reach the internal web server (X.X.X.30:443) through the kali VM.

From the AWS instance we can now reach the web server:

As we have access from the BurpSuite of our local VM to the AWS instance, we can reach the website on BurpSuite navigating to localhost:7890:

That’s it! We have access to everything now from our local VM.

Of course, if we have access to the client’s website from the AWS instance, you can go directly using the first tunnel and you won’t need to configure the second one.

** Another method for connecting to the jump attack box can be found in this new post **