/var/log $ cat "Hack The Box - Vault Walkthrough"
2019-04-05 | hackthebox ctf
- Find a HTTP upload form.
- Bypass the upload filter to upload a PHP reverse shell.
- Get the SSH credentials, a password and find a second machine running HTTP.
- Use the OpenVPN config website on the second machine to get a reverse shell back to the first one.
- Get the user flag and SSH credentials for the second machine.
- Find the address of the third machine.
- Figure out how to ssh into the third machine.
- Transfer the encrypted root flag from the third machine back to the first machine.
- Decrypt the root flag with the found password from step 3.
Tools used: nmap, gobuster, browser, php reverse shell, netcat, ssh, openvpn, ncat, scp, file, gpg
nmap we find OpenSSH running on port 22 and Apache httpd on port 80:
SSH is only accessible with valid credentials. This leaves HTTP to enumerate. Opening
gobuster on the domain leads to nothing. Taking the information presented on the website, the server’s organization name seems to be ‘Slowdaddy’ and they have a first client named ‘Sparklays’. Trying to open
http://10.10.10.109/slowdaddy results in 404. But browsing to
http://10.10.10.109/sparklays results in 403:
gobuster -e -w /usr/share/wordlists/dirb/common.txt -r -x .php,.htm,.html,.txt -u http://10.10.10.109/sparklays/ we can find two interesting files (
../sparklays/login.php) and another directory (
Having a look at
http://10.10.10.109/sparklays/admin.php shows a login form:
http://10.10.10.109/sparklays/login.php just shows ‘access denied’:
So it could be that we need to login or bypass this. But still there is
http://10.10.10.109/sparklays/design left for another bruteforce attempt with
gobuster -e -w /usr/share/wordlists/dirb/common.txt -r -x .php,.htm,.html,.txt -u http://10.10.10.109
/sparklays/design/. And we find one more page (
../sparklays/design/design.html) and one more directory (
Opening ‘design.html’ we simply get a link to ‘changelogo.php’:
The name ‘changelogo.php’ suggests that the upload form is for image files. As it is good practice for such forms to have filters to prevent mischief, we first test if it works at all with a jpg and if we can find our file in
../sparklays/design/uploads. And yes we can:
Conclusion: The server runs PHP and there is a working file upload which we can try to use to get server access.
Getting a Reverse Shell
With to goal in mind to get a get shell we first try to upload an unobtrusive .php file simply containing
<?php phpinfo(); ?>. And as assumed it isn’t working:
Trying different methods to bypass the filter mechanism we find that that
.php5 files are allowed:
And fortunately they also get executed:
So the next step is simple: upload a PHP reverse shell script and start a netcat listener to get a shell:
Enumerating /home and SSH Access
We can find two users on the box: ‘dave’ and ‘alex’. Having a look at
/home/dave/Desktop we find three interesting files:
The ‘Servers’ file gives us two more IPs: 192.168.122.4 for ‘DNS + Configurator’ and 192.168.122.5 for ‘Firewall’. The entry ‘The Vault - x’ suggests this is where we can find either the user or root flag but we don’t know it’s address by now. Checking with
ifconfig we find our box has also the IP 192.168.122.1 in the 192.168.122.0/24 subnet.
The content of ‘key’ (itscominghome) suggests it is a password for something we don’t know yet.
Knowing that the box is running ssh and assuming the content of
ssh are dave’s ssh credentials (dave:Dav3therav3123) we try to ssh into the box to have a fully interactive shell and persistent access:
Pivoting to 192.168.122.4
Running a simple ping script to check out the remaining 192.168.122.0/24 subnet we find the two IPs .4 and .5 alive:
So either the mentioned ‘The Vault’ doesn’t react on ICMP pings or it is not in the subnet.
Checking for useful tools we find netcat installed. So we can use it as a simple port scanner to check out the two alive addresses (
nc -w 2 -zv 192.168.122.4 1-1000 2>&1 | grep -v -i "refused")
So we find .5 has no open ports in the range from 1-1000 and .4 has 22 and 80 open. If this brings us no further we might have to go back an try the full range. But first let’s use netcat again to check if .4 is really running SSH and HTTP:
This confirms that we indeed have SSH and HTTP. Assuming that SSH needs valid credentials, starting with HTTP presents the better options. Since it would be a nightmare enumerating it via command line we forward port 80 with SSH (
ssh -L 127.0.0.1:80:192.168.122.4:80 email@example.com) so that we can conveniently explore it:
The ‘… DNS Settings’ link doesn’t work. The other one leads to this:
The text shown implies 192.168.122.4 has OpenVPN installed and we can input config file entries and execute it. Researching about OpenVPN we find out that it can be used to execute commands after it connects. This could be used to get a reverse shell, but we need to figure out which configuration works by trial and error.
This step took me quite a while. I ended up with a configuration containing a
bash reverse shell command:
Paste the config on the website and hit ‘Update file’ to load it on on the box:
Start a listener on the first box and click ‘Test VPN’ to get a shell. Practically we’re directly logged in as ‘root’. Having a look around
/home we see again ‘alex’ and ‘dave’. While
/home/alex contains no obvious cluses,
/home/dave contains the user flag we’re looking for and again something which looks like SSH credentials:
Getting into ‘The Vault’
/home/dave/ssh we have the credentials ‘dave:dav3gerous567’ which could be for SSH access on
192.168.122.4 aka ‘DNS’. And indeed they are, so we can now tunnel through
10.10.10.109 to ‘DNS’ from our attacker machine with
ssh -t firstname.lastname@example.org ssh email@example.com. As ‘dave’ is a sudoer on ‘DNS’ we elevate ourselves with
/etc/hosts we find the missing address for ‘The Vault’:
We can’t ping
192.168.5.2 so this might be a dead end. Good thing is ‘DNS’ has
nmap installed. But doing a ping agnostic scan brings nothing really useful to light except that the IP seems to be alive:
So back to enumerating ‘DNS’ to see what we can come up with. In
var/log/auth.log we find something interesting:
Especially the entry with
/usr/bin/nmap 192.168.5.2 -Pn --source-port=4444 -f looks interesting. So we are also running it and now we get an open port when trying it from 4444:
As there is also
ncat installed we check what we get on port 987 when coming from 4444. Turns out to be SSH:
As ‘ssh’ does not allow the configuration of a source port we need a little trick here. We start a
ncat listener and tell it to execute a shell commad when establishing a connection, thus redirecting the stdin and stdout of that command to use the
ncat connection (see Ncat Users’ Guide for details). Then we connect to the listener with
But SSH needs some credentials. Best guess is to use the same that we have for ‘DNS’ (dave:dav3gerous567) and hope for the best. We execute
ncat -l 3333 --sh-exec 'ncat 192.168.5.2 987 --source-port 3333' & ssh dave@localhost -p 3333 to find it working:
In dave’s home dir we find a file called
root.txt.gpg which presumably is the root flag. Checking it with
file we find it encrypted:
Getting the root Flag
We remember that on the initial machine we found a file named
key which contained the string ‘itscominghome’ which could be the password to decrypt the flag. But neither ‘The Vault’ nor ‘DNS’ has
gpg installed. Only the inital machine has it (or our attacker machine). So the first step is to transfer the file from ‘The Vault’ to ‘DNS’ using the same trick with
ncat as before (mind the capital P for specifing the port in
Then we transfer the file one more time from ‘DNS’ to the initial machine with
scp (alternatively we can use
base64 to copy/paste it):
Now we can decrypt the root flag with
gpg -d /tmp/root.txt.gpg using ‘itscominghome’ as passphrase: