Kerberoasting Demystified: Practical Attack, Detection, and Mitigation

Kerberoasting remains one of the most effective post-exploitation techniques in Active Directory (AD) environments. Because it leverages legitimate Kerberos protocol mechanics, traditional perimeter defenses often fail to flag it. If you are stepping up your internal penetration testing skills or building threat detection pipelines, understanding Kerberoasting at a functional level is essential.

In this post, we will walk through the core protocol mechanics, demonstrate how to enumerate target accounts, show how attackers request service tickets, and finish with practical detection strategies you can deploy today.

How Kerberos Service Principal Names Work

To understand Kerberoasting, you must understand Service Principal Names (SPNs). An SPN is a unique identifier that Kerberos uses to associate a service instance with a service account in Active Directory.

When a domain user wants to access a service—such as an MSSQL database or an IIS web application—the authentication process follows these basic steps:

1. Authentication Service (AS) Request: The user authenticates against the Key Distribution Center (KDC) on the Domain Controller and receives a Ticket Granting Ticket (TGT).

2. Ticket Granting Service (TGS) Request: The user presents the TGT to the KDC and requests a TGS ticket for a specific SPN (e.g., MSSQLSvc/sqlserver01.corp.local:1433).

3. TGS Response: If the user has a valid TGT, the KDC issues a TGS ticket encrypted with the password hash of the service account associated with that SPN.

4. Service Access: The user sends the TGS ticket to the target service to authenticate.

The key vulnerability lies in step 3: any authenticated domain user can request a TGS ticket for ANY account that has an SPN registered, regardless of permissions. Because the returned ticket is encrypted using the target account password hash, an attacker can extract that encrypted ticket from memory and attempt to crack it offline.

Enumerating SPNs in the Domain

Before requesting tickets, an attacker needs to find service accounts that have SPNs configured. Built-in tools and common security frameworks make this straightforward.

Using PowerShell, you can query Active Directory via LDAP filters without installing specialized tools. For example, using the ActiveDirectory PowerShell module:

Get-ADUser -Filter ‘ServicePrincipalName -ne $null’ -Properties ServicePrincipalName, MemberOf

Alternatively, using native Windows tools like setspn.exe:

setspn.exe -Q /

This command lists all registered SPNs across the domain. Look specifically for user accounts rather than computer accounts. Computer account passwords are managed automatically by Active Directory, 128 characters long, and rotated frequently. User service accounts, however, are often created by humans and frequently use weaker, static passwords.

Requesting and Exporting Tickets

Once suitable SPNs are identified, the next phase is requesting service tickets.

Using PowerShell and the System.IdentityModel library, an attacker can request a TGS ticket for a target SPN directly into memory:

Add-Type -AssemblyName System.IdentityModel New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList ‘MSSQLSvc/sqlserver01.corp.local:1433’

When this code executes, the Windows Kerberos API handles the TGS request and stores the resulting ticket in the current user session Kerberos ticket cache.

To extract the ticket for offline cracking, attackers commonly use tools like Rubeus or Mimikatz. Rubeus automates both enumeration and extraction in a single step:

Rubeus.exe kerberoast /stats /outfile:hashes.txt

This command requests TGS tickets for all non-machine accounts with SPNs, extracts the encrypted portion, and formats it for popular password crackers like Hashcat or John the Ripper.

Offline Cracking with Hashcat

Once you have exported the Kerberos ticket hashes (formatted as hash type 13100 for krb5tgs or 23800 for RC4-HMAC), you move offline. Because cracking occurs entirely on an attacker-controlled host, zero network traffic is generated during this phase.

A typical Hashcat command for RC4-HMAC Kerberoast hashes:

hashcat -m 13100 -a 0 hashes.txt wordlist.txt -r rules/best64.rule

If the service account password is present in the wordlist or discoverable via rule-based mutations, Hashcat will output the plaintext password. With that password, an attacker gains direct access to the service account, which often holds elevated rights across database servers, service infrastructure, or backup systems.

Detecting Kerberoasting Activity

Because requesting TGS tickets is standard domain behavior, detecting Kerberoasting requires looking for anomalous patterns rather than single events.

The primary log source for detecting Kerberoasting is Windows Event ID 4769 (A Kerberos service ticket was requested) on your Domain Controllers.

Look for these specific indicators:

1. High Volume of 4769 Events: A single account requesting dozens of TGS tickets in a short time frame indicates automated enumeration.

2. Encryption Type Downgrade: Modern Active Directory environments default to AES encryption (0x12 or 0x11). Attackers often explicitly request RC4-HMAC (0x17) encryption because RC4 hashes are significantly faster to crack offline. Filter for Event ID 4769 where Ticket Encryption Type is 0x17 and Service Name does not end with $.

3. Non-Standard Requestors: Flag accounts requesting tickets for service accounts they never normally interact with.

A sample XPath query for Event Viewer or SIEM filtering:

Event[System[EventID=4769]] and Event[EventData[Data[@Name=‘TicketEncryptionType’]=‘0x17’]] and Event[EventData[Data[@Name=‘TargetUserName’]!=‘*$’]]

Remediation and Defensive Controls

Defending against Kerberoasting requires structural changes to identity management:

1. Group Managed Service Accounts (gMSA): Replace standard user accounts used for services with gMSAs. Active Directory automatically manages 128-character complex passwords for gMSAs and rotates them every 30 days.

2. Long, Complex Passwords: For service accounts that cannot use gMSAs (e.g., third-party legacy appliances), enforce passwords of at least 25-30 characters.

3. Honey SPNs (Deception): Create a decoy user account with an enticing SPN (e.g., MSSQLSvc/finance-db.corp.local) and an intentionally weak password. Set up instant alerting for any Event ID 4769 generated against this SPN. Since no legitimate system should ever request a ticket for a decoy SPN, any hit is a high-confidence indicator of compromise.

Conclusion

Kerberoasting remains a staple of internal penetration testing because it targets standard protocol mechanics rather than software bugs. By understanding how SPNs map to service accounts, how ticket requests work, and how to spot ticket request anomalies, security teams can effectively harden Active Directory against one of its most persistent threats.

Photo by Brett Jordan on Unsplash.