How to Fix Zerologon (CVE-2020-1472) on Domain Controllers

Zerologon (CVE-2020-1472) is a critical Netlogon flaw that lets an unauthenticated attacker on the network impersonate any computer to a domain controller and take over the domain. Fix it by installing a February 2021 or later update on every domain controller, setting FullSecureChannelProtection to 1, and leaving the vulnerable-connection allow list empty.

What the scanner is actually detecting

Two Tenable products report this issue, and they look at different things:

The Nessus plugin synopsis reads: “The Netlogon service on the remote host is vulnerable to the zerologon vulnerability.” The plugin needs the DC’s RPC endpoint mapper to be reachable, and Tenable states it only runs if Only use credentials provided by the user is disabled in the scan policy, so a clean result from a policy with that option enabled proves nothing.

The underlying bug is in how domain controllers handle the Netlogon Remote Protocol (MS-NRPC). Microsoft’s fix enforces secure RPC on the Netlogon secure channel, and it shipped in two phases: August 11, 2020 (initial deployment) and February 9, 2021 (enforcement).

Real-world risk

The critical rating is earned. NVD scores it CVSS 10.0. The attacker needs no credentials, only network access to a domain controller. Tenable’s plugin description says the attacker can change the computer’s Active Directory password and escalate to domain admin, and Tenable lists public exploits. CISA added CVE-2020-1472 to its Known Exploited Vulnerabilities catalog on November 3, 2021 and marks its use in ransomware campaigns as “Known” (our guide to the CISA KEV catalog explains what that listing means for your patch deadlines).

The honest context: domain controllers are rarely reachable from the internet, so Zerologon is mostly a way to turn any internal foothold, such as one phished workstation, into full domain control. And because the February 2021 updates made enforcement mandatory, a Windows DC flagged in 2026 almost always means one of three things: it has missed years of updates, it is Windows Server 2008 R2 without Extended Security Updates, or it is a Samba DC with an insecure setting. Separately, Microsoft warns that any machine account placed on the allow-list policy can have its identity taken over by an attacker.

How to confirm it on the host

List every domain controller first. Microsoft says all DCs must be updated, including read-only domain controllers (RODCs):

Get-ADDomainController -Filter * |
  Select-Object HostName, OperatingSystem, IsReadOnly

On each DC, check the build and recent updates from an elevated PowerShell prompt:

Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersion' |
  Select-Object ProductName, CurrentBuild, UBR

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 10 HotFixID, InstalledOn

Compare against the February 9, 2021 updates, which Microsoft’s release notes say enable enforcement mode. Any later cumulative update or Monthly Rollup also contains the change:

Then check the registry value and the Netlogon events in the System log:

reg query "HKLMSYSTEMCurrentControlSetServicesNetlogonParameters" /v FullSecureChannelProtection

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5827,5828,5829,5830,5831} -MaxEvents 50 |
  Select-Object TimeCreated, Id, Message

Get-WinEvent returns an error if no matching events exist, which is a good result here. For an independent check, Tenable’s plugin page links Secura’s test script. According to its README it attempts the authentication bypass, exits without performing any Netlogon operations, and gives up after 2000 pairs of RPC calls on a patched DC. It takes the DC’s NetBIOS name and IP address. Run it only against DCs you are authorized to test:

./zerologon_tester.py EXAMPLE-DC 192.0.2.10

On a Samba domain controller, check the effective setting and version:

testparm -sv 2>/dev/null | grep -i 'server schannel'
smbd --version

How to fix it

Windows domain controllers

1. Install the latest cumulative update or Monthly Rollup on every DC, including RODCs, and reboot one DC at a time. The February 2021 packages for 2019 and 2016 are expired, so install the current update instead. Monthly Rollups are cumulative; Security-only packages are not, which makes the latest Monthly Rollup the simplest reliable path on 2012 and 2012 R2. Microsoft notes that Windows Server 2008 R2 SP1 needs an ESU license to install any update that addresses this issue.

2. Set the enforcement registry value. Microsoft says DCs with February 2021 or later updates enforce regardless of this key, but Tenable Identity Exposure checks for it, and setting it to 1 matches the enforced behavior. No reboot is required.

   reg add "HKLMSYSTEMCurrentControlSetServicesNetlogonParameters" /v FullSecureChannelProtection /t REG_DWORD /d 1 /f

   To push it to all DCs, create a Group Policy Preferences registry item under Computer Configuration > Preferences > Windows Settings > Registry in a GPO linked to the Domain Controllers OU.

