Detection methods for the CVE-2020–1472 (Zerologon) by using the existing Windows log
CVE-2020–1472 3 seconds to get the DC admin
In August 2020, Microsoft released the security update CVE-2020–1472 (Netlogon Elevation of Privilege Vulnerability), a new elevation of privilege type (EoP) vulnerability also known as “Zerologon”. Briefly, it allows any normal domain account can reset the password of the domain controller computer account to the empty password. This vulnerability is given the highest score . A lot of articles talked about this vulnerability, so you can get more technical details in the whitepaper from secura.com
There is another form of the exploit of this vulnerability that does not need a password reset but in this article i focus only on how to detect the first form of the exploit that allows to modify the password of domain controller computer account. If i can have time, i will try to test that exploit. All those information can be found on the Dirk-jan Mollema ‘s blog and the implementation on this github repo.
Firstly, i am going to show you how easily utilize this exploit via the module already integrated to the well known “best hacker’s friend” Windows tool “mimikatz” :
From the video, the result is that we have obtained the NTLM hash of the kerberos account. That will allow the creation of golden ticket or to impersonate any user account that you would like :)
So now we need to analyze how to detect this exploit.
Detection
By analyzing the output from the Mimikatz tool or from the source code on github, we can summarize the actions in the following steps :
- (i) Try a numerous attempts with the goal of producing the ciphertext of all null bytes from the plaint text of all null bytes.
- (ii) When the right key is found, use NetrServerPasswordSet2 to reset the password of the DC computer account.
request[‘ComputerName’] = target_computer + ‘\x00’ request[‘ClearNewPassword’] = b’\x00' * 516
1. First method with event id
With the condition (i), there is not many logs on Windows by default that allows us to detect this kind of exploit. What i found on my lab is the two eventID that can occur in the same time when we launch the exploit :
- eventID 5805 : Netlogon error by “Access is denied”. it might be generated by (i) the attempts.
- eventID 4742 : A computer account was changed. It is generated by (ii), password reset. Here we note that the subject account name is “Anonymous logon” , the account name impacted is the domain controller computer account (WIN-E9FVTO2970$) , and the attributes “password last set” is enabled.
Hence, theoretically ,the final detection rule based on Windows event log is :
- The detection of the two event id at the same time : 5805 for the failed attempts and 4742 for the success of exploit.
- The 4742 eventid must have :
- Subject account name : ANONYMOUS LOGON
- Computer account name : [DCComputerAccount]
- Password last set: have a value
I do not test this rule on the production server. However, if your DC server is patched, of course you can combine with the event ID to get more accurate detection.
- Event ID 5829 is generated when a vulnerable Netlogon secure channel connection is allowed
- Event IDs 5827 and 5828 are triggered when vulnerable Netlogon connections are denied
- Event IDs 5830 and 5831, triggered when vulnerable Netlogon connections are allowed
2. Second method with netlogon log :
I think the second method that iam going to present will give the better result in detecting the exploit of this vulnerability. It means without the patch we could also detect it.
In order to setup this, the first thing we need is to enable the netlogon debug. You can find the detail on the Microsoft’s website. Here i resume with the following commands :
# enable the debug flag of netlogn
Nltest /DBFlag:20000300
the flag 0x20000300 is meant that we need to get only the real important errors and the session related logs with the timestamp for each event. This reduces the volume of log generated by the DC and focus only the important events.
#define NL_CRITICAL 0x00000100 // Only real important errors
#define NL_SESSION_SETUP 0x00000200 // Trusted Domain maintenance
#define NL_TIMESTAMP 0x20000000 // TimeStamp each output line
After that we need to restart the netlogon service in order to get it applied to the DC.
Once setup already, you can find the netlogon log in the file :C:\Windows\debug\netlogon.txt.
when we launch the exploit, we look at the netlogon log file, what we get is in the following self-explanatory figure
This value “d98c1dd4 04b2008f 980980e9 7e42f8ec” is actually the md5 of the empty password. Why ? if you reorder them, you can get D41D8CD98F00B204E9800998ECF8427E=md5(“”)
Therefore, if you can push the netlogon log file to your SIEM or any search engine, here is my proposed rule for the detection (in my opinion we can get get nearly 100% of detection):
- find the multiple netlogon failed attempts (“bad password 0 …” or “Failed to authenticate …”) => it is the (i) condition. This is good but it could generate the false positives if you have a complex production domain architecture. So you can use the fact that if the source IP generating those logs is not DC computer account, it could be the case.
- If the above event following the event resetting password to empty string , especially this special number string “d98c1dd4 04b2008f 980980e9 7e42f8ec”. it could show the success of the exploits.
Conclusion
In this article, i have presented 2 methods that can help you detect the exploit of the CVE-2020–1472. I hope i would not miss any thing and sorry if i get some English typos. For me, if you can enable the netlogon log, you can have more power on the detection. Anyway have a good reading !
