CVE-2020-1472 Zerologon: What It Was and How to Confirm Domain Controllers Are Safe

CVE-2020-1472 Zerologon: What It Was and How to Confirm Domain Controllers Are Safe

Originally published 24 September 2020 · Reviewed 5 November 2026

Zerologon was one of the most serious Active Directory vulnerabilities of 2020, and the questions it raised, such as whether anything still depends on a compatibility exception, remain useful for any older domain. This article explains what it was, how Microsoft rolled out the fix, and how to confirm that your domain controllers are no longer exposed. It is historical background plus a checklist, not a guide to attacking anything.

What the vulnerability was

CVE-2020-1472 is an elevation of privilege vulnerability in the Netlogon Remote Protocol (MS-NRPC), which domain members use to authenticate to domain controllers over a secure channel. Microsoft scored it at the maximum, CVSS 10. A flaw in the cryptographic handling of the secure channel meant an unauthenticated attacker with network access to a domain controller could impersonate a computer account, including the domain controller's own account, and in the worst case take over the domain. The risk was highest where an attacker already had a foothold on the internal network.

How the fix was staged

Microsoft addressed the issue in two phases, documented in its support article on managing Netlogon secure channel changes:

1. Initial deployment phase, from the updates released on 11 August 2020. Domain controllers enforced secure RPC for Windows devices, trust accounts and domain controllers, and logged events for devices that used the vulnerable behaviour so that you could find and fix them. Administrators could allow specific non-compliant accounts through a group policy named "Domain controller: Allow vulnerable Netlogon secure channel connections".
2. Enforcement phase, from the updates released on 9 February 2021. Domain controllers moved to enforcement mode. Vulnerable secure channel connections were denied unless explicitly allowed by that group policy, and the earlier registry setting that enabled enforcement early was no longer needed.

Events to know

On domain controllers, the System log records Netlogon events about vulnerable connections. During the initial phase, Microsoft documented event 5829 for a vulnerable connection that was allowed, and events 5827 and 5828 for a connection that was denied. Events 5830 and 5831 indicate a connection allowed because of the group policy exception. After the enforcement phase, vulnerable connections are denied, so you should expect the deny events and not the allow events. If you see allow events, investigate: it means an exception is in place or an older domain controller is not patched.

Confirm your own domain is safe

1. List all domain controllers and their patch levels. Every one needs updates from 9 February 2021 or later. A single unpatched domain controller, including a forgotten one at a branch office or in a lab, undermines the rest.
2. Check the exception policy. Look in Group Policy for "Domain controller: Allow vulnerable Netlogon secure channel connections" and any accounts listed in it. Each entry is a risk you accepted; remove it if the device can be fixed.
3. Search the System log for Netlogon events on domain controllers, and resolve any vulnerable connections you find.
4. Find non-Windows or old devices. NAS appliances, Samba servers, legacy storage and old Windows versions were the usual reasons for exceptions. Update or replace them.
5. Check trusts and domain controllers outside the main domain. Child domains, trusted domains and appliances acting as domain controllers must be covered too.
6. Review account hygiene. If you ever suspected an attack, follow Microsoft's incident guidance and treat the domain as potentially compromised: reset machine and krbtgt passwords as advised, and review privileged groups.

Lessons for older domains

Zerologon showed that a flaw in a protocol that every domain member uses can turn a small foothold into complete control. Keep domain controllers patched on a short schedule, reduce the number of systems that can reach them, restrict administrative paths, and prefer migration away from end-of-life Windows Server versions. Hybrid environments should still review on-premises identity security, because Microsoft Entra Connect carries on-premises accounts into the cloud.

Why the exceptions mattered

Most of the delay in closing this vulnerability came from devices that could not use the secure channel properly, not from the domain controllers themselves. Storage appliances, print servers and older operating systems often needed vendor updates, and some organisations chose to allow them through the group policy exception to avoid an outage. That choice traded safety for uptime. If you inherited a domain that still has such an exception, list the accounts, find an owner for each, and set a date to replace or update the device. An exception with no owner and no date tends to live forever.

What to record

For an audit or a customer questionnaire, keep a short record: the date each domain controller received the February 2021 or later updates, the contents of the exception policy (ideally empty), a note that no vulnerable connection events appear in the last thirty days, and the name of the person who checked. That evidence answers most questions about this vulnerability in a few lines, and it proves that the control is being operated, not just remembered.

Microsoft references

• How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472, reviewed 5 November 2026.
• CVE-2020-1472 Security Update Guide entry, reviewed 5 November 2026.

This article was first published on 24 September 2020. It was rewritten on 5 November 2026 as historical background with a verification checklist, and the contact details in the original were removed. Microsoft's live documentation takes precedence if it has changed.