Box #4 of my month-long challenge will be ServMon, HTB's most recently retired Easy Windows machine.
Yeah, I'll admit... So far, it's all been Easy Windows machines. And this is a deliberate choice. for starters, Windows is my weakesta point, so I have to bring those skills and knowledge up. I also hope to take some of that "extra" time to sort out some kind of Reporting solution.
Naturally we start with a basic port scan, and we can see right away that FTP is allowed and accepts anonymous user. So let's take a look at what's here, and download the 2 files available. Reviewing the files' contents gives us some kinda juicy details, but nothing really actionable. Back to the portscan.
We can see port 8443 is open, and serving a website of sorts. Loading the site with HTTPS shows it is some kind of "NSClient++". Googling this brings me to NSClient++. Searchsploit also shows that there's a couple of possible exploits, but they all require an existing, low-level user credentials, which we still do not have.
Back to the good ol' portscan, we see that port 22 is open, but without any credentials, this is kinda useless, and there's no point trying to brute force it either (NEVER the answer for HTB). Continuing the review, SMB is open as well! Let's take a look.
No anonymous user access. Can't get anything like this... Back to ye olde portscan.
Without realizing it, somehow, for some reason, my initial portscan didn't actually complete properly... Maybe because I didn't wait long enough after "starting" the VM...? I dunno... But on a bit of a whim since I had no other real concrete leads, I ran a simpler portscan, and sure enough, NOW port 80 is showing up. Loading port 80 loads a "NVMS-1000". searchsploit shows this is vulnerable to some directory traversal. NOW I know what to do next... that's where the hint comes in from earlier. So load up burpsuite, try to load the page, send it to the Repeater, change the GET request to "GET /../../../../../../../../../../../../users/Nathan/Desktop/Passwords.txt", and we get the contents of that password file! Yeah!
So now we have some passwords, and some users... let's see if we can do some credential stuffing and get something through SMB. So I manually create a users file and populate it with the 2 users we know of from the ftp, as well as Administrator and Guest (you never know). Next, I create the password file and toss in the passwords we just got.
Now, we can use hydra to try all the user/password combos. Starting with ftp, but no solid results. So I suspect these are likely some SMB passwords. But no matter what I try with the SMB connections, I keep getting errors.. so either I'm doing something wrong here, or this isn't the route to go. Maybe it's got something to do with that port 8443 NSClient++...?
Now when I load it in Firefox, it doesn't seem to load properly... I only get the following:
I've seen this kind of behaviour before at work... A few times. In fact, I've seen it here at home too. For some reason, there are some pages that just do not load completely properly in Firefox and/or Chrome, and this looks similar. So I decide to install chromium and load the page that way. And sure enough, there is a login propmpt:
Ok... So we've got some passwords, but none of those worked. So maybe they're for the SSH? It's the only thing we haven't seriously checked out, and now that we have some potential usernames and passwords, let's try them all out. So I Google how to brute force SSH, and am presented with hydra.
Now I want to clarify something here... "TRUE" brute forcing would be, for example, attempting every single combination in order, one by one. THIS kind of brute force won't ever really solve anything in HTB, so THAT kind of BRUTE force isn't going to help. That being said, most of the tools that would PERFORM the iterations, need to be provided a "list" of usernames and/or passwords. So instead of listing ALL POSSIBLE combinations (TRUE brute force), we are just going to use a (very) curated short list of possibilities.
Rather than trying each possible combination, we can parse through them all very quickly with "hydra" (Kali CLI command). With this, we are able to find a good set of creds, can use them to login via SSH, and get that user.txt.
From here, we can go back to those earlier exploits we found with NSClient++ since we now have access to the system. Doing so, we are able to get the password to log in to the NSClient++ WebUI.
Or so I thought... because it didn't work at all. Then I thought back to some of those files we got off the FTP, where we have a note, "2) Lock down the NSClient Access - Complete". Using my Google-fu, I found the admin guides for NSClient++ and started reading up the configuration details. It noted there was a config file, "c:\program files\nsclient++\nsclient.ini". So I load up FileZilla and connect to the victim using Nadine's credentials over SFTP, and sure enough, it connects. So I look for that file and download it for review. Right away, as the admin guides had me expect, we see the following:
allowed hosts = 127.0.0.1
So I go ahead and try to just add "allowed hosts = *", but saving the file kept giving me permissions errors. Same with just editing that first line. So I figure since we have the SSH session to the server itself already, we can just redirect port 8443 through the SSH session:
ssh -L 8443:127.0.0.1:8443 Nadine@servmon
And sure enough, now we are able to load and log in to the NSClient++.
Now here's were things went sour... so far, things had progressed pretty smoothly. At this point, things went awry.
In short, I spent a couple hours, spinning my wheels working to get the "script" and "schedule" to work and launch the reverse shell. Depite how well I seemed to follow the insctructions in the exploit doc, AND the NSClient++ documentation itself, nothing would actually launch the reverse shell. I'll be totally honest here, I got SO despaired on the matter that I caved and looked up some of the existing writeups for this box.
They showed me EXACTLY what I was already doing. WTF!? Why is it working for them and not for me???
At one point, I just started throwing all the shit on the wall I could find, and it got to a point where the WebUI stopped responding... I think I broke something, so I just reset the box. After resetting, I go through the whole exploit again and still, NOTHING. On the verge of just totally giving up (since even the walkthroughs weren't helping), I stepped away for a bit.
Upon my return, by some miracle I cannot describe, the reverse shell had connected. As soon as that was in place, BOOM, there's the root flag.
I have NO idea how/why it connected like that, seemingly out of the blue. My best idea is that BEFORE the reset, I may have even "gotten" it, but just didn't give it the time it needed to start and connect. Afterwards, I probably messed something up throwing all that shit on the wall, and couldn't get the connection for that reason. After the reset, I think I just had to give the reverse shell (and launching script) enough time to actually launch and connect. Comically enough, none of the walkthroughs I read in my despair mentioned waiting for any period of time (though they never do anyways).
 HTB-ServMon Report
|
|
HTB ServMon Report |
|
 Friday, 07 August 2020 15:07  476.65 KB  374 |
Download |
For the report today, I am continuing with my CherryTree notes and exports, and hope that it conveys the information effectively. As alwaysm feel free to hit my up with your questions and comments!
