ZeroLogon has quickly become popular and well known because of multiple proofs of concept and exploits implemented in Python, .NET, Powershell, and Mimikatz implemented a module for it. So if you are an attacker or need to test your environment then you have plenty of options. As defenders, we also have options for detection on the network. If you aren’t familiar with ZeroLogon and need a quick overview then please check out our ZeroLogon Blog.
When looking at the PoC code and corresponding network traffic, some elements standout that can be used for detection. One of the most glaring is the repeated NetrServerReqChallenge and NetrServerAuthenticate requests and responses.
Within the NetrServerAuthenticate request, you may want to create detections based on the DCE_RPC version, packet flags, and certainly the Opnum. Also, in the NetrServerAuthenticate section, the Client Credential may be visible as well as the Negotiation Options. Detection within NetrServerAuthenticate isn’t always possible as shown below. This section can and should be encrypted.
According to Secura’s report, it takes an average of 256 attempts to exploit. So looking for many NetrServerReqChallenge and NetrServerAuthenticate requests/responses and ending with a NetrServerPasswordSet request/response, can be useful for network detection. Though I have seen some reports on the attack working with much lower attempt numbers.
There is another detection mechanism that can be useful for detecting post exploit activity. If the password is changed for the domain controller itself, it creates errors within the network. According to Secura’s report, this is due to password discrepancies between active directory and registry. I noticed that once the DC’s password was modified I started getting KRB5KRB_AP_ERR_MODIFIED errors. This can be another mechanism for detection within the network, especially if the errors are coming from multiple clients.
In summary, there are two primary methods that can be used to identify the potential exploitation of Zerologon. Monitoring for a large number of NetrServerReqChallenge and NetrServerAuthenticate in a short period of time will identify attempts to force a ClientCredential to all zeros. The interval may vary depending on the network but it only takes about 3 seconds to complete the exploit. The threshold may need to be adjusted in the network to account for potential false positives or as the exploits become more mature but starting around 5-10 seconds should be safe. For more specific alerts that trigger on the full exploitation chain, you should monitor for where you see a large number of the Challenge/Authenticate which are followed by a NetrServerPasswordSet request/response.
Additionally, you can monitor for post-exploitation activity via Kerberos certificate errors that indicate that the server password has been modified.
As time goes on attacks will evolve and so will the detection mechanisms. For now, these network indicators can be a useful tool to add to your arsenal. Trustwave customers using our IDPS devices or ruleset service will find protection against exploits targeting this vulnerability.