SANS ISC InfoSec Forums

I am sure that many penetration testers among our readers try to minimize their travel. While many years ago we had to be physically present for internal penetration tests, today it is very common that client organizations setup virtual machines for penetration testers, which are then used to perform internal penetration tests.
In most cases this will boil down to two VMs: one with Kali Linux and the other one with your favorite scanner. However, it is also quite common that only one VM is provided and that one is used to tunnel traffic through (or pivot through it).

I was recently performing an internal penetration test where the only VM I had was a Kali Linux VM, with SSH to it.
Depending on the target environment, one can manually perform a penetration test, but since I was dealing with a larger number of machines in the scope, I wanted to run a vulnerability scanner. However, the only VM I had was the Kali Linux VM and an SSH connection.

Tunneling network traffic through the VM seems like an obvious choice, however this not all that trivial since the scanner generally needs raw access to sockets. So this diary describes one solution I came up with – let us know if you have another solution for this problem.

The diagram below shows our target devices. We will want to establish an SSH connection from the vulnerability scanner server to the Kali Linux VM, and use that connection to scan the target network.

SSH has extremely powerful tunneling capabilities (actually, so powerful that it is a bit scary). We will use SSH’s Tunnel option to tunnel traffic between two TUN TAP interfaces. These are virtual devices that behave as real interfaces so our scanner will not know the difference.

First we need to create such devices on both sides with the following command:

# tunctl -t tap0

Now we can assign an IP address to this interface. On the scanner server:

# ifconfig tap0 10.100.100.100 netmask 255.255.255.0

And on the Kali Linux VM:

# ifconfig tap0 10.100.100.101 netmask 255.255.255.0

We will link those devices with an SSH tunnel. Now, in order to do that we need to be root on both sides so I created an SSH key that I copied on the Kali Linux VM:

This allows us to login without specifying a password. Additionally, the target SSH server must allow tunneling – this can be done by adding the following line into /etc/ssh/sshd_config on the Kali Linux VM:

PermitTunnel=yes

And we are now ready – we can simply login from the scanner server to the Kali Linux VM with the following ssh command:

# ssh -o Tunnel=ethernet -f -w 0:0 root@kali.linux true

This will establish a tunnel and execute the “true” command (which does nothing), and send the process into background.
The tunnel should be up now, we can check that with the ethtool command:

We’re not done yet though. We need to now configure our scanner server to send data for the target network (10.10.0.0/8 above) through that tunnel. While there are more and less complex ways to do that, I opted to simply enable forwarding on the Kali Linux server with NAT (masquerading) and setup a route to the target network.

There we go – our tunnel is up and happily moving data between our networks. No more battling with proxychains! We can now simply start a scan as we would normally do and SSH will do the job for us.
Before ending this diary, let me mention another interesting tool: sshuttle (https://github.com/sshuttle/sshuttle). In many cases you can use this tool as well, its benefit is that it does not require root privilege on the target server. I had some issues running a scanner with sshuttle so YMMV.

Could it also be a solution to set up a VPN server (e.g. openvpn) on the Kali Linux and to make a VPN connection from your scanner to the Kali Linux?
What would be the advantage of an SSH tunnel versus a VPN tunnel?

On a semi-related note, tunneling is a great method to run command and control from the outside to the inside or to exfiltrate data. I've seen as much as 3 M/bps capacity when DNS tunneling was used. With DNS tunneling the data is encoded into either DNS TXT records where each DNS packet has a corresponding encoded data packet. When the query hits an Internet DNS server that's also running the tunneling software it gets decoded and turned back into the original data packet. A second method uses long random subdomains encoded as data. Both methods usually are able to "hide in the noise" of normal network traffic levels.

If your IPS or firewall has protections against DNS and SSH tunneling be sure to enable it. If you have Check Point firewalls and IPS, their tunneling protections were never successfully bypassed by pen testers in over a decade of my experience and it detected them every time with zero false positives.