In August 2020, Microsoft released an update to fix a critical Windows Server vulnerability in Active Directory — CVE-2020-1472 (more known as Zerologon) . This update was successfully installed on all domain controllers 4 months ago. However, not all Windows admins know that the installation of the update on DCs is not quite the end of the story. In this post, we’ll talk about Zerologon vulnerability, how to protect AD domain controllers from it, why another Zerologon update will be released in February 2021 and what a Windows Server administrator should do with all this.
ZeroLogon: Windows Netlogon Vulnerability CVE-2020-1472
The critical vulnerability CVE-2020-1472 in Active Directory in all Windows Server versions (2008 R2, 2012, 2012r2, 2016, 2019) allows a non-authenticated user to get domain administrator privileges remotely. Due to a bug in the AES-CFB8 encryption protocol implementation in Netlogon Remote Protocol (MS-NRPC), an attacker having access to a domain controller over the network can escalate privileges and change the domain controller account password in AD. Then an attacker can authenticate on a DC with the SYSTEM privileges and get the full control over the Active Directory (reset domain administrator passwords or do any other things in AD).
Netlogon protocol is used to authenticate users and computers in AD domain networks. Netlogon is also used to remotely update computer account passwords in the Active Directory domain.
To implement the Zerologon vulnerability, the attacker needs to establish a connection over Netlogon (the following ports are used: RPC locator TCP/135, RPC dynamic port range and SMB protocol over TCP/445) using the specific sequence starting with zeroes. The Netlogon vulnerability allows you to impersonate the legitimate domain computer, and you can change the DC account password after escalating your privileges.
Maximum CVSS rating (10 of 10 points) was given to the vulnerability.
All Windows Server versions are affected:
- Windows Server 2019, Windows Server 2016;
- Windows Server 2004, 1909, 1903 ;
- Windows Server 2012 R2/2012;
- Windows Server 2008 R2 SP 1.
At the moment, there are several working Zerologon public exploits (also a zerologon module was added to mimikatz).
Do not test zerologon exploits in your network, since if you reset your DC password to an empty one, you may damage your AD infrastructure.
There is a Python script to test your DCs for the zerologon vulnerability: https://github.com/SecuraBV/CVE-2020-1472.
Windows Server Updates against Zerologon
Because Microsoft no longer supports Windows Server 2008 R2, there is no publicly available bugfix for this OS version. However, if you purchased an Extended Security Updates (ESU) 1-year subscription, you can download and install the 4571729 update for WS2008R2.
There is an unofficial Zerologon patch for Windows Server 2008 R2 — 0patch (https://blog.0patch.com/2020/09/micropatch-for-zerologon-perfect.html). You can use it at your risk.
Other Windows Server versions have updates available in Windows Update, WSUS or you can manually download updates from Microsoft Update Catalog and install MSU update file manually.
- Windows Server 2019 (KB4565349), Windows Server 2016 (KB571694);
- Windows Server 2004 (4566782), 1909 (KB4565351), 1903 (KB4565351);
- Windows Server 2012 R2 (KB4571723), Windows Server 2012 (KB4571702).
Protecting Active Directory Domain Controllers from ZeroLogon
The updates fixing Zerologon vulnerability were released in August 2020. To protect your Active Directory, you must install the August cumulative update (or a later one) for your Windows Server version on all domain controllers.
Actually, the patch is a temporary fix.
Microsoft is going to fix Zerologon in two stages that allow to provide smooth transition to secure Remote Procedure Call (RPC) in Netlogon:
- The first (deployment) phase. The August patch is an emergency fix to protect domain controllers from the known attack scenario. But this update doesn’t completely fix the vulnerability (other scenarios to attack DCs through Netlogon are also possible). Legacy systems that don’t support the new secure version of RPC protocol for Netlogon can still connect to a domain controller.
- The second (enforcement) phase. The next update will be released on February 9, 2021. After you install this update, all domain controllers will reject connections that are using the old Netlogon protocol (however, you may set exclusions for legacy devices using GPO, we will show how to do it below).
After installing the first patch, you can find device connection events that use the insecure version of Netlogon RPC in the domain controller logs. Also, if you don’t have legacy devices in your network, you can disable support for the old Netlogon RPC version on your domain controllers, without waiting 2021 (using the FullSecureChannelProtection registry parameter).
After you install a security update, the events of connecting computers using a vulnerable Netlogon version will be registered in the domain controller logs. You should pay attention to the following EventIDs from NETLOGON in Event Viewer -> Windows Logs -> System:
- EventID 5827 and 5828 — The Netlogon service denied a vulnerable Netlogon secure channel connection from a computer account. This message means that the connection of this computer using a vulnerable Netlogon version is denied (it is a reference message till February 2021, no real actions are taken to block the connection). You can save all events to a CSV file and analyze the names of the devices trying to connect to a DC. Use the following PowerShell command:
Get-EventLog -LogName System -InstanceId 5827 -Source NETLOGON|Select-Object message| Export-Csv C:\Temp\5827.csv -Encoding utf8
- EventID 5829 — a connection using a vulnerable Netlogon version is allowed;
- EventID 583, 5831 — a connection using a vulnerable Netlogon version is allowed because the device is added to the policy “Domain controller: Allow vulnerable Netlogon secure channel connections”.
Starting February 2021, you must install the latest security updates on all detected devices. In Windows, it is enough to install the latest cumulative update. Ask your device/software vendors (OEM) for updates for all other devices that use the Netlogon Remote Protocol to connect to Active Directory.
A special security update will be released in February that will put domain controllers in a mode where all connecting devices must use the secure version of the Netlogon protocol. At the same time, the devices specified in the Event 5829 (which don’t support the secure Netlogon version) won’t be able to connect domain. You will have to add these devices to GPO exclusions manually.
It means that no longer supported Windows versions (Windows XP/ Windows Server 2003/Vista/2008) won’t able to work normally in your AD domain.
Group Policies for Zerologon
If there are no devices left on your network that support only the insecure Netlogon version, you can create a separate GPO to force DCs to use a secure Netlogon version before February 9, 2021 (when the second stage update will be released, which denies connections using an unsafe Netlogon version). To do it, deploy the following registry key using GPO to all your DCs:
- Registry key:
- Parameter type:
- Parameter name:
- 1 — enables the enforcement mode. DC will deny connections via a vulnerable version of Netlogon. The parameter has no effect for accounts added to the policy “Domain controller: Allow vulnerable Netlogon secure channel connections” (see below);
- 0 – allows a DC to accept connections using a vulnerable Netlogon version from non-Windows devices (this option will be deprecated in the enforcement phase release).
How to Allow Non-Windows Devices to Connect to DC Using Netlogon?
A special parameter that allows certain devices/accounts to use a vulnerable Netlogon version to connect to a DC appeared in the GPO. The policy is called Domain controller: Allow vulnerable Netlogon secure channel connections and you can find it under Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
You must create a security group in AD and add the accounts/devices to it that need to be allowed to establish a secure channel with the domain controller using legacy Netlogon RPC.
Enable the policy for the DC (on the Default Domain Controller policy level), click Define Security and specify the group that is allowed to use an insecure Netlogon protocol (Create Vulnerable Connection -> Allow).
By checking the Deny option, you can deny using the insecure Netlogon RPC for the specific devices.