HTB - Servmon
Zweilosec's writeup of the easy-difficulty Windows machine ServMon from https://hackthebox.eu
Overview
This was an easy Windows machine....but don't get stuck chasing the rabbits!
Useful Skills and Tools
Logging into FTP Anonymously
ftp <remote_ip>
Name: anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password: any@email.address
Windows files in static locations for LFI testing purposes
C:\Windows\win.ini
C:\Users\<username>\Desktop\desktop.ini
If you have already gathered a potential username
Using SSH to forward local ports to access secured remote assets
ssh -L <local_port>:<remote_address>:<remote_port> <username>@<server_ip>
PowerShell history file location
C:\Users\<username>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt
Enumeration
Nmap scan
First off, I started my enumeration with an nmap scan of 10.10.10.184. The options I regularly use are: -p-, which is a shortcut that tells nmap to scan all TCP ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oN <name> saves the output to file with a name of <name>.
Lots of open ports on this machine. There are a number of clues in this output that would tell you that this is a Windows machine such as ports 135 - Microsoft Windows RPC, 139 - Netbios, and 445 - Server Message Block (SMB). The FTP client also reports SYST: Windows_NT and SSH is running on OpenSSH for_Windows_7.7. With that, it's usually best to start with enumerating the low ports that are well known.
Anonymous FTP
If port 21 - FTP is open, that is usually a good place to start as logging in as Anonymous can be an easy way to find useful information. To do this enter anonymous when it prompts you for a name, then give an email address when it prompts for a password. This does not have to be a real address, just in the format a@b.c.
Through FTP I was able to find two different users, Nadine and Nathan. Each user's folder had a text document in it with some interesting information.
Nathan's folder contained a to-do list that lets us know that there are two services NVMS and NSClient on this machine, the security of which has not been completely locked down. It seems as if public access to NVMS should still be still available, and whatever "secret files" may still be in an accessible location.
The file Confidential.txt in Nadine's folder gave me some more good news. She left Nathan a file on his desktop that looks to contain passwords. This may be one of the "secret files" that Nathan was planning to lock up in SharePoint that he hadn't gotten to yet.
HTTP - Port 80 🐇🐇
Since I still didn't have a way in, the next place to enumerate was HTTP on port 80. Navigating to http://10.10.10.181 redirected to http://10.10.10.184/Pages/login.htm which had a page title of NVMS-1000. This looks like the page with public access that Nathan's to-do list had mentioned.
NVMS-1000 Exploit Research
A quick exploit search using searchsploit nvms 1000 found a directory traversal exploit for this web portal at https://www.exploit-db.com/exploits/47774, and also a Metasploit scanner to check for this vulnerability at https://www.rapid7.com/db/modules/auxiliary/scanner/http/tvt_nvms_traversal.
Initial Foothold
Can use GET requests and directory traversal to access files on the system. Blog from Rapid7 shows good way to test for LFI and directory traversal for Windows. since we know the location of the Passwords.txt file, use this to exfiltrate
I used Burp suite's repeater tool to craft my requests and test for this vulnerability on this machine.
The machine was indeed vulnerable, and I used the information from the message Nadine left for Nathan to form my directory traversal GET request. The server returned a list of seven passwords for me try out.
Road to User
Now that I had some credentials, it was time to try to log into the machine with them. I decided to use the toolhydra to do a brute force attack against SSH for both users Nathan and Nadine.
Thank you Nadine for using one of the same passwords you recommended!
After determining the correct password I easily logged in and got a shell as Nadine.
user.txt
Metagaming - Other user's artifacts
As you can see in this output, there were at least a few different people working on this machine around the same time as me, and that they had left their enumeration scripts behind. On my first couple Hack the Box attempts I found useful information in a public location and thought it was part of the box, only later to find out that I had been receiving spoilers due to other user's artifacts. Please be courteous to other users in this shared environment and clean up after yourself!
Path to Power (Gaining Administrator Access)
Enumeration as User Nadine
NadineI was able to find a PowerShell history file for Nadine at C:\Users\Nadine\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt, though there was nothing relevant to the challenge...there were however, lots of attempts to do things (some quite humorous!) from other users though! Unfortunately I accidentally deleted the contents while cleaning up my notes for publishing so you can't enjoy them too.
After browsing through the installed programs I came across something I didn't recognize: NSClient++.
The changelog didn't really hold any information that seemed useful at first, though it did give me an idea of how long it had been since the program had received an update: 2018-01-18.
I found a potential password in the nsclient.ini folder, though I wasn't sure what it might go to. It didn't work for the Administrator account, unfortunately. Near the bottom of this file were some obvious edits by other users, so I knew this had to be important. I reset the box to avoid spoiling the rest of it for myself.
NSClient++ Exploit Research
A Google search of nsclient++ changelog led to http://www.nsclient.org/download/0.5.2/, where I was able to correlate the dates in the changelog.txt with the versions of the program's releases. It looked like the installed program was nightly build version 0.5.2.31 from 2018-01-18.
Again, a quick Searchsploit check found an exploit that might work for this version of NSClient++. https://www.exploit-db.com/exploits/46802
Well this didn't look too awfully complicated. I now had step-by-step instructions for privilege escalation all the way to nt authority\system.
Running the command in the exploit to get the NSCP web client administrator password gave me the same password that I had seen in the nsclient.ini file.
Looking back through my notes, I saw that there was a port I hadn't checked out yet from my early Nmap scan. Port TCP 8443 showed a website with the information http-title: NSClient++. Navigating to http://10.10.10.184:8443 resulted in failure. After doing a bit more looking around I found an entry in nsclient.ini that seemed to specify that the Web interface could only be accessed from the specified hosts, which only included 127.0.0.1 in this case. Later I noticed the port was also listed in nsclient.ini, oops.
Using SSH to create a redirect tunnel (Local Port Forwarding)
In order to access this page through the web browser without some sort of remote desktop capability I had to set up port forwarding from my local machine to the remote host. Since the web portal would only accept traffic from it's own localhost on port 8443, we needed to set up some way to redirect traffic to and from my browser to appear to come from the remote machine. Luckily this is pretty easy to do with SSH.
ssh -L 8443:127.0.0.1:8443 Nadine@10.10.10.184
The web portal on port 8443
https://127.0.0.1:8443/index.html#/
The web portal seemed somewhat complicated to interact with, and the instructions given in the exploit weren't completely clear how to link to the evil.bat script and it's scheduler through the web portal. After doing lots of reading through the documentation on nsclient, I discovered an easier sounding method of interacting with the service.
Taking the API route
While reading through the API documentation at https://docs.nsclient.org/api/scripts/ I thought it sounded like a much easier to deal with route than going through the web portal. With just two simple commands I could upload my script and execute a query against that script to get it to run. The documentation even gave specifics on how to upload the contents of the script by passing it as a string in the command, rather than actually creating and sending a file.
For my payload script I still used the one recommended by the exploit author, even though I was sending it to the server by a different method. It was a very simple netcat reverse shell..
To send the payload to the server I used curl as specified by the documentation and sent the contents of my payload script as --data-binary "<string>". It prompted me to enter the admin password we had retrieved from the nscp client.
After sending the script it let me know that it had added the script under the name evil. This is the name to use to run a query against it in order to run it.
At first, I tried executing the script but I didn't receive a reverse shell. I realized after doing a bit of troubleshooting that I hadn't actually uploaded nc.exe to the remote host. My command to transfer the file had not completed successfully, but I had missed the error message it gave in my rush to finish since it was well past my bedtime. Let this be a lesson to always take your time and pay attention to details, no matter how tired or in a hurry you may be :)
I was not the only to make mistakes while transferring files to this machine. Another user had tried to upload nc.exe (I overwrote this) and their evil.bat to the C:\Temp folder but had failed (file size of 0 bytes seen above). I figured out that had forgotten to add --output <file_name> at first. Luckily it gave a warning to remind me of this.
Despite the error message seen above, once I successfully uploaded nc.exe to the folder I had specified in my payload C:\Temp, and then sent the execute query once again, I received my reverse shell on my host machine. The error message above I believe is to let an administrator know that there was a long-running script that did not terminate within the specified timeout period.
Getting a root shell
Bam! Now I was logged in as nt authority\system and had full control of the system.
root.txt
The last thing to do was, of course, to collect my proof.
Oops. Apparently in a cmd.exe shell the direction of the slash is important when using type to read a file!
Thanks to dmw0ng for a fun and interesting challenge! I certainly learned a few new useful tricks for dealing with Windows machines.
If you like this content and would like to see more, please consider buying me a coffee!
Last updated
Was this helpful?