HackTheBox Writeup — Cache

Jack Roberts
6 min readNov 30, 2020


Hack the Box is an online platform where you can practice your penetration testing skills. This is my write-up for the HackTheBox machine ‘Cache’, which runs a Linux OS and is one of the ‘medium’ rated machines.

1. Cache Info Card.

1. Summary

The initial foothold on this box involves clever enumeration with cewl and wfuzz to find another virtual host, which reveals the OpenEMR web application, and then chaining together an SQLi vulnerability, password cracking and an authenticated RCE vulnerability to get ‘www-data’. We then escalate to the user ‘Ash’ using some previously identified credentials, and enumerate a local memcache server to get credentials for the user ‘Luffy’. Luffy is seemingly inside docker container, so we use a standard GTFObins one-liner to break out of this restricted environment and escalate to root.

2. Enumeration and Initial Foothold (www-data)

As always we start off with an Nmap scan to see what services are running. A handy tip is to store the machine’s IP address in an environment variable so we don’t have to type it in each time we need it, although this only applies to the current tab and needs to be repeated if extra tabs are open.

2. Cache Nmap Scan.

Only two ports open, SSH and HTTP, lets go and check out the web application.

3. Default Web Application

A very basic website with a couple of links, including an author and login page. The login page is a barebones implementation and since we don’t have any credentials yet, let’s check out the author’s page.

4. Default Web Application — Author.html

Some interesting information to be grabbed here, including the author’s name (Ash), a hostname (cache.htb) and maybe a hint to checkout Ash’s other project HMS. Perhaps we can access this if we can login?

After failing with some default credentials, I decided to look at other files that are loaded with this web application and found an interesting ‘functionality.js’ file.

5. Website Credentials for ‘Ash’

Awesome! The website only performs a client-side check for user credentials. However, logging-in with these credentials provides nothing useful, just another web page.

6. Result of Authenticated to the Website.

I then took a look back at the author page and specifically the hostname ‘cache.htb’ and wondered whether Ash’s other project has a separate hostname (i.e. virtual host). To check this I created a wordlist from the author.html page and ran a wfuzz scan to fuzz for other hostnames associated with the IP address

7. Cewl — Wordlist Generation

To get the correct format to fuzz for the hostname, I had to refer back to the network tab within the web developer tools to see the request, although this could have also been done in BurpSuite.

8. Wfuzz — Virtual Host Fuzzing

HMS gives a 302 redirect. Adding ‘hms.htb’ to the /etc/hosts file to associate this virtual hostname with the IP address we get the OpenEMR web application.

9. Modified /etc/hosts file.
10. OpenEMR Web Application Default Page.

I began to research exploits for OpenEMR but only found (authenticated) RCE exploits, meaning we had to find some credentials. Further research found an SQL Injection vulnerability at the following location:

11. SQL Injection PoC

Perhaps we can dump the database and any user credentials? Lets first get the vulnerable network request with BurpSuite, and save it into a text file to pass into SQLmap.

12. SQLi Vulnerable Network Request

Now to identify the databases we can run SQLmap with the command below, which identifies two databases.

sqlmap -r burp_request.txt --threads=10 --dbs
13. SQLMap — Identifying Databases incl. Openemr

Lets inspect the tables this database contains to try and find where the user credentials are stored.

sqlmap -r burp_request.txt --threads=10 -D openemr --tables
14. SQLMap (2) — Identifying Table Containing User Credentials

The final command to run with SQLMap dumps the data from the ‘users_secure’ table and we identify a username and password hash.

sqlmap .... --threads=10 -D openemr -T users_secure --dump
15. SQLMap (3) — Dumping User Credentials

We can tell from the password hashes format that it is a ‘bcrypt’ style hash, so I ran this through JohnTheRipper and it cracked it easily. This gave us the following credentials to go log into the OpenEMR web application:

  • username : openemr_admin
  • password : xxxxxx
16. JohnTheRipper — Cracking Password Hash

After logging into the OpenEMR web application, I used searchsploit and downloaded the authenticated RCE scripts, however I saw many HTB users complain that using these scripts (without explicit modification) were causing the box to break, so I opted for a safer route. That is, to find an area I can upload my PHP reverse shell code.

After much enumeration of the application I found the following PHP files accessible at:

17. OpenEMR — Uploading PHP Reverse Shell Code

With this uploaded I started a netcat listener on my machine, accessed the document at the location below and obtained a reverse shell as www-data.

18. Initial Foothold: www-data

3. User — Ash

Phew, that was long.

Thankfully escalation to Ash is super easy, we can simply use the credentials identified in the ‘functionality.js’ file previously and grab the user.txt flag.

19. User Shell (Ash) and User.txt

4. User — Luffy

After performing some enumeration with LinPeas, I noticed that the box was listening for connections locally on port 11211. This port is associated with Memcached servers and would be fitting considering the name of the box.

20. LinPeas (Active Ports)— Memcache Port Listening Locally

Using Raj Chandel’s blog post on penetration testing memcached servers as a reference point, I connected to the port as ‘Ash’ with telnet and managed to extract user credentials for Luffy.

21. Extracting Luffy SSH Credentials from Memcached Server
22. User Shell (Luffy)

5. Root

One thing I noticed earlier when running LinPeas was a lot of references to Docker, and although no docker instances are running, Luffy is a member of the docker group.

23. Luffy in Docker Group

GTFObins documents a method to run and bind the host’s OS to the docker container’s /root . Firstly I checked the docker images available on the machine and we find ‘ubuntu’. This is the only thing we need to change from the GTFObins one-liner, although I did also change the shell to spawn from ‘sh’ to ‘bash’.

Running this one-liner gives us a root shell where we can grab root.txt.

24. Root Shell


Thanks for reading and keep an eye out for future writeups! Feedback is always welcome, and my HackTheBox profile is linked below.



Jack Roberts

MSc Cyber Security Student at Lancaster University. Mostly posting CTF writeups from HackTheBox, TryHackMe and VulnHub.