Welcome to my very first, public write-up of a Hack The Box BOX! Now, I’m just trying this out, and I’m not sure at the moment how this will all work out. I do need to polish up my write-up skills and so this is a great way to work on that while I blog at the same time. I see there’s a few other vloggers out there that have a pretty darn good handle on the whole CTF instructional video series thingy (lookin’ at you IPPSEC!), so I don’t think I want to jump into recording videos of me doing these boxes at the moment. Especially not for the first few rounds anyway…
With that out of the way, let’s get straight to it.
First, as with all things, we’ll start with our nmap scan to see what’s under the hood:
Right away we can see we have ssh enabled and could have some later use. Also we have smb enabled with guest account access. This lets us know we can begin to start poking around some file shares at the very least. Using smbclient -L [IP address], we can poke at the shares of Bastion to see what’s available to us as a guest:
Also keep in mind, while reading write-ups, these are pretty much like technical reports, so I won’t spend a lot of time going over ALL the enumeration and wasted “time” of “tried” things, because it makes zero sense to type up all the FAILS, so if this reads as if it’s going too fast that’s because it is. I’m documenting all the steps necessary to exploit the machine, nothing really extra. I don’t know the exact time it took for me to root Bastion but lets’ just say its probably more than a day of total hours. It may take you 20 minutes to read this write-up and root Bastion if following along from the retired list.
Getting back on track:
You’re more than welcome to try to access all the shares using smbclient with the following syntax:
however, from experience I can tell you usually with guest access privileges you’re lucky to get access to one share, let alone the C$ or ADMIN$ shares. IPC$ is the default share and will most likely always be accessible but most of the times it won’t be special.
Here, we can access the Backups share easily and start to look around. You can also use the smbclient help command to see what options are available to you. We can see we have a very interesting folder called WindowsImageBackup and with a name like that you can almost guarantee they want you to poke around in here. First thing I would do however, is mount this share to your attacking machine, just so it’s easier to manage and look around. I find the smbclient interface cumbersome and would rather not look around this way even though it’s totally ok to do so. To mount this share with the mount command use:
mount -t cifs //10.10.10.134/Backups [Path of your local machine] -o vers=1.0
I made a custom directory in my HTB and bastion folders to mount the share called remote, and used the mount command to mount the root of the Backups folder to my local “remote” folder. Also, at the time of this writing this command worked lol. If you’re new to all this you will probably find out quickly that a lot of older tutorials or write-ups you come across for command syntax sometimes just doesn’t work due to command updates and etc. I had to use the vers=1.0 option because of SMBv1 being outdated and insecure. Without it, through error messages (and lots of attempts) I was receiving feedback that the command was being upgraded to later versions of SMB and it just wouldn’t connect the share. This of course took a while to figure out, but hey, it is what it is.
Ok, we now have the Backups share mapped to our local machine… Now here is where you can insert HOURS UPON HOURS of enumeration and trying different things. As I mentioned before, these write-ups can not depict the time it takes for proper enumeration and trying things that fail. The beauty of Pentesting is literally spending hours learning about systems you would have otherwise never came across. And also thinking up ideas to try and spending hours watching them fail miserably. Anyway, I digress…
While enumerating the WindowsImageBackup folder, I finally come across two vhd files.
Turns out these are the two intended files to find in order to obtain user. You can google what vhd files are, but the real quick and dirty version is they are virtual hard disks that contain an entire image of a system. Now, here’s where things got a little hectic for user. These files are HUGE. And anyone’s first guess would probably be to try and download them through the network, but that’s not necessary or practical. We can actually mount these vhd files, similar to how we mounted the Backups share, just so we can access the files over the network instead, without making local copies. Insert HOURS UPON HOURS of grueling research, and reading here also because finding the tool to work, and the SYNTAX to make it happen was a nightmare… But I finally was able to get it done.
Just remember to PAY ATTENTION to your folder names and/or path spelling and where you want to mount WHAT. I can’t tell you how many times I got error messages only to realize I had something mistyped or was trying to mount to a location that didnt even EXIST! Anyway, once the vhd files are correctly mapped, you can now poke around them without a mass download of an entire disk. Here is where you can deploy your normal Windows enumeration tactics. Mind you, we still don’t have user or root. We were just able to use what was provided to get a foothold into a system’s backup image. We haven’t actually exploited anything since the shares and the vhd files were accessible to ANYONE over the network. (I wouldn’t make this argument in court, I’m just being technical so to speak).
So… we have full read access to this image. What should we look for first? Well, I could tell you I didnt look for the right thing, so please insert several more hours of grueling enumeration here. Fast forward into the system32/config directory we can see a SAM and SYSTEM file ready and available for the taking. Now, usually these files are not accessible on live systems, but since this is just an IMAGE, they aren’t being used at the moment and can be easily downloaded onto your attacking machine for Cracking of those juicy Windows Hashes.
If you’re using Kali, there’s a really quick and dirty tool called pwdump you can use to obtain the hashes. You just need the SAM and SYSTEM files available in the same directory you call the tool and voila! Hash magic!
One quick glance at the hashes for the trained eye and you can see that the Administrator and guest accounts have nothing as their passwords. The LM and NTLM hashes here are the default NULL password hashes, but that doesn’t mean using nothing can work for Admin access of course. We do have an NTLM hash for the user L4mpje. Now, here is where you can get creative and find multiple tools to crack the hash. Me, on the other hand, I probably took a little lazy route and threw it into a website called crackstation.net and turned out it was able to crack. No shame in my game, as long as I get to where I’m going. That’s part of the beauty of this industry, there’s so many ways to do the same things…
Now, remember when we saw ssh enabled on port 22? This would be a perfect time to try this password against this user. A quick ssh session against this user with the password takes us right into Bastion to obtain the user flag:
Now that we are logged in with a low priv-user, we now have to poke around and find a way to own this machine with the root or Administrator account. As before, insert HOURS UPON HOURS of grueling enumeration and fails and finally we come to the application that’s going to give us the keys to the kingdom (at least one of the applications, of course there could always be more and unintended ways to root these boxes).
Turns out mRemoteNG is installed on this machine and it also turns out it doesn’t protect credentials the way it should. After much research on the application, you can find info that tells you the config files for mRemoteNG saves passwords that aren’t well encrypted. The key here is to find that pesky config file and take a look for yourself. After searching with the where command in Windows I was able to find the location of the confCons.xml file in AppData\Roaming\mRemoteNG:
I did a quick type confCons.xml file to gander inside and voila, I saw an interesting line entry:
Seems like we have a juicy password for the Administrator account. It looks to be base64 encoded, but I doubt it would be that easy. Since the mRemoteNG weak password encryption issue is a known vulnerability I decided to do some research and found this python script on github.
I simply copied this python script, made a quick executable copy of it on my machine and threw the base64 encoded password to it. It then did it’s magic and threw back to me a decoded Administrator password. I then plugged it into a ssh session and voila! Bastion rooted!
Thanks again for reading! Hopefully if you were stuck on Bastion this helped!