The Undying Zombie: Windows Kerberos RC4 Disclosure

It is the year 2026. We are on the verge of quantum computing, AI writes our poetry, and yet, deep inside the belly of the Windows operating system, a cryptographic zombie from 1987 is still shambling around. I am talking, of course, about RC4 (Rivest Cipher 4).

CVE-2026-20833 isn't a complex heap overflow or a race condition in the kernel. It is a testament to the persistent nightmare of backward compatibility. The vulnerability lies in the Windows Kerberos Key Distribution Center (KDC). Despite AES being the standard for over a decade, the KDC has remained frustratingly polite. If a client or a service account asked for a ticket encrypted with RC4-HMAC (etype 23), the KDC would oblige.

Why does this matter? Because RC4 is effectively 'cryptographic cheese'. It has known biases in its keystream output. For a hacker, seeing RC4 in a Kerberos exchange is like finding a safe with the combination written on a sticky note attached to the door. This vulnerability allows an attacker to explicitly request this weak encryption to peel back the layers of Kerberos security.

The root cause here is CWE-327: Use of a Broken or Risky Cryptographic Algorithm. In a secure Kerberos environment, the KDC should negotiate the strongest possible encryption (AES-256). However, the Windows KDC logic contained a fallback mechanism that was too permissive.

When a user requests a Ticket-Granting Service (TGS) ticket, the encryption type used for the ticket is determined by the msDS-SupportedEncryptionTypes attribute of the target service account. If that attribute allows RC4, or if it isn't set (defaulting to legacy behavior in older domains), the KDC will happily wrap the session key and the ticket in RC4-HMAC.

The flaw is that a local attacker doesn't need to break into the KDC to trigger this. They simply need to request a ticket for a service that supports RC4. Even if the domain generally prefers AES, the mere presence of RC4 support allows the attacker to 'downgrade' the security of that specific transaction. The KDC failed to enforce a 'hard floor' on crypto quality, effectively allowing clients to dictate their own insecurity.

Since Windows is closed-source, we don't have the luxury of a GitHub commit link. However, based on the behavior analysis and the patch (KB5073381), we can reconstruct the logic flow that led to this mess. The vulnerability exists in the ticket issuance logic within kdcsvc.dll.

The Vulnerable Logic (Pseudo-code):

// Pre-patch: The KDC is too accommodating
EncType selectedType = GetBestCommonEtype(clientSupported, serviceSupported);
 
// If the service allows RC4 (23), we use it. No questions asked.
if (selectedType == RC4_HMAC) {
    Ticket tgs = GenerateTicket();
    EncryptTicket(tgs, RC4_HMAC, serviceKey);
    return tgs; // Vulnerable: KDC issues weak crypto
}

The Patched Logic:

The fix introduces a check against a global enforcement policy (registry keys) before agreeing to use RC4. It's a bouncer at the door checking IDs.

// Post-patch: The KDC checks the new enforcement policy
EncType selectedType = GetBestCommonEtype(clientSupported, serviceSupported);
 
if (selectedType == RC4_HMAC) {
    // Check if RC4 is explicitly banned via Registry or Group Policy
    if (IsRC4DisabledGlobally() || !IsRC4AllowedForService(serviceAccount)) {
        // Log Event ID 33 (Audit) or Block
        LogError("RC4 request denied due to security policy.");
        return KRB_AP_ERR_MODIFIED; // Access Denied
    }
    
    // Only proceed if we are in 'Audit' mode or legacy mode
    EncryptTicket(tgs, RC4_HMAC, serviceKey);
    return tgs;
}

The patch effectively creates a 'kill switch' for RC4, allowing administrators to force the KDC to reject these requests even if the service account is misconfigured to support them.

Exploiting this is trivially easy because it relies on standard protocol features. We are essentially doing Kerberoasting, but we are guaranteeing that the hash we get back is the weaker RC4-HMAC version, which is exponentially faster to crack than AES.

The Attack Chain:

1. Reconnaissance: The attacker gains low-level access to a domain-joined machine. They query Active Directory for service accounts.
2. Target Selection: The attacker looks for accounts where msDS-SupportedEncryptionTypes is missing or includes 0x4 (RC4).
3. The Trigger: Using a tool like Rubeus, the attacker requests a ticket specifically asking for RC4.

   Rubeus.exe kerberoast /etype:rc4 /nowrap

4. The Capture: The KDC (pre-patch) obliges and returns a TGS encrypted with the target service account's NTLM hash (RC4).
5. The Crack: The attacker takes this hash offline. Because it is RC4, they can use hashcat -m 13100 and chew through millions of passwords per second.

This bypasses the safety net of AES. Even if the password is reasonably strong, the speed at which RC4 can be brute-forced (compared to the computational cost of AES derivation) significantly lowers the bar for a successful compromise.

The impact here is High Confidentiality Loss, but let's translate that into English. If an attacker can force RC4 usage, they can recover the plaintext password of service accounts with frightening speed.

Once a service account is compromised:

1. Silver Tickets: The attacker can forge a TGS for that service. If the service is MSSQL, they are now sysadmin. If it's a domain controller service, it's Game Over.
2. Lateral Movement: The attacker uses the compromised credentials to move laterally to other servers where that account has rights.
3. Passive Decryption: If the attacker is sniffing network traffic, and they know the RC4 key (which they just cracked), they can decrypt past and future traffic protected by that session key.

This vulnerability turns the 'secure' Kerberos protocol into a mechanism for credential distribution to attackers.

Microsoft's January 2026 update (KB5073381) provides the gun to shoot the zombie, but—crucially—it does not pull the trigger automatically. You have to do it yourself.

Remediation Steps:

1. Install the Update: Apply the January 2026 cumulative updates to all Domain Controllers.
2. Audit First: Enable the KdcAuditRc4Usage registry key. Watch your System Event Log for Event ID 33. This will tell you which legacy applications are still trying to use RC4. If you block them immediately, you will break production.
3. The Scream Test: Once you've identified and upgraded the stragglers, set the registry to Enforce mode (KdcForceAES).
   • HKLM\System\CurrentControlSet\Services\Kdc\KdcForceAES = 1
4. Sanitize AD: Run a script to update msDS-SupportedEncryptionTypes on all user and computer objects to ensure only AES-128 and AES-256 are flagged.

If you don't set the registry keys, the patch does nothing but sit there looking pretty. You must actively configure the KDC to reject RC4.