When I came up with Kerberoasting in 2014, I never thought it would live for more than a year or two. I (erroneously) thought that people would clean up the poor, dated credentials and move to more secure encryption. Here we are 11 years later, and unfortunately it still works more often than it should. In 2024, healthcare giant Ascension was hit by ransomware. On September 10, 2025, a senator wrote a letter to the FTC about Kerberoasting and Microsoft’s deficiencies in protecting Windows. Let’s first very briefly discuss what Kerberos is, then I’ll touch on Microsoft’s response and the senator’s letter to the FTC.
All 500 of the Fortune 500 use Active Directory and therefore Kerberos to authenticate to their Windows systems. A user receives a “ticket” to prove who they are to registered services inside Active Directory (for simplicity, I’ll just say server). To protect the ticket, it is encrypted using a derivative (hash) of the server’s password. The server decrypts the ticket and then decides if the user has access, and if so, how much access.
The issue is any valid user (even a compromised one) can request a ticket for any server. This means an attacker can request and save tickets for any and all servers. With those tickets in hand, the attacker then makes a guess as to the server’s password and attempts to decrypt the tickets. Since the attack is offline, an attacker can attack the password as fast as their (often specialized) hardware will let them, up to billions of attempts per second. And with no lockout of the account due to the the attack being offline.
For a little more depth (but not a ton), see the end of this article. For much more in-depth technical details, I have hands-on pay-what-you-can training (down to free, as in beer, as in $0) on the topic available at training.redsiege.com.
Sen. Ron Wyden (D–Oregon) sent a letter to FTC Chairman Andrew Ferguson in response to the 2024 ransomware breach of the healthcare giant Ascension. Ars Technica wrote an article on the topic. The senator called out Microsoft for supporting RC4 encryption on Kerberos tickets, which makes the Kerberoasting attack significantly faster.
Let’s see why RC4 matters.
With the Kerberoast attack, attackers are targeting the encryption key (the server’s password), not the underlying encryption protocol. The common encryption protocols for encryption on tickets are RC4, AES128, and AES256. The attackers aren’t fundamentally breaking RC4, but…
The problem with RC4 is that it is significantly faster to crack RC4 Kerberos tickets than it is to crack AES128 or AES256 tickets. Based on a quick benchmark on my laptop’s GPU, AES128 and AES256 are approximately 350 and 700 times slower to crack, respectively (benchmarks by some others show it is even slower). And yes, AES based Kerberos tickets are still susceptible to Kerberoasting, it just takes longer.
The thing is, longer matters. If it takes a day to crack an RC4 ticket, that would take nearly a year to crack the same AES128 ticket, and nearly two years for AES256. If an attacker can’t crack the ticket in a reasonable amount of time, they move onto the next thing. Also, it gives the organization more time to detect an intruder before they elevate or extend their access. Is it perfect, no, but it is better. In security we far too often make perfect the enemy of good (or better).
That said, if the password is really bad, going a thousand times slower isn’t going to have any meaningful benefit.
In the Ars Technica article, Microsoft is quoted as:
RC4 is an old standard, and we discourage its use both in how we engineer our software and in our documentation to customers – which is why it makes up less than .1% of our traffic. However, disabling its use completely would break many customer systems. For this reason, we’re on a path to gradually reduce the extent to which customers can use it, while providing strong warnings against it and advice for using it in the safest ways possible. We have it on our roadmap to ultimately disable its use. We’ve engaged with The Senator’s office on this issue and will continue to listen and answer questions from them or others in government.
In Q1 of 2026 any new installations of Active Directory Domains using Windows Server 2025 will have RC4 disabled by default, meaning any new domain will inherently be protected against attacks relying on RC4 weaknesses. We plan to include additional mitigations for existing in-market deployments with considerations for compatibility and continuity of critical customer services.
Microsoft claims this affects “less than 0.1% of traffic”, but this statistic is misleading. It’s like saying “only 0.1% of our doors are used by burglars” – attackers will simply choose the weak door. Microsoft has prioritized backward compatibility over security, leaving all organizations vulnerable by default.
The truth is, since the protocol is enabled (by default), all an attacker needs to do is request an RC4 ticket. The surrounding traffic (99.9%) is irrelevant. Microsoft has left RC4 enabled because they have chosen to support backward compatibility (as mentioned in the quote), which leads to a faster Kerberoast attack.
The second paragraph is misleading as well. They state that “in Q1 of 2026 any new installations of Active Directory Domains using Windows Server 2025 will have RC4 disabled by default”. The key here is “new”. Existing Active Directory Domains will still maintain their backward compatibility, and RC4, by default. If a new server is installed, and it doesn’t support RC4, that doesn’t prevent the rest of the domain, and the Domain Controllers (the brains of the Domain) from preventing RC4.
On October 11, 2024, Microsoft published a blog post titled Microsoft’s guidance to help mitigate Kerberoasting. In the article Microsoft discusses mitigations for Kerberoasting, including disabling RC4 and forcing the more secure AES encryption. Unfortunately, this was only a blog post, and it was released on a Friday.
The blog post from Microsoft does include mitigations for the attack. At the time of the post, Microsoft was criticized for posting it on a Friday afternoon, and as a blog post.
In short, disable RC4 for Kerberos tickets. As you prepare to do this, you need to find systems that are using RC4 tickets. Unfortunately, ticket creation is not logged by default. To enable it, follow the guidance here. With auditing enabled, look for EventID 4769 and for outdated encryption (see the same article to find systems requesting RC4 tickets. Resolve the issues for those services, or exclude them from the broader ban on RC4.
The fundamental problem that leads to a successful Kerberoasting attack is bad passwords. Ideally use Managed Service Accounts (see the Microsoft blog post) or use a long, secure, and preferably random password. Remember, attackers are guessing billions of passwords per second. A secure password for a user is much different than a secure password for these accounts.
Of course, it is always important to not only implement these mitigations, but also to test to make sure.
1. Ask Your CISO These Questions:
2. Require These Changes:
3. Business Decisions Needed:
I don’t think we’ll see RC4 going away anytime soon as backward compatibility continues to be the bane of security. I’m really excited to see Senator Wyden and his team for pushing for security changes. I just want to see the world as a better, more secure place.
I have attempted to explain the attack as simply as possible. Some nuances are technically not correct, but the gist stands. (That is a note for the pedantic folks out there).
Kerberos uses “tickets” for authentication (verify identity) and authorization (what level of access to give). A ticket is what is used when a user wants access to a server. To secure the tickets they are encrypted using a password hash.
With Kerberos, the central brain of the network, a Domain Controller (DC), creates the ticket. Think of this ticket as being like a driver’s license. The ticket is then presented to the server. The server decrypts the ticket, and then based on the information inside, decides if the user has access. Much like if you go to the post office to pick up a package. The postal worker looks at your ID and decides if you should get your package. They don’t call back to the state where the license was issued to see if you should get the package.
With access as any compromised user, an attacker can request access to any server, but it is up to the server to decide if the user should have access (not the DC). Since the DC doesn’t know if the user has access, any user can request a ticket for any server.
The problem is, the ticket sent to the server is encrypted using the password of the server (technically the password hash, but the hash is derived from the password so you can effectively say it is encrypted using the password). So an attacker requests a ticket for all the services, copies them to their offline system, and attacks the tickets. The attacker attempts to guess the server’s password, hashes it, and attempts to decrypt the ticket. They do this over and over again until the ticket is successfully decrypted With specialized hardware they can do this very, very fast. Since this is an offline attack, there is no account lockout.
With the password for the server, attackers have gone from low-privilege user to higher-privilege. This can lead to significant compromise.
For much more in-depth technical details, I have hands-on pay-what-you-can training (down to free, as in beer, as in $0) on the topic available at training.redsiege.com.
By Red Siege | October 2, 2025
As proud sponsors of Wild West Hackin’ Fest, Red Siege is excited to return to Deadwood for another year of cutting-edge training, engaging talks, and unique experiences. The event is […]
Learn More
By Red Siege | September 22, 2025
by Ian Briley Let’s be honest, when starting a new skill or interest, one of the largest hurdles is setting up an environment//playground//attack range for your learning activities. Sometimes it […]
Learn More
By Red Siege | September 8, 2025
by Ian Briley To get around a DLP (Data Loss Prevention) implementation, you don’t need a fancy C2 setup to exfil your treasures. In fact, it’s incredibly easy using native […]
Learn More