Forest is a Windows machine running Active Directory. An anonymous LDAP bind allows for enumeration of the system which can be leveraged to AS-REP-Roast a list of users and obtain a TGT encrypted with a user's password hash. After cracking the password offline, the credentials can be used to authenticate and further enumerate the system, resulting in the discovery that the compromised user is a member of the Account Operators group (members of this group have account creation, modification, and group membership management privileges). Therefore, a new user can be added to another privileged group (Exchange Windows Permissions) which has WriteDacl access rights on the domain, this grants the ability to run a DCSync attack and reveal the NTLM hash for the Administrator account.
nmap scan:
Open ports:
- 53 (DNS)
- 88 (Kerberos)
- 135, 593 (MSRPC)
- 139, 445 (SMB)
- 464 (kpasswd)
- 389, 3268 (LDAP)
- 636, 3269 (LDAPS)
Active Directory:
- domain name: htb.local
- hostname: FOREST
I attempted an anonymous LDAP bind with crackmapexec which allowed me to view users on the system:
I created a list of users and ran GetNPUsers.py from Impacket to see if any accounts were vulnerable to AS-REP-Roasting.
As shown in the output above, svc-alfresco was the only user with the UF_DONT_REQUIRE_PREAUTH flag set (meaning that Kerberos pre-authentication wasn't required), resulting in the retrieval of the AS-REP message with a TGT that has been encrypted with the user's NTLM password hash. So I saved the TGT in a file called hash.txt and cracked it with john.
I confirmed the creds worked by making a connection with evil-winrm:
With the valid credentials I was able to authenticate and collect AD data with bloodhound-python to do some further enumeration:
After importing the data into bloodhound, viewing reachable high value targets for svc-alfresco showed that the user was a member of the Account Operators group due to nested group membership (Service Accounts → Privileged IT Accounts → Account Operators):
Members of the Account Operators group have a certain level of administrative rights. As stated on the Microsoft Docs:
The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including accounts for users, Local groups, and Global groups. Group members can log in locally to domain controllers.
As shown below, Account Operators had GenericAll on the Exchange Windows Permissions group which had WriteDacl on the domain, as a result, members of this group could grant themselves any privileges on the HTB.LOCAL object.
I used the WriteDacl Windows abuse info provided in bloodhound as a guide to run a DCSync attack. Although, I had to make some modifications to make it work properly.
Privilege escalation consisted of the following steps:
Since I needed the Add-DomainObjectAcl cmdlet from PowerView for one of the final steps to grant the user DCSync permission, I started a local python server which contained PowerView.ps1 from PowerSploit:
Downloaded it onto the target machine and imported the script into the current session:
Created a new user (user1) and added them to the Exchange Windows Permissions group:
Granted user1 DCSync permission:
Used secretsdump.py to dump NTLM hashes:
I ran psexec.py to pass the NT hash of the Administrator user to obtain a shell as nt authority\system:
