Kerberoasting: How It Works and How to Defend

Kerberoasting is not a Kerberos flaw you can patch away. It is a password and privilege failure exposed through normal ticket behavior.

Any authenticated domain user can request service tickets for accounts with service principal names. That is expected. The danger appears when the ticket protects a service account with a guessable password, useful rights, and access to important systems. The attacker can take part of the ticket offline and test password guesses without generating another domain controller event.

Defending the domain means finding that intersection before an intruder does. Count the accounts. Check the encryption and key state. Rank privilege and reach. Replace human managed secrets where the application permits. Then detect request patterns that do not match normal service use.

What is Kerberoasting?

Kerberoasting is a credential access technique that requests a Kerberos service ticket for an account tied to a service principal name, then tests guesses against ticket material offline. MITRE ATT&CK tracks it as T1558.003 under Steal or Forge Kerberos Tickets. A valid domain account is enough to request the ticket. Administrative privilege is not required for that request.

The service principal name, usually shortened to SPN, tells Kerberos which account represents a service instance. Services need this mapping so clients can authenticate. Older applications often run under ordinary domain user accounts with SPNs attached. Those accounts may have passwords set by a person, no automatic rotation, and rights accumulated over years. That combination creates the target.

A successful crack gives the attacker the service account password. What happens next depends on the account. A narrow identity for one application may offer little. A service account that is a local administrator across 200 servers or belongs to a powerful directory group can become a direct lateral movement path.

How does Kerberoasting work?

The actor first gains any identity that can authenticate to the domain. They query directory information for user accounts with SPNs, then request service tickets for selected targets. The domain controller issues the ticket because the request resembles ordinary access to a registered service.

Part of that ticket is protected with key material derived from the service account secret. The actor exports the ticket data and performs password guesses on infrastructure they control. The domain controller does not see those guesses. It sees the original service ticket request.

If a guess succeeds, the actor has a valid service account credential. They may authenticate to systems the account can reach, inspect its group membership, search for stored secrets, or use its privileges to obtain more control. The ticket request was quiet. The account design decides the blast radius.

Which accounts create real Kerberoasting risk?

Start with four conditions. The account has an SPN. Its secret can be guessed within a useful period. Its rights matter. Its allowed path reaches something valuable. Do not flatten those conditions into a list where every SPN becomes the same severity.

Password age is a warning, not proof. A 12 year old randomly generated 40 character secret may resist practical guessing. A password changed yesterday can still be a company name plus a season and year. Since defenders should not store clear text passwords for inspection, use account type, rotation method, known policy, creation history, and controlled password audits to estimate crackability.

Privilege changes urgency. Check directory groups, delegated rights, local administrator reach, service logon scope, share permissions, database roles, scheduled tasks, and access to secrets. The least privilege guide explains how to reduce that capability without breaking the workload.

Reach completes the path. A service account may hold modest directory rights but still run on a server where powerful administrators sign in. It may access a backup system, deployment share, database, or management API. Endpoint and identity context should meet before the team sets priority.

Does AES stop Kerberoasting?

AES makes ticket password guessing more expensive than RC4, and moving away from RC4 is important. It does not turn a weak password into a strong one. MITRE notes that Kerberoasting can target ticket material protected with different algorithms. RC4 is the urgent legacy case because it is cheaper to test and often signals an old account or compatibility dependency.

Microsoft's RC4 detection and remediation guidance maps ticket encryption type 0x17 to RC4 HMAC and identifies events 4768 and 4769 as the main Kerberos audit records. It also warns that the processed encryption field and the raw directory attribute do not always show the same thing. Read the issued ticket, advertised types, available keys, and account configuration together.

Strong account design is still the control. Use managed identities with long random secrets, reduce privilege, restrict where they can authenticate, and remove SPNs that no longer represent a live service. Encryption is one layer. It should not carry the whole defense.

What changed for Kerberoasting defense in 2026?

Microsoft changed how patched domain controllers assume support for RC4 when an account lacks an explicit encryption configuration. The official KB 5073381 rollout guidance says updates from January 13, 2026 introduced audit controls and nine KDC service events numbered 201 through 209. Updates from April 14 changed the default assumed types to AES only, with a temporary rollback path. July 2026 updates removed that rollback control and enabled enforcement.

This is a meaningful defensive shift, but it is not permission to flip a registry value blindly. Microsoft says the absence of audit events does not prove every non Windows client will work after enforcement. Linux services, appliances, old keytabs, and applications may need direct interoperability tests.

The practical consequence is immediate. RC4 dependency is now both a security exposure and a service continuity issue. Teams that ignored service account ownership may discover it through failed authentication. Inventory and test before a maintenance window turns the lesson into an outage.

How do you inventory Kerberoasting exposure?

Begin with user accounts that have an SPN. The following read only command uses the Active Directory PowerShell module syntax. Run it from an approved administrative workstation with directory read access. Review disabled accounts too, because an old SPN may show cleanup debt.

