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, anddns.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.
.onionlookups signal Tor hidden-service resolution -- treat these as elevated concern and look for Tor binaries or proxy configuration.
- Focus: the alert's
-
Is the alerting binary the expected tool in the expected install context?
- Focus:
process.executable,process.code_signature.subject_name,process.code_signature.trusted, andprocess.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.
- Focus:
-
Does the command line and launch chain fit a legitimate workflow?
- Focus:
process.command_line,process.parent.executable, andprocess.parent.command_line. - Implication: more concerning if a document, script, or unexpected launcher started the process, or if the arguments look staged or evasive.
- Focus:
-
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, usingdns.resolved_ipto bridgedns.question.nametodestination.ip; treatdestination.as.organization.nameas 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 tofile.path,file.origin_url,file.Ext.windows.zone_identifier, and laterprocess.executablereuse 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.
- Focus: same-host file and process activity around the alert time, scoped to the alert's
-
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.ipconnections with no preceding DNS, siblingdns.question.namevalues under different TLDs, or repeated reuse of the samedns.resolved_ipacross 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.idanduser.idin 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.
- Focus: related alerts for the same
-
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.namefamily, andhost.idacross prior alerts or against workflow records. - Before creating an exception, build on
process.executable,process.code_signature.subject_name, thedns.question.namefamily, andhost.idoruser.id. Avoid exceptions on the TLD alone,process.namealone, orhost.idalone.
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.namefamily, and boundedhost.idoruser.idscope 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, connecteddestination.ipvalues, the alert'sprocess.entity_id,process.command_line,process.parent.command_line, and any stagedfile.pathvalues. Then apply reversible containment such as temporary DNS or egress blocks for the observed infrastructure or heightened monitoring onhost.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, writtenfile.pathartifacts, and connecteddns.question.nameordestination.ipinfrastructure 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.idanduser.idalerts for the samedns.question.name,destination.ip, orprocess.executablepattern 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
- Potential File Download via a Headless Browser
- Port Forwarding Rule Addition
- Potential File Transfer via Certreq
- Potential Protocol Tunneling via Cloudflared
- Potential Protocol Tunneling via Yuze