Detection rules for SIGRed vulnerability

To defend your environment from the SIGRed vulnerability, we recommend implementing the detection logic included below into your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.

Executive summary

On July 14, 2020, Microsoft released a security update related to a remote code execution (RCE) and denial of service (DoS) vulnerability (CVE-2020-1350) in Windows DNS Server (2003 - 2019).

まとめ

National Institute of Standards and Technology (NIST) assigned a critical CVSS scoreof 10 out of 10 based on remote code execution without authentication and potential to self-replicate without user interaction
The vulnerability is estimated to be 17 years old and impacts older operating systems (Windows 2003+), which may no longer be supported
The DNS role, which must be enabled to be impacted, is enabled in most environments, and is required by Active Directory and Kerberos services
The vulnerability was reported by Check Point Research and given name “SIGRed”

Timeline of events

May 19, 2020 - Initial Check Point disclosure sent to Microsoft
June 18, 2020 - CVE-2020-1350 issued to vulnerability
July 14, 2020 - Microsoft released patch
July 16, 2020 - First public DoS proof-of-concept published
July 17, 2020 - Elastic releases SIGRed public detection logic

インパクト

All systems leveraging the Windows DNS server service are impacted (Windows 2003+). This includes machines such as domain controllers/member servers leveraging Active Directory/Kerberos, as these services rely on the Windows DNS service.

Of note, this is an impact on the way Windows DNS server improperly handles malformed requests and not an underlying issue with the DNS protocol itself.

The SIGRed exploit leverages multiple tactics and techniques categorized by the MITRE ATT&CK® framework:

戦術（Tactics）

手法

検知

検知のロジック

On June 30, 2020, The Elastic Security Intelligence & Analytics Team released our Detection Rules Repository to the public. Expanding on the rules that were released with that post, we’ve included network and endpoint rules that target CVE-2020-1350 (SIGRed) in the public repository:

Unusual child of dns.exe - Kibana Query Language (KQL)

The detection logic in Figure 1 (below) identifies suspicious or unexpected child processes spawned from the Windows DNS service (dns.exe). This activity may indicate activity related to remote code execution (RCE) or other forms of exploitation.

event.category:process and event.type:start and process.parent.name:dns.exe and not process.name:conhost.exe

Figure 1 - Unusual child process of dns.exe

Unusual file operations of dns.exe (KQL)

The detection logic in Figure 2 (below) identifies suspicious or unexpected files being modified by the Windows DNS service (dns.exe). This not only indicates potential RCE or exploitation, but may also indicate preparation for post-compromise activities. For example, this service which is running with SYSTEM privileges could be used to silently write a DLL to Windows system folder setting up possible execution through a known DLL side-loading vector.

event.category:file and process.name:dns.exe and not file.name:dns.log

Figure 2 - Unusual file modification by dns.exe

Network (Packetbeat and Filebeat with the Zeek or Suricata modules)

As detailed in the Check Point SIGRed research, abnormally large DNS responses can cause the heap-based buffer overflow scenario. The logic in Figure 3 (below) identifies large DNS responses using either Packetbeat or Filebeat (with Zeek or Suricata modules enabled).

event.category:(network or network_traffic) and destination.port:53 and (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes>60000

Figure 3 - Abnormally large DNS response (KQL)

防御のための推奨アクション

Review and implement the above detection logic within your environment using technology such as Endpoint security, Winlogbeat, Packetbeat, or network security monitoring (NSM) platforms such as Zeek or Suricata.
Use the included network rule to identify large DNS queries and responses from internal and external populations.
Ensure that you have deployed the latest Microsoft Security Update (Monthly Rollup or Security Only) and restart the patched machines. If unable to patch immediately: Microsoft released a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied.
Maintain backups of your critical systems to aid in quick recovery.
Perform routine vulnerability scans of your systems and patch identified vulnerabilities.