Keeper Writeup — HTB

Gabriel Marques
5 min readAug 23


Hello everyone! This is my first writeup for a HackTheBox’s machine. Hope you enjoy! If you have any tips or want to comment something about this writeup (or something I could have done better), please do! Thanks in advance!
I’m using Parrot 5.3 Security Edition for this writeup.

First, I’ll start checking the top 1000 open ports (since it’s an easy machine, shouldn’t be that hard to get an open port for exploiting). I like to use -vv just for checking more info while scan is being done.

nmap -sC -sV -vv [MACHINE IP]
Ports 22 and 80 open

Apparently we have a nginx 1.18.0 running. Let’s check the website’s content.

Website’s content

As some other machines, we’ll need to add the hostname to our /etc/hosts file.

sudo nano /etc/hosts
Adding the IP address to both ‘keeper.htb’ and ‘tickets.keeper.htb’

Ok, after adding the hosts and clicking the link, we get to another page.

Best Practical’s Request Tracker 4.4.4

Trying “admin/admin” and “admin/password” didn’t work. Let’s search the RT’s default username and password for checking if it works.

No work at all to get this

Magically it worked. Now we’re inside the Request Tracker.

Request Tracker main page

I’ll try to search the tickets for any clue.

Search > Tickets > Simple Search
After search “a”

We’ve found a ticket from Enoch Root to Lise Nørgaard.

Ticket’s history

Nothing really useful, but now we know there’s two users in this system.
Let’s head to the Users area.

Found it on Admin > Users, let’s go to Select
Users on this website

Let’s check both users for more information.

Nothing userful on root user
Apparently, username and password in clear text

Next step is test if this credentials are working, maybe user ‘lnorgaard’ uses the same password for the machine.

ssh lnorgaard@keeper.htb
## password Welcome2023!
And we’re in! Going with “ls” to see if the flag’s already here.
Yup, there’s user.txt, going with “cat user.txt” to get the user flag

Now, we’re heading to the root flag. I like to user two commands to check SUID and Sudo permissions.

sudo -l
find / -perm -u=s -type f 2>/dev/null
First one didn’t work, moving to the next.
Nothing unusual for SUID escalation.

Noticed there’s a file named “” inside. We’ll open a quick HTTP server using Python to get this file and check its content.

python3 -m http.server
Serving on port 8000

On our side, we’ll download the file and check what’s inside.

wget http://[MACHINE IP]:8000/
Downloading .zip file
.zip contents

We have two files inside, a .dmp file and a .kdbx file. After some search, it seems that “KeePassDumpFull.dmp” is a dump file from Windows’ KeePass software, and “passcodes.kdbx” is a KeePass file for some kind of password (maybe root password).
There’s a CVE for KeePass dump files (CVE-2023–32784), and there’s a GitHub PoC for this specific scenario (check here).

I’ve downloaded the same files on my Windows for better checking, GPU stuff and all. After cloning the repo, let’s try to check the .dmp content if the CVE works.

dotnet run [Path to dump]
It worked! There’s the output

So, we get the following “probable” pasword (considering * as a wildcard character, since the PoC wasn’t able to retrieve from file):

*{l, `, -, ', ], A, I, :, =, _, c, M}dgr*d med fl*de

Essentially, we know the PoC file couldn’t retrieve three characters, considering the first one will always be a wildcard. So we have “**dgr*d med fl*de”. Considering the username “lnorgaard” and the user being “Lise Nørgaard”, after a Google search for this last name, we see that this is usually a Dannish lastname.

There we see from Christian Nørgaard on Wikipedia

So, what if we just pasted our password in Google Translate to check if something pops up?

As expected, nothing here.

What happens if we tried to remove the asterisks?

We get “rødgrød med fløde” from here.

That would probably be the password, let’s check it downloading and using KeePass to open the “passwords.kdbx” file.

Using as master password
And here we are!

Double clicking “keeper.htb” entry, we get some interesting info.

An easy password?
Permission denied.

Couldn’t be that easy, huh? If permission for login is denied using password, I guess there’s other way around it. When you double-click “keeper.htb” entry, you’ll see that the notes are interesting.

PuTTY .ppk file on plain text?

Next step we’ll copy this text and save it on a “file.ppk”, then try to open with PuTTYGen.

Yes, it works!

Next, we’ll go on Conversions > Export OpenSSH key (force new file format), and save as “key.pem”. Then, we’ll use this key to try SSH again on keeper.htb to see if it works.

ssh -i key.pem root@keeper.htb
Bad permissions? Let’s try again

Apparently that your private key can’t be accessible by others, so let’s reduce the permissions and try again.

chmod 700 key.pem
And we’re in!

Last step, same as user flag, check if the flag is on “/root”, then get the flag.

Here we go!

Hope you enjoyed it, thanks for reading it!



Gabriel Marques

Technology passionate since 1996 and cybersecurity student.