How To Detect Zerologon Attacks

Edit (September 21, 2020): Researchers have discovered a new method to exploit the Zerologon vulnerability. This article is about to get an update soon to detect that method. Subscribe using the Join button above to get a notification when the new article is posted.

By now you have probably heard of the latest vulnerability with a logo and splash page. It's called Zerologon (CVE-2020-1472 with a CVSS Score of 10) and it comes with its own whitepaper. We think that this vulnerability actually deserves the attention and send kudos to the Secura team who discovered and reported it.

What is it?

Zerologon is a bug in Microsoft's implementation of a cryptographic protocol within its Netlogon service. Windows servers rely on the Netlogon protocol for a variety of tasks, including allowing users to log in to a network. The attack works by sending a string of zeros in a series of messages that use this protocol. An attacker with no Active Directory credentials can use the exploit to obtain domain administrative credentials, as long as they have the ability to establish TCP connections with a vulnerable domain controller.

If you can connect to a Windows Domain Controller over the network, you can become a Domain Administrator. It's as simple as that!

Recommendation

Patch it! Yup, exploit code for this vulnerability has already been published and is very simple to use. The Cybersecurity and Infrastructure Security Agency (CISA) is aware of this risk and is recommending organizations to review Microsoft’s August Security Advisory for CVE-2020-1472 and apply the necessary updates.

How To Detect A Zerologon Attack

DETECTION STEP 1: FIND THE HAYSTACK

As the Secura folks explain in their whitepaper, the first step of the Zerologon exploit (find "Exploit step 1" in the paper) is to spoof the ClientCredential field in a NetrServerAuthenticate call in a netlogon message.

"The expected average number of tries needed will be 256, which only takes about three seconds in practice."

So, doing the math, on average 256 tries also means on average 255 failures (I suck at math, correct me if I'm wrong). That amount of failures coming from one client IP should generate a considerable amount of signal. But, where do we look for that signal? Active Directory logs are usually filled with a lot of legitimate "noise", which is hard to make sense of. The netlogon logs usually exist in their own log file located at:

 %windir%\debug\netlogon.log

A typical resolved path would be:

C:\Windows\debug\netlogon.log

The Netlogon Debug log is not enabled by default, so you may have to enable it. This log is helpful for monitoring or troubleshooting authentication, account lockouts, and other domain communication-related issues. So you may want to enable it just for that.

Once enabled, this log will show the aforementioned NetrServerAuthenticate calls. You can open it up the log file and search for the keyword "NetrServerAuthenticate". The log event will use the format below:

<TIMESTAMP> [SESSION] [<SESSION_ID>] <DOMAIN_NAME>: NetrServerAuthenticate entered: <VICTIM_SERVER_NAME> (<CLIENT_IP>) on account <VICTIM_SERVER_MACHINE_ACCOUNT>(Negot:<NEGOTIATION_FLAGS>) 

DETECTION STEP 2: FIND THE NEEDLE IN THE AFOREMENTIONED HAYSTACK

Now, using just the technique above will yield a lot of noise. There is a lot of legitimate netlogon activity and lot of it uses NetrServerAuthenticate calls. What we're looking is something that matches the attack patterns specifically. This is where "Exploit step 2: disabling signing and sealing" comes in. As explained in the paper, the attacker has to disable RPC signing and sealing " by simply not setting a flag in the NetrServerAuthenticate3 call". The flag is reported in the <NEGOTIATION_FLAGS> field shown above and gives us one more pattern to key in on. The Zerologon vulnerability test script provided with the paper and also the full proof-of-concept exploit code posted here, here, and here

all use a flag value of "0x212fffff".

# Standard flags observed from a Windows 10 client (including AES), with only the sign/seal flag disabled. 
flags=0x212fffff

That specific flag manifests itself in the log event as the string "Negot:212fffff".

<TIMESTAMP> [SESSION] [<SESSION_ID>] <DOMAIN_NAME>: NetrServerAuthenticate entered: <VICTIM_SERVER_NAME> (<CLIENT_IP>) on account <VICTIM_SERVER_MACHINE_ACCOUNT>(Negot: 212fffff) 

Conclusion

Searching for the keywords "NetrServerAuthenticate" and "Negot: 212fffff" in the netlogon.log file should show you a Zerologon attack. It will show you the victim server (<VICTIM_SERVER_NAME> field), whether it is a domain controller or not, and also the attacker IP (<CLIENT_IP> field).

Instead of manually searching for this string, it would be much better to aggregate you logs into an Open Source log search tool like Elastic stack or hosted commercial solutions like Sumologic or Splunk. This will allow you to:

a) Alert you automatically when an event like this occurs on any of your servers, without a manual retroactive investigation.

b) Let you be certain about an attack by being able to count the number of malicious netlogon messages from a single client (remember that it requires on average 256 calls).

c) Actually let you investigate other funky stuff going on on your Windows machines.

A Splunk query for Zerologon detection (which can then be set up as an alert) would look like:

sourcetype="MSAD:NT6:Netlogon" "NetrServerAuthenticate" "(Negot: 212fffff)" 
| rex field=_raw "\[SESSION\] \[(?<some_number>.*)\] (?<domain>.*): (?<netlogon_msg>.*): (?<dc_name>.*) \((?<src_ip>.*)\) on account (?<machine_account>.*) \((?<netlogon_error>.*)\)" 
| stats count by src_ip,dc_name,domain 
| where count > 10

Caveat: It is possible that the flag value changes from "212fffff" to something else for other versions of Windows and for other nuances.

A successful attack can be detected by looking for the string "NetrServerPasswordSet" in the same netlogon.log log file. [Edit (September 21, 2020): This only detects one attack vector. New attacks have been discovered since the Secura paper was published. Subscribe to the blog using the Join button at the top for the update.]

About us: Overseer Security provides part-time cybersecurity leaders (dedicated hours per week) to build your security and privacy programs and policies and then help implement processes, infrastructure, and tooling. Talk security to us at hello@ovrsr.com.

References:

Secura Zerologon Whitepaper: https://www.secura.com/pathtoimg.php?id=2055

Secura test code: https://github.com/SecuraBV/CVE-2020-1472/