Some vulnerabilities are dangerous because of a subtle bug. Zerologon was dangerous because of a subtle cryptographic bug, and it produced one of the cleanest full-compromise primitives the industry has seen. Discovered by Tom Tervoort of the Dutch security firm Secura, CVE-2020-1472 let an unauthenticated attacker with only network access to a domain controller take over an entire Active Directory domain — no credentials, no phishing, no user interaction. It earned the maximum possible severity rating, and it became one of the most rapidly weaponized flaws of its year.
Vulnerability identity and severity
Zerologon is an elevation-of-privilege flaw in the Netlogon Remote Protocol (MS-NRPC), the mechanism Windows machines use to authenticate to a domain controller and to maintain their secure channel. Microsoft assigned it a CVSS 3.x base score of 10.0 (Critical) — the ceiling of the scale. An unauthenticated attacker who can reach the DC over the network can impersonate any domain-joined computer, including the DC's own machine account, and ultimately grant themselves domain administrator control.
Timeline and impact
- August 11, 2020 — Microsoft ships an initial patch as part of Patch Tuesday, without publicizing the full severity.
- September 14, 2020 — Secura publishes a detailed technical whitepaper coining the name "Zerologon," and public proof-of-concept code appears almost immediately.
- September 18, 2020 — CISA issues Emergency Directive 20-04, ordering U.S. federal agencies to patch within days.
- February 9, 2021 — Microsoft moves the domain controllers into "enforcement mode" by default, completing the two-phase remediation.
The impact was severe and immediate. Because the exploit is fast, unauthenticated, and requires only network reachability, it became a favorite for post-intrusion privilege escalation and was folded into numerous ransomware playbooks. CVE-2020-1472 sits in CISA's Known Exploited Vulnerabilities catalog.
Root cause: an all-zero initialization vector
The flaw lives in ComputeNetlogonCredential, the function that establishes the Netlogon secure channel. To prove it knows the shared secret (derived from the computer account password), a client computes a cryptographic credential over a challenge. Microsoft's implementation used AES in CFB8 mode, but with a fixed initialization vector of all zeros rather than a unique, random IV.
AES-CFB8 encrypts one byte at a time, feeding each ciphertext byte back into the cipher state. With an all-zero IV and a plaintext of all zeros, there is roughly a 1-in-256 chance — depending on the specific key — that the entire ciphertext also comes out as all zeros. An attacker does not need to know the key. They simply present a client credential of all zeros and retry the handshake. On average, within a few hundred attempts (a matter of seconds), one attempt succeeds and the attacker authenticates as the target computer.
The following pseudocode illustrates the flawed setup at a conceptual level only:
iv = 0x00 * 16 # should be unique and random, is fixed zero
plaintext = 0x00 * 8 # attacker-controlled all-zero client challenge
ciphertext = AES_CFB8_encrypt(key, iv, plaintext)
# ~1 in 256 keys => ciphertext is also all zeros => auth "succeeds"
Once authenticated as the domain controller's own machine account, the attacker uses a follow-up Netlogon call to set that machine account password to empty in Active Directory, which grants the leverage needed to extract credentials and escalate to domain admin.
Samba is also affected
Netlogon is not exclusive to Windows. Samba, when acting as an Active Directory or classic domain controller, implements the same protocol and was therefore vulnerable to the same cryptographic weakness. Samba's own advisory noted that installations relying on the insecure default were exposed. Since Samba 4.8 (2018), the default server schannel = yes mitigated the issue, but deployments on older Samba versions — or any that explicitly set server schannel = no or auto — needed to move to server schannel = yes (or upgrade) to close the gap. Mixed environments running Samba DCs should treat Zerologon with the same urgency as their Windows counterparts.
Detection
- Monitor Netlogon event IDs on domain controllers: 5827 and 5828 (denied machine-account connections), 5829 (allowed vulnerable connection), and 5830/5831 (allowed by explicit policy). A spike in 5829 events indicates vulnerable connections still occurring.
- Watch for anomalous machine-account password changes — Event ID 4742 — especially for the DC's own computer object, which is the tell-tale sign of a successful Zerologon exploit.
- Correlate authentication bursts. Hundreds of rapid, failing Netlogon authentication attempts from a single source in a very short window match the brute-force-the-cipher behavior.
Remediation
- Apply the August 2020 or later Windows updates to every domain controller. This is non-negotiable and is the foundation of both patch phases.
- Ensure enforcement mode is active. The February 9, 2021 update turned it on by default, but confirm no registry override (
FullSecureChannelProtection) has disabled it and that all DCs are current. - For Samba domain controllers, upgrade to a supported release and confirm
server schannel = yesis set so secure channel enforcement is in effect. - Remediate non-compliant devices that appear in 5829 events rather than adding blanket exceptions, so you can fully enforce without breaking legacy systems.
- Audit for prior compromise if any DC ran unpatched with network exposure — check for unexpected machine-account password resets and newly privileged accounts.
How Safeguard helps
Zerologon is an infrastructure-and-component story: the same flawed Netlogon implementation shipped inside Windows Server and inside every container or host running a vulnerable Samba build. Safeguard's software composition analysis inventories the Samba versions present across your container images and hosts and flags builds that fall under CVE-2020-1472, so a forgotten domain-member image or an old Samba DC layer surfaces as a concrete finding rather than an assumption. The Safeguard CLI runs that same detection inside your build pipeline and against image registries, catching a vulnerable Samba package before it is promoted. For the services you expose, Safeguard's DAST engine helps confirm which reachable surfaces are live rather than theoretical, so remediation effort follows real exposure. If you are weighing Safeguard against a single-vendor scanner, compare the coverage side by side.
A cryptographic mistake in a decade-old protocol became a one-command domain takeover the moment it was understood. Continuous, version-accurate inventory is how you make sure the vulnerable build is not still sitting in a base image somewhere. Create a free Safeguard account or read the documentation to get started.