Jumping into this box with a basic NMAP scan shows us a couple of interesting things. First, the SSH server, but that’s pretty normal for HTB boxes. I tried to log into it with anonymous credentials, but that didn’t work out. The most important thing to pick up on from the scan is that it’s likely a Windows machine with NetBIOS and SMB shares, due to the ports 135,139, and 445. Port 135 had several well-known vulnerabilities plague it over the years, so maybe it could be vulnerable to one on this box. Also, there have been vulnerabilities for SMB, like the famous EternalBlue. So we could run some exploit tests against those ports just in case…
Initial Foothold
Exploit Checks
I didn’t find anything useful for RPC exploits, but did find some for the EternalBlue SMB exploit.
Then I made another search, this time on “ms17-010”, the vulnerability CVE code.
Then I ran the exploit …
But no dice… the exploit path is probably a bust, so I moved on from wasting any more time on that approach.
SMB Guest Access
Then I tried the easy thing that should have been done first: connect to SMB without credentials.
I tried first connecting with the file explorer in kali, but it wouldn’t accept a connection without credentials. So I tried smbmap next.
That also didn’t work, but maybe I was just using it wrong. Either way, I moved on to trying smbclient.
Finally I was getting somewhere, I could see the shares listed on the SMB service!
So then I used smbclient to log in and went exploring…
After looking at all the folders, the only interesting one is WindowsImageBackup. Also there is a warning about downloading the entire backup file:
After digging into the “Backups” share, I found a WindowsImageBackup with two VHD files.
I don’t often listen to signs well, so I proceeded to download the VHDs anyway, but it disconnected the session pretty quickly.
Search For User
Getting Into the VHD
Reading just a little in the forums led to a hint from L4mpje that the VHD files can be opened remotely.
Initial googling led to opening VHD files with native windows disk management, but that wound require making a windows VM, or opening my host machine to a network full of hackers, so I decided to keep searching…
mount -t cifs //10.10.10.134/Backups /mnt/remote -o ro
That is the command explained in the article above, and it allowed me to mount the remote SMB share to a local folder…
… where I could see and access the VHD files directly! Awesome way to do things and I’ll definitely be keeping notes on this method.
Another cool technique is to seperately mount the VHD files to another folder and explore inside, using the local shell!
I first opened the smaller VHD, but it turned out to be a system boot partition, so then I opened the larger one to find the next clue.
Extracting the Secret Sauce
From here I just explored for a looooong time, looking and prodding at everything.
Eventually looked into opening the Registry and extracting passwords.
Tried mimikatz, but it didn’t run in kali well. Tried a tool to open the registry like a filesystem and poke around, that didn’t work. Eventually found pwdump from the creddump package that works the best:
I knew there were some programs for cracking these hashes with dictionary files, hashcat being one I’ve used before and also John the Ripper.
From reading some of the forums to get hints previously, I noticed people talking about “John”, so I guessed JtR would be the way to go. I wasn’t sure what type of hash to put in, and instead of letting john go through them all I looked up the possibilities and tried some until I got it right.
To get the available formats for John, use:
john -list=formats
This is the result of the password cracking:
Awesome, a user password for L4mpje!!! bureaulampje
Using the credentials found in the Registry, I logged into the SSH and the flag is in the Desktop folder.
The Search for Root
First Clues
With the user flag found and a live login to the box, I searched around the files and folders for an hour or more. Just poking and prodding.
When reading the forum for clues, several people said to look for a program that seems out of place:
Nothing really out of place there, how about the x86 program files:
Bingo! mRemoteNG looks pretty out of place! I’ve used this software before, so I know that it stores connections to things, which necessarily includes the passwords. Maybe there’s some passwords we can retrieve.
mRemoteNG
This is the directory listing for mRemoteNG:
After looking at the mRemoteNG.exe.config, there wasn’t anyting obviously useful to me. So I looked in the program data folders.
Nope, nothing there either.
And in AppData\Local\mRemoteNG there is only one file, user.config
That gave me the path of the log file, but nothing was really interesting in the log file itself. However, other things were in the AppData folder:
confCons.xml looked particularly interesting. It was clearly important since it had all those backups.
On close inspection I could see there was a connection defined for L4mpje, and another for Administrator. The Administrator password is what we want, but it’s encrypted.
We’re given encryption details at the beginning of the file. One possible option is to take those details and try to decrypt it. But I don’t want to do that if we can get mRemoteNG to do the decryption for us.
The forum posts suggested Google had the answers once we discovered which software was out of place. I found that an external command can be made that will display the decrypted password!!!
If you download the Zip version instead of installer, everything stays in the same folder, so it’ll be a little easier to manipulate. To get the connection details into mRemoteNG, copy the text that was extracted from the SSH session into an xml file and save it as confCons.xml.
After copying the text, saving it, and opening mRemoteNG, I got an error:
Turns out a straight copy of the text from the shell resulted in data not formed well, so I had to clean up the XML and reload. After that it worked great.
Then the external tools script could be put in to extract the password.
Admin password found!! With that you can log into the SSH with Administrator and grab the root flag!