FortiEDR automates the protection against advanced threats, pre and post-execution, with real time orchestrated incident response functionality.
Article Id 200549

Zerologon (CVE-2020-1472) continues to draw attention even a year after its initial disclosure in Sep 2020. Zerologon is currently one of the most extensively exploited post-exploitation Windows vulnerabilities, having been adopted by several ransomware groups and advanced persistent threat actors with varying goals and capabilities. FortiGuard Responder Managed Detection and Response (MDR) team has observed a recent increase in Zerologon detections within FortiEDR protected platforms. This article will break down key elements of the Zerologon vulnerability, how threat actors exploit it, and how FortiEDR detects and protects against it.


What is Zerologon:

CVE-2020-1472, also known as "Zerologon," is a critical elevation of privilege vulnerability in Microsoft's Netlogon Remote Protocol (MS-NRPC). Netlogon is a Local Security Authority service that handles authenticating users into the domain that, when exploited, allows a hacker to impersonate any computer, including the root domain controller.


Netlogon Vulnerability:

During the Netlogon authentication, the client and server each choose an 8-byte random challenge and publicly exchange the values. This random challenge, along with the domain password, is used to generate a shared AES session key. After establishing the shared session key, the client demonstrates that it has generated the same value by encrypting the eight-byte challenge created at the beginning of the process using the new AES session key and sending the result to the server. 


Netlogon uses a custom variant of AES-CFB8 (8-bit cipher feedback) that encrypts one byte at a time rather than the standard version, which encrypts 16 bytes at a time. The Zerologon vulnerability is caused by an insecure implementation of the custom AES-CFB8 encryption variant that forms the basis of the Netlogon protocol which enables a ‘brute force’ type attack. The initialization vector (IV), a one-time value used in the AES-CFB8 encryption, should always be unique and random but hardcoded to a value of 16 zero bytes. This 16-byte IV is encrypted with the previously generated AES key and then XOR'ed with the plain text to create ciphertext. In this implementation, if the first byte of the AES encryption output is 0, then XORing it with the plain text, which is all zeros, produces an all zeros ciphertext. The probability of the first byte of the AES encryption output being zero is 1/256. This problem in the Netlogon implementation is that it allows an unauthenticated attacker to authenticate without the session key (which requires knowledge of the domain password) by creating a challenge of 8-byte zeros and repeatedly authenticating until it creates a ciphertext of all zeros.


In the following exploit POC, the initial authentication request with an all-zero plain text challenge is shared with the Netlogon authentication server using the NetrServerReqChallenge call. The attacker then repeatedly attempts to authenticate with an all-zero ciphertext using the NetrServerAuthenticate3 call.



 Figure 1Exploit POC code that attempts to authenticate with all-zero ciphertext.


Since an all-zero ciphertext will decrypt to an all-zero plaintext using the shared AES session key, an attacker can use the same logic to reset the password using the NetrServerPasswordSet2 call. A cleartext new password for the client is encrypted with the same AES session key. This password consists of 516 bytes, and the last four indicate the password length. By providing 516 zeroes, the server decrypts it to 516 zeros, leading to an empty password.



Figure 2. Exploit POC code that resets the domain password to an empty password.


Changing the password this way only updates it in the AD. Thus, this vulnerability allows an attacker on the local network to move laterally and impersonate any computer, including the root domain controller.


How FortiEDR mitigates against this threat

An attacker who has gained an initial foothold into the victim network, attempting to exploit the Zerologon vulnerability in the below event. The source IP differing from the domain controller is a red flag. The FortiEDR real-time protection detects and blocks the attempt to elevate privileges from user to domain admin.



Figure 3. View of FortiEDR console showing ‘Privilege Escalation Exploit Detected’ event related to Zerologon exploit.


FortiEDR’s Exfiltration Prevention policy detected the ‘Privilege Escalation Exploit’. Such exploits are normally used by attackers to gain full control of a domain controller as part of an exploit chain, or lateral movement. This, in turn, can result in credential stealing.


Exploitation of Zerologon

Since its discovery last year, the Zerologon (CVE-2020-1472) vulnerability has gotten a lot of attention. The following is a list of campaigns that took advantage of the Zerologon vulnerability.



Figure 4. Zerologon has been exploited by threat actors in a number of campaigns over the last year.


In the FortiEDR platform, the detection of Zerologon has increased in recent months. The graph below shows the trend of Zerologon events over the last year.



Figure 5. Trend Chart for Zerologon detection within the FortiEDR platform.



 We strongly recommend that customers install the February updates to be fully protected from the zerologon vulnerability. This update will enable enforcement mode on all supported Windows Domain Controllers and will block vulnerable connections from non-compliant devices unless manually added to a security group referenced in the "Domain controller: Allow vulnerable Netlogon secure channel connections" group policy.