Zerologon CVE-2020-1472 Enforcement Active Directory: Why It's Still Missing on So Many DCs

Zerologon CVE-2020-1472 Enforcement Active Directory: What It Means

Zerologon CVE-2020-1472 enforcement active directory gaps are the part of this vulnerability's remediation that keeps getting skipped, even though the vulnerability itself is old news. Zerologon is a critical (CVSS 10.0) elevation-of-privilege flaw in the Netlogon Remote Protocol (MS-NRPC), the mechanism domain-joined machines use to establish a secure channel with a domain controller. It was discovered and responsibly disclosed by Tom Tervoort at Secura, who published the technical whitepaper in September 2020 (Secura). Microsoft's own advisory tracks it as a Netlogon Elevation of Privilege Vulnerability (MSRC CVE-2020-1472).

The reason this is still worth writing about three years-plus after disclosure isn't the exploit itself — it's the enforcement phase. Microsoft shipped Zerologon fixes in two stages, and the second stage is where most environments quietly stall: patched, but never confirmed as enforcing. This matters because "Zerologon" carries enough name recognition that many teams treat it as a solved, historical issue rather than something worth re-checking during a routine audit — and it keeps turning up alongside the most common Active Directory misconfigurations that audits find every year.

How Zerologon Works

The root cause is a cryptographic implementation error in ComputeNetlogonCredential, the function MS-NRPC uses to derive a session key during NetrServerAuthenticate3. Netlogon uses AES-CFB8 for this exchange, but Microsoft's implementation set the initialization vector (IV) to a fixed value of 16 zero bytes instead of a random one — a violation of how AES-CFB8 is supposed to be used (Secura whitepaper, via Pwnie Awards).

That flaw has a specific, exploitable consequence: for roughly 1 in 256 possible keys, encrypting an all-zero plaintext with AES-CFB8 and a zero IV produces an all-zero ciphertext.

The Attack Sequence

An unauthenticated attacker on the network can:

