Kerberoasting
Any authenticated domain user can request a Kerberos service ticket for any service principal, and that ticket is encrypted with the service account's own password hash, offline and unrateable to test.
How it works
In Kerberos, any authenticated domain user can request a service ticket for any service that has a registered service principal name (SPN), because requesting a service ticket is the normal, expected step before using that service. The Key Distribution Center encrypts the ticket's service portion using a key derived from the target service account's own password, and hands that encrypted ticket to the requesting user without checking whether the requester has any actual right to use the service. That behavior is intentional and part of how Kerberos authorization is meant to work; the ticket is useless without the service's cooperation, unless someone tries to recover the password that encrypted it.
The historical weakness attackers exploit is that service accounts, unlike interactive user accounts, frequently have long, unrotated passwords set once at creation and never revisited, because rotating a service account's password without breaking the service it authenticates to is operationally painful. A ticket encrypted with a weak or old password can be tested against candidate passwords offline, away from any domain controller, with no failed-logon event generated anywhere in the process. CVE-2025-60704 (CheckSum), disclosed at Black Hat Europe in December 2025, is a related but distinct flaw: the Key Distribution Center skipped a cryptographic verification step in the S4U2self extension, letting an attacker forge an identity assertion rather than recover a password. Microsoft rated it Important (CVSS 7.5), not Critical.
Why it works
Kerberos assumes that a service account's key is hard enough to derive from an intercepted ticket that possession of the ticket alone is not a meaningful risk. The control assumption that fails is password strength and rotation discipline on accounts that were never designed to be checked the way human passwords are: no interactive login attempt to lock out, no MFA prompt to fail, and often no owner tracking whether the password has ever changed. The protocol behavior of issuing service tickets to any authenticated requester is correct and necessary; the exposure exists entirely in what happens to that ticket after issuance, on infrastructure the defender does not control.
How to detect it
- A single account requesting service tickets for an unusually large number of distinct SPNs in a short window, which is not something a normal user or application workflow does.
- Service ticket requests using a weaker encryption type (RC4) where AES is available and enforced elsewhere in the domain, since downgrade to RC4 makes offline testing meaningfully faster.
- Ticket requests for service accounts with no corresponding recent authentication from the service itself, suggesting the request came from something other than the service's own workflow.
Be honest about the limits: requesting a service ticket is normal Kerberos behavior performed constantly by legitimate clients connecting to legitimate services, and this has a real false-positive problem. A single request for a single SPN is indistinguishable from legitimate use, and even elevated request volume can occur from misconfigured applications or monitoring tools that enumerate SPNs for inventory purposes. This detection works as a volume and pattern signal across a baseline, not as a rule that fires cleanly on a single event.
How to stop it
- Use Group Managed Service Accounts (gMSA) wherever the application supports them, since their passwords are long, random, and rotated automatically by Active Directory rather than set once by an administrator.
- Set long, random passwords on any service account that cannot use gMSA, and rotate them on a defined schedule rather than leaving them unchanged since creation.
- Enforce AES encryption for Kerberos service tickets and disable RC4 where the environment allows it, removing the weaker encryption type from the pool an attacker can request.
- Monitor SPN-heavy accounts for unusual ticket request volume, understanding the false-positive rate going in, and correlate against expected service behavior rather than alerting on raw counts.
- Patch the S4U2self verification gap behind CVE-2025-60704 promptly, since it is a distinct forgery path rather than a password-strength issue and is not mitigated by strong service account passwords. See PAM for how privileged service accounts specifically should be governed.