Zerologon Vulnerability: Analysis and Detection Tools

NETLOGON PROTOCOL

According to Microsoft, “The Netlogon Remote Protocol is a remote procedure call (RPC) interface 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 between the members of a domain and 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.” (MSDN)

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/19896c1c-7e64-419b-a759-a9dc5662a780

One point of difference that NetLogon has from other RPC protocols, is its authentication scheme:

1. A Client Challenge is sent from the Client
2. A Server Challenge is sent from the server
3. A Session key is created from session secret and challenges
4. Both client and server utilize the previously made session key to and the Challenges to create client/server credentials
5. both credentials together with the session key will be used to authenticate the user

The main issue this scheme has is because of the way Client and server Credentials are computed a basic flow in a primitive cryptography type is implemented wrongly.

AES-CFB8 ENCRYPTION

One of the encrypting components of the ComputeNetlogonCredential Function is AES-CFB8 Encryption.

This encryption has been implemented in an unsecure way, and as such, creating this vulnerability.

AES-CFB8 is a controlled mode of AES Encryption (AES receives 16 bytes and returns a value of the same length) which is meant to receive 8 bytes.

This Component receives an 8-byte value, attaches it to 16 random bytes called “Initialization Vector”.

AES Encryption is then applied to the said vector and the first byte of the value of the result is then used to XOR the first byte of the 8-byte expression on which the protocol is used, and repeats those steps until the phrase is all encoded.

THE PROBLEM

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.

The attacker may use the NetrServerPasswordSet2 call in such situation, since it receives a password to set and an encryption key which is derived from the current session key (which is an all zeros CFB8). The structure of the password Netlogon expects is 516 bytes, the last four bytes representing the length of the password. By overriding those bytes with more zeroes, the password is then set to be empty, and by that blank, providing Domain privileges to the attacker.

The steps to use this exploitation have been implemented in the following PoC :

https://github.com/dirkjanm/CVE-2020-1472/blob/master/cve-2020-1472-exploit.py

In order to check if your domain is vulnerable to this CVE, please check the following repository:

https://github.com/SecuraBV/CVE-2020-1472

ARTIFACTS

The exploits leave behind various artifacts which can be used for detection. The most documented artifact is Windows Event ID 4742 “A computer account was changed”, often combined with Windows Event ID 4672 “Special privileges assigned to new logon”.

The problem with the ID 4742 artifact is that even though it is uncommon, it does happen periodically, and can therefore lead to false positive detections. Furthermore, there is new exploit for Zerologon, which does not require resetting any computer password. The problem with ID 4672 is that it is not required for the original exploit and is often attributed to further abuse of new privileges, like DC Sync, for example.

Digging deeper, we found two more useful artifacts that appear from exploiting the Zerologon vulnerability, even if not used to reset the Domain Controller computer password. First is a specific memory pattern in lsass.exe memory, which appears when lsass.exe processes the Zerologon authentication packets.

lsass.exe memory dump after cve-2020-1472-exploit.py by dirkjanm

The second is an abnormal spike in traffic between lsass.exe and the attacker as part of the key guessing step of the exploit which resembles brute force tries.

Process Monitor network capture during execution of cve-2020-1472-exploit.py by dirkjanm exploit

DETECTION

Cynet 360 already detects and alerts its customers when this vulnerability is exploited in your environment. However, we highly recommend that you apply the latest security updates.

First is a YARA rule which can be used to scan memory dumps of lsass.exe. The rule will alert upon detection of Mimikatz or other Zerologon exploits.

Second is an executable file, Cynet.ZerologonDetector.exe which detects spikes in network traffic of lsass.exe from a given IP. The YARA rule can detect attacks that occurred prior to its deployment and provide an indication upon detection of a Zerologon exploitation.

NETWORK TRAFFIC SPIKE DETECTION

Successful detection of Mimikatz lsadump::zerologon attack

Cynet’s Zerologon exploit detector locally monitors real-time network traffic metadata flowing to lsass.exe. If it detects a spike in traffic, it issues an alert. Alerts can be sent to:

• The screen that’ running the tool
• Registry, setting a key in registry with attacker’s IP as data
• Log File, Cynet.ZerologonAttacksDetected.txt near the extracted executable
• Email, using SMTP, disabled by default (requires configuration)

NETWORK TRAFFIC SPIKE DETECTOR INSTALLATION GUIDE

1. Download Cynet.ZerologonDetector.zip, and save on Domain Controller
2. Left click > Extract All on the Domain Controller to C:\Cynet.ZerologonDetector\
   
3. Configuration can be done before execution, in Cynet.ZerologonDetector.ini
4. After configuration (of SMTP, for example), you have 2 options, both should be executed as Administrator:
   1. For one-time execution, run Cynet.ZerologonDetector.exe
      
   2. To execute now and on each startup, run _Install AutoStart.bat
      
      
   3. At any time you can uninstall using _Uninstall AutoStart.bat

For transparency, sources are also provided for auditing where needed. This tool is not intrusive and is based on ETW from Microsoft.