Hacking V: Tunnelling Techniques

We deliberately also kept an eye out for network information during privilege escalation, because IT infrastructure is often split into different network segments. Many times these comprise a DMZ network (demilitarised zone), in which IT systems and their services are enabled for the outside world. But critical systems generally remain hidden to us as attackers. In order to penetrate deeper into a network, we may need to navigate through already compromised IT systems. For example, we could configure an IT system that was compromised by us to act as a proxy, or use it to tunnel internal services back to us.

The secure shell protocol (SSH) enables not only direct access to an IT system, it also supports packet tunnelling. We can use three variants for this purpose: local port forwarding, remote port forwarding and dynamic port forwarding. In principle, any of these techniques would allow us to communicate with a service that is inaccessible to us through an intermediate host (pivot), insofar as this host is permitted to communicate with the service.

Let’s assume the following scenario: We have gained full control over the blog of Dubius Payment Ltd, and we have determined that its open network connections are connected to a remote database. This database is located within an internal network, which apparently can only be reached via the blog due to the firewall settings. But in order to still be able to access the database from our attacking machine, our goal is to tunnel to the database via the blog with ssh.

With local port forwarding we connect to the SSH service on our pivot (blog.dubius-payment.com), which establishes a tunnel back to our attacker machine via the port indicated (4444). So all queries that we then send to our local port are received by the SSH service and forwarded to the internal service (MySQL):

This technique, however, requires an SSH user on the pivot. If such a user is not available, we can use remote port forwarding. For this purpose, we must be able to execute commands on our pivot. With remote port forwarding, we connect in an opposite way to local port forwarding from our pivot (blog.dubius-payment.com) to our own SSH service on our attacker machine. As before, a tunnel is now created which we can use to address the internal database (MySQL):

A tunnel must be set up or an SSH command must be executed for every individual service, both for local port forwarding and remote port forwarding. This becomes impractical when scanning an internal network, such as the private network of Dubius Payment Ltd. Therefore, dynamic port forwarding is a better alternative. With dynamic port forwarding, the pivot (blog.dubius-payment.com) acts as a SOCKS proxy via SSH:

Together with the proxychains tool, we can easily use our attacker machine’s local tools to access inaccessible areas, because all data is routed through the SOCKS proxy. To do this, we only need to set our attacker machine and the above port (127.0.0.1:4444) as the SOCKS proxy in the proxychains configuration file and execute proxychains before each of our commands, as the following port scan shows:

proxychains nmap -Pn -sT db.dubius-payment.com

As soon as we have identified an internal network and can reach it via a pivot, the fun starts all over again: a “new world“ of IT systems that is yet to be discovered and compromised.