Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions rules/network/lateral_movement_dns_server_overflow.toml
Original file line number Diff line number Diff line change
Expand Up @@ -2,21 +2,14 @@
creation_date = "2020/07/16"
integration = ["network_traffic", "panw"]
maturity = "production"
updated_date = "2026/04/29"
updated_date = "2026/05/27"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No FP section?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To match what is done in other rules, removing this per #6201 (comment). as it is covered in the guide, and generally not expected to happen.

"""
Environments that leverage DNS responses over 60k bytes will result in false positives - if this traffic is
predictable and expected, it should be filtered out. Additionally, this detection rule could be triggered by an
authorized vulnerability scan or compromise assessment.
""",
]
index = ["logs-network_traffic.*", "logs-panw.panos*"]
language = "kuery"
license = "Elastic License v2"
Expand All @@ -27,18 +20,19 @@ note = """## Triage and analysis

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](https://www.elastic.co/blog/detection-rules-for-sigred-vulnerability) during July 2020.

#### Possible investigation steps
### 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, for `SIG` or `RRSIG` 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
### 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](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.
- Based on this rule, which looks for a threshold of 65k bytes, activity below this value is expected to be legitimate. 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 in observed attacks were all 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.
- Network security devices such as PAN-OS firewalls, Fortinet, and NetFlow exporters record `destination.bytes` as the total bytes across an entire session rather than a single DNS response. Long-lived flow records (`event.duration` > 60 seconds) with `event.action` of `flow_terminated` or `network_flow` are excluded to reduce this noise. Duration is used rather than packet count because a genuine SigRed TCP exchange completes in seconds and cannot be made to exceed 60 seconds by an attacker continuing to use the connection.

### Related rules

Expand Down Expand Up @@ -78,8 +72,12 @@ query = '''
((event.category:(network or network_traffic) and destination.port:53)
or network.protocol:"dns"
or data_stream.dataset:(network_traffic.dns or zeek.dns))
and destination.bytes > 60000
and destination.bytes >= 65000
and event.type:("allowed" or "end" or "protocol" or "start")
and not (
event.action:("flow_terminated" or "network_flow")
and event.duration > 60000000000
)
'''


Expand Down
Loading