HackTheBox: Forest - OSCP Prep

This is a ‘easy’ rated HTB AD challenge in which we will be enumerating and attacking purely the DC. My offensive AD knowledge isn’t great so I apologise for any poor explanations.

Reconnaissance

Nmap

I always start my boxes & pentests with a thorough nmap scan. This will help me enumerate the possible routes for further recon & initial-access.

nmap -p- -sV -sC -o full_thorough.log 10.10.10.161

Wow, there are a lot of ports open. I’m not going to explain each one, however, let’s quickly list the stood out to me.

• 88/tcp - Kerberos. Kerberos is an authentication protocol found in Windows AD enviroments. Seeing this port open is a indicator that this could be a Domain Controller.

• 389/tcp - LDAP. Lightweight Directory Access Protocol, or LDAP, is a protocol that applications can use to speak to directory services, i.e. AD. This could be a possible route for enumeration which we will investigate later

• 445/tcp - SMB. This is also a route for enumeration, we will look into this soon.

• 5985/tcp - WinRM. This protocol allows remote access (i.e. a shell), but requires a valid set of credentials. This could be an oppurtinity for initial access.

In the smb-os-discovery scans we discover that the domain name is htb.local. I’ll edit my hosts file to point this domain to 10.10.10.161.

SMB

We’ve discovered SMB is open, a common misconfiguration in AD enviroments is allowing guest or null authentication. Let’s test this out.

In the above I’m using two sets of common null/guest credentials, '':'' & 'guest':''. We can see the later gets an authentication error, however the the first set, with an empty username & password, doesn’t recieve any error.

Knowing this, let’s try use crackmapexec to enumerate further information over SMB.

No luck. Although null authentication is allowed, it looks like we cannot enumerate any useful information through it.

LDAP

LDAP is also a great place to look for enumeration, and also can be misconfigured to allow anonymous authentication. Let’s test this out.

ldapsearch -x -H ldap://htb.local -D '' -w '' -b "DC=htb,DC=local"

Fantastic. The output of this command dropped all the domain information from LDAP. This is a lot of information - we can use LDAP queries & filters to get a more manageable output.

Extract users

ldapsearch -x -H ldap://htb.local -D '' -w '' -b "DC=htb,DC=local" "objectClass=user" "sAMAccountName"

This works by quering the whole directory, DC=htb,DC=local, where the objectClass attribute is set to user, and using sAMAccountName to extract to just the usernames. Let’s see the output.

Great! We’ve got a list of users, but this is quite messy, let’s do some Linux trickery to get an output of pure usernames.

Only the last 8 are real valid user accounts.

Extract OUs

ldapsearch -x -H ldap://htb.local -D '' -w '' -b "DC=htb,DC=local" "objectClass=organizationalUnit" "dn" | grep "dn:" | cut -d ':' -f2

I then searched through these OUs individually with ldapsearch. All of the user accounts we previously discovered existed in the role-based OUs (Helpdesk, Sysadmin, Sales ect).

However, in the Service Accounts OU, I discovered a new service account!

We can add this svc-alfresco service account to our user list.

Initial Access

When it comes to gaining initial access in AD enviroments, when we don’t have an internal webservice to pwn to gain remote code execution there are a few options I know to take.

1. Brute-forcing / Password spraying - We can enumerate the password policy to validate whether brute-forcing with a wordlist will be possible. If it’s not, we can do a password spray attack.

2. AS-REP Roasting - This is a Kerberos attack on user accounts which have the specfic AD attribute, ‘Dont require Kerberos preauthentication’, enabled. With this technqiue it is possible to gain credentials to get initial access.

3. Service / Kernel exploits - Perhaps this version of Windows Server, or one of the running services, is inherently vulnerable to publically accessible exploits.

AS-REP Roasting

Of these 3 options, I first went for the 2nd, AS-REP Roasting. This is because it’s simple to check. Let’s explain how this attack works.

The above shows the various stages of the Kerberos authentication protocol. At the first stage, a AS_REQ packet is sent. AS_REQ is sent the KDC on the Domain Controller, to request for a Ticket Granting Ticket (TGT). The AS_REQ contains fields which include:

• A timestamp encrypted with the requesting users password hash

• The username of the authenticated user

