Netmon is an easy Windows box. It was discovered that the machine has an open FTP port that allows for anonymous access. There, we also found the user flag rather quickly. Further, we found configuration files for the running web application called PRTG Network Monitor. In one of them (old.bak) we found a valid username and password. However, this did not work and we had to guess the correct password based on the information we got from the old password. Once we had access to the system, we were able to exploit a known authenticated remote code exeuction, which gave us system access.
Enumeration
As always, we start by scanning the target machine’s open ports:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
rustscan --ulimit 5000 netmon.htb -- sV -sC -oN nmap_scan
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack Microsoft ftpd
| ftp-syst:
|_ SYST: Windows_NT
| 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
|_02-25-19 11:49PM <DIR> Windows
80/tcp open http syn-ack Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
|_http-trane-info: Problem with XML parsing of /evox/about
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-favicon: Unknown favicon MD5: 36B3EF286FA4BEFBB797A0966B456479
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
135/tcp open msrpc syn-ack Microsoft Windows RPC
139/tcp open netbios-ssn syn-ack Microsoft Windows netbios-ssn
445/tcp open microsoft-ds syn-ack Microsoft Windows Server 2008 R2 - 2012 microsoft-ds
5985/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
47001/tcp open http syn-ack Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-title: Not Found
|_http-server-header: Microsoft-HTTPAPI/2.0
49664/tcp open msrpc syn-ack Microsoft Windows RPC
49665/tcp open msrpc syn-ack Microsoft Windows RPC
49666/tcp open msrpc syn-ack Microsoft Windows RPC
49667/tcp open msrpc syn-ack Microsoft Windows RPC
49668/tcp open msrpc syn-ack Microsoft Windows RPC
49669/tcp open msrpc syn-ack Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
Here, nmap shows us a bunch of open ports. But most importantly for us is the open FTP port which allows anonymous access and the hosted web application on port 80.
Enumeration Port 21 - FTP Anonymous Login / User Flag
As nmap has already showed us, there is an accessible FTP service which allows anonymous access. So let’s connect and check out what’s stored on the system:
Going through the file system, we can also find the user.txt. That was very simple!
Initial Foothold through Port 80 - PRTG Network Monitor / Root flag
Looking at the website hosted on port 80, we see the following:
A quick google search reveals the default credentials for the application:
Unfortunately, they seem to not work. Let’s take a step back and remember what we’ve got so far. We still have access to the FTP server. Maybe there are some files that can help us. Another google search tells us that there are PRTG configuration files that store all credentials and settings for the web application. Let’s see if we can access those files:
Great! We got access to those files. As we know the default username, which is prtgadmin, we can scan the files for existing entries. And we find one! The file PRTG Configuration.old.bak contains the password PrTg@dmin2018.
We can now use the credentials to log in to the application! Or can we? Submitting the login form with the given credentials still results in an error. Hmmmm… What if the password is in the old.bak file for a reason? Maybe it’s an old password and it was updated in the recent version. Let’s create a password list with different dates at the end (pure guess) and see if that results in something:
1
for i in {1995..2022}; do echo "PrTg@dmin$i"; done > passwords.txt
Afterwards, use Burp’s Intruder functionality to send the requests with the passwords from the list: And indeed, we find something! The password is PrTg@dmin2019 instead of ..2018.
Great! We can now log in. Further, we see the installed version of the software 18.1.37...
So what can we do now? Let’s search for known vulnerabilities using searchsploit:
Interesting! An authenticated remote code execution for a version that’s above the installed one. Seems promising. Also, we fulfill all requirements as we have valid credenitals to access the dashboard.
Providing the necessary parameters and running the script seems to work! The exploit script creates a new user called pentest with the password P3nT3st!:
To get access to the system, we use psexec in combination with the credentials of the script:
Finally, we capture the root flag!
