64Base: 1.0.1 Vulnhub’s VM Walkthrough


This is my write-up for the 64Base Vulnhub VM.

netdiscover -r $IP/24 to locate the VM’s IP


nmap and nikto to enumerate the target’s web service.
Nikto returned quite a few results from the robots.txt. From the output, it can be concluded that there are a few false positives.
Nmap returned quite a few interesting ports. The actual SSH hosted is on port 62964 instead of 22. I spent awhile trying to exploit the radmin service on 4899 but no to avail. Therefore, I was quite positive that the actual attack vector lies on the web service.

I created a directory file from the robots.txt file, ready to brute force the target.

I turned to WFuzz to brute-force the directories from the text file I’ve created.
We will take note of the results from the WFuzz attack.


I visited the site manually on port 80.


The page-source revealed the first flag, in a long hex string format.


I tried the credentials discovered on the /admin directory and SSH, but no to avail.
I then discovered a hint on the post.html page.


The Imperial-Class seems familiar, it is part of our results from the WFuzz scan. However, there was an error in the capitalization of the directory path.

After a few tries with the hint provided in the page source… the additional value BountyHunter was required in the directory.

I tried decoding the hex strings and it returned partial values for flag2, I then tried again combining all the hex strings.



The Youtube link hinted that “Burp” was required. Which I immediately knew it was referring to Burp Suite Proxy tool. I was proxying my requests anyway so I just have to look up in the history tab.


Decoding the value of flag3…


Awesome, seems like command injection/code execution to me.

Remembering the hint from post.html, we are suppose to use system instead of exec. Trying it out…


Nice. flag4 was discovered as well.


Another credential that did not work for /admin or SSH. We will take note of this.

Next, I tried to execute some code that will get me a reverse shell. It seems that there are some input filtering in-place and the login.php script checks for the usage of netcat.

I then found out that wget is available on our target.


I spent quite some time here trying to figure out how to wget a reverse shell from our web server onto the target machine, after messing around with characters like “;”, “&&”, and “|”, it was possible to bypass it by using 2 “|” instances instead of 1.


Ready to receive our reverse-shell connection.


Using the find command, we can quickly discover flag5.
It seems that flag5 seems to have some content judging it by the file size. We should always respect the hints and definitely “look inside”.
It seems to be a image file from the file command output

Downloading the flag5 over to our Kali machine…


Running the usual exiftool command on it, it can be seen that there is a hex string in the comments section of the image file.


I tried to use python to convert the hex string and then base64 to decode it but it was not successful. The output indicates that this is a RSA key file and I decided to use xxd instead to decode it.


I made use of the key file to try and SSH into our target as root, but I was prompted for the key phrase… surprise surprise.


I fired up John to crack the key phrase with our trust worthy rockyou.txt wordlist. Bingo.
usetheforce it says.


flag6 can be seen right after we login as root.


After decoding it numerous time, it was finally over…



Interesting VM.
The part where I have to spend quite awhile bypassing the input filtering to get a reverse shell was fun.
I made sure I check out the login.php to see how the filtering was implemented afterwards 🙂

Cheers and stay safe people!