Abnormally Large DNS Response
Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/07/16"
3integration = ["network_traffic"]
4maturity = "production"
5updated_date = "2024/05/21"
6
7[rule]
8author = ["Elastic"]
9description = """
10Specially crafted DNS requests can manipulate a known overflow vulnerability in some Windows DNS servers, resulting in
11Remote Code Execution (RCE) or a Denial of Service (DoS) from crashing the service.
12"""
13false_positives = [
14 """
15 Environments that leverage DNS responses over 60k bytes will result in false positives - if this traffic is
16 predictable and expected, it should be filtered out. Additionally, this detection rule could be triggered by an
17 authorized vulnerability scan or compromise assessment.
18 """,
19]
20index = ["packetbeat-*", "filebeat-*", "logs-network_traffic.*"]
21language = "kuery"
22license = "Elastic License v2"
23name = "Abnormally Large DNS Response"
24note = """## Triage and analysis
25
26### Investigating Abnormally Large DNS Response
27
28Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as [SigRed](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.
29
30#### Possible investigation steps
31
32- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment.
33- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts.
34- Further examination can include a review of the `dns.question_type` network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, for `SIG` or `RRSIG` data.
35- Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning.
36- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.
37
38#### False positive analysis
39
40- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. In packet capture files received by the [SANS Internet Storm Center](https://isc.sans.edu/forums/diary/PATCH+NOW+SIGRed+CVE20201350+Microsoft+DNS+Server+Vulnerability/26356/), byte responses were all observed as greater than 65k bytes.
41- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host.
42
43### Related rules
44
45- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45
46- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9
47
48### Response and remediation
49
50- Initiate the incident response process based on the outcome of the triage.
51- Ensure that you have deployed the latest Microsoft [Security Update](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350) (Monthly Rollup or Security Only) and restarted the patched machines. If unable to patch immediately, Microsoft [released](https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability) a registry-based workaround that doesn’t require a restart. This can be used as a temporary solution before the patch is applied.
52- Maintain backups of your critical systems to aid in quick recovery.
53- Perform routine vulnerability scans of your systems, monitor [CISA advisories](https://us-cert.cisa.gov/ncas/current-activity) and patch identified vulnerabilities.
54- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.
55"""
56references = [
57 "https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
58 "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/",
59 "https://github.com/maxpl0it/CVE-2020-1350-DoS",
60 "https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability",
61]
62risk_score = 47
63rule_id = "11013227-0301-4a8c-b150-4db924484475"
64severity = "medium"
65tags = [
66 "Use Case: Threat Detection",
67 "Tactic: Lateral Movement",
68 "Resources: Investigation Guide",
69 "Use Case: Vulnerability",
70]
71timestamp_override = "event.ingested"
72type = "query"
73
74query = '''
75(event.dataset: network_traffic.dns or (event.category: (network or network_traffic) and destination.port: 53)) and
76 (event.dataset:zeek.dns or type:dns or event.type:connection) and network.bytes > 60000
77'''
78
79
80[[rule.threat]]
81framework = "MITRE ATT&CK"
82[[rule.threat.technique]]
83id = "T1210"
84name = "Exploitation of Remote Services"
85reference = "https://attack.mitre.org/techniques/T1210/"
86
87
88[rule.threat.tactic]
89id = "TA0008"
90name = "Lateral Movement"
91reference = "https://attack.mitre.org/tactics/TA0008/"
Triage and analysis
Investigating Abnormally Large DNS Response
Detection alerts from this rule indicate possible anomalous activity around large byte DNS responses from a Windows DNS server. This detection rule was created based on activity represented in exploitation of vulnerability (CVE-2020-1350) also known as SigRed during July 2020.
Possible investigation steps
- This specific rule is sourced from network log activity such as DNS or network level data. It's important to validate the source of the incoming traffic and determine if this activity has been observed previously within an environment.
- Activity can be further investigated and validated by reviewing any associated Intrusion Detection Signatures (IDS) alerts.
- Further examination can include a review of the
dns.question_type
network fieldset with a protocol analyzer, such as Zeek, Packetbeat, or Suricata, forSIG
orRRSIG
data. - Validate the patch level and OS of the targeted DNS server to validate the observed activity was not large-scale internet vulnerability scanning.
- Validate that the source of the network activity was not from an authorized vulnerability scan or compromise assessment.
False positive analysis
- Based on this rule, which looks for a threshold of 60k bytes, it is possible for activity to be generated under 65k bytes and related to legitimate behavior. In packet capture files received by the SANS Internet Storm Center, byte responses were all observed as greater than 65k bytes.
- This activity can be triggered by compliance/vulnerability scanning or compromise assessment; it's important to determine the source of the activity and potentially allowlist the source host.
Related rules
- Unusual Child Process of dns.exe - 8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45
- Unusual File Modification by dns.exe - c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9
Response and remediation
- Initiate the incident response process based on the outcome of the triage.
- Ensure that you have deployed the latest Microsoft Security Update (Monthly Rollup or Security Only) and restarted 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, monitor CISA advisories and patch identified vulnerabilities.
- If you observe a true positive, implement a remediation plan and monitor host-based artifacts for additional post-exploitation behavior.
References
Related rules
- Potential Privilege Escalation via InstallerFileTakeOver
- Potential Remote Code Execution via Web Server
- Potential Remote Credential Access via Registry
- Attempt to Mount SMB Share via Command Line
- Connection to External Network via Telnet