HTB - NetMon without MetaSploit


An easy box according to HTB ranking and a not so easy one according to this site. For me, it was really painful. Let me overshare!


HTB - NetMon


Quick recon based on HTB logo and info :

  • Windows box ;
  • Misc info : web, PowerShell, file misconfiguration ;
  • Probably runs PRTG NetWork Monitor tool.


sudo nmap -T4 -A -p- -oA nmap $target_ip
Starting Nmap 7.91 ( ) at 2021-02-12 15:25 CET
Nmap scan report for $target_ip
Host is up (0.056s latency).
Not shown: 65522 closed ports
21/tcp    open  ftp          Microsoft ftpd
| 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
|_02-25-19  10:49PM       <DIR>          Windows
| ftp-syst:
|_  SYST: Windows_NT
80/tcp    open  http         Indy httpd (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/
| 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-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
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
No exact OS matches for host (If you know what OS is running on it, see ).
TCP/IP fingerprint:

Network Distance: 2 hops
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode:
|   2.02:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2021-02-12T14:28:15
|_  start_date: 2021-02-12T14:02:36

TRACEROUTE (using port 8888/tcp)
1   59.00 ms
2   59.12 ms $target_ip

OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 152.62 seconds

We find a few interesting services :

  • FTP server (21/tcp) : Microsoft ftpd, with anonymous login enabled ;
  • Web server (80/tcp) : Indy httpd (Paessler PRTG bandwidth monitor) ;
  • Remote powershell (5985/tcp) ;
  • SMB and Netbios related services on ports 135/tcp, 139/tcp and 445/tcp ;
  • HTTPAPI httpd 2.0 (SSDP/UPnP) on 47001/tcp ;
  • Several high ports fo RPC.

Nikto scan reveals PRTG version, and the webpage displays a login page.

Netmon Login

Default and common credentials won’t work here.

Looking up PRTG on searchploit won’t give us much : an authenticated RCE and a DoS exploit… and yes it works! But as fas I know, it is useless in our case. It means we’ll have to dig deeper. Before that, let’s continue to sratch the surface for other services, we are looking for an easy win! :)

We can also enumerate smb shares :

nmap -p 445 --script=smb-enum-shares.nse,smb-enum-users.nse $target_ip

but nothing comes up!

Let’s explore the FTP server. Here, we have access to quite a lot of files such as :

  • Program Files ;
  • Program Files (x86) (we now know that our OS is 64 bits) ;
  • Users, Windows, Inetpub, etc.

In the Users\Public folder we will find our user flag.

NetMon User Flag

Now, I am guessing that the most relevant folder will be /Program Files (x86)/PRTG Network Monitor in which we might find useful info such as installation logs, and maybe even credentials if we are super lucky.

So far, we haven’t found much… My guess is still with PRTG logs or something similar. I will then explore PRTG folder for anything interesting, and also common places we might have access to.

In order to make exploration more easier, I am using FileZilla.


Enumerating username in the “Forgot password” page, tells us that the default ptrgadmin user exists :

NetMon Forgot Password OK

Notice the slightly different error message when testing with a fake username (username == zjdpdjpo) :

NetMon Forgot Password NOK

While researching on internet where PRTG stores its credentials, I came across a few pages where it seems that our version leaks clear text password in the ProgramData folder. Now, I tried to access this folder from my FTP client and couldn’t do it… I have been stuck here for HOURS! So I cheated, and checked official walk through. It turns out, I made a typo… and one can access the said folder and get some juicy files, especially PRTG Configuration.old.bak. Inside this file, we’ll find Graal (or, do we?) :

NetMon Credentials

Once again, and I have no idea why this time (probably another typo?) I also went stuck for too long. The password in the backup file ends in 2018, but unfortunately it doesn’t work. One can assume it is an old password, and the year has changed, so has the password. Hence, I tried to replace the year with 2019, 2020, 2021 and even 2022 (current year + 1)… Nothing worked… I was really feeling down and cheated, again. It happens that the second password I tested was the correct one! I tried it again, and this time, it worked and I was finally inside the admin panel!

Now that we are authenticated, it is finally time to check our Authenticated RCE we found earlier.

We need to grab our authenticated cookie, Burp Suite can do that easily, then run the following command :


Once it is done, the script should have created a new admin user called pentest.

Now, remember we also found a remote powershell running? Time to use it! I found that using a Powershell’s docker was pretty easy :

docker run -it  quickbreach/powershell-ntlm

From here, we connect to our remote machine :

Enter-PSsession -ComputerName $target_ip -Authentication Negotiate -Credential pentest

One we are in as SYSTEM, we simply browse to the flag dir and display it :

NetMon Root Flag


While everything seemed pretty straightforward I spent way more time than I care to admit for stupid mistakes on my side. Which in the end made it a very exhausting box for me. Once again, we saw how nasty a few misconfiguration + CVE can be!