RC4 in Kerberos: The Cipher That Wouldn’t Die (Until Now)
- Shannon
- Mar 14
- 7 min read
Like with previous blogs, all code can be found here! A fully usable PowerShell module to help you hunt!
If you’ve spent any meaningful time working with Active Directory, you’ve probably heard the refrain: “Just disable RC4.” It has been de facto security advice floating around for well over a decade. Most of us nodded when we first heard it, assumed someone in the security team took care of it during the last domain functional level upgrade, and moved on to the next operational fire.
Except RC4 never actually left the building.
It just moved into the basement and kept the lights off.
Microsoft recently published a definitive guide titled What is going on with RC4 in Kerberos? and the tone feels like a long-overdue house cleaning. Microsoft is finally forcing the issue, so enterprises MUST comply. Throughout 2026, RC4 is being evicted from Windows Kerberos flows. If you run AD, this is the change you want to get ahead of before your helpdesk starts melting.
The Invisible Fallback that Everyone Forgot
RC4, specifically ARCFOUR, dates back to 1987, which means it’s about to turn 40 next year. In the Windows 2000 era it was a superstar. It was fast, simple, and easy for computers to run without using much CPU, which mattered a lot when hardware was slower than what we have today.
Technically speaking, RC4 is a stream cipher, which means it encrypts data one byte at a time by generating a pseudorandom stream of bytes called a keystream. That keystream is combined with the original data using a simple XOR operation to produce encrypted output. As long as both sides share the same secret key, they can generate the same keystream and reverse the process to recover the original message.
The design made RC4 extremely attractive in the early days of modern networking because it was lightweight and easy to implement. Unfortunately, researchers later discovered statistical weaknesses in how RC4 generates its keystream. Those weaknesses make it possible to recover information about the underlying data or the key under certain conditions. So while RC4 was once a workhorse for protocols like SSL and Kerberos, cryptography doesn’t age like wine; it ages like milk you just discovered behind the yogurt in the office fridge.
While we all moved to AES-128 and AES-256, Kerberos kept RC4 around for "compatibility." The problem is that Kerberos is a ridiculously polite and forgiving protocol. Kerberos negotiates and is the great compromiser. If a client and a server can’t agree on a modern cipher, they look for common ground. Too often, that common ground is the digital equivalent of a rusted-out bridge: RC4. Yikes.
Why RC4 is a Kerberoasting Goldmine
In a Kerberos environment, weaknesses in the cipher directly translate to identity theft. Attackers love RC4 because of Kerberoasting.
When a service ticket is encrypted with RC4, the password hash is derived from the account's NTLM hash, which lacks modern salting. This makes it roughly 1,000x faster to crack than an AES-encrypted ticket. By leaving RC4 enabled, you aren't just supporting old tech; you’re leaving a "Please Rob Me" sign on your service accounts. This vulnerability is a major driver behind the new CVE-2026-20833 hardening.
The 2026 Sunset Schedule
Microsoft isn't ripping the band-aid off in one go. They’ve laid out a phased Deprecation Roadshow to give us time to find the skeletons in our closets:
January 13, 2026 (The Observation Phase): Domain Controllers (DCs) get smarter. The Key Distribution Center (KDC) will start favoring AES even if the request is ambiguous. Crucially, new Audit Events (Event IDs 201–209) will start firing, telling you exactly who is still asking for RC4.
April 2026 (The Pressure Phase): The KDC gets strict. It will begin blocking RC4 usage that previously relied on "default" assumptions. You can still use the temporary RC4DefaultDisablementPhase registry key to toggle an "Audit Mode" if things break, but the clock is ticking.
July 2026 (The Hard Stop): The safety rails are gone. RC4 is disabled by default for Kerberos, and the "fallback" to RC4 is officially dead.
Hunting for RC4 Before It Hunts You
The good news is that you do not have to wait for Kerberos events to start telling you what is wrong. You can proactively search for accounts that may still rely on RC4 behavior.
The key attribute to examine in Active Directory is msDS-SupportedEncryptionTypes. If this attribute is empty or configured incorrectly, the account may fall back to older encryption behaviors instead of explicitly advertising AES support.
This is where things get interesting. The script that often floats around online for this task has a couple of problems. It references the wrong password property for managed service accounts, and it also fails to account for a PowerShell quirk involving attributes with hyphens in their names.
So before we go hunting, let’s fix the script (and find those skeletons).
The "RC4 Hunter" Script
Run this on a machine with the Active Directory PowerShell module to generate your remediation "hit list":
Import-Module ActiveDirectory
Get-ADServiceAccount -Filter * -Properties `
"msDS-SupportedEncryptionTypes","PasswordLastSet" | `
Select-Object Name, DistinguishedName, PasswordLastSet,
@{Name="EncryptionTypes"; Expression={
$enc = $_.'msDS-SupportedEncryptionTypes'
if ($null -eq $enc) {
"DEFAULT / NOT SET"
}
else {
$types = @()
if ($enc -band 4) { $types += "RC4" }
if ($enc -band 8) { $types += "AES128" }
if ($enc -band 16) { $types += "AES256" }
if ($types.Count -eq 0) { "Unknown ($enc)" }
else { "$enc : " + ($types -join ", ") }
}
}} |
Where-Object {
$_.EncryptionTypes -eq "DEFAULT / NOT SET" -or
$_.EncryptionTypes -match "RC4" -or
$_.EncryptionTypes -match "^Unknown"
}This identifies managed service accounts that either have RC4 explicitly enabled or rely on default encryption behavior that may still negotiate RC4.
But that only tells half the story.
Many environments still run services using traditional user accounts with SPNs attached. Those accounts are just as important to check.
Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties ` "servicePrincipalName",`
"msDS-SupportedEncryptionTypes","PasswordLastSet" | `
Select-Object Name, SamAccountName, DistinguishedName, PasswordLastSet, ` @{Name="EncryptionTypes"; Expression={
$enc = $_.'msDS-SupportedEncryptionTypes'
if ($null -eq $enc) {
"DEFAULT / NOT SET"
}
else {
$types = @()
if ($enc -band 4) { $types += "RC4" }
if ($enc -band 8) { $types += "AES128" }
if ($enc -band 16) { $types += "AES256" }
if ($types.Count -eq 0) { "Unknown ($enc)" }
else { "$enc : " + ($types -join ", ") }
}
}},
@{Name="SPNs"; Expression={ ($_.ServicePrincipalName -join "; ") }} | `
Where-Object {
$_.EncryptionTypes -eq "DEFAULT / NOT SET" -or
$_.EncryptionTypes -match "RC4" -or
$_.EncryptionTypes -match "^Unknown"
}Together, these two scripts give you a decent picture of where RC4 may still be lurking.
Why RC4 Has Been So Hard to Kill
Once you start investigating these accounts, a few common patterns tend to appear:
The first is password age. AES encryption keys are generated when passwords are set or changed. If a service account has not had its password rotated in years, the AES keys may not exist even if the environment otherwise supports them.
Another common issue is third-party infrastructure. Older NAS appliances, legacy Linux distributions, embedded devices, or line-of-business software often rely on older Kerberos libraries that only understand RC4. Those systems will need updates, configuration changes, or regenerated keytabs before they can survive the 2026 cutoff.
And then there are the odd little surprises that show up when you copy PowerShell scripts from helpful web pages and discover a Unicode dash hiding inside your command. That one does not break Kerberos, but it can definitely ruin your afternoon.
Fixing the Cipher the Right Way
Once you identify accounts that need attention, the fix is usually straightforward.
For managed service accounts, you can explicitly set the supported encryption types to AES128 and AES256. In Active Directory, that combination is represented by the numeric value 24.
Set-ADServiceAccount -Identity provAgentgMSA -Replace `
@{"msDS-SupportedEncryptionTypes"=24}To confirm the change, run a simple verification query.
Get-ADServiceAccount -Identity provAgentgMSA -Properties `
"msDS-SupportedEncryptionTypes" | Select-Object ` Name,@{Name='EncValue';Expression={$_.'msDS-SupportedEncryptionTypes'}}If the result shows 24, the account now explicitly supports AES128 and AES256.
For traditional service accounts stored as AD user objects, the same attribute can be updated with a similar command.
Set-ADUser -Identity svc_sqlapp -Replace `
@{"msDS-SupportedEncryptionTypes"=24}Then make sure to verify.
Get-ADUser -Identity svc_sqlapp -Properties "msDS-SupportedEncryptionTypes" ` | Select-Object Name,@{Name='EncValue';Expression=`
{$_.'msDS-SupportedEncryptionTypes'}}One practical detail worth remembering is that Kerberos tickets do not immediately update themselves (the fundamentals haven't changed, yo). Depending on the service and account type, you may need to restart the application or rotate the password so the new encryption behavior takes effect.
The Real Takeaway
Microsoft’s RC4 phase-out flips the traditional approach to security hardening. Instead of asking administrators to disable weak ciphers manually, the platform is finally assuming that strong encryption should be the default. It is the right move, even if it is going to uncover a few forgotten dependencies along the way.
RC4 has survived for years because it hid behind compatibility. It lingered in old service accounts, in appliances that nobody wanted to touch, and in quiet Kerberos negotiations that happened behind the scenes. But hidden does not mean harmless.
So if you manage Active Directory (it's ok...there are a lot of customers still heavily reliant upon ADDS), now is a good time to go hunting. Check your service accounts, rotate passwords where needed, set explicit encryption types, and clean up the leftovers before 2026 does it for you.
Because as it turns out, RC4 never really left.
It just waited patiently for the audit logs to catch up with it.
Further reading for your next dinner party (hardy har har)! Microsoft / Primary Sources
Microsoft AskDS blog explaining the RC4 changes
Microsoft documentation on detecting and remediating RC4 usage in Kerberos
Kerberos encryption types and how Windows chooses them
Microsoft deep dive on supported Kerberos encryption types
Kerberoasting / Why RC4 Matters
Microsoft explanation of Kerberos ticket events and encryption types
Microsoft Defender for Identity guidance on Kerberoasting
Active Directory PowerShell
Get-ADServiceAccount documentation
Set-ADServiceAccount documentation
Get-ADUser documentation
Comments