Pentesting Windows Active Directory with BloodHound | HackTheBox Forest | CREST CRT Track
We covered HTB Forest as part of CREST CRT Track where we performed AS-REP ROASTING and DCsync on the machine running Windows server active directory. There was no online application to serve as an attack surface, it was a special box. We had to take advantage of a null session to obtain a user’s hash, which we then applied to the box to obtain a shell. We then use that shell to run Bloodhound to find a way to elevate our user account privileges, use that account to dump secrets, and finally log in to the box as the administrator using those secrets.
Initial Enumeration & Discovery
I started by performing an Nmap scan on the target machine to uncover open ports and services. My command was:
nmap -A <IP_ADDRESS>
This scan was quite revealing! I found several open ports, including Port 53 (DNS), Port 88 (Kerberos), which immediately suggested possibilities for Kerberoasting or AS-REP Roasting, Port 445 (SMB) and RPC, and Port 5985 (WinRM), which looked like a promising entry point if I could get some credentials. The scan also confirmed it was a Windows Server 2016 with Active Directory installed (LDAP), and I identified the domain name as forest.htb.local.
Next, I delved into RPC Client Enumeration to gather user and group information. I connected using:
rpcclient -U "" -N <IP_ADDRESS>
Once connected, I enumerated users with enumdomusers, which listed users like Administrator, Guest, Sebastian, Lucinda, service_alfresco, Mark, and Andy. Then, I enumerated groups using enumdomgroups, finding familiar groups like Domain Admins and Domain Users. To see who was in the Domain Admins group, I used querygroupmem <GROUP_RID>, and it showed only the Administrator.
Exploiting AS-REP Roasting
I remembered that AS-REP Roasting can be exploited if a user account has the “Do not require Kerberos preauthentication” attribute set. I used GetNPUsers from the Impacket toolkit to try and roast some hashes:
getNPUsers.py <DOMAIN_CONTROLLER_IP>/<FULLY_QUALIFIED_DOMAIN_NAME> -usersfile <USERS_FILE>
The usersfile contained the list of users I’d gathered earlier. This was a success! I managed to retrieve the hash for the user service_alfresco.
With the hash in hand, I moved to cracking it using John the Ripper:
john <HASH_FILE> --wordlist=<WORDLIST_PATH>(I usedrockyou.txtas my wordlist)
It didn’t take long for John to crack the password for service_alfresco, revealing it to be S3rvice.
Gaining Initial Foothold (WinRM)
Now that I had valid credentials, I used WinRM to get a shell on the machine. Evil-WinRM was the perfect tool for this:
sudo evil-winrm -i <IP_ADDRESS> -u <USERNAME> -p <PASSWORD>
This gave me a shell as the service_alfresco user, and I was able to snag the user flag.
Privilege Escalation with BloodHound
To figure out how to escalate my privileges further, I turned to BloodHound. First, I needed to collect data from the Active Directory environment using SharpHound, which is BloodHound’s ingestor. I downloaded SharpHound onto the target machine (though the exact download command wasn’t shown, it’s typically done via PowerShell) and then ran it with:
Invoke-BloodHound -CollectionMethod All -Domain <DOMAIN_NAME> -LDAPUser <USERNAME> -LDAPPass <PASSWORD>
This generated a handy ZIP file with all the collected data. I then downloaded this ZIP file to my local machine using Evil-WinRM’s download command:
download <FULL_PATH_TO_ZIP_FILE_ON_TARGET> <LOCAL_PATH_TO_SAVE>
Once I had the data, I started the Neo4j console (sudo neo4j console) and then BloodHound itself (sudo bloodhound). After uploading the ZIP file, I ran the “Find Shortest Path to Domain Admins” query.
The analysis in BloodHound was crucial! It showed a path: service_alfresco -> Service Accounts -> Privileged Accounts -> Account Operators. More importantly, it highlighted that the Account Operators group had WriteDACL permissions over the Exchange Windows Permissions group. This meant that service_alfresco, being effectively part of Account Operators, could add itself to the Exchange Windows Permissions group.
Exploiting WriteDACL and DC Sync
My first step was to add service_alfresco to the Exchange Windows Permissions group. I did this on the target machine with:
net group "Exchange Windows Permissions" service_alfresco /add
Being part of Exchange Windows Permissions can lead to DC Sync rights, which is a powerful privilege. I first tried to grant these rights manually using PowerShell, but the Add-DomainObjectAcl command wasn’t recognized.
So, I switched to Impacket’s ntlmrelayx.py, which proved successful:
ntlmrelayx.py -t ldap://<FULLY_QUALIFIED_DOMAIN_NAME> --escalate-user service_alfresco
This started a web server, and by navigating to 127.0.0.1 on my attacker machine and providing service_alfresco credentials, I successfully granted DC Sync rights.
With DC Sync rights in hand, I could now dump all domain hashes, including the Administrator’s, using SecretsDump from Impacket:
secretsdump.py <DOMAIN_NAME>/<USERNAME>:<PASSWORD>@<FULLY_QUALIFIED_DOMAIN_NAME>
This command successfully retrieved the NTLM hash for the Administrator account.
Gaining Administrator Access (Pass the Hash)
Finally, I used the Administrator’s NTLM hash with PSExec (also from Impacket) to gain a system shell. While the exact command execution wasn’t fully shown in the video, the general idea is:
psexec.py -hashes <ADMIN_LM_HASH>:<ADMIN_NTLM_HASH> <DOMAIN_NAME>/administrator@<TARGET_IP> cmd.exe
This granted me full administrative access to the machine, allowing me to retrieve the root flag and complete the challenge! This video provided an excellent demonstration of a common Active Directory attack chain, from initial enumeration and exploiting misconfigurations to leveraging powerful tools like BloodHound for privilege escalation and ultimately achieving domain compromise via DC Sync.
