Luke Lauterbach

Summary

Microsoft recently announced that the Kerberos RC4 encryption algorithm will be disabled in the April Windows Update (More Reading). It will be able to be re-enabled until the July Windows Update, at which point it will be completely removed and there will be no option to re-enable it (More Information).

Details

Why does this matter? Well Kerberos RC4 has been a weak point in Active Directory environments for many years. Kerberoasting is a VERY common attack, where attackers can obtain Kerberos tickets for any account with a Service Principal Name (SPN) set in Active Directory. Tickets are encrypted, but the encryption can be broken to reveal the password used to encrypt the ticket. This is very common for service accounts. This is not a software vulnerability that can be patched. It is a consequence of how Kerberos service tickets are designed. In many Active Directory environments, it's just a given that an attacker will be able to get encrypted Kerberos tickets.

There are four different Kerberos encryption types, including three that are commonly in use today:

• DES (deprecated since Server 2008)
• RC4
• AES128
• AES256

Of the three active encryption algorithms, RC4 is by far the weakest. I have 8 Nvidia 5080 GPUs that I use for password cracking. With these GPUs, I can attempt approximately 15.6 billion password guesses per second against the RC4 encryption algorithm. The same GPUs can only attempt 18.3 million guesses per second against AES128 and 9.2 million against AES256. Cracking a Kerberos ticket encrypted with AES256 takes 1,696x longer than an RC4 encrypted ticket.

Disabling RC4 is a very positive change by Microsoft, and is a rare win from a company that typically values backwards compatibility above all else.

The change should not impact the majority of organizations. All versions of Windows since Server 2008 (non-R2) support AES encryption, along with all Microsoft applications released since 2008. There is one risk that will impact a very small portion of organizations: if an account has not changed its password since the domain was at a functional level of Server 2003, Kerberos authentication will completely break, as AES keys derived from the password will not exist in AD until the password for the account is reset. The solution is simple: make sure the domain is at a functional level of at least Server 2008 and reset the password of any account that hasn't had a password change since the domain was upgraded. A password reset will generate the necessary AES keys for Kerberos to function again.

During my penetration tests, I regularly encounter domain accounts without AES keys (due to the password never being reset), and I even occasionally run into domains at a functional level of Server 2003. So it's certain that a small number of organizations will run into issues when April Windows Updates are applied.

The Fix

Organizations have a few different ways of checking to make sure they won't be impacted:

• The January 2026 Windows Update included auditing policies that can enabled on Kerberos Key Distribution Centers (KDCs). Specifically, Event IDs 4768 and 4769 include the ticket encryption type used during authentication. Any account that doesn't include AES would not be able to use Kerberos to authenticate once the April Windows Update is installed (More Reading).

• Organizations can check to make sure all of their accounts have had their password changed since the domain was updated to a functional level of Server 2008 (if the date of the domain upgrade is known).

  • This can be accomplished with the following PowerShell script:

    param(
        [Parameter(Mandatory = $true)]
        [datetime]$SinceDate
    )
    
    Import-Module ActiveDirectory -ErrorAction Stop
    
    Get-ADUser -Filter {
        Enabled -eq $true -and PasswordLastSet -lt $SinceDate
    } -Properties PasswordLastSet |
        Select-Object Name, SamAccountName, UserPrincipalName, PasswordLastSet |
        Sort-Object PasswordLastSet |
        Format-Table -AutoSize
    

  • The output will look like this:

  

• During my penetration tests, I dump the ntds.dit database from a Domain Controller and extract the NTLM and Kerberos keys for domain accounts from the database. PassInspector is a tool we've built to analyze domain user credentials. Part of the analysis is checking to see if any accounts do not have AES keys stored.

Attack Example

Kerberoasting is a well documented attack, with a variety of tools available to perform the attack. Impacket's GetUserSPNs is my favorite. By default, GetUserSPNs will find all user accounts in Active Directory with SPN values set and perform a Kerberoasting attack on each of the accounts. This is noisy and will be caught by the most basic Identity Threat Detection & Response (ITDR) solutions. A targeted Kerberoast would be much less noisy. But I'm a Pen Tester, not a Red Teamer, so I'm okay with a little noise.

Encrypted Kerberos tickets will be returned for each account with an SPN value set. The encryption algorithm used to encrypt the ticket returned will depend on which encryption algorithms are allowed for the account. The following values represent each of the encryption algorithms (specifically, the Kerberos etype value):

• $23$ - RC4
• $17$ - AES128
• $18$ - AES256

The difficulty of cracking each of these encryption types varies dramatically. An Nvidia 3080 GPU (which is admittedly dated now, but is what I have sitting around right now), can attempt approximately 1.3 billion password guesses per second against the RC4 encryption algorithm. The same GPU can only attempt 900,000 guesses per second against AES256.

900,000 guesses per second still seems like a lot. But consider a Kerberos ticket encrypted with RC4 that takes 5 minutes to crack. That same password would take 5 days to crack if the Kerberos ticket had been encrypted with AES256.

Conclusion

Eliminating RC4 in April's Windows Update is a rare win for Microsoft Security. It will drastically cut down on the number of organizations falling victim to Kerberoasting attacks and is unlikely to impact many organizations. Organizations that are worried about being impacted can do a tiny amount of prep work to make sure they aren't impacted.