Hard

Introduction

Prompt: The next host is a Windows-based client. As with the previous assessments, our client would like to make sure that an attacker cannot gain access to any sensitive files in the event of a successful attack. While our colleagues were busy with other hosts on the network, we found out that the user Johanna is present on many hosts. However, we have not yet been able to determine the exact purpose or reason for this.

Target: 10.129.202.222

Nmap Scan

Starting off with a default scripts, service enumeration nmap Scan

rpc, smb, rdp

RDP being open and them explicitly mentioning the user Johanna earlier leads me to believe I should be bruteforcing RDP as our actual access, could be smb vulns too though

Running smb bruteforcing on the user Johanna with the mutated password list we generated using the htb custom password list and custom rules. This was done in the previous challenge so I didn’t regenerate it

While that was running I also started

a hydra attempt on RDP, but that was giving the following errors:

[3389][rdp] account on 10.129.202.222 might be valid but account not active for remote desktop: login: Johanna password: 123452020, continuing attacking the account.

SMB Bruteforce

Eventually the SMB bruteforce did find a valid credential

[+] 10.129.202.222:445    - 10.129.202.222:445 - Success: '.\Johanna:1231234!'
1231234!

Using SMB client to try and list shares on the SMB server

Initial Access as Johanna

Attempting to RDP into the machine using Johanna: 1231234! works so the hydra error message didn’t end up mattering much.

In the recently accessed files I find a local Database for a password manager

The password 1231234! didn’t end up decrypting this, maybe we will need to transfer it over and bruteforce.

Doing some research .kbdx files are a database file for the local password manager keepass.

Googling, there is a keepass2john script for making a hash to brute force so that seems like a path forward

Attempting to move the file from the rdp session to my host made the session explode, so I ended up making a new target.

Next idea was hosting a python upload server or opening a smb share on my attacking machine and then mounting it on the windows host to copy the keypass file over. I opted for the first option here

#make venv
python3 -m venv upload
#go into venv
source /upload/bin/activate
#install upload server
python3 -m pip install uploadserver
#run server
python3 -m uploadserver
 

I navigated to my upload server in the browser after forming another RDP session to the new host and upload the keypass file that way

With the file now on my attacking host I converted the file to a hash and then ran john on it with the mutated password list I used to bruteforce SMB

Qwerty7!

Initial Access as David

Opening the Logins file in the RDP session with the password above we find a login for david. I right clicked on the field and copied password to get it.

david:gRzX7YbeTcDG7

Then I open a cmd instance as johanna and attempt to spawn in a shell as david using the credentials we found

runas /user:david cmd.exe
#that prompts for his password and we log in with a shell as david

Running tree in Davids home directory I find presumably the share that we saw earlier in smbmap

Cracking a backup file

Inside is a Backup.vhd file.

I use the same method as before to copy the file over to my attacking machine as I assume we are going to need to crack that thing.

A weird nuance was spawning google chrome as david for permissions

#starting chrome in davids cmd temrinal
start chrome

Then I just navigated to the location manually in chrome again and uploaded it from there

Once the file is transfered over I followed some steps from the earlier module to crack encryted virtual hard drives

#convert the vhd to a set of hashes
bitlocker2john -i Backup.vhd > Backup.hashes
#use some parsing to select one of the hashes
grep "bitlocker\$0" Backup.hashes > Backup.hash
#run hashcat on the hash with the same password list as before
hashcat -m 22100 Backup.hash ~/Desktop/mut_password.list -o backup.cracked
 
cat backup.cracked
123456789!

I couldn’t figure out how to start a session of explorer as david from the cmd session I had earlier… So I host a web server on my attacking machine to copy the vhd file from there to somewhere Johanna has permissions in our rdp session

#on attacking machine
python3 -m http.server
 
#on target in cmd through our rdp session
curl -O http://<my ip>/Backup.vhd
 

Realizing I don’t have admin permissions to mount the drive, I copy the backup.vhd file to a windows vm and mount it here by just clicking on it. It will then prompt for credentials and you can enter the password we got from cracking the backup: 123456789!

Inside we find a SAM and System file. Earlier we learned you can extract credentials from those with an impacket script

Running systems dump on the SAM and System files

For whatever reason my kali instance of impacket wasn’t working, so I reinstalled it, system-wide this time for convenience later

#installing pipx, using --break-system-packages because lazy, could use venv
python3 -m pip install pipx --break-system-packages
#instlaling impacket system wide
python3 -m pipx install impacket
 

Running secrets dump now that it is installed

Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 
 
[*] Target system bootKey: 0x62649a98dea282e3c3df04cc5fe4c130
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:e53d4d912d96874e83429886c7bf22a1:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:9e73cc8353847cfce7b5f88061103b43:::
sshd:1000:aad3b435b51404eeaad3b435b51404ee:6ba6aae01bae3868d8bf31421d586153:::
david:1009:aad3b435b51404eeaad3b435b51404ee:b20d19ca5d5504a0c9ff7666fbe3ada5:::
johanna:1010:aad3b435b51404eeaad3b435b51404ee:0b8df7c13384227c017efc6db3913374:::
[*] Cleaning up... 
 

copied that admin into a file and ran hashcat against it with the same password list we’ve been using and that cracks it.

sudo hashcat -m 1000 admin.hash ~/Desktop/mut_password.list --show
 
Liverp00l8!
 

Using the same runas trick in johannas cmd from earlier I open a shell as administrator passing in the password we found above and retrieve the flag

runas /user:administrator cmd.exe