Malicious actors often abuse legitimate Dynamic DNS services to host malicious payloads or interactive command and control nodes. Attackers will automate domain resolution changes by routing dynamic domains to countless IP addresses to circumvent firewall blocks, block lists as well as frustrate a network defenders analytic and investigative processes. This search will look for DNS queries made from within your infrastructure to suspicious dynamic domains.
- Type: TTP
- Product: Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud
- Datamodel: Network_Resolution
- Last Updated: 2021-01-14
- Author: Bhavin Patel, Splunk
- ID: a1e761ac-1344-4dbd-88b2-3f34c912d359
Kill Chain Phase
- Command & Control
- Actions on Objectives
- CIS 8
- CIS 12
- CIS 13
1 2 3 4 5 6 | tstats `security_content_summariesonly` count values(DNS.answer) as answer min(_time) as firstTime from datamodel=Network_Resolution by DNS.query host | `drop_dm_object_name("DNS")` | `security_content_ctime(firstTime)` | `dynamic_dns_providers` | `detect_hosts_connecting_to_dynamic_domain_providers_filter`
The SPL above uses the following Macros:
detect_hosts_connecting_to_dynamic_domain_providers_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.
List of fields required to use this analytic.
How To Implement
First, you'll need to ingest data from your DNS operations. This can be done by ingesting logs from your server or data, collected passively by Splunk Stream or a similar solution. Specifically, data that contains the domain that is being queried and the IP of the host originating the request must be populating the
Network_Resolution data model. This search also leverages a lookup file,
dynamic_dns_providers_default.csv, which contains a non-exhaustive list of Dynamic DNS providers. Please consider updating the local lookup periodically by adding new domains to the list of
This search produces fields (query, answer, isDynDNS) that are not yet supported by ES Incident Review and therefore cannot be viewed when a notable event is raised. These fields contribute additional context to the notable event. To see the additional metadata, add the following fields, if not already present, to Incident Review. Event Attributes (Configure > Incident Management > Incident Review Settings > Add New Entry):\n1. Label: DNS Query, Field: query\
- Label: DNS Answer, Field: answer\
Label: IsDynamicDNS, Field: isDynDNS
Detailed documentation on how to create a new field within Incident Review may be found here:
Known False Positives
Some users and applications may leverage Dynamic DNS to reach out to some domains on the Internet since dynamic DNS by itself is not malicious, however this activity must be verified.
Associated Analytic Story
- Data Protection
- Prohibited Traffic Allowed or Protocol Mismatch
- DNS Hijacking
- Suspicious DNS Traffic
- Dynamic DNS
- Command and Control
|56.0||70||80||A dns query $query$ from your infra connecting to suspicious domain in host $host$|
The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.
source | version: 3