Hack The Box – Bastion

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

First thing first, lets run an nmap scan on it:

nmap -sC -sV -O -oA nmap/bastion

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

We will also run an additional UDP scan to see if there is anything hiding there:

nmap -sU -O -oA nmap/Bastion-UDP

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

I probably didn’t need the -O as we already know the OS version from earlier, being Windows 2016 Standard.

The results are in:

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 -U anonymous


We have success! We know the sharenames. Let’s see if we can connect into any of them. Our command for that is:

smbclient //$ -U anonymous

smbclient //$ -U anonymous

Both Permission Denied.

smbclient // -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 \\\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 // /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:


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.


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:


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 // -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!

Posted in HTB

Leave a Reply

Your email address will not be published. Required fields are marked *