Attacktive Directory

This will be my first of many Active Directory themed blogs focused around exploitation. I have recently been exposed to a lot of Active Directory exploitation with a number of online courses, my own local and Azure AD attack labs and CTF style challenges. I found this challenge to be quite easy as I already have some experience with Active Directory exploitation and security, however this was great practice and was really so much fun!

This is the first time I'm trying to explain concepts relating to Active Directory and Kerberos in a blog post, so there may be some inaccuracies with some of the concepts I am explaining. I have tried my best to do as much research as possible relating to this challenge, but if you spot any inaccuracies, comment them below please!

A medium level Active Directory challenge

Approx. 30 mins to complete

Enumeration

We will kick of this challenge with an Nmap scan.

nmap -sC -sV -O 10.10.150.81

1. -sC to scan using default scripts.

2. -sV to probe open ports for service and version information

3. -O to enable OS detection

From our scan, we see that port 88 is open with Kerberos running which gives a strong indication that this is a domain controller, we also have port 53 open which is used for DNS. We also gather from the Nmap scan that the NetBIOS_Domain_Name is THM-AD and that the domain name is SpookySec.local.

Enumerating users via Kerberos

Now that we know what ports are open on the target and we know that this is a domain controller. We want to enumerate users in Active directory and to do so we need to run a tool called Kerbrute to enumerate valid users in the domain.

Kerbrute abuses the way that Kerberos responds to queries for invalid users. When Kerbrute sends a TGT request with no preauthentication for an invalid user, Kerberos will respond with an error message " KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN". When Kerbrute sends a requests for a TGT with a valid username, Kerberos will respond with either a TGT in a AS-REP response or a KRB5KDC_ERR_PREAUTH_REQUIRED response. Kerbrute will pick up on these responses to identify valid domain usernames.

To carry out this attack, we will pass the userenum command to enumerate usernames and will also supply our username list "userlist.txt".

./kerbrute userenum --dc 10.10.150.81 -d spookysec.local userlist.txt  

We can see below that two users that standout are the svc-admin which is an admin service account and also the backup account. We would want to target the backup account and disrupt and backup processes or services running or even gain access to a backup server to prevent an organisation from recovering from backups. The svc-admin account could be a service account that is possibly in a high privilege security group such as domain admins or could be used to gain access to sensitive servers and assets.

Abusing Kerberos

There is an attack called ASREPRoasting, where an account has the privilege “Does not require Pre-Authentication” set. This means that the account does not need to provide valid identification before requesting a Kerberos ticket with that account. We can use a tool called GetNPUsers.py to query any accounts that are ASREProastable from the KDC. We just need a list of usernames which we have already enumerated from Kerbrute. Instead of passing all of the users to the tool, we will only pass svc-admin and the backup account as the most interesting accounts we want to attack.

We see that the svc-admin account is ASREProastable and the GetNPUsers.py script dumps the TGT ticket for the svc-admin account. With a TGT ticket we can use this to requests tickets for resources in the domain without providing valid identity to the KDC. We could use the TGT to request access tokens from the TGS for specific resources in the domain.

/usr/bin/impacket-GetNPUsers spookysec.local/backup -no-pass -dc-ip 10.10.150.81
/usr/bin/impacket-GetNPUsers spookysec.local/svc-admin -no-pass -dc-ip 10.10.150.81

What we can do is crack the hash for this ticket and get the password for the svc-admin account. The TGT which is sent to the client is encrypted using the clients password as the encryption key. If we can decrypt the token, we have the password for this svc-admin account.

Crack the TGT hash

We identify this hash as an AS-REP hash (Kerberos 5, etype 23, AS-REP) which has a mode of 18200 as found in the hashcat documentation.

hashcat -m 18200 svc-admin-tgt-hash.txt /usr/share/wordlists/rockyou.txt -O

Running the above command, we are able to crack the hash as management2005 (svc-admin:management2005).

SMB Enumeration

Since we have SMB open, we can try to see what shares are available for us to connect to as the svc-admin user. We see the backup share is writeable so we connect and download the backup_credentialss.txt file.

smbclient -U 'svc-admin' -L \\\\10.10.150.81\\

The contents of the file looks to be base64 encoded so we can pipe the contents to base64 to decode it.

cat backup_credentials.txt | base64 -d 

The contents of the decoded file are the back up account credentials: backup@spookysec.local:backup2517860

Domain Privilege Escalation

We can use a tool called secretsdump.py which will allow us to dump all of the password hashes that this backup account can offer us. We use the backup accounts credentials for authentication against the domain controller. We can see below we have the NTLM hash of the administrator account which is an account of interest to us. This is most likely a local administrator on the machine.

/usr/bin/impacket-secretsdump spookysec.local/backup:backup2517860@10.10.150.81

We can use a tool called Evil-WinRM (Windows Remote Management) to perform an attack called a Pass-the-hash attack which will allow us to authenticate as this user without providing a password and just use the hash. This tool utilises Windows Remote Management which is Microsoft's implementation of WS-Management , a SOAP based protocol for device and server management.

/evil-winrm.rb -i 10.10.150.81 -u administrator -H 0e0363213e37b94221497260b0bcb4fc

Congratulations, we now have a shell as the administrator on the domain controller and effectively have full control over the Active Directory domain and domain controller. From here, we would potentially carry out further attacks for persistence such as crafting golden-tickets with a krbtgt hash which I have covered in another blog post here.

I hope I have explained my method clearly and provided justified reasoning for the actions I took. I have really enjoyed learning about Active Directory from an infrastructure and defence point of view and then attacking it from a red team/ offensive security perspective.