Kerberos Abuse: The Attacks Your Kerberos Infrastructure Enables

Kerberos is the backbone of Active Directory authentication. It was designed as a secure protocol, and in theory, it is. But in practice, the way organizations configure and manage their Kerberos infrastructure creates attack opportunities that I exploit on nearly every engagement. The issue is never Kerberos itself -- it is the assumptions administrators make about how it works and the shortcuts they take when deploying services.

Understanding these attack paths from a defensive perspective is essential. If you know what I look for when I target your Kerberos infrastructure, you can close those doors before I arrive.

Kerberoasting: The Most Reliable AD Attack

Kerberoasting remains my single most successful attack technique. Any authenticated domain user can request a Kerberos service ticket (TGS) for any account that has a Service Principal Name (SPN) registered. The ticket is encrypted with the service account's password hash. I take that ticket offline and crack it with hashcat or John the Ripper. No network traffic, no alerts, no interaction with the target service.

The reason this works so consistently is that service accounts almost always have weak, static passwords. In my experience, over 80% of service account passwords I extract through Kerberoasting crack within an hour. Many crack in seconds. The password "SqlService2020!" is not a caricature -- it is a real password I have cracked on multiple engagements.

What makes Kerberoasting devastating is not just the password recovery. It is that service accounts are almost always over-privileged. They have Domain Admin rights because someone decided the application "needed" elevated access, or because the vendor documentation said to grant full permissions. Once I crack one service account password, I often have the keys to the entire domain.

Defending Against Kerberoasting

The definitive fix for Kerberoasting is Group Managed Service Accounts (gMSAs). A gMSA has a 240-character randomly generated password that rotates automatically every 30 days. You cannot Kerberoast a gMSA because the password is computationally impossible to crack. Every service that supports gMSAs should be migrated immediately.

For services that cannot use gMSAs, enforce passwords of at least 25 characters with high entropy. Do not use human-readable passwords for service accounts. Generate random strings and store them in a privileged access management vault. Rotate them at least quarterly.

On the detection side, monitor Event ID 4769 on your domain controllers. Look specifically for ticket requests using RC4 encryption (encryption type 0x17). Modern Windows environments should be using AES encryption. A spike in RC4 ticket requests, especially from a single source, is a strong indicator of Kerberoasting activity. Configure your SIEM to alert on this pattern.

AS-REP Roasting: Kerberoasting's Cousin

AS-REP Roasting targets accounts that have Kerberos pre-authentication disabled. When pre-authentication is disabled, I can request an AS-REP for the account without providing any credentials, and the response contains data encrypted with the user's password hash. I crack it offline just like Kerberoasting.

This setting is sometimes disabled for compatibility with legacy applications or older clients. The fix is straightforward: audit all accounts in your domain for the "Do not require Kerberos preauthentication" flag and remove it wherever possible. Run this PowerShell query regularly: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True}. Any account on that list is vulnerable.

Delegation Attacks: Unconstrained, Constrained, and RBCD

Kerberos delegation is one of the most misunderstood and most dangerous features in Active Directory. It allows a service to impersonate a user when accessing other services. There are three types, and all of them create attack opportunities when misconfigured.

Unconstrained delegation is the most dangerous. When a user authenticates to a server with unconstrained delegation, their full Ticket Granting Ticket (TGT) is stored in memory on that server. If I compromise that server, I can extract every TGT and impersonate every user who authenticated to it -- including Domain Admins. I can also use the PrinterBug to coerce a domain controller to authenticate to my compromised server, capturing the DC's machine account TGT and performing a DCSync attack.

Constrained delegation limits which services can be accessed, but it still has abuse potential. If I compromise an account with constrained delegation configured, I can use S4U2Self and S4U2Proxy to obtain service tickets for the allowed target services as any user, including Domain Admins.

Resource-Based Constrained Delegation (RBCD) is the newest form and the one I abuse most frequently during NTLM relay attacks. If I can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer object, I can configure it to trust a machine account I control and impersonate any user to that computer.

Hardening Kerberos Delegation

Start by auditing all delegation configurations in your domain. Use BloodHound or the following PowerShell commands to identify accounts with delegation enabled. For unconstrained delegation: Get-ADComputer -Filter {TrustedForDelegation -eq $True}. For constrained delegation: Get-ADComputer -Filter {msDS-AllowedToDelegateTo -like '*'}. Review each result and determine whether delegation is genuinely required.

For accounts that truly need delegation, use constrained delegation with protocol transition disabled whenever possible. Add all privileged accounts to the Protected Users security group, which prevents their TGTs from being cached on delegated servers. Mark all sensitive accounts with the "Account is sensitive and cannot be delegated" flag.

Monitor Event ID 4768 for TGT requests and Event ID 4769 for service ticket requests associated with delegation. Watch for S4U2Self and S4U2Proxy operations from unexpected sources. These events are logged on domain controllers and should be forwarded to your SIEM for correlation.

Golden and Silver Tickets: Post-Compromise Persistence

Once an attacker has Domain Admin access and extracts the KRBTGT hash via DCSync, they can forge Golden Tickets -- TGTs that are valid for any user, including nonexistent accounts, with any group membership. A Golden Ticket is valid for the lifetime of the KRBTGT password, which in many environments has never been changed.

The defense is to rotate the KRBTGT password twice in succession, which invalidates all existing TGTs. This should be part of your incident response plan and should be done proactively on a regular schedule. Microsoft recommends rotating it every 180 days. Use the official KRBTGT reset script and test in a lab environment first.

Run PingCastle or Purple Knight regularly to assess your Kerberos configuration. These tools identify accounts with SPNs that are vulnerable to Kerberoasting, delegation misconfigurations, and stale KRBTGT passwords. Treat their findings as your Kerberos hardening checklist and work through them systematically.