Detecting the CVE-2020–1472 (Zerologon) attacks

6 min readNov 1, 2020

Zerologon Vulnerability

CVE-2020–1472 (also known as “Zerologon”) is an elevation of privilege (privilege escalation) vulnerability that exists in the Microsoft’s Netlogon Remote Protocol (MS-NRPC) and being actively exploited.

Attacker with a foothold on your internal network to essentially become Domain Admin with one click. All that is required is for a connection to the Domain Controller to be possible from the attacker’s viewpoint.

The attack utilizes flaws in an authentication protocol that validates the authenticity and identity of a domain-joined computer to the Domain Controller.

Due to the weak cryptographic algorithm in Netlogon’s authentication process it is possible to spoof the identity of any computer account (including that of the DC itself) and set an empty password for that account in the domain.

The exploitation of this vulnerability most of the time will lead to change for encrypted machine account password in Active Directory only so the local registry-backed password is out of sync with the domain’s causing a potential lockout scenario.

The attacker can address this temporary hurdle by manually restoring the value to the original from Active Directory after recovering it from the NTDS.dit file, such as by using Impacket’s secretsdump tool. There is another way of abusing Zerologon vulnerability that does not need a password reset, Spool Service and NTLM Relay.

The vulnerability was discovered by Tom Tervoort of Secura BV and was addressed by Microsoft on August 11th, 2020.

Netlogon Protocol

The Netlogon Remote Protocol is a remote procedure call (RPC) interface that is used for user and machine authentication on domain-based networks.

The Netlogon Remote Protocol RPC interface is also used to replicate the database for backup domain controllers (BDCs).

The Netlogon Remote Protocol is used to maintain domain relationships from the members of a domain to the domain controller (DC), among DCs for a domain, and between DCs across domains. This RPC interface is used to discover and manage these relationships.

The Zerologon Problem

Netlogon Remote Protocol use the AES-CFB8 Encryption. AES-CFB8 is obscure because it is not well known and not well tested. The use of AES-CFB8 within MS-NRPC has an issue with the Initialization Vector (IV) which should be a random number.

AES-CFB8 security relies on the IV to be chosen randomly. Unfortunately, in Netlogon RPC, IV is defined to be 0, as part of the ComputeNetlogonCredential check.

Once in 256 attempts on average the server will generate random key which after encryption in AES-CFB8 will generate a zero byte to XOR with.

The Call NetrServerReqChallenge in Netlogon Remote Protocol uses a NetrServerAuthenticate3 call, which receives a parameter called ClientCredential.

ClientCredential is handed to the call by the input in NetrServerReqChallenge. This value may contain any value given to it (in the form of 8 bytes). An attacker can use the value 0 (x8) and as such, if he attempts this call repeatedly, he will hit an iteration in which the AES IV is also 0 and NetrServerAuthenticate3 will succeed.

In other words, by simply sending large number of Netlogon messages in which various fields are filled with zeroes, an attacker can change the computer password of the domain controller that is stored in the Active Directory.

Impact

The entire attack is straightforward and very fast and can last up to three seconds, at most. In addition, this attack has a huge impact and have been used by ransomware groups to be spreading the ransomware to the entire environment like Ryuk ransomware. Organizations that have not already applied Microsoft’s August 11, 2020 security updates should patch CVE-2020–1472 on an emergency basis.

There are now multiple public PoC exploits available, and if the AD servers are not patched, great damage can be caused to businesses.

There are tools to check if your servers are susceptible. Tervoort and Secura released a tool on GitHub to verify that your domain controllers are patched or discover if they are vulnerable.

DETECTION

The exploits leave behind artifacts which can be used for detection, we will look for three artifacts and analyzing them.

Detecting Zerologon with Windows Event Logs

windows create several relevant events in the DCs that could help detect Zerologon. When attempting to detect a Zerologon exploit, the set of events to look for will vary depending on the attacker’s exploitation mathod.

Successful exploitation resulting in a rest of the computer account password and it will be shown in security logs with event id 4742 “A computer account was changed”, password last set change, performed by Anonymous Logon.

The event id 4742 it does happen periodically, every 30 days computer account passwords are reset automatically by Active Directory therefore it can lead to false positive detections, however it need to be combined with other artifacts, like system event id 5805 “NETLOGON”.

You will notice system event id 5805 coinciding with the same timestamp of security event id 4742, which the are together indicator of compromise.

The next step would be to look for the attacker authentication using the DC computer account. Using secretsdump from Impacket to dump hashes This will be shown in the security logs with event id 4624 “An account was successfully logged on”.

At the same time, it combined with Windows Event ID 4672 “Special privileges assigned to new logon” with the same Logon ID.

In addition, it will generate multiple security logs with event id 4662 “Directory Service Access” with computer account and the same Logon ID.

Windows security event id 4742 with system event id 5805 “NETLOGON” are already good indicators of a Zerologon exploit in the environment.

Detecting Zerologon with Netlogon debug file

The second is the netlogon debug file, it will give us signification sign for the exploit of this vulnerability. Note this log file need to be enabled, to enable Netlogon logging:

1. Open a Command Prompt window (administrative Command Prompt window for Windows Server 2008 and later versions).

2. Type the following command, and then press Enter:

Nltest /DBFlag:2080FFFF

You can find the detail on the Microsoft’s website her https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service.

when we launch the exploit again, we look at the netlogon log file her:

C:\Windows\debug\netlogon.txt.

First, we can find multiple netlogon failed attempts which indicate the brute force to the computer account.

Her we can find the same event log id that triggered in the system logs and computer account password set empty.

Detecting Zerologon with Network

The third way to detect the zerologon is an abnormal spike in traffic between lsass and svchost to the attacker as part of the key guessing step of the exploit which resembles brute force tries.

Conclusion

Since Zerologon Vulnerability have been be publication, attacker start compromised the environment and spreading their tools. Therefore, organizations should patch for CVE-2020–1472, is necessary and important to combat this potential threat. on an emergency basis.