Zerologon: When Bad Crypto Hands You the Keys to the Kingdom

In the world of exploit development, we usually deal with complex memory corruption, race conditions, or convoluted logic chains that require stars to align. Then came Zerologon (CVE-2020-1472). Discovered by Tom Tervoort of Secura, this wasn't just a bug; it was a fundamental embarrassment to modern cryptography. It turned the fortress of Active Directory into a house of cards that could be toppled by—quite literally—doing nothing but sending zeros.

The vulnerability resides in the Netlogon Remote Protocol (MS-NRPC), a core component used for machine authentication in Windows domains. Historically, this protocol relied on 64-bit DES (yes, really), but it was eventually upgraded to use AES. The problem? The implementation of AES was so flawed that it effectively neutered the encryption entirely.

What makes this terrifying is the barrier to entry. You don't need user credentials. You don't need complex shellcode. You just need a network connection to the Domain Controller (DC). In about three seconds (or roughly 256 network packets), an attacker goes from "nobody" to "Domain Admin," holding the ability to dump the entire NTDS.dit database. It is, without hyperbole, the holy grail of network privilege escalation.

To understand Zerologon, you have to look at how Microsoft implemented AES-CFB8 (Cipher Feedback Mode, 8-bit). In any sane cryptographic system, the Initialization Vector (IV) must be random and unique for every encryption operation. This randomness ensures that the same plaintext doesn't always map to the same ciphertext. Microsoft, however, decided to read the "Random IV" requirement and say, "Nah, let's just make it all zeros."

The ComputeNetlogonCredential function defined the IV as a fixed string of 16 zero bytes. In AES-CFB8, the encryption of the first byte depends on the encryption of the IV. The flaw relies on a statistical quirk: for any given secret key (the machine account password), there is a 1 in 256 chance that the first byte of the AES output for an all-zero input will be 0x00.

Here is where the math kills the security. In CFB8 mode, the ciphertext byte is XORed with the plaintext byte. If the crypto output is 0x00 and your plaintext is 0x00 (which we control), the resulting ciphertext is 0x00. Because CFB feeds the ciphertext back into the next round as the IV, if you keep sending zeros, the encryption loop gets "stuck" outputting zeros. The entire session key negotiation collapses into a string of null bytes.

The issue wasn't a buffer overflow; it was a logic error in the protocol specification itself. The MS-NRPC spec dictated the use of AES-CFB8 but failed to mandate a random nonce for the handshake. Instead, the implementation looked something like this:

// Pseudo-code representation of the vulnerable logic
unsigned char IV[16];
memset(IV, 0, 16); // The fatal flaw: Fixed IV of all zeros
 
// AES-CFB8 Encrypt
// If AES_Encrypt(Key, IV)[0] == 0x00, and Input is 0x00:
// Then Output is 0x00.
// This zero feeds into the next round as part of the new IV.

Because the attacker controls the Client Challenge (which acts as the input plaintext), they can set it to 8 bytes of zeros (0000000000000000). They also set the expected Client Credential (the ciphertext) to zeros.

The server takes the challenge (zeros), encrypts it with the machine account hash (the Key) using the fixed zero IV. If that 1-in-256 statistical anomaly hits, the server computes the result as... zeros. It compares the computed credential (zeros) with the client's provided credential (zeros), matches them, and authenticates the session. No password required.

Exploiting this is insultingly simple. The attacker targets the NetrServerReqChallenge and NetrServerAuthenticate3 calls. Since we are looking for a 1-in-256 probability, we don't need a supercomputer. We just need to retry the handshake a few hundred times. On a local LAN, this takes less than 3 seconds.

Once the handshake succeeds (the server accepts our all-zero credential), we have an authenticated Netlogon session. But we don't know the session key (which is derived from the real machine password). We only know that for this specific instance, the encryption stream is broken and equals zero.

So, what do we do with a broken session? We use it to call NetrServerPasswordSet2. This RPC call allows a computer to update its own domain password. We send a request to set the Domain Controller's computer account password to—you guessed it—an empty string. Because we disable the encryption (signing/sealing) on the RPC packet, the server accepts the cleartext password change. The DC now has no password. We can then use standard tools like secretsdump.py with an empty password to DCSync the domain.

The impact of Zerologon cannot be overstated. It was the weapon of choice for ransomware groups like Ryuk and Conti in late 2020. Traditionally, ransomware operators would land on a workstation via phishing, then spend days trying to pivot laterally, steal admin credentials, or crack Kerberos tickets to reach the DC. Zerologon shortcut this entire process.

With CVE-2020-1472, lateral movement became instant. If an attacker compromised a single machine on the network—even a lowly guest Wi-Fi connection with visibility to the DC—they could instantly elevate to Domain Admin.

Furthermore, the exploit is destructive. By resetting the DC's machine account password to an empty string, the DC loses trust with the domain. It stops functioning correctly until manually repaired. While sophisticated attackers (like the zer0dump tool authors) found ways to restore the password after exploitation, script kiddies and ransomware automated bots often left broken DCs in their wake, causing immediate denial of service alongside the data breach.

Microsoft's fix was a two-phase rollout because fixing the crypto meant breaking compatibility with legacy devices that didn't speak "Secure RPC."

Phase 1 (Aug 2020 - KB4571703): This patch prevented the specific zero-day exploit by enforcing Secure RPC for Windows devices but allowed non-Windows devices to connect insecurely if logged. It effectively stopped the "spoofing" attack by validating the cryptographic handshake more rigorously.

Phase 2 (Feb 2021): Enforcement Mode. Microsoft mandated that all devices interacting with Netlogon must use Secure RPC. If you have an ancient printer or a legacy Samba 3 server that can't do Secure RPC, it gets dropped.

For defenders, the key takeaway is ensuring your Domain Controllers are fully patched and that Domain Controller: Allow vulnerable Netlogon secure channel connections group policy is NOT enabled unless absolutely necessary for a specific legacy device. If you see Event ID 5829 or 4742 (computer account changed by anonymous), you are likely already compromised.