Zerologon: From Zero to Hero – Part 1

What is Zerologon?

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.

Timeline

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.

Microsoft: Plan and Changes

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.

Phase 1 – Deployment

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:

• Enforcement of secure RPC usage for machine accounts on Windows-based devices, trust accounts, and all Windows and non-Windows DCs
• A new group policy, ‘Domain controller: Allow vulnerable Netlogon secure channel connections’
• The new FullSecureChannelProtection registry key
• New events to monitor around NetLogon connections

Let’s dive deeper into a few of those.

New Group Policy

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.

New Registry Setting

The FullSecureChannelProtection setting(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\FullSecureChannelProtection) has two options:

• 0 – the default value in this phase, this configuration allows for vulnerable Netlogon secure channel connections from non-Windows devices.
• 1 – enforcement mode, Domain Controllers will deny all vulnerable connections unless the account is in the aforementioned group policy

New Events

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.

Event 5827 & 5828

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:

1. Not running a supported version of Windows
2. Not fully updated
3. Configured with the ‘Domain member: Digitally encrypt or sign secure channel data (always)’ policy not set to Enabled

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.

Event 5830 & 5831

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.

Event 5829

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:

1. Patching all DCs in the forest
2. Monitoring for the new events that exist so you can
   • Make sure the applications/machines making vulnerable connections are updated
   • Ensure an exception is made in the group policy setting where applications or machines cannot be updated
3. If all of the steps above are completed, you can enable the enforcement mode registry key ahead of the enforcement phase outlined below.

Phase 2 – Enforcement

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:

• Enforcing secure RPC usage for machine accounts on non-Windows based devices, unless explicitly configured in the group policy
  • This means that the FullSecureChannelProtection registry key is no longer needed
• Removal of event ID 5829 (since these events will get denied in this phase, they’ll fall under event IDs 5827 and 5828)

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.

Seeing it in Action

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 11^th patch.