Preamble
In April, I started working through the HackTheBox Pro Lab, “Dante”. As a Pro Lab, Dante strays away from the usual machines that HackTheBox stands up and instead offers a complete network to enumerate, attack, and pwn. However, this means that I was forced to use a skill that I had only briefly been introduced to: pivoting.
Pivoting is a key post-exploitation skill that enables an attacker to use an already compromised target to get at additional targets that the attacker would otherwise not be able to directly access.
As the skill suggests, pivoting is not quite so straightforward. Fortunately, there are a variety of tools available:
Meterpreter
If your shell on a target was achieved via meterpreter session, then the good news is that there is plenty of automation/tools built into meterpreter to help with pivoting. Metasploit has an autoroute meterpreter script that will add additional networks to Metasploit’s routing table.
Once the route(s) are added, targets (RHOSTS) may be directly engaged with metasploit payloads.
Proxychains
Another option I explored with was using the dynamic port forwarding tool, proxychains. This tool is nice as it can be used to force any program we use as an attacker through the dynamic proxy. The downside of using proxychains is that it isn’t quite as intuitive as meterpreter.
If proxychains is installed on the attacker machine, then there is a configuration file for it residing in /etc/proxychains.conf. The bottom of the file can be altered to specify the proxy (or set of proxies) to pivot traffic through.
When pivoting through an already compromised target, we can leverage proxychains and pair it with SSH tunneling by setting the proxy to localhost and a local port.
ssh -i privateKey -D9050 user@
Note: in the above command I’m using a private key generated with ssh-keygen (named ‘player’) and binding it to port 9050. In the course of events, I had already copied the corresponding public key to the user’s authorized_keys file found in their .ssh directory.
When proxychains is invoked, it tunnels the application through the ssh connection (assuming that the /etc/proxychains.conf is set to socks4 127.0.0.1 9050), running as if it were running locally on the target.
It should be noted that there are some hang-ups to this, as various programs do not play well with this tunnel or the SOCKS4/5 protocols (such as nmap or gobuster). In nmap’s case, it is both slow and requires the -sT option (or else nmap defaults to performing SYN scans which doesn’t work with proxychains). Gobuster also only works with the SOCKS5 protocol.
Chisel
Another option for pivoting is via the use of a tool called chisel. There are some instances where an SSH tunnel cannot directly be achieved from the attacker machine to the target to pivot on. In those circumstances, Chisel can provide what’s called a “reverse pivot”, wherein the target connects back to a designated listening port on the attacker and sets up yet another listener.
When the attacker directs a program at the second listener, that traffic is piped to the pivot and directed at the specified secondary target.
I could describe further in depth how to deploy Chisel, but Ippsec actually demonstrates the technique when working through the “Reddish” machine on HacktheBox.
SSHuttle
One concern I had working through this was how I could view/render various web content in my attacking browser as I pivoted through the network; there are a number of secondary targets that host HTTP(S) webservers but - absent cURLing the content via one of the above methods - I wasn’t sure how to view the sites.
A little research showed that there was already a tool called SSHuttle that could perform this work for me.
Continuing the use of the private key mentioned in the proxychains section (above), the VPN can be established by running the following command:
sshuttle -vr user@
In the command above, I am invoking sshuttle to verbosely (-v) make a remote connection (-r) to the target host with the given username. Because in this particular instance I am using a private SSH key to do so, I also have to instruct sshuttle to pass a particular command via --ssh-cmd. Since I want to pivot to any discovered hosts on the secondary network, I list that secondary network with a subnet mask of 255.255.255.0 (or CIDR notation /24).
Closing Thoughts
There are many other tools and mechanisms for performing pivoting (including classic portfwd), but the ones above were what I ended up leveraging in the target environment. As I progress, I’m sure that there will be plenty others that I’ll end up leaning on.