Click here to bookmark this page
Click here to remove bookmark
Click here to bookmark this page
Click here to remove bookmark
Recently, Microsoft issued the patch for CVE-2020-1472 a.k.a. Zerologon, a critical vulnerability that allows an attacker without credentials to elevate to the highest possible privileges in the domain.
So, you have applied the patch* to all your systems, especially all your domain controllers (DC). Now what? How can you make sure nobody exploited Zerologon and compromised all your credentials before you patched?
In this article, you will learn how to look for indicators of compromise (IOC) that Kroll specialists have identified for the different ways threat actors exploit CVE-2020-1472. Our objective is to provide clients with a roadmap as well as landmarks for discovering if they have already been victimized by a Zerologon exploit.
Since the publication of the Zerologon CVE, threat actors have released different exploitation strategies. Understanding that each strategy generates different IOCs is key to knowing where and how to look for potential compromises.
Kroll has tested and analyzed the main exploits to capture the unique IOCs associated with each strategy. The team focused on three primary exploit strategies or “cases,” which we refer to throughout this article:
In case 1 and case 2, the password of the DC computer account would be reset. The only difference is that in case 2, the attacker reestablishes the original password after the exploitation.
Depending on the artifacts that you have available in your environment at the time of the analysis and when the potential exploitation happened, you will be able to reliably detect each of the cases by using one artifact or the other. The following section describes how to use common artifacts to detect a Zerologon exploit.
You can detect if a Zerologon exploit has occurred in your environment by using the following artifacts when available: default Windows event logs, Password history, LSASS and Snort/Suricata.
Whatever method you use, the checks must be done on all domain controllers in the infrastructure.
We always advise to save Windows event logs and take a full memory dump (hypervisor snapshots/checkpoints or third parties tools) then follow our detection guide. This ensures you save important artifacts that could help in further analysis.
Zerologon Exploit Detection Cheat Sheet
Each of these artifacts has its own set of pros and cons, as detailed below:
Windows event logs
Dump of hash history
LSASS (Yara rules)
Windows creates several relevant events in the DCs that could help detect Zerologon. When attempting to detect a Zerologon exploit, the set of events to look for will vary depending on the attacker’s exploitation strategy.
In case 1, after a successful exploitation, the attacker will authenticate using the DC computer account. This will be captured as Security 4624: An account was successfully logged on and display the following characteristics (Figure 1):
Figure 1 – Security Event 4624 Example
If you find this event with the described conditions, an attacker has managed to exploit Zerologon to authenticate using the DC computer account via NTLM.
The next step would be to look for a password reset for the DC computer account. This will be captured as Security 4742: A computer account was changed and display the following characteristics (Figure 2):
Account Name: the DC computer account
Password Last Set: computer account passwords are reset automatically by Active Directory every 30 days; look for an event 4742 with a password reset of the DC computer account soon after the previous event 4624
Authentication Package: NTLM
Figure 2 – Security Event 4742 Example
Windows security events 4742 and 4624 are already good indicators of a Zerologon exploit in the environment.
There are certain cases, e.g., when the attackers use Mimikatz to exploit Zerologon, that generate another security event, namely event 5805. Mimikatz is a well-known Windows tool used to extract plaintext passwords and hashes from lsass.exe process and perform pass-the-hash and pass-the-ticket attacks, among others. As of September 18, 2020 (release 2.2.0 #19041), Mimikatz has a new module to scan for and exploit Zerologon.
If you notice security event 5805 coinciding with the same timestamp of security event 4742, you will have yet another indicator of compromise. Specifically, look for Event 5805: The session setup from the computer ***DC NAME*** failed to authenticate. The following error occurred: Access is denied with the following characteristics (Figure 3):
Logged: same timestamp as the security event 4742
General: the computer name will be the DC itself
Figure 3 – Security Event 5805 Example
If the original password is not reestablished by the attacker, the DC might be left inoperative as the password in Active Directory and in the local registry/LSASS is different. In order to avoid this, sometimes the attackers decide to reestablish the password of the original DC computer account after the exploitation.
Look for the same Windows security events as in case 1, with the exception that you should now find two events 4742 (password changed) for the DC computer account in a short period of time.
Remember that by default, a computer account’s password is only reset every 30 days, so finding two password resets for the same computer account in a short period of time is not normal and indicates the exploitation of Zerologon.
This is an exploitation strategy where the password of the domain controller computer account does not need to be reset. Instead, the attacker triggers a feature called “spool” service to force a DC to make a connection to another computer.
The threat actor will exploit two Windows bugs on two different DCs:
This attack requires a few more prerequisites than case 1 and 2 because two different DCs are required and the attacker needs to have at least one unprivileged domain account to run the printer bug.
Only one Windows security event relevant to this exploit is captured by default, and it will be present on the two abused DCs with the same timestamp.
On the DC abused by the Zerologon exploit, look for Event 4624: An account was successfully logged on with the following characteristics (Figure 4):
Figure 4 – Security Event 4624 Related to Case 3 Example
On the DC abused by the printer spooler vulnerability, look for Security 4624: An account was successfully logged on with the following characteristics (Figure 5):
Note: Many events 4624 can be found on DCs as every authentication generates them, and we recommend searching and filtering based on the characteristics described above.
Figure 5 – Security Event 4624 on DC Abused by Printer Spooler Vulnerability
Zerologon exploitation can also be detected by observing the password hashes in the database. Based on Kroll’s analysis and open-source intelligence, this Zerologon exploit will reset the DC computer account with a null password. Accordingly, this detection method involves checking the password hashes history of all the DC computer accounts to see if their password was reset to null and/or then reestablished to the original one.
Note: This method will only be effective when a password has been reset, i.e., case 1 or case 2.
By default, Active Directory will keep the hash of the last 24 passwords of every account, including the DC computer accounts. For that reason, this detection method covers a longer period than Windows logs (as these might have not been retained for long enough).
Two main methods can be used to extract the history of the password hashes: via NTDS.DIT dump or via MS-DRSR.
First, in a domain controller, create a copy of the NTDS.DIT database with ntdsutil:
ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q
From the files created in C:\temp, we will need ntds.dit and SYSTEM.
One can use secretsdump.py from Impacket Tools to extract the relevant hashes from the copy of the database.
python3 secretsdump.py -ntds /home/user/Desktop/NTDS/Active\ Directory/ntds.dit -system /home/user/Desktop/NTDS/registry/SYSTEM -history LOCAL
Another tool in PowerShell (which does not require Python) that can be used is DSInternals*.
Run this tool in a PowerShell session to execute the following command:
PS C:\> Import-Module .\DSInternals\DSInternals.psd1
PS C:\> $key = Get-BootKey -SystemHivePath .\ntds_files\SYSTEM
PS C:\> Get-ADDBAccount -SamAccountName DC_SAMACCOUNTNAME -BootKey $key -DBPath
.\ntds_files\ntds.dit | Format-Custom -View NTHashHistory
Replace the specific paths of the files NTDS.dit and SYSTEM for your case, and DC_SAMACCOUNTNAME with the domain controller SamAccountName (e.g., DC01$).
Another way of extracting the password hashes history is via directory replication service (DRS) remote protocol, which offers the benefit of not having to create a copy of the NTDS.dit database in advance.
The tool secretsdump.py from Impacket Tools* can be used in the following way and replacing the parameters as noted:
python3 secretsdump.py USERNAME:[email protected]_FQDN -just-dc -just-dc-user DC_SAMACCOUNTNAME -history
Replace the following parameters:
DSInternals can be used for this purpose as well. To make it easier, run this tool in a PowerShell session using domain admin credentials:
PS C:\> Import-Module .\DSInternals\DSInternals.psd1
PS C:\> Get-ADReplAccount -domain DOMAIN_FQDN -Server DC_FQDN -SamAccountName
DC_SAMACCOUNTNAME | Format-Custom -View NTHashHistory
Replace the following parameters:
Now that you extracted the hashes for each DC computer account, you will be able to detect case 1 and case 2 as follows.
If the current hash is 31d6cfe0d16ae931b73c59d7e0c089c0 (this represents a null hash), the exploit has been executed successfully, and the attacker has not reestablished the original password (Figure 6).
Figure 6 – Password History Detection: Null Hash 31d6cfe0d16ae931b73c59d7e0c089c0
If you identify two consecutive identical hashes in the password history, the exploit has been executed and the attacker has restored the password to the “original” one (Figure 7).
Figure 7 – Password History Detection: Two Consecutive Identical Hashes
Yara is a powerful detection tool mainly used in malware research and detection. It is a string searcher that can be used on many data file types.
In this case, it is useful to search for a specific pattern composed of the DC computer name (with a final $) plus a null password inside the lsass.exe process memory (the process that manages any authentication on Windows).
Note: Detecting Zerologon with Yara rules is only possible if the domain controller has not been rebooted after it was exploited. If the DC was rebooted, the relevant artifacts in memory will be lost.
Kroll’s analysts have written a Yara rule* to detect the following three conditions in memory:
Once downloaded, the rule can be executed via the Volatility framework or with the standalone Yara tool on an LSASS dump.
Volatility framework allows you to inspect, analyze and extract important artifacts from a memory dumped from a system.
In this specific scenario, if you have a memory dump from a domain controller, you can execute the following command to run the yarascan plugin (edit with your settings):
python vol.py -f /path/2016DCmem.dmp --profile=Win2016x64_14393 yarascan -y /path_to_yararule/zerologon.yar
The command can give you these results:
An example of an exploited DC can be seen in Figure 8.
Figure 8 – Example of Zerologon Exploit Output from Yarascan
First, create a dump of the lsass.exe process. This can be done with Sysinternals ProcDump* or by using the Volatility memdump plugin:
procdump64 -ma lsass.exe lsass.dump
python vol.py -f /path/2016DCmem.dmp --profile=Win2016x64_14393 pslist
python vol.py -f /path/2016DCmem.dmp --profile=Win2016x64_14393 memdump -p PID -D /path_to_the_new_lsass_dump/
Once a dump of the lsass.exe process is created, you can run the Yara standalone with the following command:
yara /path_to_yararule/Zerologon.yar /path_to_dump/lsass.dmp
This process can output the same cases as described before. For example, Figure 9 presents an example of the output when a system is patched and has been scanned.
Figure 9 – Output of a Patched and Scanned System
If the server is updated but the Yara rule detects the exploit, someone scanned the DC or at least tried to exploit it without success.
Since Zerologon generates multiple logon attempts, another very effective way of detecting a Zerologon exploit is to analyze the traffic coming to the DCs.
For environments with an IDS/network inspection in place, this can be a good method for detection.
The public Snort rules repository EmergingThreats has released a new rule that successfully identifies the attempt to exploit Zerologon based on the network traffic generated during the exploit.
This rule checks the number of attempts to access the DC via NetrServerAuthenticate with 0x00 client credentials, as the rule itself states (Figure 10).
alert tcp-pkt any any -> [$HTTP_SERVERS,$HOME_NET] ![139,445] (msg:"ET EXPLOIT Possible Zerologon NetrServerAuthenticate with 0x00 Client Credentials (CVE-2020-1472)"; flow:established,to_server; content:"|00|"; offset:2; content:"|1a 00|"; distance:19; within:2; content:"|5c 00 5c 00|"; within:50; content:"|24 00 00 00 06 00|"; distance:0; fast_pattern; content:"|00 00 00 00 00 00 00 00|"; distance:0; isdataat:!5,relative; threshold: type limit, count 5, seconds 30, track by_src; reference:url,www.secura.com/blog/zero-logon; reference:cve,2020-1472; classtype:attempted-admin; sid:2030871; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Server, created_at 2020_09_14, cve CVE_2020_1472, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, updated_at 2020_09_18;)
Figure 10 – Snort Rule via NetrServerAuthenticate
This rule has a limit threshold of five for every 30 seconds, meaning that an event will be shown five times every 30 seconds. As multiple requests matching the rule will be sent in order to exploit the vulnerability, the appearance of these five consecutive alerts will flag this attack with great accuracy.
Figure 11 shows the detection of the exploit on a Suricata IDS server, as per the log entry registered in eve.json log file.
Figure 11 – Detection of the Exploit on a Suricata IDS Server
Since its publication, CVE-2020-1472 upended internal security teams’ patch schedules. The Department of Homeland Security issued an urgent directive on Friday, September 18, mandating that all systems be patched by no later than 11:59 p.m. EDT on Monday, September 21. Recently, the FBI warned of Zerologon exploits targeting networks supporting election systems and Microsoft warned of state-sponsored hackers successfully exploiting the vulnerability over the last two weeks.
Immediate attention is required to avoid critical issues. If your organization is concerned with exposure by Zerologon, Kroll experts are available to help.
Zerologon: instantly become domain admin by subverting Netlogon cryptography (CVE-2020-1472): https://www.secura.com/blog/zero-logon*
Original scanner: https://github.com/SecuraBV/CVE-2020-1472/blob/master/zerologon_tester.py*
A different way of abusing Zerologon (CVE-2020-1472): https://dirkjanm.io/a-different-way-of-abusing-zerologon/ *
Cynet Yara rule: https://go.cynet.com/hubfs/rule%20Zerologon.yara *
Emerging Threats: https://doc.emergingthreats.net/*
* Hyperlinks included in this article are not validated by or endorsed by Kroll
Global, end-to-end cyber risk solutions.
Delivering actionable recommendations using the best technology and expertise available.
Mature your cyber security with unparalleled visibility and constant protection.
Services using cutting-edge tools to help clients map a prioritized path to increased cyber security.
Assess clients' info security through simulated attacks using real-world hacker techniques.
Compliant notifications, reputation-saving remediation, and litigation support.
Kroll delivers more than a typical incident response retainer—secure a true cyber risk retainer with elite digital forensics and incident response capabilities and maximum flexibility for proactive and notification services.
Services to help teams safeguard information assets while supporting business operations.