In this article

Zerologon Vulnerability: Analysis and Detection Tools

September 22, 2020
Last Updated: January 15, 2024
Share on:

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.

This is part of an extensive series of guides about Network Attacks

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.
  • FullSecureChannelProtection registry key to enable DC enforcement mode for all machine accounts (enforcement phase will update DCs to DC enforcement mode).
  • 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.

Get our Complete Guide

How to Build a Security Framework

  • Key frameworks for IT security programs
  • Managing risk associated with security controls
  • Addressing cyber insurance, cloud security, zero trust


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:

  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.


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.

Cipher-block chaining (CBC) mode encryption | Download Scientific Diagram


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 :

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


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 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.

A screenshot of a social media post Description automatically generatedProcess Monitor network capture during execution of 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.

Get our Complete Guide

How to Build a Security Framework

  • Key frameworks for IT security programs
  • Managing risk associated with security controls
  • Addressing cyber insurance, cloud security, zero trust


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)


  1. Download, and save on Domain Controller
  2. Left click > Extract All on the Domain Controller to C:\Cynet.ZerologonDetector\
    A screenshot of a cell phone Description automatically generated
  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
      A screenshot of a cell phone Description automatically generated
    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.

How would you rate this article?

In this article

Let’s get started!

Ready to extend visibility, threat detection and response?

Get a Demo

Search results for: