Zerologon: Look Ma! No password!

Written by Jean-Camille LOISEAU & Anup Tripathi | Published 13 August 2021

Computers and servers are protected by a username & password in order to control and restrict their access. This has been for decades now the go-to default security mechanism for all systems from the desktop PC to the mighty Domain Controller.

This lock mechanism is a prime target for attack as controlling is controlling the kingdom.

In September 2020, the security community discovered that the entire password gate can simply vanish in within seconds. No signals, No alerts, any system just broken in, within mere moments due to a flaw in the lock mechanism.

Zerologon (Mitre: T1210) is the name associated with the vulnerability discovered and presented in 2020 by Dutch researcher Tom Tervoort. Since August 2020 Microsoft has released multiple patches to help remediate the vulnerability identified worldwide as CVE-2020-1472 in catalog of publicly disclosed cybersecurity vulnerabilities.

What is Zerologon?

The term Zerologon first and foremost refers to a vulnerability in the Netlogon Remote Protocol (MS-NRPC and hereafter Netlogon) and its implementation and design by Microsoft teams when it was originally setup.

Zerologon describes specifically the way the flaws in the encryption process of the NetLogon protocol can be abused to bypass the authentication, disable signing and sealing security, and change the password of the Domain Controller all automatically within a few seconds on a non patched DC.

What is behind the Zerologon vulnerability?

Netlogon is the protocol used for user and machine authentication on domain-based networks in Windows. However, there are open source implementations of that same protocol (with the same flaw) such as SAMBA created for Linux.

Netlogon is also the protocol that enables computers to authenticate to the domain controller and update their password in the Active Directory. The key issue is when Microsoft designed that protocol, they cut corners on the encryption mechanism to make authentication faster.

Using Netlogon, a computer or server can connect to a Domain Controller (DC). For this to happen, the 2 machines must set up a secure channel with each other in order to start negotiating and exchanging information securely.

Netlogon was designed to use AES-CFB8 (8-bit cipher feedback) to encrypt the initial communication between machines and specify the Initialisation Vector (IV) that launches the encryption process

To ensure security, the encryption set up by the IV must be fully random & unpredictable. Unfortunately, AES-CFB8 configuration does not create a random number for its IV. Instead it is a fixed value of 16 bytes of zeros which neither random nor unpredictable.

It turns out that with AES-CFB8, 1 of every 256 logon handshake inevitably generates a session cipher text that comes out as a sequence of zeros. An attacker can thus "bruteforce" 256 times and eventually there will be 1 sessions "secured" by an all zero cipher that will be accepted by the DC.

Now if it would be a user account trying to brute force their way in, this would not be a problem as they would be stopped after 3 attempts. But computer accounts logon attempts aren't covered by such policy so as to ensure continued availability of systems.

What is a Zerologon attack?

In a Zerologon attack, an attacker will attempt to leverage the vulnerability instantly become Domain Admin by Subverting Netlogon Cryptography flaw in the design of AES-CFB8, Instead of taking over the victim's DC, they can also imply render it unavailable thus causing Denial Of Service (DOS).

To do that that, the attacker must be able to initiate a handshake communication with the Domain Controller. This can be done from anywhere within the network (any open port will do) or remotely if the attacker manages to penetrate a server in the DMZ for example.

For this reason, Zerologon exploitation attacks are considered insider attacks/ However, all the attacker really needs is enough of a foothold anywhere in the network to establish a session over transmission control protocol (TCP) session with a DC.

Once they do, they use a script that will bombard the DC with spoofed handshake attempts where the challenge is just made of 8-bytes of zeros until the inevitable happen due to the flaw. The DC will eventually accept it bypassing authentication.

From there, attacker can further abuse Netlogon's flaws and feature to eventually reset the password of the domain controller and take it over thus opening avenue for further , even more damaging, attacks to ensue.

Why should I care about Zerologon attack?

