OSCP Prep #5 HTB Write-Up Netmon
1. Target Overview
Machine Name: Netmon
Platform: HackTheBox
Operating System: Windows
In this walkthrough, I document my attack path against the Netmon machine. The goal is to enumerate available services, identify an attack vector, gain initial access, and ultimately escalate privileges to obtain full system compromise.
Tools Used
Rustscan
Used for fast port discovery to quickly identify open services on the target system.
Nmap
Used for service detection and detailed enumeration after identifying open ports.
FFUF
Used for web directory fuzzing to discover hidden paths and endpoints on the web server.
NetExec (nxc)
Used to enumerate SMB services and test authentication against the target system.
FTP
Used to access and download exposed configuration files from the FTP server.
Impacket
Specifically psexec.py, used to gain remote command execution over SMB once administrative credentials were obtained.
2. Enumeration
Port and Service Enumeration
I began by scanning the target using Rustscan to quickly identify open ports, which were then enumerated with Nmap for service detection.
The scan revealed the following notable services:
21/tcp – FTP (Microsoft ftpd)
80/tcp – HTTP (PRTG Network Monitor)
135/tcp – MSRPC
139/tcp – NetBIOS
445/tcp – SMB (Microsoft Windows Server 2008 R2 / 2012)
5985/tcp – HTTPAPI (WinRM)
Several high RPC ports (49664–49669)
One important result came from the Nmap ftp-anon script, which reported that anonymous FTP login was allowed:
ftp-anon: Anonymous FTP login allowed (FTP code 230)
In situations like this, I prefer to enumerate SMB and FTP first before diving deeply into the web application. These services often expose useful files, credentials, or configuration data that can later be leveraged against the web interface.
However, it is still useful to have web reconnaissance running in the background while investigating other services. To accomplish this, I started a directory brute-force scan using ffuf against the web server.
Running ffuf in the background allows me to begin discovering potential hidden directories or endpoints on the web server while I continue manually enumerating SMB and FTP.
SMB Enumeration
With initial reconnaissance underway and ffuf running in the background, I began manually enumerating the exposed services starting with SMB on port 445.
This test checks whether anonymous SMB access is permitted. However, the server returned an access denied response, indicating that anonymous authentication is not supported for SMB share enumeration on this system.
Since SMB did not allow unauthenticated access, I shifted my attention to the FTP service on port 21, which earlier enumeration suggested allowed anonymous login.
FTP Enumeration
Since SMB did not allow unauthenticated access, I shifted my attention to the FTP service on port 21, which earlier enumeration suggested allowed anonymous login.
I connected to the FTP server and began exploring the exposed directories. I first navigated to the Users directory, but aside from the user flag there was nothing of immediate value.
Next, I inspected the ProgramData directory. This location is often a valuable target during enumeration because it commonly stores application configuration files, logs, and other operational data, which may contain sensitive information such as credentials.
Inside this directory, I discovered several PRTG configuration files. Because PRTG was identified earlier during web enumeration, these files were particularly interesting. I downloaded them to my attacker machine for offline analysis.
get "PRTG Configuration.old"
get "PRTG Configuration.old.bak"
get "PRTG Configuration.dat"
After successfully transferring the files, I exited the FTP session so that I could analyze the configuration files locally.
Credential Discovery
After downloading the PRTG configuration files from the FTP server, I began inspecting them locally to see if they contained any useful information.
Two of the files did not appear to contain anything particularly interesting. However, when inspecting PRTG Configuration.old.bak, I discovered credentials embedded within the configuration data.
This revealed the following credentials:
Since the target web application was identified earlier as PRTG Network Monitor, these credentials appeared to be promising candidates for authentication.
Web Application Login
I navigated to the web interface at:
http://10.129.230.176
This presented a PRTG Network Monitor login page.
I first attempted to authenticate using the credentials discovered in the configuration file:
Username: prtgadmin
Password: PrTg@dmin2018
However, the login attempt failed.
Next, I tried the common default credentials often associated with PRTG installations:
Username: prtgadmin
Password: prtgadmin
This also failed.
At this point I considered that the credentials were recovered from an old backup configuration file, which suggested they might be slightly outdated.
Looking again at the password, I noticed that it contained a year value:
PrTg@dmin2018
Since the backup file dated from 2018, it was possible that the password had been updated to reflect a newer year. I tested this hypothesis by modifying the password accordingly.
Username: prtgadmin
Password: PrTg@dmin2019
This time the authentication was successful, granting access to the PRTG Network Monitor dashboard.
3. Exploitation
Foothold
Now that I had successfully authenticated to the PRTG Network Monitor dashboard, the next step was to determine whether the application version contained any known vulnerabilities.
Earlier enumeration revealed that the application version running on the server was:
PRTG Network Monitor 18.1.37.13946
With version disclosure available, I began searching for publicly known vulnerabilities affecting this version of PRTG.
During my research, I discovered documentation describing CVE-2018-9276, a command injection vulnerability affecting versions of PRTG Network Monitor prior to 18.2.39.
The vulnerability description explains that an attacker with access to the PRTG administrative web console can exploit an OS command injection vulnerability by supplying malicious input within certain configuration parameters.
Specifically, the issue occurs in the Notifications configuration, where the value supplied in the “Parameter” field is passed directly to a PowerShell script without proper input sanitization.
Because the input is not properly sanitized, it becomes possible to inject additional commands that will be executed on the underlying Windows system.
Further investigation revealed that values supplied through this configuration are written to the file:
C:\ProgramData\Paessler\PRTG Network Monitor\PRTG Configuration.dat
Since this file stores parameters used by the notification system, manipulating these parameters allows arbitrary command execution when the notification is triggered.
Research confirmed that inserting a payload similar to the following into the Parameter field would result in command execution:
test.txt;net user pentest p3nT3st! /add
This payload demonstrates that arbitrary commands can be injected by terminating the expected input and appending additional commands, in this case creating a new local user on the system.
Since I already had authenticated administrative access to the PRTG interface, this vulnerability provided a viable path to achieve remote command execution on the host.
Remote Code Execution
After identifying CVE-2018-9276, I began following the proof-of-concept described in the research. The vulnerability exists in the Notifications configuration of PRTG, where parameters passed to certain notification scripts are not properly sanitized before being executed.
To begin testing this, I navigated within the PRTG interface to:
Setup → Account Settings → Notifications
From the notifications page, I clicked the "+" icon on the right side and selected “Add new notification.”
Leaving most of the settings unchanged, I scrolled to the bottom of the configuration page and selected the option:
Execute Program
This option allows a script to be executed when the notification is triggered. I selected one of the default demo PowerShell scripts provided by the application and focused on the Parameter field, which is where the command injection occurs.
Although many characters are filtered, enough characters remain usable to allow command injection by chaining commands.
I supplied the following payload in the Parameter field:
test.txt;net user neo p3nT3st! /add;net localgroup administrators neo /add
This payload performs two actions:
Creates a new local user named neo
Adds that user to the Administrators group
After saving the notification configuration, I returned to the notifications list and selected the newly created notification. I then clicked the bell icon to trigger the notification and execute the command.
After a few seconds, the payload executed successfully.
SYSTEM Shell
To verify that the new user had been created successfully, I tested SMB authentication using the credentials created by the payload.
The output confirmed that the neo account had full administrative access to the system shares.
With administrative SMB access available, I used Impacket's psexec.py to obtain a shell on the target.
The tool uploaded a service executable to the ADMIN$ share and executed it remotely, spawning a shell on the system.
Once connected, I verified the privilege level:
This provided full control of the target machine, completing the exploitation phase of the engagement.
4. Privilege Escalation
In this case, separate privilege escalation was not required.
The credentials recovered from the configuration backup file allowed authentication to the PRTG administrative interface. By default, the prtgadmin account operates with high privileges within the application, and the notification scripts executed by the application run under the SYSTEM account on the host.
Because of this configuration, exploiting the CVE-2018-9276 command injection vulnerability resulted in commands being executed directly as NT AUTHORITY\SYSTEM.
As a result, once the command injection payload was triggered, the new user account created through the exploit already possessed administrative privileges on the system. Using those credentials with psexec immediately yielded a SYSTEM shell.
5. Lessons Learned
Importance of Securing FTP Services
The initial attack vector in this engagement originated from the FTP service. Anonymous access allowed retrieval of sensitive application files, specifically the PRTG configuration backup files. Even though these were backup files, they still contained valuable information that could be leveraged during the attack.
This highlights the importance of restricting FTP access and preventing anonymous exposure of sensitive data. File services should never expose internal application data to unauthenticated users.
Value of Enumerating ProgramData
Another key takeaway from this machine is the importance of inspecting the ProgramData directory on Windows systems.
Many applications store operational data, configuration files, and backups within this directory. As seen in this engagement, configuration backups located in ProgramData contained credentials that were later used to authenticate to the web application.
Because of this, ProgramData should always be considered a high-value enumeration target during Windows engagements.
Leveraging Version Disclosure
Once authenticated to the PRTG web interface, the application revealed its exact version number. This allowed quick identification of a publicly known vulnerability affecting that specific version.
Version disclosure can significantly reduce the time required to identify viable exploits, making it an important piece of information during application enumeration.
Thinking Critically About Credential Artifacts
Another useful lesson came from analyzing the credentials discovered in the configuration backup file.
Initially, the recovered password PrTg@dmin2018 did not work. However, recognizing that the file was an old backup suggested the password may have been updated since the backup was created.
Testing the same password with an updated year value eventually led to successful authentication.
This demonstrates the importance of thinking critically about how credentials may evolve over time, especially when they originate from backups or archived configuration files.
6. Defensive Insight
Restrict Anonymous FTP Access
Anonymous FTP access should never expose internal application directories or configuration data. Sensitive files such as configuration backups, application data, or credentials should always be restricted to authenticated users only.
Properly restricting FTP access could have prevented the attacker from retrieving the configuration files that ultimately led to credential discovery.
Protect Application Configuration Files
Configuration files frequently contain sensitive information such as credentials, tokens, and operational parameters. These files should be carefully protected and never exposed through publicly accessible services.
Additionally, backups should be stored securely and should not be left accessible through network services.
Maintain Proper Patch Management
The vulnerability exploited in this engagement (CVE-2018-9276) had already been publicly documented and patched in later versions of PRTG.
Maintaining proper patch management practices and keeping software up to date is one of the most effective ways to prevent attackers from exploiting known vulnerabilities.
Enforce Input Validation and Sanitization
The command injection vulnerability occurred because user-supplied input from the Notification parameter field was passed directly into a PowerShell script without sufficient input validation.
Applications that execute system commands must strictly sanitize and validate all user input to prevent command injection vulnerabilities.
