DNS Request to Suspicious Top Level Domain

This rule detects 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/07/20"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12This rule detects DNS queries to commonly abused top level domains. Malware authors may use these
 13domains to host command and control infrastructure, exfiltrate data, or to download payloads
 14for later execution.
 15"""
 16from = "now-9m"
 17index = ["logs-endpoint.events.network-*"]
 18language = "eql"
 19license = "Elastic License v2"
 20name = "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 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    "Use Case: Threat Detection",
 60    "Tactic: Command and Control",
 61    "Tactic: Exfiltration",
 62    "Data Source: Elastic Defend",
 63    "Resources: Investigation Guide",
 64]
 65timestamp_override = "event.ingested"
 66type = "eql"
 67query = '''
 68network where host.os.type == "linux" and dns.question.name != null and process.name != null and
 69dns.question.name like~ (
 70  "*.forum", "*.pro", "*.team", "*.lol", "*.kr", "*.ke", "*.nu", "*.space", "*.capital", "*.in", "*.cfd", "*.online",
 71  "*.ru", "*.info", "*.top", "*.buzz", "*.xyz", "*.rest", "*.ml", "*.cf", "*.gq", "*.ga", "*.onion", "*.network",
 72  "*.monster", "*.marketing", "*.cyou", "*.quest", "*.cc", "*.bar", "*.click", "*.cam", "*.surf", "*.tk", "*.shop",
 73  "*.club", "*.icu", "*.pw", "*.ws", "*.fun", "*.life", "*.boats", "*.store", "*.hair", "*.mom",
 74  "*.beauty", "*.bond", "*.biz", "*.live", "*.zone"
 75)
 76'''
 77
 78[[rule.threat]]
 79framework = "MITRE ATT&CK"
 80
 81[[rule.threat.technique]]
 82id = "T1071"
 83name = "Application Layer Protocol"
 84reference = "https://attack.mitre.org/techniques/T1071/"
 85
 86[[rule.threat.technique.subtechnique]]
 87id = "T1071.004"
 88name = "DNS"
 89reference = "https://attack.mitre.org/techniques/T1071/004/"
 90
 91[[rule.threat.technique]]
 92id = "T1090"
 93name = "Proxy"
 94reference = "https://attack.mitre.org/techniques/T1090/"
 95
 96[[rule.threat.technique.subtechnique]]
 97id = "T1090.002"
 98name = "External Proxy"
 99reference = "https://attack.mitre.org/techniques/T1090/002/"
100
101[[rule.threat.technique]]
102id = "T1102"
103name = "Web Service"
104reference = "https://attack.mitre.org/techniques/T1102/"
105
106[[rule.threat.technique.subtechnique]]
107id = "T1102.001"
108name = "Dead Drop Resolver"
109reference = "https://attack.mitre.org/techniques/T1102/001/"
110
111[[rule.threat.technique.subtechnique]]
112id = "T1102.002"
113name = "Bidirectional Communication"
114reference = "https://attack.mitre.org/techniques/T1102/002/"
115
116[[rule.threat.technique]]
117id = "T1568"
118name = "Dynamic Resolution"
119reference = "https://attack.mitre.org/techniques/T1568/"
120
121[[rule.threat.technique.subtechnique]]
122id = "T1568.002"
123name = "Domain Generation Algorithms"
124reference = "https://attack.mitre.org/techniques/T1568/002/"
125
126[rule.threat.tactic]
127id = "TA0011"
128name = "Command and Control"
129reference = "https://attack.mitre.org/tactics/TA0011/"
130
131[[rule.threat]]
132framework = "MITRE ATT&CK"
133
134[[rule.threat.technique]]
135id = "T1567"
136name = "Exfiltration Over Web Service"
137reference = "https://attack.mitre.org/techniques/T1567/"
138
139[[rule.threat.technique.subtechnique]]
140id = "T1567.001"
141name = "Exfiltration to Code Repository"
142reference = "https://attack.mitre.org/techniques/T1567/001/"
143
144[[rule.threat.technique.subtechnique]]
145id = "T1567.002"
146name = "Exfiltration to Cloud Storage"
147reference = "https://attack.mitre.org/techniques/T1567/002/"
148
149[[rule.threat.technique.subtechnique]]
150id = "T1567.003"
151name = "Exfiltration to Text Storage Sites"
152reference = "https://attack.mitre.org/techniques/T1567/003/"
153
154[rule.threat.tactic]
155id = "TA0010"
156name = "Exfiltration"
157reference = "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 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