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/10/09"
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 "Noise: Medium",
59 "Performance: Normal",
60 "Profile: Recommended",
61 "Threat: Vulnerability Exploit",
62 "Rule Type: Event Correlation (EQL)",
63 "Platform: Windows",
64]
65timestamp_override = "event.ingested"
66type = "eql"
67
68query = '''
69process where host.os.type == "windows" and event.type == "start" and
70 process.parent.name : "dns.exe" and
71 not (
72 process.executable : (
73 "?:\\Windows\\System32\\conhost.exe",
74 "?:\\Windows\\System32\\dns.exe",
75 /* Crowdstrike specific exclusion as it uses NT Object paths */
76 "\\Device\\HarddiskVolume*\\Windows\\System32\\conhost.exe",
77 "\\Device\\HarddiskVolume*\\Windows\\System32\\dns.exe",
78 "\\Device\\HarddiskVolume*\\Program Files\\ReasonLabs\\*"
79 ) or
80 (
81 ?process.parent.executable : "?:\\Program Files\\ReasonLabs\\DNS\\ui\\DNS.exe"
82 )
83 )
84'''
85
86note = """## Triage and analysis
87
88### Investigating Unusual Child Process of dns.exe
89#### Possible investigation steps
90
91- What did "dns.exe" launch, and does that define a crash path or live execution path?
92 - Focus: `process.name`, `process.executable`, `process.command_line`, and `process.parent.executable`.
93 - 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.
94- Is the child binary a recognized system or DNS-support component, or a disguised payload?
95 - Focus: `process.executable`, `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, and `process.code_signature.trusted`.
96 - 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".
97- What intent does the child command line express?
98 - Focus: `process.command_line`, `process.name`, and `process.Ext.token.integrity_level_name`.
99 - 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.
100- Do lineage and session context fit the Windows DNS service?
101 - Focus: `process.parent.command_line`, `process.parent.entity_id`, `process.Ext.session_info.logon_type`, and `user.id`.
102 - 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.
103- Did the child produce follow-on execution or artifacts after the spawn?
104 - 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.
105 - $investigate_0
106 - $investigate_1
107 - $investigate_2
108 - Hint: prioritize descendant `process.command_line`, `file.path`, `registry.path`, and `destination.ip`. Missing network telemetry is unresolved, not benign.
109 - 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.
110- If local evidence remains suspicious or unresolved, do same-host alerts show the same DNS-service execution pattern?
111 - 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`.
112 - $investigate_3
113 - $investigate_4
114 - Hint: broaden scope only after child identity, command intent, lineage, or follow-on recovery remains suspicious or incomplete.
115 - Implication: escalate scope when related alerts repeat the "dns.exe" child pattern or child binary identity; unrelated or nonmatching alerts keep the case narrower.
116- 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.
117
118### False positive analysis
119
120- 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.
121- 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.
122- 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.
123
124### Response and remediation
125
126- 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.
127- 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.
128- 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.
129- 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.
130- 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.
131- 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.
132- 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.
133"""
134
135setup = """## Setup
136
137This 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.
138
139Setup instructions: https://ela.st/install-elastic-defend
140
141### Additional data sources
142
143This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
144
145- [CrowdStrike](https://ela.st/crowdstrike-integration)
146- [Microsoft Defender XDR](https://ela.st/m365-defender)
147- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
148- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
149- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
150"""
151
152[rule.investigation_fields]
153field_names = [
154 "@timestamp",
155 "host.name",
156 "host.id",
157 "user.id",
158 "process.entity_id",
159 "process.pid",
160 "process.executable",
161 "process.command_line",
162 "process.pe.original_file_name",
163 "process.hash.sha256",
164 "process.code_signature.subject_name",
165 "process.code_signature.trusted",
166 "process.parent.entity_id",
167 "process.parent.executable",
168 "process.parent.command_line",
169]
170
171[transform]
172
173[[transform.investigate]]
174label = "File and registry events for the same child process"
175description = ""
176providers = [
177 [
178 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
179 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
180 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
181 ],
182 [
183 { excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" },
184 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
185 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
186 ]
187]
188relativeFrom = "now-1h"
189relativeTo = "now"
190
191[[transform.investigate]]
192label = "Network events for the same child process"
193description = ""
194providers = [
195 [
196 { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
197 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
198 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
199 ]
200]
201relativeFrom = "now-1h"
202relativeTo = "now"
203
204[[transform.investigate]]
205label = "Child process events from the dns.exe child"
206description = ""
207providers = [
208 [
209 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
210 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
211 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
212 ]
213]
214relativeFrom = "now-1h"
215relativeTo = "now"
216
217[[transform.investigate]]
218label = "Process events from the same dns.exe parent"
219description = ""
220providers = [
221 [
222 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
223 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
224 { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.parent.entity_id}}", valueType = "string" }
225 ]
226]
227relativeFrom = "now-1h"
228relativeTo = "now"
229
230[[transform.investigate]]
231label = "Alerts associated with the host"
232description = ""
233providers = [
234 [
235 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
236 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
237 ]
238]
239relativeFrom = "now-48h/h"
240relativeTo = "now"
241
242[[rule.threat]]
243framework = "MITRE ATT&CK"
244
245[[rule.threat.technique]]
246id = "T1210"
247name = "Exploitation of Remote Services"
248reference = "https://attack.mitre.org/techniques/T1210/"
249
250[rule.threat.tactic]
251id = "TA0008"
252name = "Lateral Movement"
253reference = "https://attack.mitre.org/tactics/TA0008/"
254
255[[rule.threat]]
256framework = "MITRE ATT&CK"
257
258[[rule.threat.technique]]
259id = "T1190"
260name = "Exploit Public-Facing Application"
261reference = "https://attack.mitre.org/techniques/T1190/"
262
263[rule.threat.tactic]
264id = "TA0001"
265name = "Initial Access"
266reference = "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, andprocess.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.
- Focus:
- 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, andprocess.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".
- Focus:
- What intent does the child command line express?
- Focus:
process.command_line,process.name, andprocess.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.
- Focus:
- 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, anduser.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.
- Focus:
- 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+ childprocess.entity_id, orhost.id+process.pidin a tight alert window.- $investigate_0
- $investigate_1
- $investigate_2
- Hint: prioritize descendant
process.command_line,file.path,registry.path, anddestination.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.
- Focus: recovered file, registry, network, DNS, and descendant process events for
- 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, prioritizingprocess.parent.nameof "dns.exe", the same childprocess.executable, or the sameprocess.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.
- Focus: same-parent process starts and related alerts on
- 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, andhost.idform 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 samehost.idwithout 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, andhost.idmatch 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 onprocess.parent.nameof "dns.exe",process.namealone, 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.idthat 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
- Microsoft Exchange Server UM Spawning Suspicious Processes
- Mounting Hidden or WebDav Remote Shares
- Potential Remote Desktop Tunneling Detected
- Suspicious Microsoft HTML Application Child Process
- Command Execution via SolarWinds Process