Kerberoasting in 2026: Why This Attack Still Works on Your AD
Kerberoasting persists because most environments still have SPN-mapped service accounts with RC4 enabled and passwords that have not rotated in years. Here is what continuous ISPM monitoring catches and what good looks like.
Kerberoasting still works because the preconditions are still everywhere
The attack has not changed much since it was named. Any authenticated domain user can request a Kerberos service ticket for any account with a registered SPN. If that account's password is weak and the ticket is encrypted with RC4-HMAC (etype 0x17), an offline brute-force takes minutes on commodity hardware. The reason this keeps showing up in red-team reports is simple: the average service account in a mid-sized Active Directory environment is several years old, has a manually set password that has not rotated since a junior admin left, and still advertises RC4 support because no one ever forced AES.
A continuous ISPM check targets exactly that combination. The signal is not subtle. Look for SPN-mapped accounts where msDS-SupportedEncryptionTypes does not exclude RC4, where the pwdLastSet attribute is more than 365 days old, and where the account is not a group Managed Service Account. Any one of those conditions is a finding. All three together is a high-severity item that belongs in a daily digest, not a quarterly audit.
What good looks like is straightforward to state, harder to actually deploy at scale:
- AES-only enforcement. Set msDS-SupportedEncryptionTypes to 24 (AES128 + AES256) on every service account. Remove RC4 from the negotiation entirely. Windows Server 2022 domain functional level makes this easier to enforce via policy.
- Rotation cadence under 90 days. For accounts that cannot be converted to gMSAs immediately, a 90-day maximum password age is a floor, not a ceiling. Automate it or it will not happen.
- gMSA migration as the exit ramp. Group Managed Service Accounts eliminate the human-rotation problem completely. The KDC handles the 30-day key rotation. If a service supports gMSAs and you have not migrated it, that is technical debt with a known exploit attached.
Kerberoasting detection at the network layer (watching for anomalous TGS-REQ volume, RC4 ticket requests from non-service principals) adds depth, but it is reactive. Eliminating the preconditions through ISPM-driven inventory and remediation is the posture that actually shrinks the attack surface. The technique persists because operators treat it as a detection problem. It is a configuration problem first.
Keep reading in Threat Intel
