RC4 Is About to Go Extinct in Kerberos. So Is Your Kerberoasting Detection

The April 2026 cumulative updates flip Active Directory domain controllers into enforcement mode for the RC4 disablement Microsoft started staging in January. That’s the headline most AD teams are tracking, and they’re tracking it as a compatibility problem: what breaks when the KDC stops assuming RC4 for accounts that never got an explicit encryption-type value. Fair concern. But there’s a second-order effect almost nobody is staffing for, and it lands on the SOC, not the directory team. Your Kerberoasting detection — the 4769 rule that’s been sitting in the SIEM since someone read the adsecurity writeup years ago — is built on RC4 being the anomaly. You’re about to make RC4 extinct. The rule will go quiet, and the people watching the dashboard will read quiet as safe.

It isn’t. Kerberoasting against AES tickets is slower and more expensive to crack, but it is the same attack, and AES does nothing to stop a service account whose password is Summer2024!. What disablement actually does is remove the cheap, loud cryptographic tell you were using to find the attack. The control improves your posture and degrades your visibility at the same moment, and if you don’t rebuild the detection before April you’ll have traded a noisy-but-real signal for a clean dashboard that means nothing.

What the rollout actually changes

Microsoft tied this to CVE-2026-20833, a Kerberos information-disclosure issue, and used it as the entry point for a phased default change that’s been coming since the CVE-2022-37966 work in late 2022. Three phases, all keyed to the monthly cumulative updates:

• January 2026 — audit. New KDCSVC events (the 201–209 range) start firing on DCs to flag interactions that would break under enforcement. Nothing is blocked yet. A temporary RC4DefaultDisablementPhase registry value under ...\Policies\System\Kerberos\Parameters lets you opt a DC into simulated enforcement early for testing.
• April 2026 — enforcement. The assumed default, DefaultDomainSupportedEncTypes, moves to AES-SHA1 only (0x18) for any account without an explicit msDS-SupportedEncryptionTypes. Accounts that genuinely only speak RC4 start getting KDC_ERR_ETYPE_NOTSUPP (failure code 0xE).
• July 2026 — no going back. Same behavior as April, except audit mode is gone and the rollback registry switch is ignored.

One detail that catches people: if your DCs are already Windows Server 2025, this train partly left the station. Server 2025 DCs don’t issue RC4 ticket-granting tickets at all. So a chunk of your environment may already be running the post-RC4 world while the rest waits for April, which means your detection baseline is already drifting and you might not have noticed.

The mechanism, briefly, because the detection depends on it

A Kerberoasting actor doesn’t need to be admin. Any authenticated principal can request a service ticket (TGS) for any account that has a Service Principal Name registered. The KDC hands back a ticket encrypted with the service account’s key. Request a ticket for an SPN tied to a user account — a SQL service account, an old IIS app pool identity — and you’re holding ciphertext that’s encrypted with that account’s password-derived key. Take it offline, guess passwords, done. No further interaction with the DC, which is exactly why it’s hard to catch.

The encryption type is the whole story for detection. An RC4-HMAC ticket (0x17) is derived straight from the account’s NT hash, and offline cracking of that is fast and well-tooled. An AES256 ticket (0x12) runs the candidate password through 4096 iterations of PBKDF2 before you can even test it, so the cracking economics change by orders of magnitude. That’s the real security win from disablement, and it’s genuine — I’m not knocking the control. The problem is purely that defenders built their detection on the etype field, and the field is about to stop varying.

The rule you have, and why it dies in April

The classic detection keys on Windows Security Event ID 4769 — Kerberos service ticket requested — filtered to Ticket_Encryption_Type=0x17. In Splunk with the Windows TA that’s roughly:

EventCode=4769 Ticket_Encryption_Type=0x17
Service_Name!="krbtgt" Account_Name!="*$"
| stats dc(Service_Name) as spn_count values(Service_Name) by Account_Name, Client_Address
| where spn_count > 15

The RC4 filter is doing enormous work here, and not because RC4 means malice. It means RC4 is rare in a healthy 2026 estate. After the 2022 default change, most legitimate Kerberos traffic is already AES, so the 0x17 events that remain are a small enough pile that you can afford to look at them. The spn_count threshold on top is what separates “user opened three apps this morning” from “principal enumerated forty SPNs in ninety seconds.”

Strip the RC4 filter and that economics collapses. 4769 is one of the highest-volume events a DC produces. In a domain of a few thousand users you’ll see tens of thousands of these an hour, and they all cluster into a logon storm around 0900 when everybody’s laptop wakes up and grabs tickets for the file shares, the mail, the print server, the intranet. Without an etype discriminator your “many distinct SPNs per principal” query is now running against the entire legitimate ticket volume of the domain, and the threshold you tuned for the RC4 subset will either drown you or miss the attack. Probably both, depending on the hour.

So after April you’re left with two unappealing options. Keep the 0x17 filter and watch the rule trend toward zero hits while the attack surface quietly migrates to 0x12. Or drop the filter and rebuild the threshold logic against full-volume AES traffic, which is real work and which most teams won’t schedule until something forces them to.

Rebuilding the signal without the etype crutch

The honest answer is that you stop leaning on the encryption type and start leaning on behavior, because behavior is what was actually anomalous all along. The etype was a convenient proxy.

