top of page
  • Writer's pictureJack Button

Pivoting through a network: The Vault - Hack The Box walkthrough.

Updated: Aug 1, 2019


Being a pentester often requires professionals to work across large, enterprise environments. Key skills required are: an understanding of networking and networking protocols, understanding how to exploit vulnerabilities in DNS, how to evade IDS/IPS and firewalls, how to pivot from one machine to another and escalate privileges, and as companies move their data and services to the cloud; methods of escaping containers or exploit APIs. Without shelling out for expensive labs access, such as the ones available on the OSCP, it can be hard to find 'real world' examples to practise on. I was recently told about a box on HackTheBox called 'Vault'. This is my walkthrough guide to completing it...


An Nmap scan shows us that SSH is running on port 22 and that there is an Apache server running on port 80 (http).

nmap scan of

It does take two hops to get to the host, but this is due to the fact that the Kali machine is connected via a VPN to HackTheBox.

SSH will be useful if we can get hold of some credentials, but our first focus should be the web server. Before navigating to the IP address in a web browser, we can set a couple of scans running. First, Nikto...

Nikto scan of

Nikto is a great tool for scanning web servers for common vulnerabilities. In this case, whilst there are opportunities for cred stealing, XSS, or defacement suggested by the scan, without a live person at the other end logging in, there is not an obvious angle of attack.

Dirb is another useful tool for enumerating web servers. It uses a word list to search for directories and files, both visible and hidden.

dirb scan of

Not a huge list of directories, but somewhere to start. Let's check out index.php first.

This could be useful information, there is a website under construction by this company.

The other page gives a 403 error code as Dirb had already elicited. It might be worth coming back to this with the inspector tool and BurpSuite later, but we have some new information from the previous page that is worth exploring first.

Another Dirb scan using our new information of 'Sparklays' reveals a number of new directories to examine more closely.

dirb scan of

Navigating to the sparklays/design page then leads to a file uploader. This is where we can start an attack.


The earlier Nikto scan during the enumeration phase suggested that the X-Content-Type-Options header is not set, this might allow us to upload files that are either not image files, or other file types with image extensions. An easy, quick exploit could be to upload a php file that will initiate a reverse shell.

Msfvenom is perfect for quickly creating a malicious file that will do just that. The code below instructs msfvenom to make a meterpreter reverse shell that calls back to the attacking machine on port 1234 and call the file name shell.php5

Using msfvenom to create a malicious payload

We then need to upload the file to the server.

Navigating to the file in the browser should then execute the malicious code on the server.

Note the 'Waiting for'; there's no error occurring and the page is not loading - this usually suggest that the code is executing as desired. It's also worth noting at this point that you should set your browser not to auto-refresh as this will reset whatever connection we pick up in the next step.

Next, we can load up Metasploit and set up our listener to collect the reverse shell.

Getting a meterpreter shell on

As you can see we collect the reverse shell and now have a meterpreter shell on host I tried a few simple commands such as 'use priv' and 'getsystem', but that would have been far too easy for a box like this (always worth a try though!).

I poked around for a while in the meterpreter shell and then dropped down to a bash shell. This reverse shell could have been set up with a php script and netcat if so desired, and had the Metasploit route not worked, this is what I would have done. However, Metasploit is a great tool and, if it works it works!

There are quite a few directories and files, as there are two user accounts 'alex' and 'dave'.

Alex user doesn't have much of interest except empty folders, but once we start looking in the dave user there are a few interesting discoveries.

From the green arrow down to the bottom of the image is where we hit the jackpot. There is a list of server ips: the DNS + Configurator, Firewall, and The Vault; however, we see The Vault, but no ip is given. Next, there is a key 'itscominghome', this could be useful later, and finally, some SSH credentials for the dave user.

We can now log on via SSH as the dave user. This will be a more stable shell and means we now have a firm foothold on the server.

Further enumeration to facilitate lateral movement

Running 'ifconfig' as dave shows us the many connections this server has. The virtual bridge highlighted is of particular interest:

Let's see if any of the machines listed in the earlier text file are present on the subnet. We can run the following command:

This simple bash script tells the dave user's machine to ping all the available ips in the subnet and use the grep tool to provide a list of hosts that respond.

The hosts from the list we discovered are here, but no Vault. It must be hiding behind the firewall. The list we discovered said that was the DNS server, so that makes a logical next target to pivot to. There is no nmap on the Ubuntu box, so we can us netcat instead. Using this netcat command, we can find out what ports are open.

This will give us a verbose readout of all port connections and then grep the list to display succeeded when a port responds.

We discover that ports 22 and 80 are open, so we can now take the steps necessary to pivot onto the DNS server.

Pivot to the DNS server.

To look at port 80 on we can set up an SSH tunnel that redirects the port from that host to our machine.

We're asked for the user dave's password and the port redirect then begins.

If we then navigate to http://localhost:1234 in a web browser, it will display whatever is hosted on port 80.

We've found the DNS settings and VPN configurator. The DNS settings page gives a 404 response, but the VPN configurator allows us to create an ovpn file and upload it. Using dirb again to enumerate the web directories there are some hidden files.

This shows what appears to be a reverse shell command.

The above image shows how the script operates.

We can, therefore, input the reverse shell code into the vpn upload box, press update file, then test. Make sure to press 'test vpn', as the first couple of times I tried it, I missed this step and it took a little troubleshooting of my code and listener set up to discover that this was necessary.

If we then set up the corresponding netcat listener we can catch the reverse shell and get root access to the DNS server.

Further enumeration as root leads us to discover the user flag for dave and more SSH credentials for dave on this host.

We can close the reverse shell and log in to this machine via SSH.

We're now logged in as user dave on the DNS machine. However, on our reverse shell we had root user. Using sudo -l shows us that dave can use sudo on any command. Running sudo su and typing in dave's password for this machine, gives us root privileges again.

Running a route -n command and then digging in the /etc/hosts file shows us the subnet and the ip address for the Vault. We now know that the Vault is located at

Next, we can check the logs and use grep to find strings containing 192.168.5

Looking towards the end of the logs, the firewall is accepting inbound traffic from port 4444 to host which is listening on port 987.

Pivot to the Vault.

I tried a few different commands here, but nmap wouldn't work. Eventually, I used the ProxyCommand option on netcat which allows SSH to travel through it.

Using dave's sudo password then gives us access to the Vault.

Some enumeration then leads us to the root flag, but it's encrypted as a gpg file and unreadable on this machine as it doesn't have gpg.

The Ubuntu box does though, so we can use base32 (I tried base64 and it wasn't on the machine) to encode it and copy it from the Vault to the Ubuntu box.

Decrypting the final flag

Using nano we can create a file that contains the base32 data. We can then run a command to re-encrypt the root data into a gpg file meaning we've essentially replicated the root file on the Ubuntu box.

We then use gpg to decrypt the file.

Typing in the passphrase 'itscominghome' (that we found right at the start) then allows use to read the final flag.

Summing up

I hope you enjoyed working through this box as much as I did. Here's a quick review and recap some of the skills and methodologies we used to complete this box.

Enumeration of a web server

Exploiting a web server through malicious file upload (reverse shell)

Scanning the network through another host.

SSH tunnelling and port redirection

Configuring a VPN to run malicious code (reverse shell)

Privilege escalation

Examining logs

Using ProxyCommand to tunnel SSH traffic through netcat

Encryption and decryption


bottom of page