Unusual File Operation by dns.exe

Identifies an unexpected file being modified by 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"]
 4maturity = "production"
 5updated_date = "2025/10/06"
 6
 7[rule]
 8author = ["Elastic"]
 9description = """
10Identifies an unexpected file being modified by 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"""
13from = "now-9m"
14index = ["winlogbeat-*", "logs-endpoint.events.file-*", "logs-windows.sysmon_operational-*", "endgame-*"]
15language = "kuery"
16license = "Elastic License v2"
17name = "Unusual File Operation by dns.exe"
18note = """## Triage and analysis
19
20> **Disclaimer**:
21> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
22
23### Investigating Unusual File Operation by dns.exe
24
25The rule flags Windows DNS Server (dns.exe) creating, changing, or deleting files that aren’t typical DNS zone or log files, which signals exploitation for code execution or abuse to stage payloads for lateral movement. After gaining execution in dns.exe via DNS RPC or parsing bugs, attackers often write a malicious EXE into System32 and register a new service, leveraging the trusted service context on a domain controller to persist and pivot.
26
27### Possible investigation steps
28
29- Validate the modified file’s full path, type, and provenance, prioritizing writes in %SystemRoot%\\System32, NETLOGON, or SYSVOL, and confirm signature, hash reputation, and compile timestamp to rapidly classify the artifact.
30- Pivot to persistence telemetry around the same timestamp by hunting for new services or scheduled tasks (e.g., SCM 7045, Security 4697, TaskScheduler 106/200) and registry autoruns that reference the file.
31- Correlate with DNS service network activity and logs for unusual RPC calls, authenticated connections from non-admin hosts, or spikes in failures/crashes that could indicate exploitation.
32- Inspect the service’s runtime state for injection indicators by reviewing recent module loads, unsigned DLLs, suspicious memory sections, and ETW/Sysmon events mapping threads that performed the write.
33- If the file is executable or a script or placed in execution-friendly locations, detonate it in a sandbox and scope the blast radius by pivoting on its hash, filename, and path across the fleet.
34
35### False positive analysis
36
37- DNS debug logging configured to write to a file with a non-.log extension (e.g., .txt) causes dns.exe to legitimately create or rotate that file during troubleshooting.
38- An administrator exports a zone to a custom-named file with a nonstandard extension (e.g., .txt or .xml), leading dns.exe to create or modify that file as part of routine maintenance.
39
40### Response and remediation
41
42- Isolate the host by removing it from DNS rotation and restricting network access to management-only, then capture and quarantine any files dns.exe created or modified outside %SystemRoot%\\System32\\Dns or with executable extensions.
43- Delete or quarantine suspicious artifacts written by dns.exe (e.g., .exe, .dll, .ps1, .js) in %SystemRoot%\\System32, NETLOGON, or SYSVOL, record their hashes, and block them fleetwide via EDR or application control.
44- Remove persistence by disabling and deleting any new or altered Windows services, scheduled tasks, or Run/Autorun registry entries that reference the dns.exe-written file path, and restore legitimate service ImagePath values.
45- Recover by repairing system files with SFC/DISM, restoring affected directories from known-good backups, and restarting the DNS service, then validate zone integrity, AD replication, and client name-resolution.
46- Immediately escalate to incident response if dns.exe wrote an executable or script into NETLOGON or SYSVOL or if a service binary path was changed to point to a newly dropped file, indicating probable domain controller compromise and lateral movement.
47- Harden by applying the latest Windows Server DNS patches, enforcing WDAC/AppLocker to block execution from SYSVOL/NETLOGON and restrict dns.exe writes to the DNS and log directories, and enable auditing on service creation and file writes in System32/NETLOGON/SYSVOL.
48"""
49references = [
50    "https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin-exploiting-a-17-year-old-bug-in-windows-dns-servers/",
51    "https://msrc-blog.microsoft.com/2020/07/14/july-2020-security-update-cve-2020-1350-vulnerability-in-windows-domain-name-system-dns-server/",
52    "https://www.elastic.co/security-labs/detection-rules-for-sigred-vulnerability",
53]
54risk_score = 47
55rule_id = "c7ce36c0-32ff-4f9a-bfc2-dcb242bf99f9"
56severity = "medium"
57tags = [
58    "Domain: Endpoint",
59    "OS: Windows",
60    "Use Case: Threat Detection",
61    "Tactic: Lateral Movement",
62    "Data Source: Elastic Endgame",
63    "Use Case: Vulnerability",
64    "Data Source: Elastic Defend",
65    "Data Source: Sysmon",
66    "Resources: Investigation Guide",
67]
68timestamp_override = "event.ingested"
69type = "new_terms"
70
71query = '''
72event.category : "file" and host.os.type : "windows" and
73  event.type : ("creation" or "deletion" or "change") and process.name : "dns.exe" and
74  not file.extension : ("old" or "temp" or "bak" or "dns" or "arpa" or "log")
75'''
76
77
78[[rule.threat]]
79framework = "MITRE ATT&CK"
80[[rule.threat.technique]]
81id = "T1210"
82name = "Exploitation of Remote Services"
83reference = "https://attack.mitre.org/techniques/T1210/"
84
85
86[rule.threat.tactic]
87id = "TA0008"
88name = "Lateral Movement"
89reference = "https://attack.mitre.org/tactics/TA0008/"
90
91
92[rule.new_terms]
93field = "new_terms_fields"
94value = ["file.path", "host.id"]
95[[rule.new_terms.history_window_start]]
96field = "history_window_start"
97value = "now-7d"