3. Empty the allow list. Open Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: Allow vulnerable Netlogon secure channel connections in the GPOs that apply to your DCs. By default the policy is not configured, which is the secure state. Remove any accounts or groups granted “Allow”; Microsoft specifically says to remove the Administrator group or any group not created for this policy.
4. Fix Windows devices that log event 5827. Microsoft says fully updated, supported Windows should not make vulnerable connections. Confirm the device is supported and patched, and that Domain member: Digitally encrypt or sign secure channel data (always) is Enabled.
5. Handle third-party devices. Any non-Windows device with a machine account in AD must use secure RPC. Get a vendor update, or retire the device. If you must keep one running temporarily, add it to a security group created only for the allow-list policy, as Microsoft recommends, and track it as a documented exception.

Samba domain controllers

The Samba advisory says Samba 4.8 and later insist on a secure channel by default, equivalent to server schannel = yes, and are vulnerable only if the setting is no or auto. Older releases are vulnerable unless it is set to yes. Upgrade to a supported Samba release, then set this in the [global] section of smb.conf on every DC and restart Samba:

[global]
    server schannel = yes

The advisory documents a per-account exception for a device that cannot comply, such as server require schannel:triceratops$ = no. Treat it like the Windows allow list: temporary and documented.

How to verify the fix and rescan

1. Rerun the build and Get-HotFix checks after the reboot and confirm each DC is at or above the build or KB in the table.
2. Confirm reg query returns 0x1 for FullSecureChannelProtection on every DC.
3. Run gpupdate /force and gpresult /h on a DC (the commands Microsoft suggests) and confirm the allow-list policy is not granting access to anything.
4. Review Netlogon events: 5827 and 5828 identify denied devices you still need to fix; 5830 and 5831 mean an allow-listed account is actively using a vulnerable channel. Netlogon event 5829 should not appear at all on a DC with February 2021 or later updates, because Microsoft removed that logging when enforcement began.
5. Rescan with a Nessus policy that has Only use credentials provided by the user disabled and can reach the DC’s RPC endpoint mapper, so plugin 140657 actually runs.

What can break and how to roll back

Microsoft says fully updated, supported Windows devices should not be using vulnerable connections. The risk is third-party devices and non-Windows DCs that still use vulnerable Netlogon connections: Microsoft warns they will be denied, which can disrupt production services. Watch for event 5827 (machine accounts) and 5828 (trust accounts) after patching.

There is no real rollback for enforcement. Microsoft states that from February 2021 you cannot disable enforcement mode, and deleting the FullSecureChannelProtection value does not turn it off; it only brings back the Tenable Identity Exposure finding. Uninstalling the cumulative update would reopen this CVE along with every other fix in it. The only supported relief valve is the allow-list policy with a dedicated security group, and Microsoft warns that an attacker can take over the machine identity of any account on it. Remove each account as soon as its vendor fix is installed.

Common false positive reasons

• Registry-only finding on a patched DC. Tenable Identity Exposure flags a missing FullSecureChannelProtection key even when the DC enforces through its updates. Microsoft says enforcement no longer depends on the key, so this reflects configuration hygiene rather than exploitability; setting the key clears the check.
• Stale results. The DC was patched after the scan that raised the finding, or the update is installed but the reboot is pending. Reboot, then rescan.

Because plugin 140657 performs an active test, a Nessus hit should be treated as real until the build, event log and rescan say otherwise.

FAQ

Is FullSecureChannelProtection still needed after February 2021?

Microsoft says no: with February 2021 or later updates, enforcement is always on. Set it to 1 anyway to satisfy configuration checks such as Tenable Identity Exposure.

Do workstations and member servers need the fix?

Microsoft says they should be updated but are not specifically vulnerable to CVE-2020-1472. The protection is enforced by the domain controllers.

Is Windows Server 2008 SP2 vulnerable?

Microsoft says no, because it does not use AES for secure RPC. It is long out of support, so replace it anyway.

Can I turn enforcement off if a device breaks?

No. Use the allow-list policy with a dedicated security group as a short-term exception while the vendor fixes the device.

Tracking this finding across many hosts

Zerologon has to be closed on every domain controller in the forest, and allow-list exceptions have to be removed as vendors ship fixes. If you use SITEY, you can upload the .nessus export to track plugin 140657 per DC, have AI draft a host-specific update or registry script that runs only after human approval through SITEY agents on Windows endpoints, and use per-finding Nessus retest to confirm closure.

Sources

• Tenable: Nessus plugin 140657, Microsoft Netlogon Elevation of Privilege (Zerologon) (Remote)
• Microsoft: How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472
• Tenable Identity Exposure: Unsecured Configuration of Netlogon Protocol
• Samba: CVE-2020-1472 security advisory
• NVD: CVE-2020-1472