Voleur HTB
Voleur Box Overview Voleur is a Active Directory machine that focuses on chaining together multiple privilege escalation paths through delegated permissions, Kerberos abuse, DPAPI credential recovery, and backup misconfigurations. Starting with a low-privileged domain user, we enumerate SMB shares and recover service account credentials from a password-protected spreadsheet. Using BloodHound, we identify a WriteSPN relationship that enables a targeted Kerberoasting attack, leading to access as svc_winrm. Further enumeration uncovers a deleted Active Directory user that can be restored to access archived profile data, where DPAPI-protected credentials reveal another privileged account. This ultimately leads to the discovery of an SSH private key for a backup service account and access to a WSL environment running on the Domain Controller. Finally, exposed backup copies of NTDS.dit, SYSTEM, and SECURITY hives allow offline extraction of domain credentials, resulting in full compromise of the Domain Controller through Pass-the-Hash. Attack Overview Enumeration Nmap Scanning Starting with a full Nmap scan against the target. Nmap Analysis The scan reveals a typical Active Directory environment. Some interesting services include: | Port | Service | |--------|---------| | 88 | Kerberos | | 389 | LDAP | | 445 | SMB | | 2222 | SSH | | 5985 | WinRM | The LDAP banner also reveals the domain name: Adding the discovered hostnames to /etc/hosts: For this machine, HTB already provides us with an initial set of credentials: Machine Information> As is common in real-life Windows pentests, you will start the Voleur box with credentials for the following account: ryan.naylor / HollowOct31Nyt Let's validate them. Instead of an authentication failure, we receive a protocol-related error. Looking back at the Nmap output, we can see: Kerberos is highly sensitive to time differences, so let's synchronize our clock first. Now retrying with Kerberos authentication: Success. Rather than authenticating with the password every time, I prefer generating a TGT and using Kerberos tickets throughout the assessment. Generating krb5.conf NetExec can automatically generate a valid Kerberos configuration file. Moving it into place: Obtaining a TGT Requesting a Kerberos ticket: Exporting the ticket: Verifying it: Everything looks good. SMB Enumeration Enumerating available shares: One share immediately stands out: We have read access to it, so let's inspect its contents. Connecting with SMBClient: Navigating further: Interesting. The share contains an Excel spreadsheet: Downloading it: image Attempting to open the spreadsheet reveals that it is password protected. Cracking the Spreadsheet Password To recover the password, I first extracted the Office hash using office2john. Viewing the generated hash: Now cracking it with John: Success. The spreadsheet password is: Opening the document reveals several interesting credentials. image Recovered credentials: Credential Validation To quickly validate the discovered credentials, I copied the usernames into users.txt and passwords into passwords.txt. Testing them with NetExec: We now have two valid service account credentials: BloodHound Analysis After importing the BloodHound data and marking both service accounts as owned, I started reviewing potential attack paths. The svc_iis account did not appear particularly useful. However, svc_ldap immediately stood out. BloodHound revealed that: image Having WriteSPN over another account is often a strong indicator that a targeted Kerberoasting attack may be possible. Since we control svc_ldap, we can modify the SPN of svc_winrm. Using BloodyAD: Awesome. Targeted Kerberoasting via WriteSPN We successfully added a custom SPN to svc_winrm, setting the stage for a targeted Kerberoasting attack. Since we control svc_ldap, we can now request a Kerberos service ticket for the SPN we just added and attempt to crack it offline. Using NetExec to perform Kerberoasting: Perfect. NetExec has already saved the ticket for us, so there is no need to manually copy the hash into another file. Cracking the Kerberos Ticket Now let's crack the ticket using John the Ripper. That was surprisingly fast. We have successfully recovered the password for: Validating the Credentials Before moving forward, let's verify that the password is valid. Awesome. The credentials are valid. At this point, I marked svc_winrm as owned in BloodHound and looked for additional attack paths. Unfortunately, BloodHound did not immediately reveal a clear route to further privilege escalation. Even though there wasn't an obvious path in BloodHound, we now have a user that can log into the machine through WinRM. Generating a TGT for svc_winrm Since we've been using Kerberos throughout the engagement, let's generate a TGT for svc_winrm. Exporting the ticket: Shell via WinRM Now that we have a valid Kerberos ticket, connecting through WinRM is straightforward. And just like that, we have our first shell on the target. User Flag Navigating to the Desktop and reading the flag: The next step is to enumerate the system as svc_winrm and look for a path to Domain Admin. Privilege Escalation While reviewing the BloodHound data, one object immediately stood out. image If you saw what I saw, then you probably noticed it too: Interestingly, the account appears as a deleted object. The problem is that restoring deleted Active Directory objects requires permissions that our current user (svc_winrm) does not have. However, earlier in the attack chain we obtained credentials for: Since svc_ldap does not have WinRM access, we need another way to execute commands as that user. Getting a Shell as svc_ldap To execute commands under the context of svc_ldap, I uploaded RunasCs.exe. Setting up a listener: Executing RunasCs: Checking the listener: Awesome. We now have command execution as: Restoring Todd Wolfe Before restoring the account, I wanted to verify that it still existed inside the Active Directory Recycle Bin. Searching for deleted objects: Perfect. Todd Wolfe is still present inside the AD Recycle Bin. Restoring the account: The command completed successfully. Testing Todd Wolfe's Credentials Earlier, the password-protected spreadsheet contained the following credentials: Now that the account has been restored, let's see whether the password still works. Output: Awesome. The credentials are still valid. Getting a Shell as Todd Wolfe Setting up another listener: Using RunasCs again: Checking the listener: Success. We now have execution as: Interesting Group Membership Checking Todd's group memberships: The account belongs to: That immediately caught my attention. Earlier, while browsing the filesystem, I noticed a directory structure that looked very relevant. Archived User Data Inside C:\IT there are several support-related directories. Since Todd belongs to the Second-Line team, I started exploring that folder. Interesting. Let's keep digging. That's unexpected. There is an archived copy of Todd's profile stored on disk. Navigating into it: Nothing immediately useful appears here. However, old Windows profiles often contain hidden directories. Checking hidden files: Perfect. The presence of AppData means we potentially have access to: And that's exactly where I started looking next. DPAPI Credential Files Inside the archived profile I found: Listing files: This is a DPAPI Credential Manager blob. To decrypt it we also need the corresponding DPAPI Master Key. Browsing to: reveals: Awesome. We now have both pieces required for DPAPI decryption: The next step is to extract both files and attempt to decrypt the stored credential. Decrypting the DPAPI Credential Earlier, we recovered both the DPAPI Credential Blob and the corresponding Master Key from Todd Wolfe's archived profile. At this point, we have everything required to decrypt the stored credential. Using Impacket's DPAPI utility: Beautiful. The credential blob contains a valid set of domain credentials: Validating the Credentials Before moving any further, let's verify the credentials. Perfect. The credentials are valid. Generating a TGT As before, I prefer working with Kerberos tickets rather than passwords whenever possible. Generating a TGT: Exporting the ticket: Verifying: Everything looks good. --- Shell as Jeremy Combs Now let's log in through WinRM. Output: Success. We now have shell access as: Third-Line Support Technician Checking Jeremy's group memberships: Interesting. Jeremy belongs to the: group. Earlier we saw support-related folders on the filesystem, so naturally I went back to investigate them. Interesting Files Navigating to: Listing contents: Output: Three items immediately stand out: Unfortunately, we don't currently have access to the Backups directory. However, the other two files are readable. Downloading them: Reviewing the Note Contents of Note.txt.txt: This note immediately explains why an SSH private key exists on a Windows Domain Controller. It sounds like someone was experimenting with: and backup tooling. That makes the id_rsa file far more interesting. Investigating the SSH Key Viewing the downloaded file: Output: At first glance we don't know who this key belongs to. Looking closer at the encoded contents reveals something interesting. Decoding the embedded data: Near the end of the decoded output appears: Awesome. We have identified the owner of the private key. SSH Access as svc_backup First, fixing the permissions on the key: My first attempt was: The connection appeared to hang. Looking back at the original Nmap scan quickly explains why. Earlier we discovered: SSH is running on a non-standard port. Trying again: Output: Success. We have successfully authenticated using the recovered SSH private key and obtained a shell as: WSL Backup Discovery Earlier, the note left by the administrator mentioned that they were experimenting with WSL for backup operations. At the time it seemed like a small detail, but now that we have access to the Linux environment as svc_backup, it makes a lot more sense. If backups are being performed from WSL, there is a good chance that backup data is stored somewhere within the mounted Windows filesystem. The first place I checked was: As expected, the Windows C: drive is mounted under: Backup Files Earlier we discovered a directory named: We couldn't access it as jeremy.combs, but now we're operating as svc_backup. Navigating into the directory: Output: Interesting. We have two backup locations: Let's inspect both. Registry Backups These are Windows Registry hive backups. Active Directory Backups And there it is. This is the Active Directory database containing all domain user password hashes. Downloading the Backup Files Copying the registry hives: Next, downloading the Active Directory database: Awesome. We now have local copies of: Dumping Domain Secrets Using Impacket's secretsdump against the offline files: And there it is. The Administrator NTLM hash: Administrator:e656e07c56d831611b577b160b259ad2 At this point the box is effectively compromised. Validating the Administrator Hash Before attempting full access, let's validate the hash. Perfect. The hash is valid. Administrator Shell Using Pass-the-Hash with PsExec: on the Domain Controller. Root Flag Reading the final flag: And that's game over. Final Thoughts Voleur was a fantastic Active Directory machine that rewarded thorough enumeration and careful analysis at every stage. What I enjoyed most about this box was that none of the individual steps were overly complicated, but connecting them together required paying attention to small details and understanding how different technologies interact within a Windows enterprise environment. The attack path flowed naturally from SMB enumeration to BloodHound analysis, targeted Kerberoasting, Active Directory object recovery, DPAPI credential extraction, SSH key discovery, and finally backup abuse through WSL. Each stage built upon information gathered from the pre