The ZeroLogon vulnerability is a privilege elevation vulnerability that exists when an attacker establishes a vulnerable NetLogon secure channel connection to a Microsoft Windows Server Domain Controller, allowing the attacker to perform a NetLogon authentication bypass attack, which simply put, can enable an attacker to obtain domain admin access, and take over an organization’s domain and effectively disrupt the organization’s functionality through ransomeware payload installation, for instance.
This Zero-day vulnerability was discovered by Security firm, Secura, and Microsoft has recently confirmed that this vulnerability is actively being exploited in the wild. Secura has released a PoC code on their Github, that actually allows exploitation of this vulnerability and it’s use and deployment is quite intuitive. If the increasing discoveries of cases of exploits in the wild is any indication, organizations that are behind in their patching need to get it together, and patch up their Domain controllers immediately.
Microsoft released a patch on August 11th (Patch Tuesday) for this vulnerability, so many organizations would already have installed it, but my experience several moons ago, leading security and patch management initiatives for some of the largest companies in the world would indicate that until the formal zero-day guidance from Microsoft, most orgs. were likely behind on applying the published updates to their domain controllers which are some of their most critical tech. assets.
This article will cover some of my findings and experience implementing the published mitigating steps to address the ZeroLogon vulnerability CVE-2020-1472.
Much of the testing outlined below was done in my lab, which features a Windows Server Active Directory domain with 2 domain controllers which I use to manage some on-premises (in a server closet) workloads connected to various Microsoft Azure monitoring and management services which I use for monitoring, security, event correlation, management and process automation. I’ll outline what I’ve done with the following:
ConfigMgr (System Center Configuration Manager) – Patch Management for On-premises and Cloud Workloads. I use this to maintain normal and emergency (zero-day) patching and testing for on-premises workloads, and Azure IaaS workloads that I manage through a combination of cross-premises connectivity (S2S VPN)-enabled management and the ConfigMgr Cloud Management Gateway (CMG) cloud service.
Azure Monitor Log Analytics – Azure Monitor is the monitoring and management solution in the Microsoft cloud. It is comprised of several underlying services for various use cases, and I specifically make use of the Log Analytics service for data collection, aggregation, querying and analysis, for creating automation workflows based on that information.
Microsoft Windows Server – I run my domain controllers on Windows Server 2016 VMs, and this operating system version is susceptible to the vulnerability.
In addition to the August patches released to mitigate this Vulnerability, Microsoft has published detailed deployment guidelines for the patches and other mitigating steps that organizations can use to address this vulnerability. They are as follows:
- Deploy the updates to all Domain controllers in your Microsoft Active Directory forest. Note that the August 11th updates may have been superseded since the initial release.
- Monitor for warning events and take steps to address any of the reference events found.
- After addressing any warning events, enable full protection by deploying domain controller enforcement mode.
Note that Microsoft has indicated that updates released on February 9, 2021 will turn on the domain controller enforcement mode by default.
I reference the required security update article number for my DC operating system version, in the update guidance provided by Microsoft but upon reviewing software updates in ConfigMgr, determined that the referenced update has been superseded for September.
Finding the latest update in ConfigMgr is a breeze, and if you make uses of WSUS for patching either on its own or in combination with some other patching product, you should easily find the update article that corresponds to your domain controller OS version.
Push this out to your Domain Controllers either as part of your normal patch schedule or through your emergency patch deployment. The update is visible in Software Center as seen below.
and once installed. The next step is to monitor for warning events. I wasn’t really expecting to find any events indicating that a vulnerable connection was attempted or allowed, and my findings bore this out. Some quick PowerShell queries confirmed this.
But importantly, I sought to monitor my network for these events for a couple of days before drawing any conclusions and this is where Azure Monitor comes in handy. A quick log query shows on-premises workloads that I’ve configured as connected sources to my Azure Monitor Log Analytics workspace.
Windows Event logs are a simple data source that you can connect to your Azure Monitor Log Analytics workspace, and that’s what I sought to use here. All collected event data is indexed in Log Analytics repos, and assigned a tag of type ‘Event’ which you can reference in your search queries. So to search your domain controller event logs for relevant event IDs 5827 and 5828 as outlined in the linked articles, the following Log query will return any events on your domain controllers event log
Event |where EventID == 5827 or EventID == 5828
There’s nothing to show in my case, but as you monitor for these events you can create an alert rule and integrate this monitoring into your existing alerting workflow, to receive an email notification or tie into a webhook to perform some automated function.
Once you’ve sufficiently monitored for warning events, and acted on any identified events, as outlined above and in the linked detailed guidance, you can move on to enabling full protection by deploying DC enforcement mode. DC enforcement mode is when all NetLogon connections are either required to use secure RPC thereby preventing the NetLogon authentication bypass made possible by this exploit. To do this before the February 9, 2021 update timeline set by Microsoft, you will need update the value data for a registry subkey that enforces the use of secure RPC.
To do this, change the value data of the following registry subkey to true or 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
The default value is false or 0, as seen when you run the following PowerShell command:
(Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters).FullSecureChannelProtection
You can make this change using PowerShell as follows:
Set-itemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters -Name "FullSecureChannelProtection" -Type Dword -Value "1"
Latest posts by Chiyo Odika (see all)
- Replicate Proximity Placement Group workloads in Azure - January 13, 2021
- Azure NetApp Files (ANF) – Deploy with JSON - October 9, 2020
- Addressing Critical ZeroLogon Vulnerability CVE-2020-1472 - September 26, 2020