Zerologon Vulnerability: Analysis and Detection Tools
Written by: Igor Kovalenko & Itamar Meydoni
What is Zerologon
In September 2020 Secura published an article disclosing a vulnerability in Windows Server (all known versions) Netlogon Remote Protocol. This vulnerability is known as CVE-2020-1472 or more commonly, Zerologon.
Zerologon poses a major threat to organizations as it targets the Domain Controller (DC).
Attackers target domain controllers in order to gain access to the domain admin account and ultimately to control the hosts and servers connected to the data center. This enables threat actors to gain access to the entire compromised environment.
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 incorrect use of an AES mode of operation 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 consists of sending a large amount of authentication requests to a Domain Controller via NetLogon. These contain a client request which contains only 0’s for the credentials and results in a successful logon when a good key is chosen randomly by the server. A good key is chosen on average 1 in 256 times.
The exploit includes the utilization of a newly acquired connection in order to reset the password to a blank value, and then perform privilege escalation to Domain Admin.
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.
Admin privileges provides a powerful weapon to attacker who aims to harm an environment. This allows the attacker to access any asset in the network and then exfiltrate precious internal data, steal banking credentials and even compromise intellectual property.
Ransomware attacks can also be easily carried out once these privileges are gained making this attack potentially devastating to an organization.
Microsoft has already issued a security patch update which was released on “Patch Tuesday” of August 2020. This update is the first of a two-part update (part two is expected to be released on February 2nd 2021) and provides the following changes to the NetLogon Protocol:
Enforces secure RPC usage for machine accounts on Windows based devices.
Enforces secure RPC usage for trust accounts.
Enforces secure RPC usage for all Windows and non-Windows DCs.
Includes a new group policy to allow non-compliant device accounts (those that use vulnerable Netlogon secure channel connections). Even when DCs are running in enforcement mode or after the enforcement phase starts, allowed devices will not be refused connection.
Includes new events when accounts are denied or would be denied in the DC enforcement mode (and will continue in the enforcement phase). The specific event IDs are explained later in this article.
We strongly recommend to keep your environment updated with the latest security patches.
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)
One point of difference that NetLogon has from other RPC protocols, is its authentication scheme:
A Client Challenge is sent from the Client
A Server Challenge is sent from the server
A Session key is created from session secret and challenges
Both client and server utilize the previously made session key to and the Challenges to create client/server credentials
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.
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.
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.
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 :
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
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.
Due to the magnitude and potential impact of this vulnerability, Cynet decided to release two detection mechanisms for the wide community that provide visibility for exploits for Zerologon vulnerability.
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)