What is Kerberoasting ?
The general concept of Kerberoasting is requesting service tickets (TGS) from the KDC (Kerberos Domain Controller) that are associated with service accounts to retrieve their hashes. Then, attempt to crack them offline with tools like Hashcat or John to recover the cleartext passwords to either escalate privileges vertically to become a local administrator or horizontally to access a set of different resources that can be used for pivoting within the network.
The service accounts can be linked to hosts like computers (CN=Computers) or domain users (CN=Users). Each service account can be mapped to a set of running services like MSSQL, Web, SharePoint, File shares, Exchange services, etc., within the domain known as Service Principal Names (SPNs).
*Service Principal Name maps the host/user service accounts to running services.
Kerberoasting can be an effective method for extracting service account credentials from Active Directory as a regular user without sending any packets to the target system. This attack is effective since people tend to create poor passwords. The reason why this attack is successful is that most service account passwords are the same length as the domain password minimum (often 10 or 12 characters long) meaning that even brute force cracking doesn’t likely take longer than the password maximum password age (expiration). Most service accounts don’t have passwords set to expire, so it’s likely the same password will be in effect for months if not years. Furthermore, most service accounts are not designed as per the principle of least privilege and are often members of Domain Admins providing full admin rights to Active Directory (even when the service account only needs to modify an attribute on certain object types or admin rights on specific servers).
Kerberos in a nutshell :
- When a user logs on to Active Directory, the user authenticates to the Domain Controller (DC) using the user’s password which of course the DC knows.
- The DC sends the user a Ticket Granting Ticket (TGT) Kerberos ticket. The TGT is presented to any DC to prove authentication for Kerberos service tickets.
- The user opens up Skype which causes the user’s workstation to lookup the Service Principal Name (SPN) for the user’s Exchange server.
- Once the SPN is identified, the computer communicates with a DC again and presents the user’s TGT as well as the SPN for the resource to which the user needs to communicate.
- The DC replies with the Ticket Granting Service (TGS) Kerberos service ticket.
- The user’s workstation presents the TGS to the Exchange server for access.
- Skype connects successfully.
How to do it ?
Once you have admin/standard user access, look for the supported SPNs and get TGS ticket for the SPN using GetUserSPNs tool from Impacket.
GetUserSPNs.py -request -dc-ip <DC_IP> <domain\user>
Now once you have the TGS hash, all we need to do is to feed the hash to Hashcat tool to fetch Server’s user.
Hashcat -m 13100 <hash_file> <rockyou wordlist>
Important note: If any of the above test gives a negative result, keep an eye on your Wireshark traffic. Mostly setting up static DHCP or DNS or Gateway IP address solves such issues. This is a very small thing to underestimate which will affect the pentesting in a peculiar way.
Mitigations:
- If possible use group managed service accounts which have random, complex passwords (>100 characters) and are managed automatically by Active Directory.
- Ensure all service accounts (user accounts with Service Principal Names) have long, complex passwords greater than 25 characters, preferably 30 or more. This makes cracking these password far more difficult.
- Service Accounts with elevated AD permissions should be the focus on ensuring they have long, complex passwords.
- Ensure all Service Account passwords are changed regularly
