Unusual DNS Request to Suspicious Top Level Domain

This rule detects unusual DNS queries to commonly abused top level domains. Malware authors may use these domains to host command and control infrastructure, exfiltrate data, or to download payloads for later execution.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/02"
  3integration = ["endpoint"]
  4maturity = "production"
  5min_stack_version = "9.3.0"
  6min_stack_comments = "DNS for Linux support was introduced in 9.3.0"
  7updated_date = "2026/09/18"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects unusual DNS queries to commonly abused top level domains. Malware authors may
 13use these domains to host command and control infrastructure, exfiltrate data, or to download
 14payloads for later execution.
 15"""
 16from = "now-5d"
 17interval = "5m"
 18language = "esql"
 19license = "Elastic License v2"
 20name = "Unusual DNS Request to Suspicious Top Level Domain"
 21note = """ ## Triage and analysis
 22
 23> **Disclaimer**:
 24> 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.
 25
 26### Investigating Unusual DNS Request to Suspicious Top Level Domain
 27
 28This rule flags a Linux process making DNS lookups for top-level domains that threat actors frequently abuse, which can reveal command-and-control staging, payload retrieval, or data theft paths that blend into normal name resolution. A common pattern is a compromised Linux server or container resolving a .xyz, .top, or .ru domain immediately before a downloader, backdoor, or script beacon starts exchanging instructions or uploading collected data.
 29
 30### Possible investigation steps
 31
 32- Review the originating binary’s full command line, executable path, parent or child lineage, and user or service account to determine whether the lookup came from approved software, an admin script, or an unexpected downloader or shell.
 33- Correlate the DNS event with nearby outbound connections, HTTP or TLS sessions, and file activity on the same host to see whether the domain was followed by beaconing, payload retrieval, or data transfer.
 34- Enrich the queried domain and any resolved IPs with passive DNS, registration age, reputation, ASN or geolocation, and prevalence in your environment to distinguish newly created or low-reputation infrastructure from known business services.
 35- Determine whether the host is a server, workstation, or containerized workload and validate if the domain fits its normal role by comparing against recent activity, peer hosts, deployed applications, and change or deployment records.
 36- If the activity is not readily explained, inspect for adjacent compromise indicators such as new cron jobs or systemd timers, unexpected binaries in writable paths, recent package or script changes, and authentication or privilege escalation events around the same timeframe.
 37
 38### False positive analysis
 39
 40- Newly deployed or updated Linux applications, scripts, or package retrieval tasks may legitimately resolve domains in low-cost or regional TLDs for updates, licensing, or content delivery; verify the process path and parent chain match approved software and that similar lookups appear on peer hosts during the same change window.
 41- A user or service performing legitimate research or accessing region-specific content may query a country-code or commonly abused TLD from a browser or expected application; confirm the domain aligns with the host’s business purpose and that the activity is limited to normal browsing without subsequent suspicious connections, downloads, or persistence changes.
 42
 43### Response and remediation
 44
 45- Isolate the affected Linux host or container from the network except for approved management access, and immediately block the suspicious domain, its resolved IP addresses, and any follow-on destinations at DNS, proxy, and firewall controls.
 46- Terminate the offending process and remove persistence tied to the activity, including unauthorized systemd services or timers, cron entries, startup scripts, shell profile changes, and newly added SSH authorized_keys for the impacted account.
 47- Preserve the malicious binary or script and relevant logs for scoping, then rebuild the system from a known-good image or snapshot rather than cleaning in place, and restore altered files only from trusted backups.
 48- Rotate credentials and secrets exposed on the host, especially SSH keys, API tokens, service account passwords, and cloud or instance metadata credentials, because DNS-based command-and-control often precedes remote tasking and data theft.
 49- Escalate to incident response immediately if the same domain or related infrastructure appears on multiple hosts, if the process ran as root or a privileged service account, or if you identify outbound uploads, payload downloads, or lateral movement activity.
 50- Harden the environment by forcing outbound DNS through approved resolvers, restricting egress to required destinations, monitoring Linux systems for new systemd or cron persistence, and adding detections for the domain, executable hash, and related infrastructure.
 51"""
 52risk_score = 21
 53rule_id = "44a2de72-fe41-4558-b7ec-3e42de5f0432"
 54severity = "low"
 55tags = [
 56    "Domain: Endpoint",
 57    "Domain: Network",
 58    "OS: Linux",
 59    "Platform: Linux",
 60    "Use Case: Threat Detection",
 61    "Tactic: Command and Control",
 62    "Tactic: Exfiltration",
 63    "Data Source: Elastic Defend",
 64    "Rule Type: ES|QL",
 65    "Resources: Investigation Guide",
 66    "Noise: High",
 67    "Performance: Normal",
 68    "Profile: Aggressive",
 69    "Threat: Suspicious TLD",
 70]
 71timestamp_override = "event.ingested"
 72type = "esql"
 73query = '''
 74FROM logs-endpoint.events.network-*
 75| WHERE host.os.type == "linux"
 76    AND event.action == "lookup_requested"
 77    AND host.id IS NOT NULL
 78    AND host.name IS NOT NULL
 79    AND user.name IS NOT NULL
 80    AND user.id IS NOT NULL
 81    AND process.executable IS NOT NULL
 82    AND dns.question.name LIKE "*.*"
 83    AND process.executable != "/usr/lib/systemd/systemd-resolved"
 84| EVAL Esql.dns_tld = MV_LAST(SPLIT(TO_LOWER(dns.question.name), "."))
 85| WHERE Esql.dns_tld IN (
 86    "forum", "pro", "team", "lol", "kr", "ke", "nu", "space", "capital", "in", "cfd", "online",
 87    "ru", "info", "top", "buzz", "xyz", "rest", "ml", "cf", "gq", "ga", "onion", "network",
 88    "monster", "marketing", "cyou", "quest", "cc", "bar", "click", "cam", "surf", "tk", "shop",
 89    "club", "icu", "pw", "ws", "fun", "life", "boats", "store", "hair", "mom", "beauty", "bond",
 90    "biz", "live", "zone"
 91  )
 92| STATS Esql.first_time_seen = MIN(@timestamp)
 93  BY host.id, host.name, user.name, user.id, process.executable, dns.question.name, data_stream.namespace
 94// New terms emulation: alert when the tuple was first seen recently within the 5-day history.
 95| EVAL Esql.recent_minutes = DATE_DIFF("minute", Esql.first_time_seen, NOW())
 96| WHERE Esql.recent_minutes <= 6
 97| KEEP host.id, host.name, user.name, user.id, process.executable, dns.question.name, data_stream.namespace
 98'''
 99
100[[rule.threat]]
101framework = "MITRE ATT&CK"
102
103[[rule.threat.technique]]
104id = "T1071"
105name = "Application Layer Protocol"
106reference = "https://attack.mitre.org/techniques/T1071/"
107
108[[rule.threat.technique.subtechnique]]
109id = "T1071.004"
110name = "DNS"
111reference = "https://attack.mitre.org/techniques/T1071/004/"
112
113[[rule.threat.technique]]
114id = "T1090"
115name = "Proxy"
116reference = "https://attack.mitre.org/techniques/T1090/"
117
118[[rule.threat.technique.subtechnique]]
119id = "T1090.002"
120name = "External Proxy"
121reference = "https://attack.mitre.org/techniques/T1090/002/"
122
123[[rule.threat.technique]]
124id = "T1102"
125name = "Web Service"
126reference = "https://attack.mitre.org/techniques/T1102/"
127
128[[rule.threat.technique.subtechnique]]
129id = "T1102.001"
130name = "Dead Drop Resolver"
131reference = "https://attack.mitre.org/techniques/T1102/001/"
132
133[[rule.threat.technique.subtechnique]]
134id = "T1102.002"
135name = "Bidirectional Communication"
136reference = "https://attack.mitre.org/techniques/T1102/002/"
137
138[[rule.threat.technique]]
139id = "T1568"
140name = "Dynamic Resolution"
141reference = "https://attack.mitre.org/techniques/T1568/"
142
143[[rule.threat.technique.subtechnique]]
144id = "T1568.002"
145name = "Domain Generation Algorithms"
146reference = "https://attack.mitre.org/techniques/T1568/002/"
147
148[rule.threat.tactic]
149id = "TA0011"
150name = "Command and Control"
151reference = "https://attack.mitre.org/tactics/TA0011/"
152
153[[rule.threat]]
154framework = "MITRE ATT&CK"
155
156[[rule.threat.technique]]
157id = "T1567"
158name = "Exfiltration Over Web Service"
159reference = "https://attack.mitre.org/techniques/T1567/"
160
161[[rule.threat.technique.subtechnique]]
162id = "T1567.001"
163name = "Exfiltration to Code Repository"
164reference = "https://attack.mitre.org/techniques/T1567/001/"
165
166[[rule.threat.technique.subtechnique]]
167id = "T1567.002"
168name = "Exfiltration to Cloud Storage"
169reference = "https://attack.mitre.org/techniques/T1567/002/"
170
171[[rule.threat.technique.subtechnique]]
172id = "T1567.003"
173name = "Exfiltration to Text Storage Sites"
174reference = "https://attack.mitre.org/techniques/T1567/003/"
175
176[rule.threat.tactic]
177id = "TA0010"
178name = "Exfiltration"
179reference = "https://attack.mitre.org/tactics/TA0010/"

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 DNS Request to Suspicious Top Level Domain

This rule flags a Linux process making DNS lookups for top-level domains that threat actors frequently abuse, which can reveal command-and-control staging, payload retrieval, or data theft paths that blend into normal name resolution. A common pattern is a compromised Linux server or container resolving a .xyz, .top, or .ru domain immediately before a downloader, backdoor, or script beacon starts exchanging instructions or uploading collected data.

Possible investigation steps

  • Review the originating binary’s full command line, executable path, parent or child lineage, and user or service account to determine whether the lookup came from approved software, an admin script, or an unexpected downloader or shell.
  • Correlate the DNS event with nearby outbound connections, HTTP or TLS sessions, and file activity on the same host to see whether the domain was followed by beaconing, payload retrieval, or data transfer.
  • Enrich the queried domain and any resolved IPs with passive DNS, registration age, reputation, ASN or geolocation, and prevalence in your environment to distinguish newly created or low-reputation infrastructure from known business services.
  • Determine whether the host is a server, workstation, or containerized workload and validate if the domain fits its normal role by comparing against recent activity, peer hosts, deployed applications, and change or deployment records.
  • If the activity is not readily explained, inspect for adjacent compromise indicators such as new cron jobs or systemd timers, unexpected binaries in writable paths, recent package or script changes, and authentication or privilege escalation events around the same timeframe.

False positive analysis

  • Newly deployed or updated Linux applications, scripts, or package retrieval tasks may legitimately resolve domains in low-cost or regional TLDs for updates, licensing, or content delivery; verify the process path and parent chain match approved software and that similar lookups appear on peer hosts during the same change window.
  • A user or service performing legitimate research or accessing region-specific content may query a country-code or commonly abused TLD from a browser or expected application; confirm the domain aligns with the host’s business purpose and that the activity is limited to normal browsing without subsequent suspicious connections, downloads, or persistence changes.

Response and remediation

  • Isolate the affected Linux host or container from the network except for approved management access, and immediately block the suspicious domain, its resolved IP addresses, and any follow-on destinations at DNS, proxy, and firewall controls.
  • Terminate the offending process and remove persistence tied to the activity, including unauthorized systemd services or timers, cron entries, startup scripts, shell profile changes, and newly added SSH authorized_keys for the impacted account.
  • Preserve the malicious binary or script and relevant logs for scoping, then rebuild the system from a known-good image or snapshot rather than cleaning in place, and restore altered files only from trusted backups.
  • Rotate credentials and secrets exposed on the host, especially SSH keys, API tokens, service account passwords, and cloud or instance metadata credentials, because DNS-based command-and-control often precedes remote tasking and data theft.
  • Escalate to incident response immediately if the same domain or related infrastructure appears on multiple hosts, if the process ran as root or a privileged service account, or if you identify outbound uploads, payload downloads, or lateral movement activity.
  • Harden the environment by forcing outbound DNS through approved resolvers, restricting egress to required destinations, monitoring Linux systems for new systemd or cron persistence, and adding detections for the domain, executable hash, and related infrastructure.

Related rules

to-top