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.
Exploitation Strategies
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:
Case 1 – DC password reset without original password reestablished
Case 2 – DC password reset with original password reestablished
Case 3 – Spool service (printer bug) + NTLM Relay without password reset
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.
Artifacts for CVE-2020-1472 Detection
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:
|
Artifacts |
Pros |
Cons |
|
Windows event logs |
|
|
|
Dump of hash history |
|
|
|
LSASS (Yara rules) |
|
|
|
Snort/Suricata |
|
|
Detecting Zerologon with Windows Event Logs
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.
Case 1 – DC Password Reset without Original Password Reestablished
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):
- Account Name: the DC computer account or anonymous logon
- Source Network Address Field: this will differ from the DC IP address and will show the IP address from where the attacker has executed the exploit
- Authentication Package: NTLM
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
Case 2 – DC Password Reset with Original Password Reestablished
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.
Case 3 – Spool Service (Printer Bug) + NTLM Relay without Password Reset
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:
- Printer spooler bug on one DC
- Zerologon bug on another DC
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):
- Logon Type: 3
- Security ID: a DC in the infrastructure abused with the printer spooler exploit
- Account Name: same DC computer account as above
- Workstation Name: same DC computer account as above
- Source Network Address: different from the DC IP address and will show the IP address from where the attacker has executed the exploit
- Authentication Package: NTLM
- Logged: same timestamp for both DCs
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):
- Logon Type: 3
- Security ID: the domain account the attacker is using (remember it is a prerequisite that the attacker should have a valid domain account to run this exploit)
- Account Name: same user account as above
- Source Network Address: IP address from where the attacker has executed the exploit
- Authentication Package: NTLM
- Logged: same timestamp for both DCs
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
Detecting Zerologon with Password History
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.
Extracting Password History via NTDS.DIT dump
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$).
Extracting Password History via MS-DRSR
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:PASSWORD@DC_FQDN -just-dc -just-dc-user DC_SAMACCOUNTNAME -history |
Replace the following parameters:
- USERNAME with username of an account with permission to get changes via MS-DRSR, such as domain admins. For instance, administrator.
- PASSWORD with password of the domain admin to be used in plain text.
- DC_FQDN with the fully qualified domain name of one of your domain controllers. It does not matter which one; for instance, DC01.CONTOSO.LOCAL.
- DC_SAMACCOUNTNAME with the SamAccountName of the domain controller to test. Remember this should be done for each of the domain controllers in the environments; for instance, DC01$.
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:
- DOMAIN_FQDN with the fully qualified domain name of your domain; for instance, CONTOSO.LOCAL
- DC_FQDN with the fully qualified domain of one of your domain controllers. It does not matter which one; for instance, DC01.CONTOSO.LOCAL.
- DC_SAMACCOUNTNAME with the SamAccountName of the domain controller to test. Remember this should be done for each of the domain controllers in the environments; for instance, DC01$.
Now that you extracted the hashes for each DC computer account, you will be able to detect case 1 and case 2 as follows.
Case 1 – DC Password Reset without Original Password Reestablished
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
Case 2 – DC Password Reset with Original Password Reestablished
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
Detecting Zerologon with Yara Rules
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:
- If a DC has been already patched for Zerologon
- If a DC has been scanned or exploited by Zerologon null password reset exploit (credits to Cynet*)
- If a DC has been exploited by the printer bug + NTLM relay exploit (case 3)
Once downloaded, the rule can be executed via the Volatility framework or with the standalone Yara tool on an LSASS dump.
Executing the Yara rule with Volatility
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:
- NO OUTPUT: if the server is vulnerable but no exploit or scanner has been found to be executed against this DC
- “Rule: Zerologon_Scanned_exploited”: if the reset password exploit (case 1 or case 2) or the scanner module has been executed
- “Rule: Zerologon_DCSYNC_Scanned_exploited”: if the printer bug + NTLM relay exploit (case 3) has been executed
- “Rule: Zerologon_patched”: if the server is patched for Zerologon
- Both “Scanned_exploited” and “patched” Rules: if the server is patched and a scanner/exploit execution has been run without consequences
An example of an exploited DC can be seen in Figure 8.
Figure 8 – Example of Zerologon Exploit Output from Yarascan
Executing Yara Rule with Standalone Yara Tool on a LSASS Dump
First, create a dump of the lsass.exe process. This can be done with Sysinternals ProcDump* or by using the Volatility memdump plugin:
Sysinternals ProcDump
|
procdump64 -ma lsass.exe lsass.dump |
Volatility
- Find the lsass.exe process PID with the pslist plugin:
|
python vol.py -f /path/2016DCmem.dmp --profile=Win2016x64_14393 pslist |
- Execute the memdump plugin on the obtained PID:
|
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.
Detecting Zerologon Using Snort/Suricata Rules
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
Zerologon Still a Growing Threat
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.
Sources
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