Triage and analysis

Disclaimer: This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

Investigating Unusual File Operation by dns.exe

The rule flags Windows DNS Server (dns.exe) creating, changing, or deleting files that aren’t typical DNS zone or log files, which signals exploitation for code execution or abuse to stage payloads for lateral movement. After gaining execution in dns.exe via DNS RPC or parsing bugs, attackers often write a malicious EXE into System32 and register a new service, leveraging the trusted service context on a domain controller to persist and pivot.

Possible investigation steps

  • Validate the modified file’s full path, type, and provenance, prioritizing writes in %SystemRoot%\System32, NETLOGON, or SYSVOL, and confirm signature, hash reputation, and compile timestamp to rapidly classify the artifact.
  • Pivot to persistence telemetry around the same timestamp by hunting for new services or scheduled tasks (e.g., SCM 7045, Security 4697, TaskScheduler 106/200) and registry autoruns that reference the file.
  • Correlate with DNS service network activity and logs for unusual RPC calls, authenticated connections from non-admin hosts, or spikes in failures/crashes that could indicate exploitation.
  • Inspect the service’s runtime state for injection indicators by reviewing recent module loads, unsigned DLLs, suspicious memory sections, and ETW/Sysmon events mapping threads that performed the write.
  • If the file is executable or a script or placed in execution-friendly locations, detonate it in a sandbox and scope the blast radius by pivoting on its hash, filename, and path across the fleet.

False positive analysis

  • DNS debug logging configured to write to a file with a non-.log extension (e.g., .txt) causes dns.exe to legitimately create or rotate that file during troubleshooting.
  • An administrator exports a zone to a custom-named file with a nonstandard extension (e.g., .txt or .xml), leading dns.exe to create or modify that file as part of routine maintenance.

Response and remediation

  • Isolate the host by removing it from DNS rotation and restricting network access to management-only, then capture and quarantine any files dns.exe created or modified outside %SystemRoot%\System32\Dns or with executable extensions.
  • Delete or quarantine suspicious artifacts written by dns.exe (e.g., .exe, .dll, .ps1, .js) in %SystemRoot%\System32, NETLOGON, or SYSVOL, record their hashes, and block them fleetwide via EDR or application control.
  • Remove persistence by disabling and deleting any new or altered Windows services, scheduled tasks, or Run/Autorun registry entries that reference the dns.exe-written file path, and restore legitimate service ImagePath values.
  • Recover by repairing system files with SFC/DISM, restoring affected directories from known-good backups, and restarting the DNS service, then validate zone integrity, AD replication, and client name-resolution.
  • Immediately escalate to incident response if dns.exe wrote an executable or script into NETLOGON or SYSVOL or if a service binary path was changed to point to a newly dropped file, indicating probable domain controller compromise and lateral movement.
  • Harden by applying the latest Windows Server DNS patches, enforcing WDAC/AppLocker to block execution from SYSVOL/NETLOGON and restrict dns.exe writes to the DNS and log directories, and enable auditing on service creation and file writes in System32/NETLOGON/SYSVOL.

References

Related rules

to-top