What survives the transition is the shape of the request pattern. One principal pulling service tickets for an unusually wide set of distinct SPNs in a tight window is the tell, etype be damned. So the detection becomes a per-principal cardinality-over-time problem on 4769, and the tuning that matters is the baseline: what’s the normal distinct-SPN count for a given account over a rolling window, and what’s a deviation worth paging on. Static thresholds will betray you here because a Configuration Manager account or a vuln scanner’s service identity legitimately touches dozens of SPNs by design. You want per-principal baselining, not a global number. If you only have the budget for a global threshold, set it high — distinct SPN count north of 20 for an interactive user account in a short window — and accept that you’re catching the loud actor and missing the patient one.

Two things make this materially easier and you should do both before April:

The January 2025 cumulative update (Server 2016 and later) added fields to 4768/4769 — AccountSupportedEncryptionTypes, AccountAvailableKeys, ServiceSupportedEncryptionTypes. Once enforcement lands and AES is universal, the targeted account’s available-keys profile becomes more useful than the ticket etype for spotting an actor probing for weak accounts. Make sure your WEF subscription or agent config is actually forwarding those fields and not truncating the 4769 message body, because the default forwarder configs from a few years ago predate them and will silently drop what you need.

The other is decoy SPNs. Stand up a service account with an attractive name, give it a real SPN, an absurd 100+ character random password, and never let anything legitimately request a ticket for it. Any 4769 naming that SPN is high-fidelity by construction — there’s no legitimate caller, so there are no false positives to tune. This is the one detection in this whole space that gets better after RC4 disablement, because it doesn’t depend on the etype at all. If you build one new thing, build this.

Where the false positives and the breakage come from

Two different noise sources, and people conflate them.

The detection noise is the SPN-cardinality problem above: scanners, management agents, and a handful of legitimately chatty service identities that will look like enumeration unless you baseline per-principal. Carve those out by name in the first week and the volume drops to something a human can read.

The operational noise is the accounts that genuinely can’t do AES, and they are messier than the docs admit. NetApp filers historically defaulted to RC4-only for CIFS. Inter-forest trust traffic falls back to RC4 unless both sides are explicitly configured for AES. Appliances, old Linux Kerberos integrations, that one Java app whose keytab nobody has regenerated since the admin who built it left. Under audit mode these light up as KDCSVC 201/202; under enforcement they become 203/204 and the authentication actually fails. The failure surfaces as a network error on SMB or 0x80090342 on a New-PSSession over WinRM, which the help desk will not connect to a Kerberos encryption change. So before April, run the audit-mode events and the Get-KerbEncryptionUsage.ps1 script from Microsoft’s Kerberos-Crypto repo, and inventory every principal still landing on RC4. The ones you can fix, fix with a password reset (which generates the missing AES keys) or an explicit msDS-SupportedEncryptionTypes. The ones you can’t — there’s a stillneedrc4@microsoft.com address for that, which tells you how clean the cutover really is.

Do not, by the way, solve your breakage by setting DefaultDomainSupportedEncTypes back to something with the RC4 bit set (0x4, 0x7, 0x27). It works, your tickets flow, and you’ve quietly re-enabled the exact attack surface the whole exercise was meant to close — domain-wide, for every account that lacks an explicit value. Scope RC4 to the specific accounts that need it, never to the domain default.

What changes the answer

Environment assumptions move this around more than usual.

A flat single-forest AD with modern DCs is the easy case: most traffic is already AES, the residual RC4 is a short list, and the decoy-SPN detection carries you. A multi-forest estate with trusts is harder, because inter-forest RC4 is both legitimate and exactly what an actor crossing a trust boundary would generate, so you can’t simply alert on cross-forest RC4 and call it done. FedRAMP and DoD environments have largely been AES-mandated for years under the relevant STIGs, so for them April is closer to a non-event on the directory side — but the detection blind spot is identical, because their old 4769 rule keyed on 0x17 too. Hybrid shops with Entra-joined endpoints add Cloud Kerberos Trust to the picture, which behaves differently again and is worth its own look before you assume your on-prem baseline covers it.

The control mapping

Treat IA-7 (cryptographic module authentication) as the driver and SI-4 as the thing that quietly regresses if you don’t act. That pairing — a control that improves while the monitoring that watched it degrades — is the whole point of this piece.

April is a hard date. Walk into it having already rebuilt the detection on behavior and stood up at least one decoy SPN, and the etype going dark is a footnote. Walk into it with the old 0x17 rule still in production and you’ll spend Q3 wondering why Kerberoasting alerts stopped, right up until the day they should have fired and didn’t.

Sources

• Detect and remediate RC4 usage in Kerberos (Microsoft Learn)
• What changed in RC4 with the January 2026 Windows update and why it is important (Microsoft Community Hub)
• What is going on with RC4 in Kerberos? (Microsoft Community Hub)
• Microsoft’s guidance to help mitigate Kerberoasting (Microsoft Security Blog)
• Kerberos RC4 hardening: what Microsoft’s CVE-2026-20833 update really means for Active Directory admins (Cayosoft)
• Windows Kerberos RC4 deprecation: what will break in Active Directory and how to fix it (4sysops)
• Detecting Kerberoasting activity (ADSecurity)