Add four operating fields outside the directory query: application owner, systems that use the account, approved authentication sources, and migration constraint. Directory attributes cannot tell you whether a finance close job depends on the identity. That answer needs the service owner and observed use.

Rank the result. Suppose 60 user backed service accounts have SPNs. Twenty have passwords older than two years. Eight of those have broad local administrator reach, and three can touch tier zero systems. The immediate queue is three, not 60. Fix those first, then work outward. Simple intersection math turns an inventory into a plan.

How do you detect Kerberoasting?

Start with event 4769 on domain controllers. Look for RC4 ticket encryption, one identity requesting many service tickets in a short period, targets the identity has never accessed, and requests from an unusual workstation. MITRE's current detection strategy combines those ticket patterns with suspicious process behavior. That context matters because legitimate inventory, monitoring, and application activity can also generate many tickets.

Microsoft publishes defensive scripts with its RC4 guidance. After retrieving them from the linked Microsoft repository and reviewing the code, this documented filter shows RC4 use found in Kerberos events:

Treat the output as a dependency and detection input, not automatic proof of attack. An old appliance may request RC4 every hour from the same source. That is a remediation item. One employee identity requesting tickets for 30 unrelated services in two minutes is a different problem. Baseline service use, then alert on new combinations.

The 2025 Microsoft Digital Defense Report says 97 percent of identity attacks observed in its cited period were password spray or brute force attacks, and Microsoft analyzed 38 million identity risk detections on an average day. Kerberoasting is a distinct technique, but the operating lesson matches. Weak and reused secrets remain profitable at enormous scale.

How do you prevent Kerberoasting from succeeding?

Replace ordinary user backed service accounts with group managed service accounts where the application supports them. Windows manages the password and its rotation. Windows Server 2025 also introduced delegated managed service accounts to help migrate compatible legacy services while disabling the original account password.

For accounts that cannot migrate yet, generate a long random secret, store it in an approved vault, rotate it on a tested schedule, and make ownership explicit. Resetting an old account password also creates modern Kerberos keys where supported. Test every consuming service before and after rotation.

Remove RC4 dependencies and require AES after compatibility proof. Clean unused SPNs. Strip powerful group membership and local rights. Deny interactive logon where the service does not need it. Restrict authentication to named hosts. These actions reduce both the chance of a crack and the value of a stolen password.

Keep privileged users off service hosts. A narrow service account on a server where domain administrators sign in still sits on a dangerous path. The Active Directory hardening guide covers administrative tiers, domain controller protection, protocol changes, and recovery.

What is the safe Kerberoasting remediation sequence?

1. Inventory: find user backed SPNs, account owners, password age, encryption state, privilege, approved sources, and reachable targets.
2. Observe: patch domain controllers, collect Kerberos events and the 2026 KDC service audit events, and identify RC4 clients and services.
3. Reduce consequence: remove broad rights, block interactive use, and restrict source and target paths before changing authentication.
4. Migrate: move compatible workloads to managed service accounts. Rotate remaining secrets and create AES keys.
5. Enforce and verify: test each application, remove RC4 fallback, confirm issued ticket types, and alert on unexpected requests.

Preserve a rollback for the application, not a permanent domain exception. If one legacy service cannot accept AES, isolate it, document the explicit account scope, set an expiry, and fund replacement. Broad RC4 fallback restores risk for unrelated services.

Which Kerberoasting metrics should leaders track?

Track user backed accounts with SPNs, managed account coverage, accounts issuing or receiving RC4 tickets, password age, accounts without AES keys, privileged service accounts, unowned SPNs, approved source violations, unusual 4769 request bursts, and exceptions past expiry. Show the intersection, not only the totals.

A useful executive measure is the count of crackable paths to important systems. If RC4 accounts fall from 40 to five but all five remain powerful, the program is not nearly finished. If the last five are isolated, monitored, owned, and scheduled for replacement, the remaining risk is at least controlled.

Frequently asked questions

Can any domain user perform Kerberoasting?

Any authenticated principal can normally request a service ticket for a registered SPN. Success still requires a service account secret that can be guessed and useful access after the guess.

Does disabling RC4 eliminate Kerberoasting?

No. It raises the cost of password guessing and removes the weakest common ticket type. Weak service account passwords, broad privilege, and unrestricted authentication still need repair.

Is every event 4769 suspicious?

Event 4769 is not suspicious by itself. Service ticket requests are normal. Look for unusual volume, targets, sources, encryption types, and timing, then correlate with account privilege and endpoint activity.

What should replace a traditional service account?

Prefer a group managed service account or delegated managed service account when the workload supports it. For other applications, use a long random vaulted secret, narrow rights, restricted logon, ownership, and tested rotation.

The executive takeaway

Ask for the ten user backed SPN accounts with the greatest privilege and reach. Move compatible services to managed accounts, rotate the remaining secrets, remove RC4 after testing, and alert on new ticket relationships. Deep endpoint context with AI driven analysis can help show where a service identity is present and what it can reach. The first responsibility is simpler. Stop letting old application passwords quietly become domain movement credentials.