Checking for SIGRed (CVE-2020-1350) and CISA ED 20-03 with Splunk

Hey everyone! 

I’m back with another Splunk Security blog post to help you identify vulnerable hosts and detect exploitation attempts using wire data. Today, we’re going to be focusing on the CVSS 10.0 (CRITICAL!) rated vulnerability named “SIGRed” or, for those less into marketing names for vulnerabilities, CVE-2020-1350. If you are one of our U.S. Public Sector customers, you’re probably concerned about complying with CISA Emergency Directive 20-03 that covers this same vulnerability.

For those who haven’t heard about CVE-2020-1350, it is an unauthenticated, remote code execution (RCE) vulnerability in Microsoft Windows Domain Name System (DNS) servers. Successful exploitation allows attackers to run any code they want with local SYSTEM access. RCEs are bad vulnerabilities, unauthenticated ones are even worse. Pair this with one of the most common authentication platforms (Microsoft Active Directory), and you’re in for a world of hurt.

My last blog post, "Detecting CVE-2020-0601 Exploitation Attempts With Wire & Log Data," reminded readers to stop reading and go patch if that wasn’t already done. Today is no different, so we’ll wait here while you get that cleaned up!

Patch Coverage - Vulnerability Scans

Anthony Perez did a great job of explaining how to identify vulnerable systems for CVE-2020-0601 in his January blog post, "Rapidly Identifying Systems Critically Vulnerable to CVE-2020-0601 and Reporting for CISA Emergency Directive 20-02." Here, I’ve provided you with an updated Search Processing Language (SPL) in case you’re in a rush to double check your patch coverage using Vulnerability scans. I’ve changed the CVE number and affected KB article numbers. There are more than last time as this affects supported operating systems going all the way back to Server 2008!

| tstats count from datamodel=Vulnerabilities.Vulnerabilities where Vulnerabilities.cve=* Vulnerabilities.mskb=* by Vulnerabilities.cve Vulnerabilities.mskb Vulnerabilities.dest 

| search Vulnerabilities.cve=cve-2020-1350 OR Vulnerabilities.mskb=4565536 OR Vulnerabilities.mskb=4556529 OR Vulnerabilities.mskb=4565524 OR Vulnerabilities.mskb=4565537 OR Vulnerabilities.mskb=4565535 OR Vulnerabilities.mskb=4565541 OR 

Vulnerabilities.mskb=4565511 OR Vulnerabilities.mskb=4558998 OR

Vulnerabilities.mskb=4565483 OR Vulnerabilities.mskb=4565503

| rename Vulnerabilities.dest as Vulnerable_Host Vulnerabilities.cve as CVE Vulnerabilities.mskb as Microsoft_KB 

| table Vulnerable_Host, CVE, Microsoft_KB

Follow the rest of Anthony’s blog post to learn more about additional detection mechanisms, such as using the operating system (OS) and the contents of the “Inventory” data model as a second pass, ensuring complete patch coverage against this nasty vulnerability.

For customers concerned with detecting the implementation of the Windows-based registry workaround (e.g., those that cannot patch and need to follow CISA ED 20-03), you want to review a neat capability of the Universal Forwarder to monitor and log on registry changes. Take a look here for the inputs.conf guidance on configuring that stanza. 

Wire Data and You

I promised we’d talk about detecting exploitation attempts using wire data, and I’m a man of my word. Again, my blog post from earlier this year showed the power of wire data to help augment log-based detections and expand coverage for your security team. In that blog, I explained how Zeek (Bro) is one of my favorite tools for this task. Take a read over there if you want to see how Zeek data works inside of Splunk. If you’re looking for a Zeek detection script, take a peek at this Corelight Github repository and consider deploying it on your sensors. 

You might be asking what to do if you aren’t a Zeek shop, but love the idea of wire data detections? Take a look at Splunk Stream! For those that aren’t familiar with Stream, it’s a purpose-built wire data collection and analytics tool. It can handle streaming data (read: wire data) and can also help threat hunters by natively ingesting PCAP data as well. 

While discussing this vulnerability with colleagues, fellow Splunker Shannon Davis offered up some handy SPL to use DNS traffic analyzed by Stream. 

index=<your_index_here> sourcetype=stream:dns message_type=RESPONSE 

| spath "query_type{}" 

| search "query_type{}"=SIG OR "query_type{}"=KEY 

| spath bytes_out 

| search bytes_out>=65258

Shannon’s search makes use of the spath command to solve for some JSON intricacies. If you reviewed the Zeek detection script earlier, you’ll see that we’re focused on the “detected with high confidence” — meaning DNS SIG or KEY queries with large responses. Shannon also warns us that depending on where Stream is configured in your environment and the direction of the traffic flows, you may need to swap bytes_out for bytes_in. With all detections and security controls, make sure you test thoroughly before deploying to production!

If you want to supercharge this search, I want to mention that now would be a great opportunity to use Common Information Model (CIM) Accelerated Data Models. Unfortunately, without modification of the default models, we cannot. According to the documentation for the Network Resolution (DNS) data model, certain traffic characteristics, such as size are not included by default. 

To operationalize these efforts, Splunk Enterprise Security customers would want to take the next step of building the detection into a Correlation Search and alert SOC analysts, keeping leadership informed of possible incidents. Splunk Phantom customers can take the unpatched systems identified and leverage playbooks to automatically contain the event, providing remediation steps like pushing the patch again, or moving devices into protected VLANs or even shutting down switch ports.

Today, we’ve taken two important steps towards ensuring the security of our systems and helping meet CISA ED 20-03 requirements. By checking for vulnerabilities seen via vulnerability scans and including detection mechanisms using wire data, your analysts can feel a little more confident. That is, until the next 10.0 rated CVE comes out… 

Happy Splunking!
Drew