Disable RC4 Kerberos Before 14 July 2026 (CVE-2026-20833)

RC4 is the legacy Kerberos cipher that makes Kerberoasting cheap, and Microsoft is turning it off. With the July 2026 security update (enforcement lands on Patch Tuesday, 14 July 2026), domain controllers stop issuing RC4 tickets by default. That closes an attacker's fastest path to service-account passwords, and it breaks every account still stuck on RC4. This post explains what RC4 in Kerberos actually is, what CVE-2026-20833 changes, whether the "PoC" works, and exactly how to disable RC4 Kerberos and detect the accounts that will fail on the 14th.

What is RC4 in Kerberos, and why is it being killed?

RC4-HMAC (Kerberos encryption type 0x17) is a legacy stream cipher used to encrypt Kerberos tickets. It is being removed because it is cryptographically weak and, more practically, because it is what makes offline cracking of service-account passwords fast.

The mechanics matter. When Kerberos issues a service ticket, it encrypts part of that ticket with the target account's key. For RC4, that key is the account's unsalted NT hash — the same hash for every ticket, with no per-account salt. Any authenticated user can request a service ticket for an account that has a Service Principal Name (SPN), take the RC4-encrypted blob offline, and brute-force it. With AES, the key is salted and the derivation is far more expensive, so the same attack goes from hours to impractical.

Here are the encryption types you will see in policies and logs:

The goal after July is simple: every account and the KDC issue and accept only 0x11 / 0x12.

CVE-2026-20833 explained

CVE-2026-20833 is the information-disclosure weakness that formalizes RC4's risk in Kerberos ticket issuance, and it is the reason Microsoft attached a hard enforcement date to the RC4 deprecation. It describes exactly the problem above: an authenticated attacker can request RC4-encrypted service tickets and crack them offline to recover the account's password.

Microsoft is rolling the change out in three phases across 2026:

1. January 2026 — Audit. New code paths and logging land. RC4 still works; you can now see where it is used before anything blocks.
2. April 2026 — Defaults shift. Domain controllers default to AES-SHA1 and the implicit RC4 fallback is disabled. Accounts that depend on RC4 begin failing authentication unless RC4 is explicitly allowed.
3. July 2026 — Enforcement. Windows updates released on or after July 2026 enable the Enforcement phase and remove Audit mode. RC4 is off by default on all domain controllers and only works if you explicitly configure an account or the KDC to permit it.

What changes on 14 July 2026 (and what breaks)

After the July update, the KDC stops issuing RC4 service tickets unless you have opted an account back in. In practice, the things that break are the things that were never migrated: old line-of-business applications with hardcoded RC4, appliances and Linux/Unix Kerberos integrations that were configured a decade ago, some cross-forest trusts, and service accounts whose password "cannot be touched because it breaks the app." Those are exactly the accounts an attacker wants, which is the whole point of the next two sections.

Does the CVE-2026-20833 PoC actually work?

There is no dramatic single-binary "PoC" for CVE-2026-20833, and expecting one misreads the vulnerability. This is not a memory-corruption RCE. The exploitation is ordinary Kerberoasting against any account for which the KDC still issues RC4 tickets: request the service ticket (Rubeus kerberoast, GetUserSPNs.py), then crack the RC4 blob offline (Hashcat mode 13100). So the honest answer is: yes, the technique works wherever RC4 issuance is still permitted, and there is nothing exotic to run. What the July enforcement does is remove the cheap path by refusing to hand out RC4 tickets in the first place. If you want to test your own exposure before the 14th, you do not need a special exploit — you need to know which accounts still get RC4 tickets, which is a detection problem, not an exploitation one.

How RC4 enables Kerberoasting

Kerberoasting (MITRE ATT&CK T1558.003) is a post-authentication technique, and RC4 is what makes it worth doing. The chain is short:

1. Any domain user requests a service ticket (TGS) for an account that has an SPN. No special privilege is needed.
2. The KDC returns the ticket encrypted with the service account's key. If that key is RC4, it is the unsalted NT hash of the account's password.
3. The attacker takes the ticket offline and cracks it with a wordlist. RC4 makes step 3 fast.

This is why RC4 service accounts are the first thing I enumerate on an engagement: an account that is both roastable (has an SPN) and privileged is the shortest line I have to a password I can actually crack. Move those accounts to AES and the offline crack usually stops being viable within a realistic time budget. If you want the cracking side of this in depth, see our breakdown of wordlists for cracking Active Directory hashes, and the wider context in the Active Directory pentesting guide.

How to disable RC4 Kerberos

To disable RC4 in Kerberos, force AES-only encryption at the domain controller and on individual accounts, then stage the rollout so legacy dependencies surface before they fail hard. There are two levers: a Group Policy setting for the KDC and hosts, and the msDS-SupportedEncryptionTypes attribute per account.