Once the KDC recieves the AS_REQ, it will validate the request by decrypting the encrypted timestamp. It can do this because the Domain Controller will have a database of all the users hashes. Once validated, the Domain Controller will send back the AS-REP packet, which contains the TGT. Part of the TGT is signed with the user’s password hash. This means if we have the TGT, we will be able to recover that users password hash, that can be cracked locally.

However, if the user has the attribute ‘Don’t require Kerberos pre-authentication’ set, when we send a AS_REQ packet, the KDC will not validify the password. Instead, it will automatically just send back the TGT, giving us the hash to crack locally!

We can do this attack from our Linux box, aslong as we have network access to DC. I used the Impacket tool GetNPUsers.py

Fantastic! The svc-alfresco service account did indeed have this ‘Dont require Kerberos preauthentication’ attribute set, so we could recover the hash.

Hash cracking

Let’s move this hash into text file as_rep_hash and crack in john with the rockyou.txt wordlist.

john as_rep_hash --wordlist=/usr/share/wordlists/rockyou.txt

Fantastic, we now have a valid set of domain credentials we can use. If you recall from the port scan we discovered port 5985, or WinRM, running, which requires a valid set of credentials to gain a remote session. Let’s use evil-winrm, a Linux tool to connect via WinRM.

evil-winrm -i htb.local -u svc-alfresco -p s3rvice

Nice, this worked and we could recover the user.txt flag.

Privilege Escalation

Bloodhound

Bloodhound is a fantastic tool for enumerating AD enviroments for all the privilege escalation vectors once initial access has been gained.

You first need a Ingestor/Collection binary/script to run on the AD enviroment, which is called SharpHound.exe. SharpHound will generate a zip file containing the results from the enumeration. We will then copy this zip over to our Kali machine to analyze with the BloodHound binary, which will provide us with a nice GUI interface.

Transferring SharpHound.exe from kali

I set up a HTTP server on my Kali box hosting SharpHound, and downloaded it using the PowerShell wget alias in the WinRM.

Nice, it’s now on our box as sh.exe. Let’s execute it.

Execution of Sharphound

.\sh.exe -c all

This is executing SharpHound with the switch -c all, to use all collection methods.

We can see it’s the output 20230804074726_BloodHound.zip being our results.

Sharphound results zip -> Kali

To do this, I’ve just setup a SMB server on my Kali machine, with smbserver.py to recieve files.

We now have the findings zip file back on the kali machine, let’s analyse these findings in the BloodHound GUI.

Analysing routes to Domain Admin

First of all lets search for our svc-alfresco user and mark this is as ‘owned’.

Okay, now have a look at the group membership of svc-alfresco.

So… svc-alfresco is in the Service Accounts group, which is in the Privileged IT Accounts group, which is in the Account Operators group! This Account Operators group is quite powerful.

Let’s search for routes from Account Operators -> Domain Admins.

Interesting. It looks like the Account Operators group, which we’re apart of, has GenericAll permissions over Exchange Windows Permissions. Exchange Windows Permissions, in turn, has WriteDACL permissions over the the whole domain!

• GenericAll permissions means we have full rights to this object. This means we can create a user and add it to this group.

• WriteDACL - permissions that allow us to modify the object’s ACEs and give us full control over the object. In this box, Exchange Windows Permissions has WriteDACL over the whole domain, meaning we can perform a DCSync attack.

Performing Privilege Escalation.

Using what we’ve found let’s demonstrate this attack. I’ll first create a new user cyben and add him to the Exchange Windows Permissions group which has WriteDACL permissions. We can add him to the Exchange Windows Permissions group, because we have GenericAllpermissions over it!

Great. Now we can use PowerView’s Add-ObjectACL function to give the cyben user DCSync rights.

Having DCSync rights gives you permission to replicate the whole NTDS.dit database. Impacket’s secretsdump.py will allow us to abuse this and dump it.

secretsdump.py htb.local/cyben:'password123!'@10.10.10.161

Amazing! We now have captured hashes for all users on the domain. Instead of cracking the Administrator hash, let’s just use a Pass-The-Hash attack to authenticate with it!

Great! We have logged on as the Administrator and can recover the root.txt flag - finishing the challenge.