A domain controller hums in a way most people never hear. Not loud. Not dramatic. Just a steady administrative breath in the background of a network that believes it is orderly.
Somewhere inside that hum, a service ticket is issued. It looks harmless. It behaves like trust encoded into structure. It carries encryption that was supposed to solve this class of problem years ago.
The uncomfortable part is simple.
Kerberoasting still works because the system is still willing to give you what you need to break it.
And once you see that flow, you stop thinking about encryption as protection and start seeing it as packaging.
There is a lean-in moment here. Most environments are not compromised through exotic failures. They are compromised through expected behavior doing exactly what it was designed to do.
The ticket is not the weakness. The assumption around it is.
Kerberoasting targets Active Directory’s Kerberos service ticket mechanism, specifically service tickets tied to Service Principal Names. In normal operation, a client requests access to a service. The Key Distribution Center responds by issuing a Ticket Granting Service response that is encrypted using the service account’s secret.
That secret is derived from the service account’s password.
Not a hardware root key. Not a per-session ephemeral secret. A password, transformed into a cryptographic key.
The attacker does not need to break Kerberos online. The protocol will happily issue the ticket as long as the request is valid and pre-authentication is satisfied. The interesting part happens after the ticket is captured.
It is taken offline.
At that point, encryption stops being a boundary and becomes a puzzle. The attacker is no longer interacting with the domain. They are interacting with math.
If the service account password is weak enough, predictable enough, or reused enough, the puzzle collapses.
That collapse is Kerberoasting.
AES did not remove the problem. It upgraded the surface.
A common misunderstanding inside modern Active Directory environments is that AES support has fundamentally changed the risk model.
It has not.
Kerberos supports multiple encryption types for service tickets, primarily AES128, AES256, and older RC4-HMAC. Many administrators believe that forcing AES removes practical attackability. This belief is usually formed in environments where security posture is evaluated through configuration flags rather than entropy reality.
AES is not the vulnerability.
The password behind the key is.
When a service ticket is encrypted with AES, it is still derived from a human-managed secret. The derivation process is deterministic. If an attacker can guess the password, they can reproduce the key and validate the ticket decryption attempt offline.
This is where trust becomes the real attack surface.
The system trusts that service account passwords are strong enough to make offline guessing infeasible. In practice, service accounts are often:
- Created early and never rotated
- Assigned complex-looking but predictable patterns
- Shared across systems for convenience
- Embedded in legacy dependencies that resist change
AES protects the structure of the encryption. It does not protect the entropy of human decisions feeding it.
That distinction is where Kerberoasting lives.
The illusion of modern cryptography in legacy identity systems
Active Directory is not a modern cryptographic system. It is a layered historical artifact. Each layer introduced improvements without removing the assumptions of the previous one.
Kerberos itself was designed in an era where network trust boundaries were smaller and identity sprawl was not industrial in scale. Service accounts were not meant to accumulate like sediment across years of deployments.
In modern enterprise environments, SPNs proliferate quietly. Every database service, web application, scheduled task, and middleware bridge becomes a potential ticket target.
The Key Distribution Center will issue service tickets to any authenticated principal requesting them. It does not evaluate intent. It evaluates structure.
This is where attackers operate: not by bypassing authentication, but by staying inside it.
What actually gets extracted
From an attacker’s perspective, Kerberoasting is not a single exploit. It is a sequence of predictable behaviors in the identity system.
A service ticket is requested for a known SPN. The domain responds with a TGS ticket encrypted using the service account’s long-term key. That ticket can be extracted from memory or network traffic depending on the environment.
Once offline, the ticket becomes a target for password guessing against the service account.
No further interaction with the domain is required.
This is important because it shifts detection difficulty. Traditional monitoring focuses on authentication anomalies, lateral movement, privilege escalation patterns. Kerberoasting, in isolation, often looks like normal service discovery behavior.
The system is doing what it is supposed to do. That is the problem.
Why AES makes defenders overconfident
AES adoption in Kerberos environments created a psychological shift more than a cryptographic one.
Security teams see AES256 and assume meaningful resistance to offline cracking. That assumption is partially correct in a mathematical sense, but incomplete in operational reality.
AES does not get brute forced directly in this context. The attack target is the password-derived keyspace, not the cipher itself.
So the real question is not “Can AES be broken?”
It is “How predictable are the service account passwords feeding AES?”
This is where most environments quietly fail. Password policies that are sufficient for user accounts are often insufficient for long-lived service identities. Complexity requirements encourage patterns. Rotation is avoided due to downtime risk. Documentation is inconsistent.
Over time, service accounts become static cryptographic anchors tied to business continuity. And static secrets are always a liability in systems that assume eventual compromise resistance.
The long tail of service account entropy decay
There is a slow degradation that happens in identity systems. It is not visible in dashboards. It does not trigger alerts.
Service accounts accumulate age.
Age reduces entropy in practice, even if the password technically meets complexity requirements. Humans stop rotating it. Teams forget why it was set a certain way. Migration projects duplicate it. Legacy integrations depend on it.
What starts as a strong credential becomes an artifact preserved for stability rather than security.
Kerberoasting exploits that preservation instinct.
The attacker does not need the newest accounts. They look for the oldest ones. The ones nobody wants to touch because something might break.
A minimal view of the attack flow
It is useful to compress the conceptual model without turning it into a checklist.
A client authenticates into the domain. It requests access to a service identified by an SPN. The domain issues a service ticket encrypted with the service account’s secret. That ticket is extracted and taken offline. Password candidates are tested until one reproduces the correct decryption outcome.
The protocol never signals failure in a way that exposes the guess. It only validates success when the correct key aligns.
That asymmetry is what makes offline attacks viable.
There is no rate limit in the traditional sense. No lockout policy applies once the data is outside the system boundary.
Where detection tends to misfire
Security tooling is generally optimized for movement inside the network, not analysis after cryptographic material leaves it.
Kerberoasting produces signals that are subtle:
- Increased TGS requests for uncommon SPNs
- Service ticket requests outside normal service usage patterns
- Slight clustering of authentication events that resemble enumeration
Individually, none of these are decisive. Together, they are still ambiguous in many environments because service communication patterns are inherently noisy.
Hybrid environments complicate this further. Cloud identity bridges and synchronized directories create multiple valid entry points for the same identity material. Visibility fragments.
By the time an offline cracking attempt begins, the system has already stopped being part of the interaction loop.
The real failure is architectural, not cryptographic
It is easy to describe Kerberoasting as a password problem. That is partially correct but incomplete.
The deeper issue is that long-term secrets are being used in a system that assumes short-lived trust exchange.
Kerberos was designed for ticketing, not for permanent credential anchoring. Service accounts violate that assumption by design necessity.
The mismatch creates exploitable structure.
AES only changes the shape of the ciphertext. It does not change the lifetime of the secret behind it.
Modern attacker reality
In contemporary environments, Kerberoasting is rarely a standalone technique. It is part of a broader identity exploitation chain.
Attackers often combine:
- Enumeration of SPNs across domain scope
- Offline cracking using GPU acceleration
- Credential reuse across services
- Escalation through service misconfigurations
The important shift is computational. What once required patience now runs at scale. Password space exploration is no longer constrained by single-machine limits.
This compresses time. And compressed time reduces detection windows.
Defenders often still think in terms of intrusion duration measured in days. In reality, meaningful compromise can occur in hours or less depending on password quality.
Why “AES-only” thinking fails
Some environments attempt to enforce AES-only Kerberos encryption as a mitigation strategy. This reduces exposure to legacy RC4 weaknesses, but it does not address the core issue.
The service ticket remains decryptable if the underlying password is weak.
The cryptographic strength of AES is irrelevant if the key is guessable.
This is the subtle inversion that gets missed: modern encryption does not compensate for weak identity hygiene. It only ensures that when compromise happens, it happens cleanly.
Mitigation that actually matters
Effective reduction of Kerberoasting risk does not come from a single control. It comes from removing structural advantages.
Service accounts need entropy that does not resemble human choice. Where possible, group Managed Service Accounts remove password handling entirely from administrators. Where not possible, rotation policies must be enforced in a way that acknowledges operational reality, not just compliance expectations.
SPN sprawl should be treated as attack surface growth. Every additional service identity is another candidate for offline analysis.
Monitoring should focus less on raw ticket issuance and more on abnormal concentration patterns tied to service principals that historically see low traffic.
There is also a quieter requirement: accepting that some level of offline attackability is inherent in the model. The goal is not elimination. It is cost elevation.
Closing edge
Kerberos still behaves as designed. AES still does what it was built to do. Nothing is broken in the obvious sense.
The system is simply more honest than its operators assume.
It issues trust on request. It encrypts that trust with strong primitives. Then it ties those primitives to secrets that age inside human organizational memory.
Kerberoasting exists in that gap. Not as a sophisticated bypass, but as a consequence of believing that modern encryption compensates for historical identity design.
The network keeps issuing tickets. Quietly. Predictably.
And somewhere outside the boundary, someone is still testing passwords against mathematics that never ask for permission.
Want to go deeper? Check out my latest guides for in-depth and actionable methods on the latest exploits of 2026:
EDR Ghosting: Syscalls, Sleep Obfuscation, and Memory Unhooking in 2026
Living Off the LOLBins: Bypassing Defender for Endpoint Without Custom Malware
