Network Activity to a Suspicious Top Level Domain

Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/08/20"
  3integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/03/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies DNS queries to commonly abused Top Level Domains by common LOLBINs or executables running from world writable
 11directories or unsigned binaries. This behavior matches on common malware C2 abusing less formal domain names.
 12"""
 13from = "now-9m"
 14index = [
 15    "endgame-*",
 16    "logs-endpoint.events.network-*",
 17    "logs-sentinel_one_cloud_funnel.*",
 18    "logs-crowdstrike.fdr*",
 19    "logs-windows.sysmon_operational-*",
 20    "winlogbeat-*"
 21]
 22language = "eql"
 23license = "Elastic License v2"
 24name = "Network Activity to a Suspicious Top Level Domain"
 25references = ["https://www.cybercrimeinfocenter.org/top-20-tlds-by-malicious-phishing-domains"]
 26risk_score = 73
 27rule_id = "e516bf56-d51b-43e8-91ec-9e276331f433"
 28severity = "high"
 29tags = [
 30    "Domain: Endpoint",
 31    "OS: Windows",
 32    "Use Case: Threat Detection",
 33    "Tactic: Command and Control",
 34    "Resources: Investigation Guide",
 35    "Data Source: Elastic Endgame",
 36    "Data Source: Elastic Defend",
 37    "Data Source: SentinelOne",
 38    "Data Source: Crowdstrike",
 39    "Data Source: Sysmon",
 40]
 41timestamp_override = "event.ingested"
 42type = "eql"
 43
 44query = '''
 45network where host.os.type == "windows" and dns.question.name != null and
 46 (
 47  process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe",
 48                  "bitsadmin.exe", "InstallUtil.exe", "python.exe", "regsvr32.exe", "dllhost.exe", "node.exe", "curl.exe",
 49                  "java.exe", "javaw.exe", "*.pif", "*.com", "*.scr") or
 50  (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or
 51  ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or
 52  ?process.executable : (
 53    "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe",
 54    "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe"
 55  )
 56 ) and
 57dns.question.name regex """.*\.(top|buzz|xyz|rest|ml|cf|gq|ga|onion|monster|cyou|quest|cc|bar|cfd|click|cam|surf|tk|shop|club|icu|pw|ws|online|fun|life|boats|store|hair|skin|motorcycles|christmas|lol|makeup|mom|bond|beauty|biz|live|work|zip|country|accountant|date|party|science|loan|win|men|faith|review|racing|download|host|zone)""" and
 58
 59not process.executable : (
 60    "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe",
 61    "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe"
 62)
 63'''
 64
 65note = """## Triage and analysis
 66
 67### Investigating Network Activity to a Suspicious Top Level Domain
 68
 69#### Possible investigation steps
 70
 71- Does the alert-local DNS result and domain shape fit the process role?
 72  - Focus: the alert's `event.action`, `dns.question.name`, `dns.Ext.status`, and `dns.resolved_ip`; use "lookup_result" for resolved IPs and "lookup_requested" for failed or request-only lookups.
 73  - Implication: concern rises when the name is algorithmic, newly introduced for that tool, or resolves to unrelated external infrastructure; weaker when the lookup fails immediately or the domain matches a known vendor pattern for that process, but a failed lookup alone does not clear the process. `.onion` lookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration.
 74
 75- Is the alerting binary the expected tool in the expected install context?
 76  - Focus: `process.executable`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.pe.original_file_name`.
 77  - Implication: more concerning when the binary is unsigned, renamed, user-writable, or inconsistent with its usual signer. Identity alone does not clear the DNS behavior.
 78
 79- Does the command line and launch chain fit a legitimate workflow?
 80  - Focus: `process.command_line`, `process.parent.executable`, and `process.parent.command_line`.
 81  - Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive.
 82
 83- Does the same process resolve the domain and then communicate with the returned infrastructure?
 84  - Why: a suspicious DNS lookup carries more weight when the same process reuses the returned IPs for follow-on connections or transfer behavior in the same window.
 85  - Focus: process-scoped "lookup_result" and connection events on the same `host.id`, using `dns.resolved_ip` to bridge `dns.question.name` to `destination.ip`; treat `destination.as.organization.name` as ownership context rather than a verdict. $investigate_2
 86  - Hint: if the transform returns no results, broaden to host-scoped network events around the alert time.
 87  - Implication: escalate when the same process repeatedly resolves the domain, connects to the returned IPs, or shows suspicious transfer patterns; lower suspicion when activity is limited to a one-off lookup with no matching connection behavior. Missing follow-on network telemetry is unresolved, not benign.
 88
 89- Do file events or child processes from the same process chain show download-and-execute or artifact staging?
 90  - Focus: same-host file and process activity around the alert time, scoped to the alert's `process.entity_id`, with attention to `file.path`, `file.origin_url`, `file.Ext.windows.zone_identifier`, and later `process.executable` reuse of a written path.
 91  - Hint: if file coverage is missing, keep the artifact review bounded to the same host, lineage, and alert window rather than treating the lookup as harmless.
 92  - Implication: staging risk rises when the chain writes scripts, archives, or executables to user-writable paths and later runs them.
 93
 94- Does the same process chain pivot to direct-IP traffic, lookalike domains, or TLD rotation that this rule would miss?
 95  - Why: attackers often keep the same process chain but swap to a nearby domain, a different abusive TLD, or direct-IP egress after the first lookup.
 96  - Focus: reuse the process-scoped network results from the prior step to look for direct `destination.ip` connections with no preceding DNS, sibling `dns.question.name` values under different TLDs, or repeated reuse of the same `dns.resolved_ip` across multiple domains. $investigate_2
 97  - Implication: escalate when the process shifts from the flagged lookup to direct-IP traffic, nearby domain variants, or fast domain and TLD rotation on the same infrastructure; lower suspicion when surrounding DNS stays limited to one recognized vendor domain family with no adjacent variant traffic.
 98
 99- If the local DNS, process, or artifact evidence stays suspicious or unresolved, does related alert history show this DNS pattern is isolated or part of broader compromise?
100  - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to test whether the same lineage, domain family, or follow-on activity recurs on the asset or follows the user across hosts.
101    - $investigate_0
102    - $investigate_1
103  - Implication: broaden scope when the host or user view shows repeated suspicious lineage, related delivery or persistence alerts, or reuse of the same infrastructure on other assets; keep scope narrow when the pattern stays confined to one recognized workflow with no contradictory evidence.
104
105- Escalate when DNS fit, process context, follow-on communication, artifacts, or variant traffic point to unauthorized C2 or delivery; close only when all evidence aligns with a recognized benign workflow; if mixed or incomplete, preserve and escalate.
106
107### False positive analysis
108
109- Software distribution, developer tooling, or security-testing workflows can legitimately query less common TLDs. Confirm by matching the same `process.executable`, `process.code_signature.subject_name`, `dns.question.name` family, and `host.id` across prior alerts or against workflow records.
110- Before creating an exception, build on `process.executable`, `process.code_signature.subject_name`, the `dns.question.name` family, and `host.id` or `user.id`. Avoid exceptions on the TLD alone, `process.name` alone, or `host.id` alone.
111
112### Response and remediation
113
114- If confirmed benign, reverse any temporary containment and document the `process.executable`, `process.code_signature.subject_name`, `process.parent.command_line`, `dns.question.name` family, and bounded `host.id` or `user.id` scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
115- If suspicious but unconfirmed, first preserve `dns.question.name`, `dns.resolved_ip`, connected `destination.ip` values, the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, and any staged `file.path` values. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring on `host.id`. Escalate to host isolation only if the preserved evidence shows likely follow-on communication or staging and the asset role can tolerate stronger containment.
116- If confirmed malicious, document the alert's `process.entity_id`, `process.command_line`, `process.parent.command_line`, written `file.path` artifacts, and connected `dns.question.name` or `destination.ip` infrastructure before initiating response actions. Prefer endpoint isolation as the first containment step; if direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can isolate the host. Block the confirmed malicious domains and direct-IP destinations before terminating processes or deleting files.
117- After containment, review other `host.id` and `user.id` alerts for the same `dns.question.name`, `destination.ip`, or `process.executable` pattern before deleting artifacts or restoring access. Then eradicate staged binaries, scripts, and any persistence or proxy changes identified during the file or variant review, and remediate the entry path that allowed the suspicious process to run. If the same suspicious window includes credential, admin-tool, or remote-session alerts, review those sessions for follow-on misuse and reset exposed credentials when the evidence supports compromise.
118"""
119
120setup = """## Setup
121
122This 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.
123
124Setup instructions: https://ela.st/install-elastic-defend
125
126### Additional data sources
127
128This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
129
130- [CrowdStrike](https://ela.st/crowdstrike-integration)
131- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
132- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
133"""
134
135[rule.investigation_fields]
136field_names = [
137    "@timestamp",
138    "host.name",
139    "host.id",
140    "user.name",
141    "user.id",
142    "process.name",
143    "process.executable",
144    "process.entity_id",
145    "process.pid",
146    "process.code_signature.subject_name",
147    "process.code_signature.trusted",
148    "dns.question.name",
149    "dns.resolved_ip",
150    "event.action",
151]
152
153[[transform.investigate]]
154label = "Alerts associated with the user"
155description = ""
156providers = [
157  [
158    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
159    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
160  ]
161]
162relativeFrom = "now-48h/h"
163relativeTo = "now"
164
165[[transform.investigate]]
166label = "Alerts associated with the host"
167description = ""
168providers = [
169  [
170    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
171    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
172  ]
173]
174relativeFrom = "now-48h/h"
175relativeTo = "now"
176
177[[transform.investigate]]
178label = "Network activity for the alerting process"
179description = ""
180providers = [
181  [
182    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
183    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
184    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
185  ]
186]
187relativeFrom = "now-1h"
188relativeTo = "now"
189
190[[rule.threat]]
191framework = "MITRE ATT&CK"
192
193[[rule.threat.technique]]
194id = "T1071"
195name = "Application Layer Protocol"
196reference = "https://attack.mitre.org/techniques/T1071/"
197
198[[rule.threat.technique.subtechnique]]
199id = "T1071.004"
200name = "DNS"
201reference = "https://attack.mitre.org/techniques/T1071/004/"
202
203[rule.threat.tactic]
204id = "TA0011"
205name = "Command and Control"
206reference = "https://attack.mitre.org/tactics/TA0011/"
207
208[[rule.threat]]
209framework = "MITRE ATT&CK"
210
211[[rule.threat.technique]]
212id = "T1127"
213name = "Trusted Developer Utilities Proxy Execution"
214reference = "https://attack.mitre.org/techniques/T1127/"
215
216[[rule.threat.technique.subtechnique]]
217id = "T1127.001"
218name = "MSBuild"
219reference = "https://attack.mitre.org/techniques/T1127/001/"
220
221[[rule.threat.technique]]
222id = "T1218"
223name = "System Binary Proxy Execution"
224reference = "https://attack.mitre.org/techniques/T1218/"
225
226[rule.threat.tactic]
227id = "TA0005"
228name = "Defense Evasion"
229reference = "https://attack.mitre.org/tactics/TA0005/"

Triage and analysis

Investigating Network Activity to a Suspicious Top Level Domain

Possible investigation steps

  • Does the alert-local DNS result and domain shape fit the process role?

    • Focus: the alert's event.action, dns.question.name, dns.Ext.status, and dns.resolved_ip; use "lookup_result" for resolved IPs and "lookup_requested" for failed or request-only lookups.
    • Implication: concern rises when the name is algorithmic, newly introduced for that tool, or resolves to unrelated external infrastructure; weaker when the lookup fails immediately or the domain matches a known vendor pattern for that process, but a failed lookup alone does not clear the process. .onion lookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration.
  • Is the alerting binary the expected tool in the expected install context?

    • Focus: process.executable, process.code_signature.subject_name, process.code_signature.trusted, and process.pe.original_file_name.
    • Implication: more concerning when the binary is unsigned, renamed, user-writable, or inconsistent with its usual signer. Identity alone does not clear the DNS behavior.
  • Does the command line and launch chain fit a legitimate workflow?

    • Focus: process.command_line, process.parent.executable, and process.parent.command_line.
    • Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive.
  • Does the same process resolve the domain and then communicate with the returned infrastructure?

    • Why: a suspicious DNS lookup carries more weight when the same process reuses the returned IPs for follow-on connections or transfer behavior in the same window.
    • Focus: process-scoped "lookup_result" and connection events on the same host.id, using dns.resolved_ip to bridge dns.question.name to destination.ip; treat destination.as.organization.name as ownership context rather than a verdict. $investigate_2
    • Hint: if the transform returns no results, broaden to host-scoped network events around the alert time.
    • Implication: escalate when the same process repeatedly resolves the domain, connects to the returned IPs, or shows suspicious transfer patterns; lower suspicion when activity is limited to a one-off lookup with no matching connection behavior. Missing follow-on network telemetry is unresolved, not benign.
  • Do file events or child processes from the same process chain show download-and-execute or artifact staging?

    • Focus: same-host file and process activity around the alert time, scoped to the alert's process.entity_id, with attention to file.path, file.origin_url, file.Ext.windows.zone_identifier, and later process.executable reuse of a written path.
    • Hint: if file coverage is missing, keep the artifact review bounded to the same host, lineage, and alert window rather than treating the lookup as harmless.
    • Implication: staging risk rises when the chain writes scripts, archives, or executables to user-writable paths and later runs them.
  • Does the same process chain pivot to direct-IP traffic, lookalike domains, or TLD rotation that this rule would miss?

    • Why: attackers often keep the same process chain but swap to a nearby domain, a different abusive TLD, or direct-IP egress after the first lookup.
    • Focus: reuse the process-scoped network results from the prior step to look for direct destination.ip connections with no preceding DNS, sibling dns.question.name values under different TLDs, or repeated reuse of the same dns.resolved_ip across multiple domains. $investigate_2
    • Implication: escalate when the process shifts from the flagged lookup to direct-IP traffic, nearby domain variants, or fast domain and TLD rotation on the same infrastructure; lower suspicion when surrounding DNS stays limited to one recognized vendor domain family with no adjacent variant traffic.
  • If the local DNS, process, or artifact evidence stays suspicious or unresolved, does related alert history show this DNS pattern is isolated or part of broader compromise?

    • Focus: related alerts for the same host.id and user.id in the last 48 hours to test whether the same lineage, domain family, or follow-on activity recurs on the asset or follows the user across hosts.
      • $investigate_0
      • $investigate_1
    • Implication: broaden scope when the host or user view shows repeated suspicious lineage, related delivery or persistence alerts, or reuse of the same infrastructure on other assets; keep scope narrow when the pattern stays confined to one recognized workflow with no contradictory evidence.
  • Escalate when DNS fit, process context, follow-on communication, artifacts, or variant traffic point to unauthorized C2 or delivery; close only when all evidence aligns with a recognized benign workflow; if mixed or incomplete, preserve and escalate.

False positive analysis

  • Software distribution, developer tooling, or security-testing workflows can legitimately query less common TLDs. Confirm by matching the same process.executable, process.code_signature.subject_name, dns.question.name family, and host.id across prior alerts or against workflow records.
  • Before creating an exception, build on process.executable, process.code_signature.subject_name, the dns.question.name family, and host.id or user.id. Avoid exceptions on the TLD alone, process.name alone, or host.id alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and document the process.executable, process.code_signature.subject_name, process.parent.command_line, dns.question.name family, and bounded host.id or user.id scope that proved the workflow. Create an exception only if that same pattern recurs consistently across prior alerts from this rule.
  • If suspicious but unconfirmed, first preserve dns.question.name, dns.resolved_ip, connected destination.ip values, the alert's process.entity_id, process.command_line, process.parent.command_line, and any staged file.path values. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring on host.id. Escalate to host isolation only if the preserved evidence shows likely follow-on communication or staging and the asset role can tolerate stronger containment.
  • If confirmed malicious, document the alert's process.entity_id, process.command_line, process.parent.command_line, written file.path artifacts, and connected dns.question.name or destination.ip infrastructure before initiating response actions. Prefer endpoint isolation as the first containment step; if direct endpoint response is unavailable, escalate with the preserved artifact set to the team that can isolate the host. Block the confirmed malicious domains and direct-IP destinations before terminating processes or deleting files.
  • After containment, review other host.id and user.id alerts for the same dns.question.name, destination.ip, or process.executable pattern before deleting artifacts or restoring access. Then eradicate staged binaries, scripts, and any persistence or proxy changes identified during the file or variant review, and remediate the entry path that allowed the suspicious process to run. If the same suspicious window includes credential, admin-tool, or remote-session alerts, review those sessions for follow-on misuse and reset exposed credentials when the evidence supports compromise.

References

Related rules

to-top