Zerologon exploits a vulnerability in NetLogon that allows a malicious actor on your network to take over a Domain Controller (DC), and eventually your entire domain. Since this attack requires no authentication and only network access, it has been given a CVSS score of 10.0 (the highest score available). At a high level, an unauthenticated attacker is able to use NetLogon Remote Protocol to connect to a Domain Controller and change the DC password to something they know, such as an ‘empty’ password. Once they have the DC’s password, they can leverage any privileges a Domain Controller has, like DCSync-ing a domain admin’s hash or the KRBTGT account. From there, the possibilities are relatively endless.
In August 2020, Microsoft released a patch to address this vulnerability and put in place some controls that can aid in monitoring for and mitigating the Zerologon attack. I’ll get more into those changes and Microsoft’s plan later. On September 11, 2020, Secura publicly announced the vulnerability, dubbed Zerologon, in their blog and posted some initial proof of concept code to Github. Since then, some well-known security researchers have started to play around with the idea of this vulnerability and we’ve seen additions to Mimikatz, as well as modifications to the exploit that don’t rely on changing the Domain Controllers password, but rather exploiting the MS-RPRN printer bug, in the instance you mistakenly left the print spooler services running on your DC. Further modifications to this exploit to try and make it less detectable are inevitable, so patching and understanding which machines in your environment are in play is extremely important.
On the topic of patching, Microsoft’s plan is a two-part, phased rollout. This includes an initial deployment phase and an enforcement phase, which is very similar to how they’re handling the LDAP channel binding and signing changes they announced earlier this year.
The start of the deployment phase is what was already released on August 11, 2020, and will continue to develop until the enforcement phase in early 2021. In summary, the initial deployment phase includes:
Let’s dive deeper into a few of those.
The new Group Policy, ‘Domain controller: Allow vulnerable Netlogon secure channel connections’ allows you to configure specific non-compliant devices to continue making vulnerable connections even after the enforcement phase begins or you choose to turn on the FullSecureChannelProtection registry setting.
The FullSecureChannelProtection setting(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\FullSecureChannelProtection) has two options:
To aid in identifying traffic that may become problematic further down the line during the enforcement phase, new events have been created. All the events mentioned below will end up in the System event log on the Domain Controller.
These events are logged when connections are denied. The most important thing to note here is that this will most likely be a Windows device that is:
It is also possible that these machines will be non-Windows DCs. If that is the case, it is recommended to work with the device manufacturer to get an update that will allow support for secure RPC with Netlogon or, if that’s not possible, add the device accounts to the group policy mentioned above.
These events are logged when connections are allowed, but only as a result of the group policy configuration. This means that the vulnerable Netlogon connection was successfully made, but only as a direct result of the account being configured to be able to do so. It would be a good idea to keep track of these events and ensure only the machines that should be allowed to make the connections are the ones doing so within your environment.
The most important of the events, this event is logged when connections are allowed, but only because enforcement mode is not in effect. This means that if you were to enable the FullSecureChannelProtection setting or wait until February 2021, these connections would fail. The idea behind this event is that it can allow you to determine which machine accounts in your environment need to enable secure Netlogon connections, get updates to support secure Netlogon connections, or be added to the group policy as an exception because you’re unable to receive an update prior to enforcement phase coming into effect.
To recap, and potentially the most important takeaway from this blog, is that the ideal deployment phase consists of:
The enforcement phase is planned to begin on February 9, 2021. This phase is going to change some of the behaviors implemented in the deployment phase, such as:
As you can see, it is very important that during the deployment phase you either patch non-Windows devices that currently cannot make secure Netlogon connections OR they’re added to the group policy setting. If you don’t, you may experience interruptions throughout your environment where these connections begin to fail.
Now that you’re familiar with this update, Microsoft’s future plans, and what you should be doing to protect your environment, take a quick look at my next blog to see just how simple exploiting the Zerologon vulnerability was prior to the August 11th patch.
Kevin Joyce is a Senior Technical Product Manager at Stealthbits – now part of Netwrix. He is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Kevin is passionate about cyber-security and holds a Bachelor of Science degree in Digital Forensics from Bloomsburg University of Pennsylvania.
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.
Read more© 2022 Stealthbits Technologies, Inc.
Hey dude , i have a question.
In windows server 2008 R2, the servar has ESU, so can get the updates. My question is
When the server is up to date, the register key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\FullSecureChannelProtection haste to be in the regedit ? , because I update the server , but i cant see the register key is added.
The update works diferent in windows server 2008 r2 ?
Really aprecciate your answer
Thanks for the question! Unfortunately, none of the testing I did was on a Windows Server 2008 R2 machine, and I don’t have access to ESU myself so I cannot test this scenario. I’m almost certain that if the registry key doesn’t exist, it would be treated as set to 0, which is the default during the deployment phase. As long as the correct patches were applied, I would think you’re in the clear from a deployment phase perspective. If at all possible, I would suggest running the POC code against a test environment/test Domain Controller using a Windows Server 2008 R2 Domain Controller, and ensuring it prevents the vulnerable Netlogon connection being made post-ESU patch application.