Let’s have a crack at Bastion. It’s been released for 2 days, so far the User is seen as “Easy” with root being “Easy”/”Not too Easy”
So things we know straight up. It’s a Windows box with the IP of 10.10.10.134
First thing first, lets run an nmap scan on it:
nmap -sC -sV -O -oA nmap/bastion 10.10.10.134
The results are in, we have 4 ports open:
- 22 – SSH
- 134 – MSRPC
- 139 – netbois-ssn
- 445 – microsoft-ds
The host scrips brings back some potentially interesting results:
Host script results: |_clock-skew: mean: -39m58s, deviation: 1h09m14s, median: 0s | smb-os-discovery: | OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3) | Computer name: Bastion | NetBIOS computer name: BASTION\x00 | Workgroup: WORKGROUP\x00 |_ System time: 2019-04-29T19:00:50+02:00 | smb-security-mode: | account_used: guest | authentication_level: user | challenge_response: supported |_ message_signing: disabled (dangerous, but default) | smb2-security-mode: | 2.02: |_ Message signing enabled but not required | smb2-time: | date: 2019-04-29 18:00:49 |_ start_date: 2019-04-29 17:50:00
I’d say the ports 139/445 (SMB) are where we really need to look at first.
We have done this is on some previous boxes, but before we first digging. Let’s do a full port scan, there might be stuff hiding on high ports? Let’s run this in very verbose mode so any results come up straight away:
nmap -sC -p- -vvv -oA nmap/bastion-all-ports 10.10.10.134
We will also run an additional UDP scan to see if there is anything hiding there:
nmap -sU -O -oA nmap/Bastion-UDP 10.10.10.134
Well, I’m glad I did the full port scan, look at these results:
5985/tcp open wsman syn-ack ttl 127 47001/tcp open winrm syn-ack ttl 127 49664/tcp open unknown syn-ack ttl 127 49665/tcp open unknown syn-ack ttl 127 49666/tcp open unknown syn-ack ttl 127 49667/tcp open unknown syn-ack ttl 127 49668/tcp open unknown syn-ack ttl 127 49669/tcp open unknown syn-ack ttl 127 49670/tcp open unknown syn-ack ttl 127
So, lets look closer at those ports.
nmap -sC -sV -O -p 5985,47001,49664,49665,49666,49667,49668,49669,49670 -oA nmap/Bastion-HighPorts 10.10.10.134
I probably didn’t need the -O as we already know the OS version from earlier, being Windows 2016 Standard.
The results are in:
PORT STATE SERVICE VERSION 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49669/tcp open msrpc Microsoft Windows RPC 49670/tcp open msrpc Microsoft Windows RPC
2 ports with HTTPAPI on. I’m not entirely sure what they are. A quick google lets me know that:
SSDP is Simple Service Discovery Protocol which advertises and looks for network services. This controls communication for the Universal Plug and Play feature (uPnP).
This now rings a bell, was there not the printer and chromecast thing supporting pewdiepie. Looks pretty similar: https://www.bleepingcomputer.com/news/security/hacker-streaming-pewdiepie-videos-on-exposed-chromecast-devices/
So, this might well be our way in. A quick searchsploit shows a few vulnerabilities for UPnP:
So there are a few Buffer Overflows for Windows, but these are 98/XP/ME and we know that our target is running Windows Server 2016, so no dice there.
A quick check that there isn’t a webpage associated with the ports, reveals both get a 404 error, so that’s no good!
Right. The question is, what do we have and where do we go from here.
My first though, before the full port scan was looking at the SMB share to see if there is anything there. Let’s give that a go.
So let’s fire up smbclient and see what we can find, first let’s try and use an anonymous user to get the shares:
smbclient -L 10.10.10.134 -U anonymous
Ok:
We have success! We know the sharenames. Let’s see if we can connect into any of them. Our command for that is:
smbclient //10.10.10.134/C$ -U anonymous smbclient //10.10.10.134/ADMIN$ -U anonymous
Both Permission Denied.
smbclient //10.10.10.134/Backups -U anonymous
Hooray! We are logged into the backups folder as an anonymous user.
A quick look around, we have a note.txt and an nmap-test-file, a couple of directories, but these are empty. There is also a .tmp file.
So we use the “get” command to bring those back to our machine.
get nmap-test-file get note.txt
So these are now locally on our host. Stupidly, I did this while in the /tools/enum4linux directory, so that is where they saved. I found them using:
find note.txt . | grep note.txt
Moved them back into the right directory.
Looking at the note.txt file first:
Interesting, so they use a VPN and there is some sort of backup. There is the folder WindowsImageBackup, let’s grab that.
The other file is empty.
Let’s see what really is in here, entering the recurse in the smb window lets us list all files, going through folders.
So there are a whole bunch of .xml files. Let’s see if we can grab all of those. Because of dash in the PC name, I can’t seem to recursively download everything, so I’ll have to do it file by file.
The XML files look to be configs, probably for the backup software. The .vhd files are the actual backups on the file structure.
Now, I think this is where the note comes in. It states don’t transfer the entire back up locally as the VPN issue. This isn’t them using a VPN, this is a message to us, the HTB VPN can’t cope with that sort of traffic. As a check we give it a go and we get a timeout. Not unexpected!
So, we either need to host it somewhere (a webserver) or mount and read it on the host pc.
So, this is now the tricky part. We know what we need. Those backups. The question is how do we get them? We have high ports open, let’s go back to the fact that both port 5985 and 47001 are httpapi ports. This now seems sensible to be our exfil point!
At this point, I had a quick look at the forum and it appears mounting it via the SMBshare is a better method. So let’s explore that.
So there are 2 commands in Windows to mount a VHD.
Via CMD:
select vdisk file="\WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd"
or Via Powershell:
Mount-VHD -Path "\WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd"
Quite reasonably, neither of these work over smbclient. As we are using SMB shares, I might be able to mount them in windows? Let’s spin up a Windows 10 VM and see if that helps! (My host machine is Windows 10, but I really don’t want to connect into HTB on my host machine!)
Ok, a windows10 VM is spun up. VPN connected and look here, we have the SMB share:
So, using the powershell we learnt earlier. Let’s try this out!
Not a great start, this is due to hyper-v and that fact I’m on VMware.
Can we use the built in “mount” function? After a lot of back and forth, I found out you can’t if you map the drive (to z:\ for example). So I try without the UNC path \\10.10.10.134\Backups\WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351
Click Mount and….
Sigh! So that would probably work, if it wasn’t a heavily used platform!
So let’s go back to Linux. The first thing we need to work out, is how to mount the SMB share, so that we can navigate to it. After some googling I managed to find this blog: https://www.shellhacks.com/mount-remote-windows-partition-share-linux/ which helped me out.
Firstly, we created a folder for the share to be connected to on our Linux box:
mkdir Share
Also downloaded and installed the cifs toolset which allows for this connection:
apt-get install cifs-utils
The next part is running the command:
mount -t cifs //10.10.10.134/Backups/ /home/Yekki/Documents/htb/Bastion/Share/ -o dom=DOMAIN,user=anonymous,pass=Hello
A quick look in the share and doesn’t this look familiar:
So we can now go through and the VHD files are there.
Now we just need to work out how to mount the VHD so we can also explore that.
There is a set of tools called libvhdi which I found in this video: https://www.youtube.com/watch?v=inxoqsH9TxI
Once the tools are installed, we can try the commands:
vhdimount 9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd /home/Yekki/Documents/htb/Bastion/Mount/
The command worked. But the permissions on the mount are very odd:
If we sudo su up to root. We are able to go into the Mount file, and we see vhdi1 as a file. We can’t directly interact with this file yet, as it hasn’t been mounted on our system.
To be able to mount and use this file, we need to calculate the offset of the mount.
First we need tp look at the partition data of the file, using:
mmls -aB vhdi1
This gives us a result of:
So the units are in 512-byte sectors.
To do the calculation we need to obtain the bc package which is a arbitrary precision calculator language.
apt-get install bc
We can then use this which is the last digits in the Start column, so for our case it’s 128. Then also using the units which we saw earlier is in 512-byte sectors.
echo 128*512 | bc
This results in 65536. This is the offset level for where the data starts.
The follow command should mount the vhd file for us to be able to explore:
mount -o ro,noload,offset=65536 vhdi1 /home/Yekki/Documents/htb/Bastion/Mount/
After waiting for a verrrry long time….
We can see that the directory is now searchable!
Lets have a look around and see if we can find a user flag.
So if this is a backup, the flag should be in Users/L4mpje
Nope. Nothing in there.
Let’s go a grep on the entire Mount to see if there is anything there:
grep -iR user.txt .
No flag. There is another step to this!
So if we remember our nmap scan from earlier, port 22 is open. So I wonder if there is an SSH password we need to get.
Windows stores it’s NTLM hashes under something called SAM the Security Account Manager. This tends to be located in Windows/System32/config
Normally you can’t open or copy this file, as it is always being used by System. However as this is a backup, not a live system. We might get lucky. So let’s head over there:
cd /Windows/System32/config
Ah there is a SAM, SECURITY and SYSTEM file. We will need all of these. I copied these across to my host machine, that way if the box gets reset is doesn’t affect the next stages.
To get anything useful from these, we need to dump it out.
There is an excellent set of tools called impacket available from here: https://github.com/SecureAuthCorp/impacket
Within that set of tools they have secretsdump.py which is what we will use. Installing impacket is easy, clone to repository then when in the folder run:
pip install .
The python script is then under impacket/examples/secretsdump.py
Running the script with the 3 variables:
./secretsdump.py -sam /home/Yekki/Documents/htb/Bastion/SAM -security /home/Yekki/Documents/htb/Bastion/SECURITY -system /home/Yekki/Documents/htb/Bastion/SYSTEM local
Give us this result:
We have the hash. Let’s run this through hashcat which has a built in NTLM hash option.
Firstly, we take out the part of the hash that we need, which is after the 3rd colon. Starting with 2611 for the L4mpje user. This is due to the the format of the NTLM hash. We have:
L4mpje:1000:aad3b435b51404eeaad3b435b51404ee:26112010952d963c8dc4217daec986d9::: User:relative identifier: LM Hash: NT Hash:
Hashcat requires just the NT hash. So we copy that into a new text file.
echo "26112010952d963c8dc4217daec986d9" > L4mpje-hash.txt
Looking at hashcat, NTLM hashes are hash mode 1000 (https://hashcat.net/wiki/doku.php?id=hashcat) We want to set the attack mode as 0 (straight) and output the file.
hashcat -m 1000 -a 0 -o password.txt L4mpje-hash.txt /usr/share/wordlists/rockyou.txt --force
We had to use the –force option as I’m doing this cracking in a VM rather than with dedicated graphics cards.
If we cat the output file we get:
There is the password. You will notice that Impacket also output the password, but I wanted to go through hashcat just to double check (and learn).
So now I guess we can use this to ssh into the box.
Success. Now, as this is the live box, we can go have another look at the User share and see if there is a flag this time.
There it is! Now just to remember how to read a file from cmd.
Win!
Now, let’s head onto root and see what we can do!
Having an initial look around the system, there are a couple of programs we can investigate. In Program Files:
We have PackageManagement which is a set of cmdlets from Windows. Seems unlikely to be our route in. The other is OpenSSH but this will be to allow our SSH session onto the box.
Heading over the Program Files (x86) we get:
I’m not sure what mRemoteNG is, but looks like it could be interesting. A quick google tells me that it’s a remote connections manager allowing for a range of different connections. A quick searchsploit brings up nothing but a google search brings back some results:
Yeah I think we are in the right place here! It looks like the “bug” was fixed in v1.76. Let’s see if we can find out the version installed. There is a changelog file, the latest entry is, v1.76.10.
So it looks like exploits aren’t the same way. Let’s see if there is password leakage anywhere.
Looking at the application, there is another config file stored in:
C:\Users\L4mpje\AppData\Roaming\mRemoteNG
If we read the config file we get a whole heap of info. But what we really need is this part:
The protocol is RDP on port 3389. However port 3389 isn’t open as we found out on our nmap scan earlier, so that’s a no go.
This password also looks a lot like a hash. It’s not base64 as it has a “/” in it. A quick google of getting password from the mRemoteNG brings up a bunch of results. This was most useful: https://robszar.wordpress.com/2012/08/07/view-mremote-passwords-4/
We can create a External Tool within the program which does:
/k echo %password%
This will then decrypt and print out the password in plain text. After wondering how I could do this from just an ssh shell, I realised that it wasn’t really an option. So instead, lets download the program and see if we can get that config file out to our local Windows VM.
I went and downloaded and installed the program from the offical github: https://github.com/mRemoteNG/mRemoteNG
After installing the program, I went about exfilling the data. I tried to copy & paste from a type. However all the spacing was wrong and was just a terrible idea all round. It then took me a while to think of what to do. If this was linux, i’d do a SimpleHTTPServer, but no good. Then I remembered how I got the data out originally, the SMB share. Obviously! Once I realised, I felt like a right wally, anyway!
So first off I used copy:
copy confCons.xml C:\Backups
Then I went back and used smbclient
smbclient //10.10.10.134/Backups -U anonymous get confCons.xml
Then to leave as few spoliers as possible, I went back to my ssh sessions:
del C:\Backups\confCons.xml
Always try to tidy up after yourself, otherwise you are ruining it for other users! Especially as the SMB is at the start of the box!
On my VM I copy the file into the same place APPDATA/Roaming/mRemoteNG
Open up the software
Both users are there. We know from the config the DC uses administrator so this is the one we are interested in.
First though, we need to create the external tool. In MRemoteNG go to “Tools” -> “External Tools”
Click New and fill in the details:
Going back to our connections, lets try the L4mpje-PC user and see if that password matches the one we got earlier:
It does, brilliant. So we know the theory here works! Let’s get the admin password!
Lets try to ssh in with those creds. Success!
Heading over to Desktop, we see the root flag there!
And there is the root flag!
I really enjoyed this box, it used skills that I had but going through the process and writing it up really helped me embed that knowledge. Getting the user password was really interesting and totally real life which I enjoyed, I can see that being used on tests in the future.
The root was also good, nice to not rely on an exploit but dig deep and enumerate until you find each of the interesting parts!