CVE-202 — What It Is,

Unpacking CVE-202 means understanding a critical flaw that impacts nearly every Windows domain. Specifically, we are analyzing CVE-2020-1472, publicly known as "ZeroLogon." This elevation of privilege vulnerability allows an unauthenticated attacker to completely compromise an Active Directory domain controller. Its severity demands immediate attention and thorough technical understanding.

Unpacking CVE-202: The ZeroLogon Vulnerability

CVE-2020-1472 is a critical elevation of privilege vulnerability in the Microsoft Windows Netlogon Remote Protocol (MS-NRPC). It received a maximum CVSS v3.1 base score of 10.0, indicating the highest level of severity. An attacker exploiting this flaw can gain domain administrator privileges without any credentials. This grants them full control over the entire Active Directory domain.

The vulnerability affects a wide range of Windows Server versions. These include Windows Server 2008 R2 (Service Pack 1), Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, and Windows Server 2019. Windows Server versions 1903, 1909, and 2004 (Server Core installation) are also vulnerable. Windows Server 2008 SP2 is not vulnerable as it does not use AES for Secure RPC. Samba domain controllers before version 4.8 were also confirmed to be vulnerable.

Technical Root Cause Analysis

The core of the ZeroLogon vulnerability, CVE-2020-1472, lies in a cryptographic flaw within the Netlogon Remote Protocol (MS-NRPC). This protocol authenticates users and machines in a domain-based network. Specifically, the issue stems from an improper implementation of the AES-CFB8 encryption mode used for session key establishment. Secure use of AES-CFB8 requires a randomly generated Initialization Vector (IV) for each plaintext encryption.

However, the ComputeNetlogonCredential function, central to this process, sets the IV to a fixed value of 16 zero bytes. This non-random, all-zero IV creates a predictable cryptographic condition. The vulnerability arises because sending an 8-byte plaintext of zeros has a 1-in-256 chance of encrypting to an 8-byte ciphertext of zeros with this fixed IV. This significantly weakens the cryptographic authentication.

Another contributing factor is that, by default, unencrypted Netlogon sessions were not rejected by servers. This combination of a fixed, zero-byte IV and the acceptance of insecure sessions allows an attacker to repeatedly attempt authentication with all-zero credentials. Once a successful all-zero ciphertext is produced, the attacker can spoof the identity of any computer, including the domain controller itself.

Exploitation Mechanics

Exploiting ZeroLogon, CVE-2020-1472, typically involves a series of steps. First, an unauthenticated attacker needs network access to a domain controller's Netlogon service, usually on TCP/445. This initial access can come from phishing, stolen VPN credentials, or lateral movement from an already compromised internal host.

The attacker then initiates an unsecured Netlogon channel. They send a series of specially crafted Netlogon authentication requests to the domain controller, with the client credential fields filled with zeros. Due to the cryptographic flaw with the fixed IV, there is a 1-in-256 chance that an all-zero plaintext will encrypt to an all-zero ciphertext. Attackers can automate these attempts, typically achieving success within an average of 256 tries, which takes only a few seconds.

Once a successful all-zero authentication is achieved, the attacker spoofs the identity of the domain controller. They can then use the NetrServerPasswordSet2 call of the MS-NRPC protocol to reset the domain controller's machine account password in Active Directory to a known, often empty, value. This effectively breaks the trust relationship and grants the attacker domain administrator privileges. With this elevated access, the attacker can perform actions like dumping all domain credential hashes (e.g., using a DCSync attack), creating new domain admin accounts, or deploying ransomware. Attackers can optionally restore the original password after gaining access to avoid detection, though this is not always done.

Detection: How to Check if You're Affected

Detecting ZeroLogon exploitation or vulnerability requires monitoring specific activities on your domain controllers. The immediate priority involves checking for unpatched systems. Use Microsoft's official guidance and scripts to identify domain controllers that lack the necessary security updates.

Monitoring Windows Event Logs is a key detection method. Look for Event ID 4742 ("A computer account was changed") where the "Account Name" and "Security ID" are "ANONYMOUS LOGON" and the "Account Domain" is "NT AUTHORITY." This indicates an anonymous user changing a computer account password, a strong indicator of ZeroLogon exploitation. Also, monitor for Event ID 5805 (System - Netlogon) which can signal failed Netlogon secure channel connections. A sudden spike in Netlogon authentication traffic from a single source to a domain controller is also suspicious.

