About Zerologon (CVE-2020-1472)
On September 11th, 2020, Secura researcher Tom Tomvoort published a blog post outlining the Zerologon vulnerability. Microsoft’s August Patch Tuesday releases contained a patch for CVE-2020-1472 which can be exploited by attackers to hijack enterprise servers due to Netlogon cryptographic weaknesses. The vulnerability allows an attacker to set a password for the computer account of an Active Directory Domain Controller, which can then be abused to pull credentials from the Domain Controller. Dirk-jan Mollema provides a great overview of this attack and its impact. The following quick blog post will outline some defense guidance for the Zerologon attack. I use Benjamin Delpy’s latest Mimikatz release to perform the attack and leverage Samir Bousseaden’s EVTX Samples in Splunk to demonstrate the attack’s telemetry. I’ll also be using Sysmon as well as network / PCAP telemetry in order to provide as much defensive coverage as possible.
Performing the Attack
Although there are a few tools out there that perform the Zerologon exploit, I’ll be leveraging the latest (as of this writing) Mimikatz release. First, we test whether the system is vulnerable:
And then we launch the exploit.
At this point, we can then perform a DCSync attack to pull sensitive data from the Domain Controller. Please note that this attack breaks Domain Controller functionality – please do not try it in production without the proper precautions, approvals, and back out plan. My testing was done on a snapshotted and often restored virtual machine.
Detections
Event Code 5805
As highlighted by Samir here a 5805 event is generated when the Zerologon attack is performed. This log lives in the System log channel of a Windows host; a simple Splunk query for this type of activity can be performed:
index=winlogs EventCode=5805
| table body,Name,dest
And the results:
Although in this example the computer name is clearly set to mimikatz, it is the failed NETLOGON to the Domain Controller, which in my case is called “Server2” that is of interest.
Event Code 4624 + 4742
An event code 4624, followed by an event code of 4724 are also triggered when the exploit is executed. Here I am using the EVTX samples provided by Samir (linked above) to perform the following query:
index= [evtx_location] EventCode=4624 OR EventCode=4742
Account_Name=”ANONYMOUS LOGON”
| table name,MSADChangedAttributes,Source_Network_Address,Account_Name
Which yields the following results:
We can see that the password for the domain controller computer account was changed and that a successful anonymous login occurred. Note: In my – albeit limited – testing, these two events did not occur on my test domain controller, so please test this detection logic.
Sysmon Event ID 3
Another detection technique for the Zerologon attack is to take advantage of the Sysmon NetworkConnect event combined with it’s powerful Rule syntax. An incoming network connection is made from the attacking machine to the victim Domain Controller to the LSASS process when the Zerologon event occurs, and we can monitor for this type of activity with the following Sysmon config snippet:
<Rule name=“Incoming LSASS NetworkConnect” groupRelation=“and”>
<Image condition=“image”>lsass.exe</Image>
<Initiated condition=“is”>false</Initiated>
</Rule>
And the following Splunk query:
index=sysmon RuleName=”Incoming LSASS NetworkConnect”
| table Protocol,Initiated,SourceIp,DestinationIp
Which produces:
Here we can see that the host 192.168.1.143 which is my attacking machine, made a network connection to the LSASS process of 192.168.1.156 which is my victim Domain Controller. Note: As always with any Sysmon rule, it will need to be tuned to weed out false positives and general noise.
Moloch Hunts
Moving away from the host layer, the Zerologon attack can also be detected via the packet capture. I am using Moloch Full packet capture here, but this detection logic can most likely be extended to other PCAP systems. If we take a look at a PCAP of the attack (I have generated my own PCAP, but if you cannot, Samir has provided one: here) we can see that the client credential field is set to all 0’s:
We can use the Hunt feature in Moloch to look for these hex bytes in our PCAP data. I will limit our hunt by telling Moloch that we only want to see RPC protocol traffic via the protocols == dcerpc query:
After filling in our bytes: 0000000000000000ffff2f21220000c0 we can run the hunt, in my little lab we can see that Moloch found 7 sessions which matched our hunt logic:
We can then open our Hunt to take a look at the data. We can see that Moloch is the master of metadata and tags our sessions with the Hunt Names and Hunt IDs for further querying and pivoting. If we expand the session traffic, we can see the network activity of the Zerologin attack:
Wrap Up
The Zerologin vulnerability should be taken extremely seriously and any affected systems should be patched as soon as possible. However, since patching isn’t always feasible, this post aimed to provide some detection guidance for this critical vulnerability using native Windows Logs, Sysmon and PCAP.
References
https://github.com/sbousseaden/EVTX-ATTACK-SAMPLES
https://twitter.com/SBousseaden
https://github.com/gentilkiwi/mimikatz/releases
https://www.secura.com/blog/zero-logon
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472
Anton is a BSides Toronto speaker, C3X volunteer, and an OSCE, OSCP, CISSP, CSSP certificate holder. Anton enjoys the defensive aspects of cybersecurity and loves logs and queries.