Zerologon has been dubbed a "perfect" vulnerability for hackers & Windows security experts' nightmare. It is so easy to implement and copy that within hours of the publication of the discovery white paper by Secura, hundreds of proof of concept Zerologon implementation already appeared on GitHub: Maximum impact - lowest barrier to entry.

This flaws affects all Windows Domain Controller and any system that also use older implementation of Samba protocol which was copied after MS-NRPC protocol. Unless fully patched, all an attacker needs to execute a ZeroLogon attack is tiny foothold on the network either physically or though remote compromise and within 2-3 seconds of brute force, they will have the ability to gain full unabridged access to a victim's domain controller.

With such access they can then do whatever they want such as steal password data, access accounts such as the Kerberos KRBTGT that handles, encrypts and signs every single Kerberos ticket requests for your domain. The attacker now has the ability to leverage golden ticket attack. In other words, if they're not the captain yet, they're to about be.

This vulnerability is as serious and widespread as it gets. And ensuring it is patched should be the top priority of ALL organization.

How does a Zerologon attack unfold?

It's important to repeat that for the Zerologon attack to occur, the attacker already entered your network, performed recon to understand its structure and the name of the domain controller and the victim's organization has not patched its systems to prevent the exploitation of the vulnerability.

1. The attacker bypasses the authentication call:

Using NetLogon's "NetrServerAuthenticate3" function, the attacker edits the ClientCredential parameter to state "00000000" and send this as challenge during the handshake with the DC. It will fail once, twice, etc. but within 256 attempts it will eventually succeed and the DC will accept it, bypassing authentication.

The DC now believes that this communication channel is with a specific authenticated user despite not knowing the password of said user.

2. The attacker disables RPC signing and sealing:

As the attacker still doesn't know the actual encryption key for the session with the DC, only that it was "encrypted" as "00000000". Fortunately for the attacker, the Netlogon protocol also enables to turn off the transport encryption "feature" by simply not setting a flag in the header of the NetrServerAuthenticate3 call.

Now, all communication is authenticated AND in plain text with the user name and password clearly visible AND editable in the message.

3. The attacker changes the password for the spoofed account

the attackers the Netlogon password change functionality and uses the NetServerPasswordSet2 to issue the target server a new password that only they know or simply they leave the frame blank thus removing the password altogether on the system.

Because all these activities are performed by misusing valid protocol, they simply raise no alert, no alarm using scripted exploit tools the entire set of 3 steps process can be achieved within a few seconds, leaving plenty of time to the attacker to then perform additional damage such as initiating Denial of Service attacks from inside the domain itself.

How do I prevent a Zerologon attack?

Zerologon is challenging to prevent from as is based on the abuse of system features that are difficult to mitigate with preventive controls. The very best and really only defense against ZeroLogon is patching all affected systems. Prevention is simply impossible on unpatched systems,

If a system cannot be patched, it must be fully isolated (think air gap) from the rest of the network and scheduled for retirement and replacement by patchable system as soon as possible.

Remember that not only Windows machines are affected. Because Netlogon is such an old and widespread protocol, it has been used as the basis for SAMBA on Unix and the open source version took with it the same flaws of the original.

In addition to applying all recommended patching, It is essential to monitor and maintain discipline of privileged accounts as certain ZeroLogon exploits are known to leverage non-Windows computer accounts with elevated privileges (such as domain replication privileges) :

1. Follow least privilege access model and maintain an up-to-date list of all domain admin, enterprise admin accounts.

2. Set up rule to forbid the use of such accounts on any system unless it is absolutely necessary and monitor that IT staff follows it.

3. Use Privilege Account Solution (PAM) to track and monitor the use of any privileged account and implement controls for any usage of these account bypassing your PAM solution.

4. Ensure that all privileged account have complex, unique rotating passwords across all systems on the network (ideally managed within separate PAM solution safes).

5. Implement tiered administration model to separate accounts supporting administration of high-risk systems from other valuable assets like domain controllers.

How do I detect a Zerologon attack?

