← All posts

Zerologon: The Netlogon Flaw That Hands Over Domain Admin, and How to Audit for It

Zerologon (CVE-2020-1472) let attackers reset a domain controller's machine password in seconds. Here is how the attack works, why it still matters, and how to verify your DCs are patched and enforcing secure RPC.

Zerologon is one of those rare vulnerabilities that earned a perfect CVSS 10.0 and deserved it. Disclosed in August 2020 as CVE-2020-1472, it let an unauthenticated attacker with nothing but network access to a domain controller reset that DC's machine account password to an empty value — and from there impersonate the DC, run DCSync, and mint Domain Admin. No credentials. No phishing. Often under three seconds. Six years later it still turns up on internal pentests, because a patched DC is not automatically an enforcing DC, and stray legacy devices keep enforcement turned off.

Why the cryptography failed

Netlogon secures its RPC channel with a scheme called AES-CFB8. The flaw was in how the initialization vector was handled: the protocol implementation fixed the IV to all zeros instead of randomizing it. With a zero IV and AES-CFB8, a plaintext of all zeros produces a ciphertext of all zeros roughly 1 in 256 attempts. An attacker simply replays a NetrServerAuthenticate3 call with a zeroed client challenge over and over. On average, a few hundred tries later the authentication succeeds without the attacker ever knowing the machine's password.

Once the session is established, the attacker calls NetrServerPasswordSet2 to set the DC's Active Directory machine account password to empty. That desynchronizes the value in AD from the one stored locally in the registry, but AD is authoritative for the attack that follows.

What the attacker does next

Owning the DC computer account is effectively owning the domain:

The single scariest property of Zerologon is speed: reconnaissance to Domain Admin in the time it takes to run one script. There is no lateral movement to detect, no credential harvesting phase to catch.

Why it is still relevant in 2026

Microsoft shipped the fix in two phases. The August 2020 patch allowed secure RPC but still tolerated vulnerable connections for compatibility. Full enforcement mode — rejecting non-secure Netlogon — arrived in February 2021 and is now the default. The gap is real environments that:

How to audit your domain controllers

Enforcement is controlled on each DC by a single registry value under the Netlogon parameters key. Confirm it is absent or set to 1:

Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
  -Name FullSecureChannelProtection -ErrorAction SilentlyContinue |
  Select-Object FullSecureChannelProtection

A value of 1 (or the value not existing on a fully patched DC, where enforcement is on by default) is good. A value of 0 means you are back in permissive mode. Also inspect the exception list — anything here is explicitly allowed to talk insecure Netlogon:

Get-ItemProperty `
  'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
  -Name 'vulnerable channel allow list' -ErrorAction SilentlyContinue

Finally, hunt for the tell-tale event on your DCs. Event ID 5829 (a vulnerable connection was allowed) is a warning during the transition period; events 5827/5828 log denied vulnerable connections once enforcing. Persistent 5829 entries name the exact machines still speaking insecure Netlogon — fix or replace them, do not widen the allow list:

Get-WinEvent -FilterHashtable @{ LogName='System'; ProviderName='Netlogon'; Id=5827,5828,5829 } -MaxEvents 50

Where WinSentinel fits

Netlogon enforcement is exactly the kind of setting that is easy to verify once and impossible to keep verified by hand across a domain. WinSentinel's Windows security audit checks Netlogon secure-channel enforcement as part of its 33-module scan — on a single machine, entirely free, with every module unlocked and no host limits. Point it at a domain controller and it reports whether enforcement is on, whether an allow-list exception exists, and whether the recent event log shows vulnerable connections being permitted.

For organizations running many DCs and member servers, the Pro tier's central node rolls those per-machine findings into a fleet view: which controllers are enforcing, which regressed after a rebuild, and a drift alert the moment someone flips FullSecureChannelProtection back to 0. That turns a one-time 2020 remediation into a continuously verified control instead of a checkbox nobody re-checks.

The takeaway

Zerologon is patched everywhere by now, but "patched" and "enforcing secure RPC with an empty allow list" are not the same thing. Confirm the registry value on every DC, empty the exception list, drive Event ID 5829 to zero by fixing the offending clients, and then keep watching — because the one DC that quietly slips back to permissive mode is a full-domain compromise waiting for a single script.