Unusual Child Process of dns.exe

Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which may indicate activity related to remote code execution or other forms of exploitation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/07/16"
  3integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/05/03"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies an unexpected process spawning from dns.exe, the process responsible for Windows DNS server services, which
 11may indicate activity related to remote code execution or other forms of exploitation.
 12"""
 13false_positives = [
 14    """
 15    Werfault.exe will legitimately spawn when dns.exe crashes, but the DNS service is very stable and so this is a low
 16    occurring event. Denial of Service (DoS) attempts by intentionally crashing the service will also cause werfault.exe
 17    to spawn.
 18    """,
 19]
 20from = "now-9m"
 21index = [
 22    "endgame-*",
 23    "logs-crowdstrike.fdr*",
 24    "logs-endpoint.events.process-*",
 25    "logs-m365_defender.event-*",
 26    "logs-sentinel_one_cloud_funnel.*",
 27    "logs-system.security*",
 28    "logs-windows.forwarded*",
 29    "logs-windows.sysmon_operational-*",
 30    "winlogbeat-*",
 31]
 32language = "eql"
 33license = "Elastic License v2"
 34name = "Unusual Child Process of dns.exe"
 35references = [
 36    "https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
 37    "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/",
 38    "https://github.com/maxpl0it/CVE-2020-1350-DoS",
 39    "https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability",
 40]
 41risk_score = 73
 42rule_id = "8c37dc0e-e3ac-4c97-8aa0-cf6a9122de45"
 43severity = "high"
 44tags = [
 45    "Domain: Endpoint",
 46    "OS: Windows",
 47    "Use Case: Threat Detection",
 48    "Tactic: Lateral Movement",
 49    "Resources: Investigation Guide",
 50    "Data Source: Elastic Endgame",
 51    "Use Case: Vulnerability",
 52    "Data Source: Elastic Defend",
 53    "Data Source: Windows Security Event Logs",
 54    "Data Source: Microsoft Defender XDR",
 55    "Data Source: Sysmon",
 56    "Data Source: SentinelOne",
 57    "Data Source: Crowdstrike",
 58]
 59timestamp_override = "event.ingested"
 60type = "eql"
 61
 62query = '''
 63process where host.os.type == "windows" and event.type == "start" and
 64  process.parent.name : "dns.exe" and
 65  not process.executable : (
 66    "?:\\Windows\\System32\\conhost.exe",
 67    "?:\\Windows\\System32\\dns.exe",
 68
 69    /* Crowdstrike specific exclusion as it uses NT Object paths */
 70    "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
 71    "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe",
 72    "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*"
 73  ) and
 74  not ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe"
 75'''
 76
 77note = """## Triage and analysis
 78
 79### Investigating Unusual Child Process of dns.exe
 80#### Possible investigation steps
 81
 82- What did "dns.exe" launch, and does that define a crash path or live execution path?
 83  - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`.
 84  - Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks.
 85- Is the child binary a recognized system or DNS-support component, or a disguised payload?
 86  - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
 87  - Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe".
 88- What intent does the child command line express?
 89  - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`.
 90  - Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling.
 91- Do lineage and session context fit the Windows DNS service?
 92  - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`.
 93  - Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child.
 94- Did the child produce follow-on execution or artifacts after the spawn?
 95  - Focus: recovered file, registry, network, DNS, and descendant process events for `host.id` + child `process.entity_id`, or `host.id` + `process.pid` in a tight alert window.
 96    - $investigate_0
 97    - $investigate_1
 98    - $investigate_2
 99  - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign.
100  - Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone.
101- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern?
102  - Focus: same-parent process starts and related alerts on `host.id`, prioritizing `process.parent.name` of "dns.exe", the same child `process.executable`, or the same `process.hash.sha256`.
103    - $investigate_3
104    - $investigate_4
105  - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete.
106  - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower.
107- Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete.
108
109### False positive analysis
110
111- Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, `process.command_line`, signer, and `host.id` form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same `host.id` without payload descendants or artifact creation.
112- Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact `process.executable`, `process.code_signature.subject_name`, `process.command_line`, `process.parent.executable`, and `host.id` match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved.
113- Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected `host.id`. Avoid exceptions on `process.parent.name` of "dns.exe", `process.name` alone, or the entire host.
114
115### Response and remediation
116
117- If suspicious but unconfirmed, preserve the child `process.entity_id`, `process.executable`, `process.hash.sha256`, signer details, `process.command_line`, `process.parent.command_line`, crash dumps, recovered endpoint events, and any collected payload artifacts before containment.
118- Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected `host.id`. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely.
119- If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and `host.id` that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts.
120- If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage.
121- Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems.
122- Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server.
123- Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited triage.
124"""
125
126setup = """## Setup
127
128This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
129
130Setup instructions: https://ela.st/install-elastic-defend
131
132### Additional data sources
133
134This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
135
136- [CrowdStrike](https://ela.st/crowdstrike-integration)
137- [Microsoft Defender XDR](https://ela.st/m365-defender)
138- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
139- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
140- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
141"""
142
143[rule.investigation_fields]
144field_names = [
145    "@timestamp",
146    "host.name",
147    "host.id",
148    "user.id",
149    "process.entity_id",
150    "process.pid",
151    "process.executable",
152    "process.command_line",
153    "process.pe.original_file_name",
154    "process.hash.sha256",
155    "process.code_signature.subject_name",
156    "process.code_signature.trusted",
157    "process.parent.entity_id",
158    "process.parent.executable",
159    "process.parent.command_line",
160]
161
162[transform]
163
164[[transform.investigate]]
165label = "File and registry events for the same child process"
166description = ""
167providers = [
168  [
169    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
170    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
171    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
172  ],
173  [
174    { excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" },
175    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
176    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
177  ]
178]
179relativeFrom = "now-1h"
180relativeTo = "now"
181
182[[transform.investigate]]
183label = "Network events for the same child process"
184description = ""
185providers = [
186  [
187    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
188    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
189    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
190  ]
191]
192relativeFrom = "now-1h"
193relativeTo = "now"
194
195[[transform.investigate]]
196label = "Child process events from the dns.exe child"
197description = ""
198providers = [
199  [
200    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
201    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
202    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
203  ]
204]
205relativeFrom = "now-1h"
206relativeTo = "now"
207
208[[transform.investigate]]
209label = "Process events from the same dns.exe parent"
210description = ""
211providers = [
212  [
213    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
214    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
215    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
216  ]
217]
218relativeFrom = "now-1h"
219relativeTo = "now"
220
221[[transform.investigate]]
222label = "Alerts associated with the host"
223description = ""
224providers = [
225  [
226    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
227    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
228  ]
229]
230relativeFrom = "now-48h/h"
231relativeTo = "now"
232
233[[rule.threat]]
234framework = "MITRE ATT&CK"
235
236[[rule.threat.technique]]
237id = "T1210"
238name = "Exploitation of Remote Services"
239reference = "https://attack.mitre.org/techniques/T1210/"
240
241[rule.threat.tactic]
242id = "TA0008"
243name = "Lateral Movement"
244reference = "https://attack.mitre.org/tactics/TA0008/"
245
246[[rule.threat]]
247framework = "MITRE ATT&CK"
248
249[[rule.threat.technique]]
250id = "T1190"
251name = "Exploit Public-Facing Application"
252reference = "https://attack.mitre.org/techniques/T1190/"
253
254[rule.threat.tactic]
255id = "TA0001"
256name = "Initial Access"
257reference = "https://attack.mitre.org/tactics/TA0001/"

Triage and analysis

Investigating Unusual Child Process of dns.exe

Possible investigation steps

  • What did "dns.exe" launch, and does that define a crash path or live execution path?
    • Focus: process.name, process.executable, process.command_line, and process.parent.executable.
    • Implication: escalate quickly for shells, script hosts, downloaders, service tools, or non-Windows paths spawned by "dns.exe"; a bounded "WerFault.exe" crash-reporting child points toward DNS service fault or SIGRed DoS, but still needs follow-on checks.
  • Is the child binary a recognized system or DNS-support component, or a disguised payload?
    • Focus: process.executable, process.hash.sha256, process.pe.original_file_name, process.code_signature.subject_name, and process.code_signature.trusted.
    • Implication: escalate when the child is unsigned, renamed, user-writable, newly seen, or PE-mismatched; a recognized Microsoft or vendor identity lowers only identity concern and does not clear unexpected execution from "dns.exe".
  • What intent does the child command line express?
    • Focus: process.command_line, process.name, and process.Ext.token.integrity_level_name.
    • Implication: escalate for discovery, script interpretation, download, service change, credential, or persistence behavior under the DNS service token; crash-reporting or bounded diagnostic arguments support fault handling.
  • Do lineage and session context fit the Windows DNS service?
    • Focus: process.parent.command_line, process.parent.entity_id, process.Ext.session_info.logon_type, and user.id.
    • Implication: escalate when parent, service, or user context does not fit a stable Windows DNS service launch; expected service lineage supports but does not prove a benign child.
  • Did the child produce follow-on execution or artifacts after the spawn?
    • Focus: recovered file, registry, network, DNS, and descendant process events for host.id + child process.entity_id, or host.id + process.pid in a tight alert window.
      • $investigate_0
      • $investigate_1
      • $investigate_2
    • Hint: prioritize descendant process.command_line, file.path, registry.path, and destination.ip. Missing network telemetry is unresolved, not benign.
    • Implication: escalate when recovered events show descendants, payload staging, persistence changes, or outbound activity; no follow-on activity supports a crash-only hypothesis but cannot clear the alert alone.
  • If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern?
    • Focus: same-parent process starts and related alerts on host.id, prioritizing process.parent.name of "dns.exe", the same child process.executable, or the same process.hash.sha256.
      • $investigate_3
      • $investigate_4
    • Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete.
    • Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower.
  • Escalate for live execution intent, suspicious identity or lineage, or recovered post-exploitation artifacts; close only when evidence tightly binds one crash-handling or recognized DNS-support workflow on this host; preserve artifacts and escalate when evidence is mixed or incomplete.

False positive analysis

  • Crash handling can legitimately produce "WerFault.exe" after a DNS service fault or SIGRed DoS attempt. Confirm that child identity, process.command_line, signer, and host.id form a crash-reporting pattern and recovered follow-on endpoint activity does not contradict it. Use incident records only as corroboration; telemetry-only closure requires a crash-reporter-only pattern on the same host.id without payload descendants or artifact creation.
  • Named DNS/security tooling, such as ReasonLabs DNS components in the rule exclusions, explains the alert only when exact process.executable, process.code_signature.subject_name, process.command_line, process.parent.executable, and host.id match that product workflow. Treat generic vendor claims, partial matches, or a trusted signer without matching behavior as unresolved.
  • Before creating an exception, anchor it on exact child path, signer or certificate thumbprint when available, command line, parent DNS service path, and affected host.id. Avoid exceptions on process.parent.name of "dns.exe", process.name alone, or the entire host.

Response and remediation

  • If suspicious but unconfirmed, preserve the child process.entity_id, process.executable, process.hash.sha256, signer details, process.command_line, process.parent.command_line, crash dumps, recovered endpoint events, and any collected payload artifacts before containment.
  • Apply reversible containment before destructive action: remove the server from DNS rotation, restrict external resolver exposure, or heighten monitoring on the affected host.id. Move to host isolation only when follow-on execution or broader compromise evidence shows the server cannot serve safely.
  • If confirmed benign, reverse temporary containment and record the exact child path, signer, command line, parent DNS service path, and host.id that proved the crash-handling or DNS-support workflow. Create an exception only after the same pattern is stable across prior alerts.
  • If confirmed malicious, weigh DNS/domain-controller criticality, then isolate the server when feasible, terminate the suspicious child and descendants after evidence capture, and block confirmed malicious domains, IPs, hashes, or payload paths identified during triage.
  • Scope other DNS servers and domain controllers for the same child path, hash, command line, signer, or "dns.exe" child-process pattern before deleting artifacts or rebuilding systems.
  • Eradicate only payloads, persistence changes, or malicious child processes identified during the investigation, restore DNS service configuration from known-good state, and reset credentials only if evidence shows credential exposure or lateral movement from the server.
  • Post-incident hardening: apply the Microsoft DNS security update for CVE-2020-1350, remove temporary SIGRed workarounds only after patching is verified, and retain process plus file, registry, and network telemetry for DNS servers where gaps limited triage.

References

Related rules

to-top