Pre-Requisite: It’s recommended to enable logging of below system and security events on your organizations DCs and collected on SIEM solution:

• Event ID 4724: An attempt was made to reset an accounts password

• Event ID 4742: A computer account was changed

• Event ID 5805: NetLogon Failures

• Event ID 5827*: Vulnerable Netlogon secure channel connection from a machine account is denied

• Event ID 5828*: Vulnerable Netlogon secure channel connection from a trust account is denied

• Event ID 5829*: Vulnerable Netlogon secure channel connection from a machine account is allowed

• Event ID 5830: Vulnerable Netlogon secure channel connection from a machine account is allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy

• Event ID 5831: Vulnerable Netlogon secure channel connection from a trust account is allowed by "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy

*These are only present if August 11th Microsoft Updates patch is installed on the DC.

There are several ways to detect ZeroLogon attack and the below Use Case/detection logic demonstrates a reliable way to detect it using a couple of strong indicators of compromise:

Step 1: Create UC/Rule with below conditions:

Event ID: 5805

AND

Event ID: 4724

OR

(Event ID: 4742 AND SubjectLogonId: "0x3e6" NOT PasswordLastSet: "-")

Step 2: The SourceHostName in all the above 3 events should be same and it should match with one of your organization’s DC hostname

Additionally, monitor event IDs 5827 and 5828 which are triggered when vulnerable Netlogon connections are denied, and event IDs 5830 and 5831 triggered when vulnerable Netlogon connections are allowed by the patched domain controllers via Group Policy.

Event ID 5829 will only be logged during the Initial Deployment Phase, when a vulnerable Netlogon secure channel connection from a machine account is allowed.

When DC enforcement mode is deployed, these connections will be denied and Event ID 5827 will be logged. This is why it is important to monitor for Event 5829 during Initial Deployment Phase and act prior to Enforcement phase to avoid outages.

How do I respond to a Zerologon attack alert?

Should a Zerologon alert trigger, your security team need to identify the source of attack (user machine, meeting room port, DMZ host, etc) and isolate it from the domain.

The security team must perform a thorough analysis on the source machine to uncover any other on-going attacks or malicious activities that could lead to a severe attack in future in your organization.

Related content:

• https://attack.mitre.org/techniques/T1210/

• https://nvd.nist.gov/vuln/detail/CVE-2020-1472

• https://www.secura.com/blog/zero-logon

• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/ff8f970f-3e37-40f7-bd4b-af7336e4792f

• https://www.trendmicro.com/en_hk/what-is/zerologon.html

• https://www.csoonline.com/article/3576193/what-is-zerologon-why-you-should-patch-this-critical-windows-server-flaw-now.html

• https://support.microsoft.com/en-us/topic/how-to-manage-the-changes-in-netlogon-secure-channel-connections-associated-with-cve-2020-1472-f7e8cc17-0309-1d6a-304e-5ba73cd1a11e

• https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/hijacking-a-domain-controller-with-netlogon-rpc-aka-zerologon-cve-2020-1472/

• https://www.tenable.com/blog/cve-2020-1472-zerologon-vulnerability-in-netlogon-could-allow-attackers-to-hijack-windows

• https://www.darktrace.com/en/blog/zero-logon-exploit-detected-within-24-hours-of-vulnerability-notice/

• https://medium.com/mii-cybersec/zerologon-easy-way-to-take-over-active-directory-exploitation-c4b38c63a915

• https://threadreaderapp.com/thread/1306280553281449985.html

• http://media.antarespolisportiva.org/zerologon-the-perfect-vulnerability-for-hackers-windows-security-experts-nightmare

• https://www.sprocketsecurity.com/blog/how-to-exploit-zerologon

• https://pentest-tools.com/blog/zerologon-vulnerability-chaining/

• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/ff8f970f-3e37-40f7-bd4b-af7336e4792f

• https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

• https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

• https://jorgequestforknowledge.wordpress.com/2020/10/14/6-steps-to-mitigate-the-zerologon-vulnerability/