GPO: Configure encryption types allowed for Kerberos

Edit the policy at:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

Enable only AES128_HMAC_SHA1 and AES256_HMAC_SHA1 (and, if a legacy system still needs it during migration, leave "Future encryption types" but not RC4). Applied to domain controllers and clients, this tells the Kerberos stack which etypes are acceptable.

msDS-SupportedEncryptionTypes per account

msDS-SupportedEncryptionTypes is a per-account bitmask that declares which encryption types that account supports. AES128 + AES256 is the value 0x18 (decimal 24). Set it explicitly on user and computer accounts, especially service accounts:

• Auditing accounts that still declare RC4 (or leave the attribute unset, which is treated as RC4-capable) is the core of the detection work below.
• After you set AES on a service account, rotate its password once so an AES key is actually generated. Setting the attribute without a password change means the account still has no usable AES key.

Rolling out without breakage

Do not flip enforcement blind. Use the audit data from January onward to build the list of accounts still using RC4, fix them in waves (test accounts, then non-critical services, then Tier 0), rotate passwords to generate AES keys, and keep a short explicit allow-list only for systems you cannot migrate before the 14th. The KDC will enforce for you in July whether or not you finished; the choice is between doing it on your schedule or firefighting authentication failures on theirs.

How to detect RC4 usage and RC4-permitted accounts

To find RC4 before enforcement, watch Kerberos service-ticket requests for the RC4 encryption type and query the directory for accounts that do not declare AES. Two data sources cover it.

From the logs. Event ID 4769 ("A Kerberos service ticket was requested") includes a Ticket Encryption Type field. A value of 0x17 is an RC4 ticket being issued right now. Collecting 4769 across your domain controllers gives you a live map of which accounts are still getting RC4 tickets and which clients are asking for them. It is also, not coincidentally, the same event used to detect Kerberoasting.

From the directory. Query every account whose msDS-SupportedEncryptionTypes is unset or still includes RC4. An account with the attribute missing is treated as RC4-capable, so "unset" is not "safe" — it is part of your exposure.

Finding every RC4-exposed account across the domain

The reporting-dry documentation stops at "query the attribute." The operational problem is doing it across a real domain and correlating it with privilege: an unset attribute on a disabled test account does not matter; the same on a Tier 0 service account with an SPN is a live path. Validating that intersection across every account and DC is exactly what ADscan does in one pass — it flags accounts that are both RC4-permitted and privileged, so you fix the ones that matter first instead of chasing a flat list.

In the assessments I run, RC4 is almost never fully gone. Roughly 9 out of 10 of the Kerberoastable and AS-REP-roastable hashes I pull come back as RC4; only about 1 in 10 environments have AES enforced across their service accounts. That is the argument for treating 14 July as a deadline you drive, not one that surprises you.

You can see the kind of exposure this surfaces in a sample AD exposure report, or run a proof of value against your own AD before the enforcement date.

Post-enforcement checklist

• GPO restricts Kerberos to AES128 + AES256 on DCs and clients.
• Every service account has msDS-SupportedEncryptionTypes = AES only, with a post-change password rotation so AES keys exist.
• 4769 collection shows no 0x17 tickets for accounts you care about.
• The explicit RC4 allow-list is empty, or documented with an owner and a migration date.
• Privileged, SPN-bearing accounts have been re-checked specifically — they are the ones that turn a missed migration into a domain-compromise path.

FAQ

What encryption type is RC4 in Kerberos?

RC4-HMAC is Kerberos encryption type 0x17 (decimal 23). Its key is the account's unsalted NT hash, which is why RC4 tickets are cheap to crack offline compared with AES (0x11 / 0x12).

Will disabling RC4 break my service accounts?

It can. Any account that only has an RC4 key — no AES key generated — will fail Kerberos authentication once RC4 issuance is enforced. Set msDS-SupportedEncryptionTypes to AES and rotate the account's password to generate an AES key before the July update reaches your domain controllers.

How do I check if RC4 is still enabled in my domain?

Collect Event ID 4769 and look for Ticket Encryption Type 0x17, and query the directory for accounts whose msDS-SupportedEncryptionTypes is unset or includes RC4. Unset counts as RC4-capable, so treat it as exposure, not as safe.

Does CVE-2026-20833 have a working exploit?

The "exploit" is standard Kerberoasting against any account still issued RC4 tickets — request the ticket, crack it offline. There is no special binary to run. July 2026 enforcement removes the path by no longer issuing RC4 tickets by default.

When exactly is the RC4 enforcement deadline?

Enforcement is enabled by Windows updates released on or after July 2026; the July Patch Tuesday is 14 July 2026. After that, RC4 is off by default on domain controllers and only works where explicitly permitted.