Loading

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.

Rule type: eql
Rule indices:

  • endgame-*
  • logs-endpoint.events.network-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*

Rule Severity: high
Risk Score: 73
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 100
References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Command and Control
  • Resources: Investigation Guide
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: SentinelOne
  • Data Source: Crowdstrike
  • Data Source: Sysmon

Version: 4
Rule authors:

  • Elastic

Rule license: Elastic License v2

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

  • 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.

  • 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.
  • 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.
network where host.os.type == "windows" and dns.question.name != null and
 (
  process.name : ("MSBuild.exe", "mshta.exe", "wscript.exe", "powershell.exe", "pwsh.exe", "msiexec.exe", "rundll32.exe",
                  "bitsadmin.exe", "InstallUtil.exe", "python.exe", "regsvr32.exe", "dllhost.exe", "node.exe", "curl.exe",
                  "java.exe", "javaw.exe", "*.pif", "*.com", "*.scr") or
  (?process.code_signature.trusted == false or ?process.code_signature.exists == false) or
  ?process.code_signature.subject_name : ("AutoIt Consulting Ltd", "OpenJS Foundation", "Python Software Foundation") or
  ?process.executable : (
    "?:\\Users\\Public\\*.exe", "?:\\ProgramData\\*.exe", "?:\\Users\\*\\Downloads\\*.exe",
    "\\Device\\HarddiskVolume*\\Users\\Public\\*.exe", "\\Device\\HarddiskVolume*\\ProgramData\\*.exe", "\\Device\\HarddiskVolume*\\Users\\*\\Downloads\\*.exe"
  )
 ) and
dns.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

not process.executable : (
    "?:\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe",
    "\\Device\\HarddiskVolume*\\ProgramData\\Microsoft\\Windows Defender\\platform\\*\\*.exe"
)

Framework: MITRE ATT&CK

Framework: MITRE ATT&CK