A modern SIEM centralizes security alerts from various sources and identifies artifacts to detect threats. Through data aggregation and leveraging correlation and machine learning techniques, SIEMs provide an integrated view of all security events in a single platform, including malicious activity that indicate the presence of bad actors exploiting a vulnerability.
‘SIGRed’ is a recent vulnerability that was brought to light by the Checkpoint research team. Researchers discovered a flaw in the implementation of the Windows DNS server while trying to find an attack path to compromise a Windows domain environment. More details on the Checkpoint research and the SIGRed vulnerability can be found here. In this post we will learn about the signals to look for in your SIEM in order to detect the SIGRed vulnerability and how Exabeam Advanced Analytics detects SIGRed.
What is the domain name system (DNS)
DNS is a network protocol that translates human-friendly domain names, such as www.exabeam.com to IP addresses. DNS uses client-server architecture and is hierarchical in nature.
- The client sends a DNS request (query) to the server
- If the server knows the answer to the request, it sends a response to the client
- If not, the server forwards the query to the next DNS server in the hierarchy
DNS operates over port 53 and uses UDP for requests/responses smaller than 512 bytes and TCP for requests/responses up to 65,535 bytes.
The SIGRed vulnerability
SIGRed (CVE-2020-1350) is a remote code execution vulnerability in Windows DNS Server that affects Windows Server versions 2003 through 2019. The vulnerability was first discovered and reported by the Checkpoint research team and given the name SIGRed. ‘Windows DNS’ is Microsoft’s implementation of DNS. It is a critical component of any Windows domain environment and is usually installed on Domain Controllers or Member Servers. The SIGRed vulnerability is the result of a 17–year-old bug in Microsoft’s implementation of parsing incoming DNS queries and DNS responses to forwarded queries in the Windows DNS Server. The bug is an exploitable integer overflow leading to a heap-based buffer overflow when parsing DNS responses with a SIG record larger than 64KB.
The vulnerability was assigned a CVSS score of 10 out of 10 because of its ‘wormable’ nature, meaning it can spread to other vulnerable systems on the network without user interaction such as by an internet worm. As the DNS service runs with SYSTEM privileges, if this vulnerability is successfully exploited, the attacker can gain domain administrator rights. However, the vulnerability does not affect Windows DNS clients and non-Microsoft DNS servers.
A typical SIEM ingests thousands of logs every hour. But if we know what to look for in the logs, we can easily identify the artifacts that indicate malicious activity. In this section, we will see how Exabeam products identify SIGRed artifacts by filtering through thousands of logs with simple search queries and detection rules and how you can set up your Exabeam deployment to detect SIGRed.
Identifying SIGRed artifacts in Exabeam Data Lake
Search for SIGRed artifacts with the following steps:
- Filter the Windows logs to look for process creation events where dns.exe is spawning suspicious child processes.
event_code:"4688" AND parent_process_name:"dns.exe"
Figure 1: Start by filtering the Windows logs to look for suspicious dns.exe activity.
- 2. Filter the query to exclude known non-malicious sub processes to reduce false positives.
event_code:“4688” AND parent_process_name:“dns.exe” AND NOT process_name:“conhost.exe”
Figure 2: Exclude non-malicious sub processes such as “conhost.exe”, “werfault.exe” and “dnscmd.exe”.
Save your search to automate detection of SIGred artifacts in Data Lake.
Detecting SIGRed in Exabeam Advanced Analytics
With Exabeam Advanced Analytics you can activate rules for the platform to automatically detect SIGRed. Download our Content Pack Version 2020.8 for the rule.
As shown in the Advanced Analytics timeline below, we can detect SIGRed by auditing Windows Process Creation logs and looking for any suspicious child processes spawned off Windows DNS service (dns.exe).
Figure 3: Exabeam Advanced Analytics Timeline audits Windows Process Creation logs for suspicious activity that indicates evidence of SIGRed.
Additional ways to detect SIGRed
As mentioned in the Checkpoint research, SIGRed can be exploited by larger DNS responses. So, one more way to detect SIGRed is to alert on network traffic larger than 64KB on port 53.
Log source: Windows
event_code=4688 and parent_process_name=‘dns.exe’ and not (process_name=‘conhost.exe’ or process_name=‘werfault.exe’ or process_name=‘dnscmd.exe’)
A Sigma rule for Windows log artifact can be found here.
Log source: Sysmon
event_code=1 and parent_process_name=‘dns.exe’ and not (process_name=‘conhost.exe’ or process_name=‘werfault.exe’ or process_name=‘dnscmd.exe’)
Log source: network traffic
dest_port=53 and bytes>64kb
Proof-of-concept (PoC) code
At the time of writing there is no known working PoC code publicly available. However, maxpl0it created a PoC for Windows DNS denial-of-service (DoS) using the SIGRed vulnerability.