Is Kerberoasting Still a Risk When AES-256 Kerberos Encryption Is Enabled?
Oct 21 2025
By: Elad Shamir • 4 min read
TL;DR Kerberoasting is fundamentally a weak password problem. Stronger encryption slows down cracking, but it doesn’t eliminate the risk. If the password is weak, AES won’t save you. There’s no new, groundbreaking tradecraft here.
Clients often ask us whether Kerberoastable user accounts (i.e., user accounts with a Service Principal Name [SPN]) remain at risk if only AES-256 encryption is enabled. In this short post, I want to put that question to rest.
Kerberoasting 101
Just kidding; not this time. There are probably more articles about Kerberoasting than any other topic in AD/Identity security, and the world doesn’t need another one. This post focuses on what’s changed and why it still matters.
I will briefly explain the fundamental idea: Kerberos service tickets have an encrypted part, encrypted with a key generated from the service account’s password. An attacker can perform an offline password attack against that encrypted part to try to crack the password. Whether the attacker is successful or not depends on the strength of the password and how fast the attacker can chew through passwords.
Kerberoastable accounts are specifically user accounts with an SPN assigned (an SPN is required because no SPN -> no service ticket), not computer accounts or managed service accounts (MSAs). The reason is simple: unlike computer accounts and MSAs, a mere mortal may set a user account password, which means the password is shorter, not random, and potentially crackable.
Encryption Types
Kerberos supports several encryption types: notably RC4, which has been the standard for many years, and AES-256, which is the current standard in up-to-date environments.
Cracking RC4 is computationally easier than cracking AES-256 by orders of magnitude. A modern GPU can chew through billions of RC4 keys per second, whereas it can only chew through thousands of AES-256 keys. Therefore, attackers obviously prefer working with RC4-encrypted tickets, which makes password attacks much more feasible.
Times Are Changing
Obtaining RC4-encrypted tickets is no longer as easy as it used to be. As of Windows Server 2019, the client can no longer influence the ticket encryption type (as opposed to the session encryption type). Instead, the domain controller chooses the strongest encryption type supported by the service account, which makes sense because the client doesn’t need to decrypt the ticket, and so it has no business requesting different encryption types.
RC4 used to be the default encryption type for user accounts, but that’s no longer the case. In up-to-date environments, it defaults to AES-256.
The combination of these two changes means that even if RC4 is supported, attackers are less likely to obtain RC4-encrypted tickets.
The final blow to RC4 is that it’s deprecated in Windows Server 2025, so it’s just a matter of time until RC4-encrypted service tickets become a thing of the past. And it is a significant blow, because cracking AES-256 is about a million times slower than cracking RC4 (rounding things up; it might be closer to half of that, but does it really matter?).
No RC4 = No Kerberoasting Risk?
As I mentioned earlier, we are often asked/told that AES-256 reduces or even eliminates the Kerberoasting risk, and this is what I want to address in this post.
It is true that brute-forcing an AES-256 key generated from a password longer than 7-8 characters is unfeasible (possibly even shorter than 7, depending on the character set and the resources available to the attacker).
However, brute-forcing is not the only password cracking strategy. Remember, attackers target user accounts rather than computer accounts or MSAs because humans potentially set their passwords, which means brute-forcing may not be required. Instead, a dictionary attack or a combination of a dictionary with a ruleset is likely to succeed, while significantly reducing the keyspace.
Does that mean Kerberoasting AES-256-enabled accounts is feasible? Not necessarily. Just like with RC4 encryption, it depends on the password strength. If the password is “password” or “12345”, it will be cracked instantly regardless of the encryption type.
Anecdotally, we regularly see service accounts with such weak passwords. Don’t dismiss it, saying, “This is 2025. No one uses such weak passwords anymore.”
Conclusion
So, before you accept the risk or dismiss findings related to Kerberoasting AES-256-enabled accounts, let me ask you a question: what’s the password?
- If you’re unsure, treat it as if RC4 is supported
- If you know and it’s not strong, then fix the password, not the encryption type
- If you know and it’s strong, then even RC4 won’t matter much
AES-256 mitigates cracking speed, not easily guessable passwords. Password strength remains the real control.