Enumeration
As with every engagement, it starts with information gathering. Ran the standard nmap scan and found the following port open on the target system. A scan for UDP ports was also done but nothing interesting was seen.
┌──(kali㉿kali)-[~/HTB/Keeper]
└─$ sudo nmap -sC -sV -p- -oA nmap/full.tcp 10.129.62.141
[sudo] password for kali:
Starting Nmap 7.94SVN ( https://nmap.org ) at 2023-12-26 19:19 EST
Nmap scan report for 10.129.62.141
Host is up (0.19s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 35:39:d4:39:40:4b:1f:61:86:dd:7c:37:bb:4b:98:9e (ECDSA)
|_ 256 1a:e9:72:be:8b:b1:05:d5:ef:fe:dd:80:d8:ef:c0:66 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 937.59 secondsInitial Access
The first thing I did was see if there was any low hanging fruit by performing a simple brute force against TCP port 22. Unfortunately, no credentials were found so moved on to TCP port 80.
┌──(kali㉿kali)-[~/HTB/Keeper]
└─$ hydra -C /usr/share/seclists/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt ssh://10.129.62.141Simply navigating to the target system’s IP in the browser revealed that there should be some sort of ticketing system that is only accessible via a domain name. After adding that entry to my /etc/hosts file I was able to access a “Request Tracker” login page.
Doing a quick Google search did not reveal any default credentials for the “Request Tracker” platform so I tried some common usernames and passwords. To my surprise root::password worked. Once logged in I was able to see an issue in the queue. The issue seems to be with Keepass on a Windows system.
After reading the details of the ticket it seems as though Keepass crashed and created a dump file on the Windows system. This file was then pulled from the Windows system to the system I am targeting.
Privilege Escalation
After remoting into the system I began to look for the Keepass dump file that was mentioned in the ticket. Eventually I found it and pulled it to my system. Did some research and discovered CVE-2023-32784. This vulnerability allows the extraction of the Keepass master password from a Keepass .dmp file. Details about the vulnerability can be found here – https://nvd.nist.gov/vuln/detail/cve-2023-32784.
I found the following Python implementation to pull the master password from the dump file.
https://github.com/z-jxy/keepass_dump
The output from the Python script was not what I was expecting as I was expecting some sort of English-based password. But as with all things I know nothing about or when I am lost I started Googling. Turns out the master password is not English as the following term popped – Rødgrød med fløde. That explains the garbled output from the Python script, the password is Danish.
After installing keepass2 on my local system I was able to open the .kdbx file using the master password of Rødgrød med fløde. In the database was password which I tried to use to switch from the lnorgaard user to the root user but that did not work. So I moved onto the PuTTY key file.
Doing some research revealed that a PuTTY key file can be converted to an OpenSSH private key. I used the following article to just do that – https://superuser.com/questions/232362/how-to-convert-ppk-key-to-openssh-key-under-linux. All that was required was to install PuTTY tools and then provide it the PuTTY key file to be converted. Just like that I had a private SSH key that I was then able to use to access the target.