1. Impersonate a computer account (including the domain controller's own account) in the Netlogon handshake.
2. Send a client challenge consisting of 8 zero bytes.
3. Repeat the handshake — on average around 256 attempts — until the server accepts the all-zero credential.
4. Once authenticated, call NetrServerPasswordSet2 to reset the machine account password of a target, including the DC itself, to a known value.

From there, an attacker who has reset a domain controller's own computer account password can authenticate as that DC and run DCSync to pull every password hash in the domain — full domain compromise, unauthenticated, in minutes. No credentials, no phishing, no malware on the endpoint — only network reachability to a domain controller's Netlogon service. Our companion piece on DCSync and ACL abuse covers what that replication abuse looks like once an attacker has the rights to trigger it.

Confirmed Exploitation in the Wild

CISA added CVE-2020-1472 to its Known Exploited Vulnerabilities catalog and issued Emergency Directive 20-04, ordering all US federal agencies to patch or disconnect affected domain controllers by 11:59 PM EDT on September 21, 2020 (CISA ED 20-04). CISA later confirmed active exploitation of the flaw by nation-state actors (CISA alert, October 2020), and it has since been observed in ransomware intrusions targeting unpatched domain controllers. The combination of a maximum CVSS score, no authentication requirement, and a public proof-of-concept is exactly why this vulnerability class deserves a re-check rather than a one-time patch-and-forget.

Why Enforcement Is a Separate Problem From Patching

Microsoft shipped the fix in two phases, and that phasing is exactly why enforcement gaps persist years after everyone believes the issue is closed.

Phase 1 — August 11, 2020 Update

This patch changed how DCs handle vulnerable Netlogon connections and introduced the FullSecureChannelProtection registry setting under HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, but enforcement was optional. DCs entered an "Initial Deployment Phase" where non-compliant devices were logged, not blocked, unless an admin explicitly set the registry value or deployed the enforcement GPO (Microsoft Support: managing Netlogon secure channel connections).

Phase 2 — February 9, 2021 Update

This update made enforcement mode the default behavior for all Windows domain controllers, regardless of the registry or Group Policy setting (Tenable: Microsoft finalizes Zerologon enforcement by default).

The GPO Exception List Gap

The gap most audits find today isn't "unpatched Zerologon" — it's environments where legacy or third-party devices (NAS appliances, print servers, older non-Windows Netlogon clients) broke under enforcement back in 2021, and an admin added them to the "Domain controller: Allow vulnerable Netlogon secure channel connections" Group Policy exception list to stop the outage. That exception list is exactly the enforcement gap: it's still there, unreviewed, years later, quietly permitting the same vulnerable handshake Zerologon abuses — scoped to whatever accounts were exempted. A domain controller can be fully patched and still have this hole open by policy, which is why patch-level reporting alone is not sufficient evidence of enforcement.

Detection

Netlogon logs specific event IDs for vulnerable secure channel activity on every domain controller. Monitor these on all DCs, not just one:

(Microsoft Support: managing Netlogon secure channel connections)

Pulling the Events

Concretely, on each domain controller:

# Pull recent Netlogon vulnerable-channel events from the System log
Get-WinEvent -LogName System -FilterXPath "*[System[(EventID=5827 or EventID=5828 or EventID=5829 or EventID=5830 or EventID=5831)]]" -MaxEvents 200 |
    Select-Object TimeCreated, Id, Message |
    Format-Table -AutoSize

# Confirm the registry enforcement state directly (informational on Feb-2021-patched DCs,
# where enforcement is the default regardless of this value)
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name FullSecureChannelProtection -ErrorAction SilentlyContinue

Any 5829, 5830, or 5831 event is a signal worth investigating — it identifies exactly which device is still relying on the vulnerable handshake and why, and gives you a concrete list to work from instead of a policy assumption. Pair Netlogon event monitoring with the wider set of Active Directory security event IDs that should already be in your SIEM, and with a broader hardening priorities review so protocol-level fixes like this one don't get treated as one-off projects that age out of scope.

Remediation

1. Confirm patch level on every DC, not a sample. Verify each domain controller has at minimum the August 11, 2020 update, and ideally the February 9, 2021 cumulative update or later, which makes enforcement the default. Missed DCs (including read-only DCs and DCs in less-visible domains/forests) are the most common gap.
2. Audit the "Domain controller: Allow vulnerable Netlogon secure channel connections" GPO. Review every entry in the exception list. For each exempted device, confirm it still exists, still needs the exception, and has no vendor firmware/software update available that adds proper secure RPC support. Remove stale entries.
3. Monitor events 5829/5830/5831 continuously, not just during a one-time deployment window. Any new occurrence means a device is depending on the vulnerable path today.
4. Set (or verify) FullSecureChannelProtection = 1 on any DC that has not yet received the February 2021+ update, as an interim control while patching completes.
5. Re-verify after infrastructure changes. New domain controllers, DC promotions from templates/images, and forest/domain trust changes can all reintroduce an unenforced or unpatched state — bake this into standard GPO and DC build review, not just the initial 2020/2021 rollout.
6. Treat DCSync exposure as the downstream risk. Zerologon's real impact is that it hands an attacker the ability to reset a DC's own account password and pull the domain's password hashes. Reviewing who and what already holds legitimate DCSync-capable replication rights closes the second half of this attack path — see our guide on ACL abuse and DCSync.

How EtcSec Detects This

EtcSec's ZEROLOGON_PATCH_ENFORCEMENT check flags domain controllers where Zerologon enforcement cannot be confirmed — whether that's a missing patch, a disabled FullSecureChannelProtection setting on a pre-February-2021 DC, or an active Netlogon exception GPO — so it doesn't get silently assumed as "fixed in 2020." It's paired with DCSYNC_CAPABLE, which flags accounts and computer objects holding replication rights that a Zerologon-style compromise would let an attacker exploit for full credential extraction. Together, the two checks map the full attack path: the initial unauthenticated foothold and the privileged replication rights that turn it into a domain-wide breach.