Inside Zerologon Attack

What is the Zerologon Attack Vulnerability?

Zerologon is a vulnerability in the Windows netlogon protocol (on Windows Server version 2008 and later) discovered by Tom Tervoort of Secura during a security review of the protocol (which had not previously undergone such a review).  Due to cryptographic and implementation errors in the protocol, an attacker can falsely authenticate and elevate their privileges to Domain Admin.  This has a number of potential impacts including:

• Full Network Control: With Domain Administrator access, the attacker has full control over the network.
• Credential Compromise: Netlogon enables an attacker to extract user account credentials for offline password cracking.
• Credential Stuffing: Passwords compromised via netlogon are likely to be used on other accounts, enabling an attacker to access bank accounts, social media, etc.
• Initial Access: With the access provided by netlogon, an attacker could steal sensitive data, deploy ransomware, etc.
• Denial of Service Attack: Zerologon enables an attacker to change a password in Active Directory but not in the registry or LSASS.  This means that services on a rebooted machine may no longer function.

Technical Details of Zerologon

Zerologon exploits a vulnerability in the netlogon authentication process, which is performed as follows:

1. Server and client each generate and exchange a random 8-byte challenge
2. The shared session key is generated as the first sixteen bytes of SHA256(MD4(domain password),challenges)
3. Client verifies the session key by encrypting and sending the original challenge that they generated encrypted with the new session key.

The zerologon vulnerability arises due to the fact that Windows netlogon uses an insecure variant of the cipher feedback (CFB) block cipher mode of operation with AES.

Normally, CFB mode is designed to encrypt 16-byte chunks of the plaintext (as shown above).  This enables the encryption or decryption of data longer than the standard 16-byte AES block size.  It starts by taking a random initialization vector, encrypting it, and XORing it with the plaintext of a block to create the ciphertext for that block.  This ciphertext is used as the input to encryption for the next block, and so on.

(via Secura)

The vulnerable version of CFB mode used in Windows netlogon (called CFB8) performs encryption one byte at a time.  To do so, it takes the following steps:

1. The initialization vector (yellow) is encrypted using AES
2. The first byte of the result (pink) is XORed with the first byte of plaintext (blue)
3. The resulting byte of ciphertext is appended to the end of the IV
4. The first byte of the IV is dropped
   1. The result is the same length as the original IV (yellow and pink above)
5. Steps 1-4 are repeated until the entire plaintext is encrypted

While the use of a non-standard encryption algorithm is bad enough, the netlogon protocol made another critical error.  The initialization vector is hard-coded to zero, not random like it should be.

This creates a vulnerability if the first byte of encryption produces a ciphertext byte of zero (which occurs with 1/256 probability).  If this is the case, then the result of encryption will always be all zeros.  This is because the input to the encryption algorithm will always be the same (since the IV is all zeros and the value appended to the end during each round of encryption is a zero).

This makes it possible for an attacker to authenticate via netlogon with no knowledge of the domain password.  By trying to authenticate repeatedly to the system with an all-zero challenge, the attacker can trigger the 1/256 chance that the shared secret (that they don’t know) encrypts the first byte of the challenge to a zero.  They can then trivially generate the encrypted challenge (step 3 in the netlogon authentication process) since it is all zeros.

How Zerologon Can Be Exploited

The Zerologon vulnerability, by itself, only enables an attacker to successfully authenticate to the domain controller and encrypt all-zero plaintexts.  However, this is enough to successfully call the NetrServerPasswordSet2 function, which is designed to change the server password.  This function takes the following parameters:

• Original client challenge plus the current time in POSIX notation
• Random data
• New password
• New password length

Of these the original client challenge, the random data, and the new password are easily set to all zeros.  In theory, the server should verify the current time and disallow a zero-length password.  However, this is not the case, making it possible to set the domain controller’s password to empty.

While changing this password does not enable the attacker to log into the machine, it does enable them to access the Domain Replication Service Protocol.  This enables them to extract the password hashes of domain administrator accounts, enabling them to generate Kerberos golden tickets.  Additionally, these hashes could be used in a pass-the-hash attack to log into the Domain Controller and as Domain Administrator and reset the password manually.  This provides the attacker with full access and control over the network.

However, this is not even the only way to exploit the Netlogon vulnerability.  A writeup by Dirk-jan Mollema describes another method that takes advantage of the NTLM protocol to gain Domain Administrator access without changing a password (which can crash services).  However, this version of the exploit requires two vulnerable domain controllers, an available domain user account, and a print spooler service running on a DC and accessible from the network (default domain controller configuration).

Zerologon Exploitation in the Wild

The patch for Zerologon was released in August 2020, and the details of the vulnerability weren’t publicly announced until September 2020.  In theory, this provided organizations with ample opportunity to apply the patch and eliminate the vulnerability.

In practice, many organizations have not applied the patch, leaving them vulnerable to exploitation.  Microsoft publicly announced that they have detected active exploitation of the vulnerability, and the Department of Homeland Security (DHS) issued a directive on September 18th requiring federal agencies to patch the issue by September 21st (i.e. the following Monday).

This is due to the fact that the vulnerability was expected to be actively exploited by cybercriminals.  This belief is backed up by a report by Tenable that multiple different exploit executables were uploaded to Virustotal.

Protecting Against Zerologon

The Zerologon vulnerability is patched in the August 2020 set of Windows updates, and is blocked by some endpoint security solutions.  Microsoft recommends taking the following steps to fix the issue:

1. Update Domain Controllers with the patch released in August 2020.
2. Monitor patched Domain Controller logs for event IDs 5829, 5828, and 5829.  These events indicate a client that is using a vulnerable netlogon secure channel connection and require either a Windows or manufacturer update.
3. Enable Domain Controller Enforcement Mode for additional visibility and protection.

After patching known domain controllers and other known affected systems, it might be wise to undergo a penetration test to discover other potentially vulnerable devices.  The vulnerability affects most versions of Windows Server, which can be deployed in a number of different environments and contexts.