Started off with an Nmap scan.
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-21 10:48 AEST Nmap scan report for 10.10.10.152 Host is up (0.23s latency). Not shown: 995 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd 80/tcp open http Indy httpd 220.127.116.1146 (Paessler PRTG bandwidth monitor) 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
I noticed that ftp (port 21) was open so I navigated to my browser to see if it allowed me to get unauthenticated access.
The unauthenticated access allowed me to see the contents of the machine. The level of access on this service allowed me to navigate through to the Users folder and obtain user.txt
I also tried navigating to the Administrators folder but unfortunately, it was not possible to do so. I then went back to my nmap scan and noticed the http service (port 80) was running the “Paessler PRTG bandwidth monitor” application.
I researched vulnerabilities for this application and noticed that there was an authenticated remote code execution exploit that I could possibly leverage. I was able to obtain default administrator credentials (prtgadmin:prtgadmin) but the login attempt failed. None of the other ports looked like a promising entry point so the next thing I attempted to do was go back to the ftp service and start enumerating for credentials files.
According to the following article, the PRTG application stores its data within:
%programdata%\Paessler\PRTG Network Monitor
By navigating to this directory, I noticed a couple of interesting files:
“PRTG Configuration.dat” and “PRTG Configuration.old” did not reveal anything interesting, however inside of “PRTG Configuration.old.bak”, I noticed the following content:
<dbcredentials> 0 </dbcredentials> <dbpassword> <!-- User: prtgadmin --> PrTg@dmin2018 </dbpassword>
I tried logging in with these credentials but I was met with a login failed error message again. I then noticed the file was a backup from 2018 and decided to update the password to match the current year and try again. This time, the login attempt was successful and I was redirected to the administration dashboard.
Although there were manual ways to perform the exploit, I decided against it and opted for a scripted approach. I found a script from the following repository.
As per the instruction, I retrieved the authentication cookies and ran the exploit.
The only thing left for me to do was to use these credentials. I used the smbexec.py from the impacket library to create a semi-interactive shell to the machine. The only thing left to do was to obtain the administrative flag!
python smbexec.py netmon/pentest:'P3nT3stemail@example.com Impacket v0.9.18 - Copyright 2018 SecureAuth Corporation [!] Launching semi-interactive shell - Careful what you execute C:\Windows\system32> C:\Windows\system32>more "C:/Users/Administrator/Desktop/root.txt" 301**************************7cc