Network-based detection systems, such as Intrusion Prevention Systems (IPS) or Network Detection and Response (NDR) tools, can detect suspicious Netlogon traffic patterns. Snort/Suricata rules exist to identify attempts to exploit ZeroLogon based on the network traffic generated during the exploit, specifically checking for multiple NetrServerAuthenticate attempts with all-zero client credentials. For broader attack surface visibility, Secably provides a free port scanner to identify exposed services, which, while not directly detecting ZeroLogon, helps assess overall network perimeter security. For more on proactive scanning, explore Stopping Active Exploits Impact, Detection.

Beyond live monitoring, examine password history for domain controller computer accounts. ZeroLogon exploitation typically resets the domain controller's computer account password to a null value. Active Directory retains the hashes of the last 24 passwords. Check if a domain controller's password was reset to null and potentially then reestablished. Tools like Mimikatz have integrated ZeroLogon detection and exploitation support, making their presence an indicator of potential compromise. Organizations can also use Zondex for internet-wide scanning to discover other potential entry points for attackers seeking internal network access.

You can use a Python script provided by Secura, the discoverers of ZeroLogon, to safely test for vulnerability without performing password resets. PowerShell scripts can also automate the execution of such testing tools to check the Primary Domain Controller.

# Example PowerShell to check for ZeroLogon vulnerability (simplified, conceptual)
# This is a conceptual example. Always refer to official vendor tools for safe testing.
$PDC = (Get-ADDomain).PDCRoleOwner
$PDC_IP = (Resolve-DnsName $PDC).IPAddress
Write-Host "Checking PDC: $PDC ($PDC_IP) for CVE-2020-1472 vulnerability..."
# Call an external, safe ZeroLogon testing script here, e.g., Secura's Python script
# python zerologon_tester.py $PDC_IP

Remediation Steps

Remediating ZeroLogon (CVE-2020-1472) requires immediate and thorough action. The primary mitigation is to apply the security updates released by Microsoft. Microsoft rolled out patches in two phases: an initial update in August 2020 and an enforcement phase in February 2021. Apply both updates to all domain controllers without delay.

After applying the August 2020 update, enable full Secure RPC enforcement. This involves setting the FullSecureChannelProtection registry value to 1 under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. This forces all Netlogon traffic between domain members and domain controllers to use secure RPC with strong cryptographic authentication, blocking the all-zero credential trick used in the ZeroLogon exploit. The February 2021 enforcement phase automatically enabled this for all Windows Domain Controllers, blocking vulnerable connections from non-compliant devices.

Audit your network for non-compliant devices, especially non-Windows machines that might be using vulnerable Netlogon secure channel connections. Microsoft's updates address Windows devices, but third-party devices might require specific configurations or updates from their vendors. For Samba deployments, upgrade to patched versions and ensure server schannel = yes is set in smb.conf.

Restrict network access to domain controllers from untrusted segments. Implementing strong network segmentation reduces an attacker's ability to establish the necessary TCP session with a domain controller. Require multifactor authentication (MFA) for privileged accounts, including domain administrators. This adds a layer of defense even if credentials are compromised. Regular vulnerability scanning and continuous monitoring, as offered by Secably's paid monitoring plans starting at $19/month, help maintain a strong security posture against evolving threats. For more information on securing your web assets, Secably also provides a HTTP security headers checker.

Timeline of Disclosure

The ZeroLogon vulnerability (CVE-2020-1472) was discovered by Tom Tervoort of Secura, a Dutch security company. Secura responsibly disclosed the flaw to Microsoft.

• August 11, 2020: Microsoft released a security update as part of its Patch Tuesday, including a patch for CVE-2020-1472. Initial technical details were not widely published at this time.
• September 11, 2020: Secura publicly released a detailed technical whitepaper on the vulnerability, dubbing it "ZeroLogon," along with a proof-of-concept (PoC) tool. This public disclosure spurred widespread attention and urgent patching efforts.
• September 2020: Multiple public PoC exploits became available, many based on Secura's original PoC. Reports of active exploitation in the wild, including to spread ransomware like Ryuk, emerged. CISA issued an emergency directive (ED 20-04) urging federal agencies to patch immediately.
• February 9, 2021: Microsoft released the second phase of updates, enabling full enforcement mode on all Windows Domain Controllers. This phase blocked vulnerable connections from non-compliant devices, and the enforcement mode could no longer be disabled.