# 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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f4a79161-d734-4a59-9f9f-9ef26ecbd9c7.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/f9f12db1-608d-42f2-bce4-d5988784af31.png align="center")

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**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/82ecbcec-d9b1-410b-bb05-a66e4de0bf96.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/55cb73a6-42c6-4c6a-a2c7-26d06c48bf97.png align="center")

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.

```plaintext
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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0680dc2a-916b-4407-ae44-6ea40f277de7.png align="center")

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:

```plaintext
http://10.129.230.176
```

This presented a **PRTG Network Monitor login page**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3a30e763-31a0-4a55-9d5a-270408a7528d.png align="center")

I first attempted to authenticate using the credentials discovered in the configuration file:

```plaintext
Username: prtgadmin
Password: PrTg@dmin2018
```

However, the login attempt failed.

Next, I tried the common **default credentials** often associated with PRTG installations:

```plaintext
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**:

```plaintext
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.

```plaintext
Username: prtgadmin
Password: PrTg@dmin2019
```

This time the authentication was successful, granting access to the **PRTG Network Monitor dashboard**.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/2d40a818-6cb2-45a5-9505-265ccc1fccae.png align="center")

## 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:

```plaintext
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:

```plaintext
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:

```plaintext
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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/a7cbe250-6751-42a9-be4a-a3293587b082.png align="center")

```plaintext
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:

```plaintext
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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/3dedd3e9-878d-4465-b78c-8f9b6e88905b.png align="center")

```plaintext
test.txt;net user neo p3nT3st! /add;net localgroup administrators neo /add
```

This payload performs two actions:

1.  Creates a new local user named **neo**
    
2.  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.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/e4d9430d-3806-43e7-bc93-55c330d8a006.png align="center")

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:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/507c7672-b2d9-4e35-9210-b318df667ac4.png align="center")

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.