Zombie Crypto: How RC4 Returned from the Grave to Kill Your Domain (CVE-2022-37966)

We have been telling sysadmins to kill RC4 for a decade. We explicitly disabled it in Group Policy. We laughed at it in CTFs. Yet, like a bad horror movie villain, it was hiding in the basement the whole time, waiting to stab us in the back. CVE-2022-37966 isn't just a bug; it's a structural indictment of backward compatibility addiction.

Here is the setup: Kerberos, the three-headed dog guarding your Windows domain, passes around 'tickets'. Inside these tickets is a special data structure called the PAC (Privilege Attribute Certificate). Think of the PAC as your relentless corporate ID badge—it lists who you are and, more importantly, what groups you belong to. To prevent you from taking a Sharpie to your ID badge and writing 'CEO', the PAC is digitally signed by the KDC (Key Distribution Center).

The vulnerability lies in how it was signed. For years, if you negotiated a ticket using the ancient RC4-HMAC-MD5 (etype 23) cipher, the KDC would use an RC4-based key to sign the PAC. Tom Tervoort at Secura figured out that this implementation was so mathematically fragile that he could forge the signature. If you can forge the signature, you can rewrite the ID badge. You can become the CEO. You can become the Domain Admin.

The root cause is a cryptographic logic error in how session keys are selected for signing the PAC. In a healthy Kerberos transaction, even if the ticket itself is encrypted with a legacy cipher (to support that Windows 2003 server you're too scared to reboot), the session key—the ephemeral secret shared between the KDC and the service—should ideally be strong (AES).

However, prior to the patch, Windows had a fatal lazy streak. If the ticket encryption was RC4, the KDC defaulted to using an RC4 session key to calculate the PAC checksums (specifically the Server Signature and KDC Signature). RC4 is a stream cipher. It doesn't handle integrity protection well, and its key derivation in Kerberos (involving MD5) is notoriously weak against collision attacks and bit-flipping techniques.

Because the KDC allowed the session key strength to degrade to match the ticket encryption type, an attacker who could coerce a target into using RC4 could mathematically manipulate the PAC contents. They didn't need the target's long-term password; they just needed to exploit the weak cryptography of the session key to craft a valid checksum for a malicious payload.

While we don't have the source code for lsass.exe, the logic flow—and the open-source Samba implementation which suffered the same fate—tells the story clearly. The vulnerability lived in the decision tree for key selection.

The Vulnerable Logic (Pseudocode):

// OLD: If ticket is RC4, use RC4 for everything
if (ticket.encryptionType == RC4_HMAC) {
    sessionKey = generate_rc4_key();
    pac.signature = HMAC_MD5(sessionKey, pac_contents);
}

This was the killer. The strength of the signature was bound to the strength of the transport. The fix introduced by Microsoft (and Samba) in late 2022 breaks this coupling. It effectively says, 'I don't care if the ticket is wrapped in garbage RC4; the session key must be AES.'

The Patched Logic:

// NEW: Force AES session keys even for RC4 tickets
if (ticket.encryptionType == RC4_HMAC) {
    // ALERT: Upgrading session key security
    sessionKey = generate_aes_key(); 
    pac.signature = HMAC_SHA1_96_AES(sessionKey, pac_contents);
}

This change destroys the exploit path. Even if an attacker forces an RC4 ticket, the KDC now calculates the signature using AES. Since the attacker cannot forge an AES-based signature without the actual AES key (which they can't derive from the weak RC4 context), the PAC modification becomes impossible.

To exploit this, an attacker needs to perform a 'bit-flip' style attack on the PAC, but it's more nuanced than a simple buffer overflow. It requires an authenticated user account (or a compromised machine account) to request tickets.

Step 1: The Downgrade The attacker scans the environment for accounts that have msDS-SupportedEncryptionTypes set to allow RC4, or simply requests a ticket specifying RC4 as the preferred encryption type. In many pre-patch environments, the KDC happily obliges.

Step 2: The Forgery The attacker obtains a valid TGS (Ticket Granting Service) ticket. They decrypt the ticket (if they own the service account) or manipulate the TGT. They extract the PAC. They locate the Logon Information buffer, which contains the user's SIDs.

Step 3: The Injection The attacker appends the SID for Domain Admins (S-1-5-21-<Domain>-512) to the GroupIds field. Now the PAC says they are an admin. But the checksums (signatures) at the end of the PAC are now invalid.

Step 4: The Bypass Using the cryptographic weakness of the RC4-HMAC-MD5 checksumming algorithm, the attacker recalculates valid checksums for their modified PAC. Because the system is using the weak RC4 session key, this forgery is computationally feasible. They reassemble the ticket and present it to the target service. The service sees a valid signature, unpacks the PAC, sees 'Domain Admin', and rolls out the red carpet.

This is a Game Over vulnerability. It is not limited to a single server. Because the PAC is the central authorization mechanism for the entire Active Directory forest, compromising the PAC validation logic allows for universal privilege escalation.

An attacker with the ability to exploit CVE-2022-37966 can:

1. Elevate Privileges: Turn any low-level user into a Domain Admin.
2. Persistence: Generate Golden Tickets or Silver Tickets with arbitrary group memberships that last for years (or until the krbtgt account is cycled).
3. Lateral Movement: Access any service (File Shares, RDP, SQL, Exchange) as an administrator without knowing the actual admin passwords.

The only saving grace is the complexity. It requires a specific combination of weak encryption settings and the capability to manipulate network traffic or ticket structures. However, for a sophisticated adversary (APT) already inside the network, this is a trivial hurdle.

Microsoft's fix was not a simple binary swap; it was a slow-motion demolition of legacy compatibility. KB5021131 introduced a phased rollout because simply turning off RC4 support would break half the legacy printers, scanners, and NetApp filers in the corporate world.

The core of the fix is in the registry key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\DefaultDomainSupportedEncTypes

Prior to the patch, this defaulted to a value that allowed RC4. After the 'Enforcement' phase (October 2023), this defaults to 0x27 (AES-only essentially), or the system is forced to use AES session keys even if RC4 is negotiated.

Mitigation Strategy:

1. Apply the Patch: Ensure all Domain Controllers are running the latest updates. This is non-negotiable.
2. Hunt for RC4: Run a script to audit msDS-SupportedEncryptionTypes on all users and computers. If you see 0x4 (RC4), scream into a pillow, then fix it.
3. Audit Logs: Look for Event ID 4769 (Kerberos Service Ticket Operations) with Ticket Encryption Type: 0x17 (RC4). If you see this, you have legacy devices that will break when you enforce the patch.