Detecting CVE-2020-0601 Exploitation Attempts With Wire & Log Data

Editor’s note: CVE-2020-0601, unsurprisingly, has created a great deal of interest and concern. There is so much going on that we could not adequately provide a full accounting in a single blog post!

This post focuses on detection of the vulnerability based on network logs, specifically Zeek as well as Endpoint. If you are collecting vulnerability scan data and need to keep an eye on your inventory of systems that are at risk, then check out Anthony Perez’s blog. If you are still trying to get your arms around CVE-2020-0601 and need a good way to synthesize the content out there and possible avenues of action, Matthias Maier has you covered with his blog.

The recent news regarding the critical Windows 10 CryptoAPI vulnerability (CVE-2020-0601) likely has you and your fellow security practitioners losing what little time you have to sleep! If you’re on top of this, you’ve already started deploying Microsoft’s patch, but maybe aren’t quite sure how to see if the vulnerability is being exploited on your network. If you’re not already patching, you should pause a moment from reading this blog post and get on it! There is proof of concept exploit code already available. 

Hopefully you’ve been taking the excellent advice that Anthony Perez provided in his recent blog post in carefully assessing your vulnerability scans to see which systems are still vulnerable; if you have not, you really should!

I would like to take a moment and add some clarity around what the vulnerability is. Most of the discussion and my demonstration is focused on using the technique to spoof web server certificates in conjunction with a Man-in-the-Middle (MitM) attack. The vulnerability can also be used to used to perform code signing (MITRE ATT&CK Technique T1116) to bypass your application whitelisting defenses. That is just one example. Remember, certificates aren’t just used for web servers!

Let me show you and your fellow SOC analysts how to detect possible exploitation attempts using both wire data and traditional log data. Wire data, even when encrypted, frequently can be meaningful in threat hunting as my dear colleague Ryan Kovar presented at .conf17. Endpoint log data is also highly informative and can be a remarkable “source of truth.” Let’s dig into wire data with Zeek (Bro) first!

Leveraging Zeek for CVE-2020-0601 Exploit Detection

First, I want to lay out a few prerequisites. This assumes that you have Zeek (Bro) installed on your network and you have added the latest Zeek script onto the sensor. Finally, you’ve made the wise decision to ingest those logs into Splunk and have installed the Splunk Add-On for Zeek aka Bro. If you have not done all of these things, follow the links included and get started!

To trigger the exploit and verify my sensor is configured correctly, I can leverage the previously linked PoC code with its included the Node.js web application. I can simulate the MitM attack by setting “www.google.com” to the IP address hosting the web app in my virtual machine’s hosts file. As you can see below, Edge on an unpatched Windows 10 has no issues with the fake certificate. Scary.

Reviewing Zeek logs with SPL is straightforward but you need to understand that there are several different log files generated and that each tells you something different. For our purposes, we are going to focus on the notice.log file, as this file contains Zeek “notices” or alerts.

If your log format looks different from mine, you’re likely using Tab Separated Value (TSV) format, which is enabled by default. As Splunk has built-in JSON syntax formatting, I’ve configured my Zeek installation to use JSON to make the event easier to view and parse, but both formats will work, you just need to adjust the SPL provided to the correct sourcetype. I have my inputs.conf configured to set sourcetype as “bro:notice:json” (if not using JSON, set sourcetype to “bro_notice”)

sourcetype="bro:notice:json" category="CVE_2020_0601::*"
| table _time src_ip dest_ip category body

When we run our search looking for notices with a category starting with CVE_20202_0601::, we see a few results. However, we only care about the alerts fired from the new detection script. The SPL can be modified to fit your environment as necessary (like adding your Zeek index!)

Perhaps you noticed that the data is already CIM compliant with the Alerts and Intrusion Detection data models. If you’re an Enterprise Security customer, you’re ready to develop a Correlation Search. Otherwise, now would be a great time to create an alert!

Using Endpoint Logs for Detection

I promised you I’d give you a couple of options, in case you’re not using Zeek yet. On the same VM, I installed the patch, then restarted the system. Once again, I browsed to the fake website, but this time the certificate wasn’t valid.

Microsoft added an API call in Windows 10 and Server 2016 (or higher) to log an entry in the Application log when an exploit attempt is made against a vulnerability that has been patched. Presumably due to the criticality of this vulnerability, Microsoft made this API call in their patch for CVE-2020-0601.

Volumes have been written, and many hours of .conf talks have been dedicated to Splunking the Endpoint, specifically around Microsoft Sysmon. If you haven’t gotten there yet, (and you really should make the time, but first finish patching!) that’s ok, you don’t need Sysmon for this detection. You will, however, need the Application log from the Windows Event log. Usually we are looking at the Security log, but not today.

sourcetype="XmlWinEventLog" eventtype=”wineventlog_application” EventCode=1 Name="'Microsoft-Windows-Audit-CVE'"
| table _time dest CVEID

To find these events, the key fields to search for are: Name=“Microsoft-Windows-Audit-CVE” and EventCode=“1”. I love this event… what better detection mechanism than the vendor providing the patch for the vulnerability shouting “Hey! Look! Over here, something bad is happening!”

I would point out that by gathering and watching your endpoint logs for signs of this exploit, you are much more likely to catch a digitally signed malicious binary during execution. One downside to this method of detection is that systems without the patch don’t log anything when the vulnerability is exploited. That’s why leveraging both techniques is crucial!

By combining both of these detection techniques, you and your fellow analysts will know when you see a malicious certificate being used on the wire. You can also cross-reference the endpoint logs to determine which endpoints were patched successfully or show that the host was susceptible and something worse could potentially occur. 

Happy Splunking!
Drew