Security Vault

Netmon

Feb 11, 20255 min read

Metadata

  • Platform: HackTheBox
  • CTF: Netmon
  • OS: Windows
  • Difficulty: Easy

Summary

An FTP share without authorizations gives us read access to most of the file system. By searching through old configuration files for the netmon web service, we find an outdated credential pair, which we can use to guess the current one. Using this access, we leverage an existing authenticated remote code execution to gain a system level shell.

Solution

Reconnaissance

Nmap reveals 6 open ports:

Nmap scan report for 10.10.10.152
Host is up (0.060s latency).
Not shown: 994 closed tcp ports (reset)
PORT     STATE SERVICE      VERSION
21/tcp   open  ftp          Microsoft ftpd
| ftp-syst: 
|_  SYST: Windows_NT
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-02-19  11:18PM                 1024 .rnd
| 02-25-19  09:15PM       <DIR>          inetpub
| 07-16-16  08:18AM       <DIR>          PerfLogs
| 02-25-19  09:56PM       <DIR>          Program Files
| 02-02-19  11:28PM       <DIR>          Program Files (x86)
| 02-03-19  07:08AM       <DIR>          Users
|_11-10-23  09:20AM       <DIR>          Windows
80/tcp   open  http         Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
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
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
 
Host script results:
| smb2-time: 
|   date: 2025-02-06T14:40:27
|_  start_date: 2025-02-06T14:29:10
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled but not required
 
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 456.15 seconds

There are a few ports we can take a deeper look at. First, we notice two web servers, one on port 80 and on port 5985. Visiting the former presents a PRTG Network Monitor to us, where we can log in if we have fitting credentials. The site’s footer contains the number 18.1.37.13946, which I presume to be this service’s version. A quick google search confirms, that there are known exploits for this version, however they need authentication. However, the default credentials often provided do not work and were probably changed.

The other webpage does not present any initial resources to us. It seems like the directory is empty, which we could confirm by executing directory enumeration.

While we don’t have anonymous/guest access to the smb service, we can access the box via FTP.

User Flag

Somehow, the ftp root directory is the C:\ drive on the machine. It seems like we can use this service to move across the entire file system, with limited privileges. However, we have enough access to move to C:\Users\Public\Desktop and read user.txt.

882639ac5c5c08ee0aa33078eef17d68

Root Flag

To escalate our access, let’s take a closer look at the files provided by the other services, such as the websites.

When we enter C:\interpub\wwwroot\, the folder seems to be empty. This could explain, why we did not get any response containing a resource from port 5985. But since we have access to this directory, we could upload a reverse shell and trigger it easily. Sadly, we do not have any permissions to upload files. Therefore, this is likely not the right way, but maybe we can use the other application on the system. As we noticed prior, we require a credential pair to exploit the netmon application. Maybe we can find one in the according directory.

Searching through C:\Program Files (x86)\PRTG Network Monitor, there doesn’t seem to be any configuration files or anything similar, where we could get credentials. However, I was able to find a configuration file C:\Windows\PRTG Configuration.dat. This file is quite long, so let’s quickly search for any credentials by using grep and searching for something like admin or root. By adding -B2 -A2, the output will also include the surrounding lines of every hit.

cat PRTG\ Configuration.dat | grep -B2 -A2 admin
                </fixed>
                <name>
                  Email and push notification to admin
                </name>
                <ownerid>
--
                </active>
                <comment>
                  This notification creates a ticket for the administrator group
                </comment>
                <comments>
--
                  0
                </isadgroup>
                <isadmingroup>
                  0
                </isadmingroup>
                <name>
                  PRTG Administrators
--
                  0
                </isadgroup>
                <isadmingroup>
                  0
                </isadmingroup>
                <name>
                  PRTG Users Group
--
                </lastlogin>
                <login>
                  prtgadmin
                </login>
                <name>

That’s a miss - this config files doesn’t contain any credentials, so lets search for others. By issuing dir -a in the root directory, we also find ProgramData. Following this path, we can find C:\ProgramData\Paessler\PRTG Network Monitor\, another directory containing three more config files.

  • PRTG Configuration.dat from 2019
  • PRTG Configuration.old from 2025
  • PRTG Configuration.old.bak from 2018

Checking each file the same way we did prior, yield a result: prtgadmin:PrTg@dmin2018

Trying these credentials on the login web page under http://10.10.10.152:80, returns a failed login. So this password is likely outdated (Remember: we found the password in .old.bak from 2018). Trying the years of these other config files, yield a hit for the password PrTg@dmin2019.

Now that we have access to the web UI, we can finally use the exploits we found prior. We can either use an exploit such as PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution - Windows webapps Exploit, or use the according module of the Metasploit Framework. By searching for prtg, we find exploit/windows/http/prtg_authenticated_rce. After entering all parameters, we get a callback and a shell as nt authority\system.

Now we can collect the root flag on the Administrator’s Desktop.

5da2370c2135524dccdc53f6f9c8eb8d

Graph View

Backlinks