CVE-2020-0601 - How to operationalize the handling of vulnerabilities in your SOC

Hey there,

Software vulnerabilities are part of our lives in a digitalized world. If anything is certain, it’s that we will continue to see vulnerabilities in software code! Recently the CVE-2020-0601 vulnerability, also known as CurveBall or “Windows CryptoAPI Spoofing Vulnerability”, was discovered, reported by the NSA and made headlines. The NSA even shared a Cybersecurity Advisory on the topic. Anthony previously talked about it from a public sector and Vulnerability Scanner angle. I wanted to take this opportunity to look at it from a security operations perspective, particularly with regard to the two proof of concept exploits which were published last week.

Source: Computerworld

Every security operations team that reads the news should have a process to work systematically on these issues. For this reason, I thought I’d put together possible questions that can be raised during such an exercise and how those can be addressed with the CVE-2020-0601 vulnerability.

What is the CVE-2020-0601 vulnerability?

If vulnerabilities are disclosed they get a CVE number and are documented in the National Vulnerability Database from MITRE. So CVE-2020-0601 got an entry with a technical description. Basically, the Windows CryptoAPI which validates the signatures of certificates is not working correctly. The CryptoAPI is missing the validation of one parameter which unfortunately leaves a gap.

What is the possible impact if it’s exploited?

Cyber attackers can create certificates under the name of legitimate owners which are then mistakenly recognized as trusted by systems that are vulnerable. These certificates can be used to create trusted https connections, trusted signed files and emails as well as signed binaries of applications where system administrators may have restricted application use and are available to trusted or specific developers and vendors only.

As Proof of Concepts (POCs) were published this week, it’s become part of every cyber attacker’s repertoire.

Am I affected by the vulnerability in my environment?

Microsoft has released a security advisory and lists most of Windows 10, Windows Server 2016 and Windows Server 2019. It is likely that your organization is affected in some way.

What mitigation options are available?

When software vulnerabilities are responsibly disclosed, a mitigation or workaround option is made available to ensure that millions of systems are not left vulnerable over a longer period of time. Microsoft released its Patch Tuesday security updates to apply.

How can I identify if the exploits are actively used in my environment?

Once the Microsoft security patch has been installed, the Windows host will detect if a manipulated certificate made the attempt to be validated. It will also write a log in the Windows application event log with the Event ID 1 - Audit-CVE and the description that it is a possible detection of CVE-2020-0601 certification validation. While the Microsoft Advisory states that “..the system will generate Event ID 1 in the Event Viewer after each reboot”, the events turned up immediately during my test without any kind of reboot.

Test via the CVETest Page from Kudelski Security

You can easily collect these with the Splunk universal forwarder. If you want to know how to filter to collect only that specific Windows event Log - check out this twitter conversation.

When rolled out, the Microsoft security patch for CVE-2020-0601 indicates that the vulnerability has been actively deployed in your environment. The hits should be configured now to trigger alerts within your Splunk or Splunk Enterprise Security instance.

What can I do if I see an exploit hit my environment?

Let’s assume that a cyber attacker successfully managed to get a malicious file that was digitally signed with a spoofed certificate executed on your endpoint and this triggered after the patch installation of the Audit-CVE event. The Audit-CVE event holds the information about the execution process id (PID) which through sysmon process monitoring or your favourite endpoint protection tool can be tied back to the corresponding file or process.

Such a playbook can look within Splunk Phantom like that:

• Alert is raised - review the file / website / traffic involved

  • Retrieve the file/url based on the path found within the alert coming from Splunk.

In this Playbook we will examine the scenario of a malicious file being deployed in the compromised system:

• 1 - Grab the source file

  • The file will be parsed and saved inside Phantom generating a hash and an id that we can use further inside our playbook.

  • The hash value will be sent to VT for a file reputation and based on the amount of positives we will either hunt the file or detonate it first with our sandbox.

• 2- Send the hash to virus total for a file reputation scan.

• 3- Detonate it in a sandbox to see what that file is doing.

• 4- Following the decision that the intendent file is malicious, we will:

  • Block the particular hash within our environment

  • Create a ticket to follow up and report our findings

  • And hunt the file using e.g. an EDR tool

• Submit it to your AV company as a sample

• 5- Furthermore we should investigate the network communication of the host for the last weeks; we are doing that with a query back to Splunk

  • We can further enhance this view by enriching our findings with our Threat intelligence.

• Finally, we can run additional playbooks as steps in order to:

  • Review which users logged on to that host in the last weeks

  • Reset the user passwords that logged on on that host in the last weeks

• 6- Now we should update/close the ticket and

• 7- Remove the malicious file from the host

Can I perform a forensic investigation if it was exploited in the past?

In most cases of security announcements it is possible to look back as the activity can be identified through machine data. Check out the SWIFT Banking attack for reference. In this case, prior to patch deployment it’s difficult to detect if this vulnerability was exploited. The research paper from SecterOps.Io gives insights into how the certificate validation and potential attack vectors can work. For defenders they recommend for example to monitor several registry keys, if they have been accessed or changed. Also, they suggest collecting from the windows event log and the Microsoft-Windows-CodeIntegrity/Operational logs in case you want to deep dive to enhance your proactive monitoring capabilities.

Windows Event Collection from Microsoft-Windows-CodeIntegrity/Operational

Hopefully, this example helps you to plan your security operations processes accordingly. That way you’ll be prepared when you look out for CVE-2020-0601 exploitation indicators or when the next vulnerability hits the news.

Best

Matthias