Kerberoasting Attack

How Kerberoasting Works

  • In Active Directory (AD), service accounts are used to run specific services or applications, such as web servers or database systems.

  • These services are associated with a Service Principal Name (SPN), which uniquely identifies them.

  • Any authenticated AD user can request a Ticket Granting Service (TGS) ticket for any SPN in the domain.

  • The TGS is encrypted using the service account's NTLM hash (derived from its password).

  • Now the attacker requests a TGS for a service with a known SPN.

  • The TGS is then extracted from memory using tools like Rubeus or Impacket.

  • The attacker uses tools like Hashcat or John the Ripper to brute force or dictionary attack the TGS offline.

  • If successful, this reveals the service account's plaintext password.

How to do it?

1. Identify Service Principal Names (SPNs)

With valid admin or standard user credentials, you can use GetUserSPNs.py (from Impacket) to enumerate SPNs and request TGS tickets for those services.

GetUserSPNs.py -request -dc-ip <DC_IP> <domain\user>
  • -request: Requests TGS tickets for the identified SPNs.

  • <DC_IP>: IP address of the Domain Controller.

  • <domain\user>: The username and domain to authenticate with.

  • When you request TGS tickets, the tool will dump the tickets in a format that can be used for offline cracking.

  • The extracted TGS hashes are encrypted with the NTLM hash of the associated service account's password.

3. Crack the TGS Hash

  • Use Hashcat to brute-force the NTLM hash of the service account password offline.

  • The hash type for TGS tickets is 13100 in Hashcat.

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 pentest 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

Shout outs:

Last updated