Detecting CVE-2020-1472 (CISA ED 20-04) Using Splunk Attack Range

Important note: For Splunk customers in U.S. Public Sector complying with actions from today's CISA Emergency Directive 20-04 the detection searches provided below, available in our most recent ESCU content can be used to effectively find systems that are under attack and have not yet been patched. Similar searches have been published by Splunker Drew Church, here.

The recent disclosure of CVE-2020-1472 vulnerability by Microsoft showcases the need for tools that allow defenders to quickly replicate published exploit code, register attack data, and create signatures or other mitigations against released exploits with a high likelihood of exploitation against popular infrastructure or operating systems. In this case, the exploit code released for this vulnerability is extremely likely to harm systems that have not yet been patched or lack other mitigations in place...

^{Source: Microsoft - Netlogon Elevation of Privilege Vulnerability*}

This attack, according to the disclosure information, allows an attacker to target a Microsoft Windows Domain Controller and perform a Netlogon authentication bypass attack, according to the security company Secura. The critical aspect of this attack is that it can access a domain controller in an unauthenticated fashion, giving attackers access and the ability to obtain high-privilege domain credentials. Specifically, this new vulnerability coined Zerologon “..takes advantage of flaws in a cryptographic authentication protocol that proves the authenticity and identity of a domain-joined computer to the DC. Due to incorrect use of an AES mode of operation, it is possible to spoof the identity of any computer account (including that of the DC itself) and set an empty password for that account in the domain." *

Secura has released the proof-of-concept code that allows exploitation of this vulnerability on their Github. The Splunk Threat Research team has been able to validate the exploit by testing it through the Splunk Attack Range. In this blog, we will show how to use Attack Range to replicate this exploit proof-of-concept (POC), test our detections, or create your own detections. 

The Splunk Threat Research, along with community members, have also authored an Analytic Story that detects this attack in various data sources. The specifically tested detections available now are:

• Detect Zerologon using Zeek
• Detect Mimikatz Using Loaded Images
• Detect Credential Dumping through LSASS access
• Detect Computer Changed with Anonymous Account 
   

You can use these detections right now as part of the latest ESCU release, or download them directly from the security-content repository.

Enter Splunk Attack Range Local

The Splunk Attack Range provides the ability to create a local version of the same components created in the cloud. This tool was designed with the mindset of helping defenders and researchers to replay or simulate attacks within an environment that allows recording, indexing and analytics of such attacks.

Attack Range local allows the operator to deploy a domain controller, a Splunk server, and a Kali Linux Machine, which are needed items to test this exploit. To install attack_range_local, simply follow these instructions for macOS or alternative this one for Ubuntu.

Let’s first build the local range by running: 

python attack_range_local.py --action build

Please make sure you enable the Kali Linux machine since it is not by default.

Once the process has finished, proceed to verify the specified machines have been built locally by running:

python attack_range_local.py --list_machines

As seen in the screenshot above, Attack Range local is built with a Splunk Server, Windows 2016 Domain Controller, and a Kali Linux attack box.

After analyzing various proof-of-concept exploits for this vulnerability, the Splunk Threat Research Team realized that they all require the latest version of impacket. Please follow the instructions on their Github to install it. The specific code we used in our testing can be found here, but you can also use this code as well. Once all those elements are in place, here is how it looks like just before starting.

Before executing the exploit, CLEAR the event log at the Domain Controller to help pinpoint the specific events as the attack is executed (Make sure to refresh the event viewer then clear, first event should be EventID: 1102). The other events previous to clearing the log are already stored at the Splunk Server which will be discussed in a moment. Execute the exploit by running:

python cve-2020-1472-exploit.py <DC hostname> 10.0.1.14

If it was successful the output should match the screenshot below.

The screenshot above on the left side contains the events that occurred during attack execution. Starting from the bottom, EventID 1102 (logs cleared) followed by EventID 5152 (connections blocked) only appears if enabled by audit, and is caused by traffic sent from the attacking machine. EventID 4742 (A computer account was changed) event does not reveal specific signs of exploitation on its own, but it was found consistently across all operating systems we tested the exploit on (Windows 2008R2 Server, Windows 2012R2, Windows 2016 Server, and Windows 2019 Server). EventID 4742 indicates a computer account was changed. Computer accounts in Active Directory are usually followed by a single dollar sign. This specific event shows Security ID: ANONYMOUS LOGON, Account Name: ANONYMOUS LOGON, and Account Domain: NT AUTHORITY.

In the Splunk server http://10.0.1.12:8000 (if you kept the default attack_range.conf addresses) all these events are also indexed and captured automatically for us. Let’s build some detections from this data.

Assessment & Mitigation

This vulnerability is not only extremely serious but based on the nature of its execution such as unauthenticated RPC calls, it can also be very difficult to detect. This is especially significant in environments where audit logging or deep packet inspection technology are not in place. The recent addition of this attack to the popular credential attack tool MimiKatz, will likely make this attack very popular. Fortunately, Splunk ESCU has two detection searches that find Mimikatz. The first detection leverages Event Code 10 from source type Sysmon. Below is a screenshot of the MimiKatz execution and the results of the “Detect Credential Dumping through LSASS access” detection executing from ESCU.

The second detection for finding Mimikatz execution leverages Event Code 7. It is also collected by Sysmon, and to test this detection the Spunk Threat Research team used the SysmonConfig-Verbose.xml verbose logging configuration. Below is a screenshot of the results of the “Detect Mimikatz Using Loaded Images” detection executing from the Splunk server search app.

Research suggests that the best course of action against this threat is a multi-factor approach. Combining network detection via Zeek sensors using the detection “Detect Zerologon via Zeek” contributed by Splunk’s Senior Security Sales Engineer Shannon Davis. As well as leveraging EDR logs to find MimiKatz using the detections discussed above. Finally, monitoring windows security event logs that contain Event ID 4742 (Computer Account Change) that look like this:

The Splunk Threat Research team has created a detection that finds this behavior called “Detect Computer Changed with Anonymous Account”. It is important to understand that this event specifically refers to COMPUTER ACCOUNT is usually accompanied by a single dollar sign ($). These events are not common in domain controllers and should be reviewed. The research found this event is associated with a successful zerologon attack. EventID 5805 (System - Netlogon) has also been referenced as part of this attack. The Splunk Threat Research team also observed this event in attacks performed against other server operating systems such as Windows Server 2012R2, 2016, and 2019. Moreover, other Event IDs that were present in other operating systems during our tests, however, their presence was not consistent across different OS versions. Last but not least, do apply recommendations from Microsoft Security Advisory!

The above detections should help mitigate this threat before applying proper patching and thereafter. Splunk Attack Range framework proved fundamental in the development of these detections and understanding of the attack. Anyone can replicate the above steps by simply downloading the code and deploying it.

_{About Splunk Threat Research Team
The Splunk Threat Research team is devoted to understanding actor behavior and researching known threats to build detections that the entire Splunk community can benefit from. The Splunk Threat Research team does this by building and open-sourcing tools that analyze threats and actors like the Splunk Attack Range and using these tools to create attack data sets. From these data sets, new detections are built and shared with the Splunk community under Splunk Security Content. These detections are then consumed by various Splunk products like Enterprise Security, Splunk Security Essentials, and Mission Control to help customers quickly and effectively find known threats.}