Detect hosts connecting to dynamic domain providers
Description
The following analytic identifies DNS queries from internal hosts to dynamic domain providers. It leverages DNS query logs from the Network_Resolution data model and cross-references them with a lookup file containing known dynamic DNS providers. This activity is significant because attackers often use dynamic DNS services to host malicious payloads or command-and-control servers, making it crucial for security teams to monitor. If confirmed malicious, this activity could allow attackers to bypass firewall blocks, evade detection, and maintain persistent access to the network.
Query · spl
| tstats `security_content_summariesonly` count min(_time) as firstTime
from datamodel=Network_Resolution where
DNS.query=*
NOT DNS.query IN ("-", "unknown")
by DNS.answer DNS.answer_count DNS.query DNS.query_count
DNS.reply_code_id DNS.src DNS.vendor_product
| `drop_dm_object_name("DNS")`
| `security_content_ctime(firstTime)`
| lookup update=true dynamic_dns_providers_default dynamic_dns_domains as query OUTPUTNEW isDynDNS_default
| lookup update=true dynamic_dns_providers_local dynamic_dns_domains as query OUTPUTNEW isDynDNS_local
| eval isDynDNS = coalesce(isDynDNS_local,isDynDNS_default)
|fields - isDynDNS_default, isDynDNS_local| search isDynDNS=True
| `detect_hosts_connecting_to_dynamic_domain_providers_filter`
Implementation guide
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 dynamic_dns_providers_local.csv.
This search produces fields (query, answer, isDynDNS) that are not yet supported by Mission Control Queue and therefore cannot be viewed when a finding is raised. These fields contribute additional context to the finding. To see the additional metadata, add the following fields, if not already present, to Mission Control Queue. Event Attributes (Configure > Findings and Investigations > Add New field):
* Label: DNS Query, Field: query
* Label: DNS Answer, Field: answer
* Label: IsDynamicDNS, Field: isDynDNS
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.
Analyst notes
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.