T1568

Dynamic Resolution

Command and Control Last updated:

Adversaries may dynamically establish connections to command and control (C2) infrastructure to evade common detections and remediations. This is achieved using malware that shares a common algorithm with the adversary's infrastructure to dynamically determine communication parameters such as domain names, IP addresses, or port numbers. Sub-techniques include Fast Flux DNS (T1568.001) — where DNS TTLs are kept extremely short and A records rotate through large pools of IPs to resist takedown; Domain Generation Algorithms (T1568.002) — where both adversary infrastructure and malware use the same seeded pseudorandom algorithm to produce hundreds of candidate domains, with only a few registered at any given time; and DNS Calculation (T1568.003) — where DNS responses encode the C2 address directly (e.g., RTM malware converting Bitcoin blockchain data to IP octets). Real-world actors leveraging this technique include APT29, SUNBURST (randomly-generated subdomains within avsvmcloud.com), Gamaredon Group, TA2541, Transparent Tribe, BITTER, Gelsemium, Bisonal, and AsyncRAT operators. Detection focuses on three primary signals: connections to known dynamic DNS providers from non-browser processes, high-frequency DNS resolution bursts characteristic of DGA cycling, and anomalous IP volatility for a single FQDN indicating Fast Flux infrastructure.

What is T1568 Dynamic Resolution?

Dynamic Resolution (T1568) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Dynamic Resolution, covering the data sources and telemetry it touches: Network Traffic: Network Connection Creation, Microsoft Defender for Endpoint, Process: Process Creation. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Command and Control
Technique
T1568 Dynamic Resolution
Canonical reference
https://attack.mitre.org/techniques/T1568/
Microsoft Sentinel / Defender
kusto 
let KnownDDNSProviders = dynamic([
    "no-ip.com", "noip.com", "dyndns.org", "dyndns.com", "duckdns.org",
    "changeip.com", "afraid.org", "freedns.afraid.org", "dynv6.com",
    "hopto.org", "ddns.net", "zapto.org", "sytes.net", "redirectme.net",
    "myvnc.com", "servehttp.com", "serveftp.com", "bounceme.net",
    "loseyourip.com", "ooguy.com", "theworkpc.com", "casacam.net",
    "dnsdynamic.org", "myfreeweb.us", "dy.fi", "3utilities.com",
    "blogdns.com", "myftp.org", "myftp.biz", "servegame.com",
    "viewdns.net", "ddnsfree.com", "dnsalias.com", "dyn.com",
    "dtdns.com", "selfip.com", "tzo.com", "dnspark.com"
]);
let BrowserProcesses = dynamic([
    "chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe",
    "opera.exe", "brave.exe", "safari.exe", "seamonkey.exe", "waterfox.exe"
]);
let HighRiskProcesses = dynamic([
    "powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe",
    "mshta.exe", "rundll32.exe", "regsvr32.exe", "msbuild.exe", "csc.exe",
    "InstallUtil.exe", "regasm.exe", "regsvcs.exe", "schtasks.exe",
    "bitsadmin.exe", "certutil.exe", "wmic.exe"
]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteUrl has_any (KnownDDNSProviders)
| where not (InitiatingProcessFileName has_any (BrowserProcesses))
| extend IsHighRiskProcess = InitiatingProcessFileName in~ (HighRiskProcesses)
| extend IsNonStandardPort = RemotePort !in (80, 443)
| extend IsHiddenProcess = (InitiatingProcessFileName =~ "" or isnull(InitiatingProcessFileName))
| extend RiskScore = case(
    IsHighRiskProcess and IsNonStandardPort, 4,
    IsHighRiskProcess, 3,
    IsNonStandardPort, 2,
    IsHiddenProcess, 2,
    1
)
| project Timestamp, DeviceName, AccountName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessParentFileName, InitiatingProcessParentCommandLine,
          RemoteUrl, RemoteIP, RemotePort, ActionType,
          IsHighRiskProcess, IsNonStandardPort, RiskScore
| sort by RiskScore desc, Timestamp desc

Detects network connections from non-browser processes to known dynamic DNS (DDNS) provider domains using Microsoft Defender for Endpoint DeviceNetworkEvents. DDNS providers allow adversaries to rapidly update C2 server IP addresses without changing the registered domain name, enabling infrastructure to survive IP-based blocklisting. The RemoteUrl field in DeviceNetworkEvents is populated with the resolved FQDN for HTTP and HTTPS connections, enabling domain-based detection of DDNS C2 traffic. The query excludes browser processes that may legitimately visit DDNS provider websites, flags high-risk interpreter and LOLBin processes initiating DDNS connections, and produces a risk score based on process type and destination port to aid analyst triage.

high severity medium confidence

Data Sources

Network Traffic: Network Connection Creation Microsoft Defender for Endpoint Process: Process Creation

Required Tables

DeviceNetworkEvents

False Positives

  • Developers or system administrators accessing personal DDNS-registered home lab or remote access infrastructure (common with No-IP or DuckDNS for self-hosted services)
  • Remote access tools such as TeamViewer, AnyDesk, or VNC clients that use DDNS to locate remote endpoints when the user has configured a DDNS address for their home machine
  • IoT management software, IP camera viewers, or NVR clients that connect to consumer DDNS services to locate home surveillance equipment
  • Network monitoring agents or IT automation tools that use DDNS-hosted endpoints for health check callbacks or configuration retrieval

Sigma rule & cross-platform mapping

The detection logic for Dynamic Resolution (T1568) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1568 Sigma rules on detection.fyi

Platform-specific guides for T1568

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-03-19 Research depth: deep
References (10)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Windows - Non-Browser DDNS Resolution via PowerShell

    Expected signal: Sysmon Event ID 22 (DNS Query): Two events with QueryName='atomictest-c2.duckdns.org' and 'atomictest-beacon.ddns.net', Image='C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe', QueryResults showing NXDOMAIN or resolved IP. Sysmon Event ID 1 (Process Create): powershell.exe with '-NoProfile -Command' command line. DeviceNetworkEvents in MDE: RemoteUrl containing 'duckdns.org' or 'ddns.net' if HTTP-level connection occurs.

  2. Test 2Windows - DGA Simulation: Bulk Algorithmic Subdomain Resolution

    Expected signal: Sysmon Event ID 22: Seven DNS query events in rapid succession from nslookup.exe, QueryName matching 'xj3kp9mq2rtv.dyndns.org' through 'kx9mn3qt7vsc.dyndns.org', QueryResults=NXDOMAIN. Sysmon Event ID 3: UDP connections to 8.8.8.8:53 from nslookup.exe. Sysmon Event ID 1: cmd.exe with the for-loop command and nslookup.exe child processes. Security Event ID 4688 (with command-line auditing enabled).

  3. Test 3Windows - DDNS Update API Callback (Adversary Infrastructure Registration)

    Expected signal: Sysmon Event ID 22 (DNS Query): QueryName='www.duckdns.org', Image='powershell.exe'. Sysmon Event ID 3 (Network Connection): TCP connection to duckdns.org:443, DestinationHostname='www.duckdns.org', Image='powershell.exe'. Sysmon Event ID 1 (Process Create): powershell.exe with '-NoProfile -WindowStyle Hidden' in command line. DeviceNetworkEvents: RemoteUrl='www.duckdns.org', RemotePort=443, InitiatingProcessFileName='powershell.exe'.

  4. Test 4Linux - DDNS Domain Resolution from Shell Process

    Expected signal: Auditd SYSCALL records: execve() calls for 'dig' and 'curl' binaries with full argument lists. Auditd SOCKADDR records (if network rules enabled): UDP connection to 8.8.8.8:53 from dig, TCP connection to ddns.net IP from curl. Syslog: DNS resolution events and connection attempts. If Sysmon for Linux is deployed: Sysmon EventCode 22 (DNS Query) for 'atomictest.hopto.org' and EventCode 3 (Network Connection) for connections to 8.8.8.8 and ddns.net IP. Network flow logs: UDP/53 to 8.8.8.8 from dig PID, TCP/80 to ddns.net IP from curl PID.

Response Playbook

Triage

  1. Look up the full queried DDNS FQDN (e.g., evildomain.hopto.org) in threat intelligence platforms — search VirusTotal, Shodan, RiskIQ/PassiveDNS, and OTX for historical malicious associations, first-seen dates, and who else is resolving this domain. A recently registered FQDN with no prior history is higher risk than a long-standing one.
  2. Examine the initiating process fully — is it a known malware vector (mshta.exe, wscript.exe, regsvr32.exe, schtasks.exe) or a legitimate application? Review the complete command line for encoded arguments, LOLBin abuse, or script paths in unexpected directories (Temp, AppData, ProgramData). Check process hash against VirusTotal.
  3. Trace the full process lineage — use DeviceProcessEvents to find the parent and grandparent of the alerting process. Unexpected parent chains (e.g., winword.exe → cmd.exe → powershell.exe, or browser → cmd.exe) strongly indicate macro-based initial access or drive-by exploitation. Legitimate DDNS software has consistent, stable parent processes.
  4. Assess connection frequency and timing — search DeviceNetworkEvents for the past 7 days for this process making connections to the DDNS domain. Is this a one-time lookup or a repeating pattern at regular intervals (every 30–300 seconds)? Regular-interval connections indicate active C2 beaconing. Use: DeviceNetworkEvents | where DeviceName == '<host>' | where InitiatingProcessFileName =~ '<process>' | summarize count() by bin(Timestamp, 5m)
  5. Examine what IP address(es) the DDNS domain resolved to — retrieve the IP from Sysmon Event ID 22 QueryResults field or from DeviceNetworkEvents RemoteIP. Look up the IP in threat intel, check ASN ownership (hosting providers vs. residential ISPs vs. known bulletproof hosters), and determine if other endpoints in your environment have connected to the same IP.
  6. Check for data transfer after the DDNS connection — review DeviceNetworkEvents for BytesSent/BytesReceived values and look for large outbound transfers (potential exfiltration) or large inbound transfers (potential payload stage download) following the DDNS resolution event.

Containment

  1. Block the specific DDNS FQDN at your internal DNS resolver level by sinkholing the domain — this prevents other hosts from resolving the same C2 FQDN and provides visibility into which other hosts attempt the same resolution. Configure the sinkhole to respond with a controlled internal IP and log all queries.
  2. Block the resolved IP address(es) at the network perimeter firewall and proxy, but do not rely on IP blocking alone — DDNS IP addresses are designed to change frequently (especially in Fast Flux campaigns) and the adversary can update the record within minutes of detecting a block.
  3. If active C2 communication is confirmed and the implant is operating, isolate the endpoint using EDR network isolation immediately — this must be done before any further credential activity or lateral movement can occur. Coordinate with the endpoint owner to minimize operational impact.
  4. If the DDNS domain resolves to a specific ASN or hosting provider bloc being used for C2, consider requesting a temporary block of that IP range at the perimeter while contacting the hosting provider's abuse team with evidence — note the operational risk of blocking legitimate traffic from that ASN.
  5. If the malicious process is injected into a legitimate application or is a DLL loaded by a legitimate process, terminate the specific PID (not the application) and quarantine the injected DLL — preserve a copy of the DLL to disk for forensic analysis before quarantine.

Evidence Collection

  1. Sysmon Event ID 22 (DNS Query) — the primary artifact. Contains QueryName (DDNS FQDN queried), QueryType (A/AAAA/TXT), QueryResults (comma-separated resolved IPs), and the full initiating process path. Critical for establishing exact timing and confirming which domains were resolved.
  2. Sysmon Event ID 3 (Network Connection) — captures the actual TCP/UDP connections established after DNS resolution, including destination IP, destination port, protocol, and initiating process. Use this to confirm C2 protocol (HTTP, HTTPS, raw TCP, DNS-over-TCP) and connection frequency.
  3. Sysmon Event ID 1 (Process Create) — captures the full command line, hashes (MD5, SHA1, SHA256), parent process, and user context of the process making DDNS connections. Hash the binary and submit to VirusTotal for immediate verdicts.
  4. Sysmon Event ID 11 (File Create) — identifies any files written to disk by the malicious process after establishing C2 contact, such as second-stage payloads, configuration files, or exfil staging archives.
  5. Windows DNS client cache — immediately run 'ipconfig /displaydns' on the isolated endpoint to capture all currently cached DNS resolutions including DDNS FQDNs, their associated IPs, and TTL values. A TTL of 30–300 seconds for a DDNS domain indicates Fast Flux infrastructure.
  6. Memory acquisition — if the malware is suspected to be fileless or DGA-based (requiring runtime domain generation), acquire a full volatile memory dump using WinPmem (winpmem_mini_x64.exe -o memory.dmp) before any remediation. DGA seed values, wordlists, and embedded C2 configurations are often only present in memory.
  7. Network PCAP — if available from a TAP, span port, or inline IDS appliance, collect full packet captures for connections to the DDNS-resolved IP. PCAP provides C2 protocol identification, beacon interval measurement, and may reveal operator commands if the protocol is unencrypted.
  8. DDNS provider abuse report — file an abuse report with the DDNS provider (No-IP, DuckDNS, Afraid.org, DynDNS) including the full FQDN, associated IP, and timeline evidence. Providers often respond by taking down the hostname and may share registration metadata with law enforcement.

Escalation Criteria

  • ! The DDNS FQDN or its resolved IP appears in a threat intelligence feed with confirmed malicious associations, or matches known infrastructure for named threat actors (APT29, Gamaredon, TA2541) — escalate immediately to incident response regardless of other indicators.
  • ! Active C2 beaconing confirmed — the process is making connections to the DDNS-resolved IP at consistent intervals (30–600 seconds) and connections are bidirectional with inbound data — the implant is actively receiving operator commands.
  • ! Multiple distinct endpoints in the environment are resolving the same malicious DDNS FQDN — indicates successful broad propagation, a phishing campaign targeting multiple users, or a supply chain compromise. Expand the scope investigation immediately.
  • ! Post-exploitation activity detected following DDNS C2 contact — any evidence of credential access (LSASS access via Sysmon Event ID 10, SAM hive reads, Mimikatz signatures), lateral movement (new SMB connections, WMI remote process creation, PsExec), or data staging (large archive file creation in temp directories) elevates to Severity 1.
  • ! The DDNS domain resolves to a new IP address every few minutes during investigation — this is Fast Flux infrastructure, indicating a professional adversary with significant operational resources dedicated to infrastructure resilience. Do not waste time on IP blocking; focus on endpoint containment and behavioral analysis.
  • ! The DDNS resolution originates from a privileged account context (Domain Admin, SYSTEM, a service account with broad access) — the blast radius of a compromised privileged account significantly increases the urgency of containment.

Investigation Guide

Forensic Artifacts

  • > Windows DNS resolver cache — 'ipconfig /displaydns' output: contains all recently resolved FQDNs with their associated IP addresses and remaining TTL values. Short TTLs (30–300 seconds) are a Fast Flux indicator. Cache is volatile and lost on DNS client restart or flush.
  • > Sysmon operational event log — Microsoft-Windows-Sysmon/Operational: Event IDs 1 (process create), 3 (network connection), 11 (file create), 22 (DNS query) provide correlated endpoint telemetry with millisecond timestamps for timeline reconstruction.
  • > Windows DNS Server analytical log — Microsoft-Windows-DNS-Server/Analytical event channel (enable via wevtutil sl Microsoft-Windows-DNS-Server/Analytical /e:true): captures all DNS queries proxied through on-premises DNS resolvers, including client IP and queried FQDN.
  • > Prefetch files — C:\Windows\Prefetch\<MALWARE>.EXE-*.pf: confirms binary execution timestamps, DLLs loaded, and files accessed. Use Eric Zimmerman's PECmd.exe to parse. Useful for establishing when malware first ran relative to first DDNS query.
  • > Network connection artifacts — 'netstat -ano' output or firewall/NAT session tables: shows active connections to DDNS-resolved IPs with process IDs for correlation with running process list. Time-sensitive; collect before isolation if possible.
  • > Registry persistence locations — HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKLM\SYSTEM\CurrentControlSet\Services (service installs), scheduled tasks at C:\Windows\System32\Tasks\: DDNS C2 malware typically installs persistence to survive reboots.
  • > Process memory artifacts — for DGA-based malware, the seed value, wordlist dictionary, TLD list, and date-based seed calculation logic are present in process memory and can be extracted to pre-compute future domain names for proactive blocking before the next registration.
  • > Browser history and download records — if infection vector was a drive-by download or spear-phishing link, browser history (Chrome: %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, Firefox: %APPDATA%\Mozilla\Firefox\Profiles\*\places.sqlite) may reveal the landing page hosted on a DDNS domain.

Tuning Guidance

Begin by baselining all DDNS provider connections in your environment over a 30-day lookback period. Many organizations have legitimate DDNS usage — remote access tools, IoT/camera systems, and developer home labs. Query DeviceNetworkEvents for all DDNS provider RemoteUrl matches and identify the initiating processes, user accounts, and destination FQDNs. Allowlist specific process+FQDN+user combinations rather than entire DDNS providers or process names — never suppress an entire DDNS provider domain from detection. For Sysmon Event ID 22 (DNS Query), verify that your Sysmon deployment configuration enables DNS query logging — it is frequently disabled in default Sysmon configs due to volume. Add it under the DnsQuery rule group with a 'ProcessName is not System' filter. For Fast Flux hunting, immediately exclude known CDN provider parent domains (akamaitechnologies.com, cloudflare.net, awsstatic.com, fastly.net, azureedge.net) which legitimately rotate through large IP pools. For DGA subdomain hunting, tune the vowel ratio threshold based on your environment's internal DNS naming conventions — some naming schemas use numeric or abbreviation-heavy labels that may have low vowel density without being malicious. Consider enriching alerts with domain age from WHOIS lookups via threat intel API integration — DDNS FQDNs registered or updated within 30 days of first observation warrant higher priority. For environments with Splunk ES, the DDNS provider list should be maintained as a lookup table (ddns_providers.csv) rather than hardcoded in SPL to enable rapid updates when adversaries pivot to new DDNS providers.

Hunting Queries

Hunt for non-browser processes making abnormally high volumes of DNS queries to external resolvers, or using multiple distinct external DNS servers instead of the corporate resolver. DGA malware systematically cycles through hundreds or thousands of algorithmically generated domain names per day looking for registered C2 domains — producing DNS query volumes orders of magnitude above legitimate application behavior. Using non-corporate DNS servers (public resolvers like 8.8.8.8) is an additional evasion indicator to split DNS logging.

Hunting — KQL
kql 
// Hunt for DGA-like behavior: non-browser processes making abnormally high volumes
// of outbound DNS queries — characteristic of malware cycling through DGA domain candidates
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 53
| where RemoteIPType == "Public"
| where InitiatingProcessFileName !in~ (
    "chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe",
    "svchost.exe", "dns.exe", "dnscache.exe"
)
| summarize
    DNSQueryCount = count(),
    UniqueExternalResolvers = dcount(RemoteIP),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    SampleCommandLines = make_set(InitiatingProcessCommandLine, 3)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessParentFileName
| where DNSQueryCount > 100 or UniqueExternalResolvers > 3
| extend SessionDurationMinutes = datetime_diff('minute', LastSeen, FirstSeen)
| extend QueriesPerMinute = iff(SessionDurationMinutes > 0, todouble(DNSQueryCount) / SessionDurationMinutes, todouble(DNSQueryCount))
| sort by DNSQueryCount desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 DestinationPort=53
  NOT (Image="*\\chrome.exe" OR Image="*\\firefox.exe" OR Image="*\\msedge.exe" OR Image="*\\svchost.exe" OR Image="*\\dns.exe")
  NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
| stats count as DNSQueryCount, dc(DestinationIp) as UniqueExternalResolvers, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(CommandLine) as SampleCommandLines by host, Image, ParentImage
| where DNSQueryCount > 100 OR UniqueExternalResolvers > 3
| eval SessionDurationMinutes=round((LastSeen-FirstSeen)/60, 1)
| eval QueriesPerMinute=if(SessionDurationMinutes>0, round(DNSQueryCount/SessionDurationMinutes,1), DNSQueryCount)
| sort - DNSQueryCount

Hunt for Fast Flux DNS indicators by identifying FQDNs that resolve to five or more distinct public IP addresses across all endpoints within a one-hour window. Fast Flux infrastructure keeps DNS TTLs extremely short (30–300 seconds) and rotates through large pools of compromised intermediary nodes to prevent IP-based blocking and resist infrastructure takedown. Legitimate CDN providers (Akamai, Cloudflare, AWS) will also appear — exclude by parent domain. Note: the KQL variant requires the DnsEvents table sourced from Windows DNS Server analytical logs or Azure DNS log forwarding into Sentinel.

Hunting — KQL
kql 
// Hunt for Fast Flux indicators: domains resolving to many distinct IPs across the environment
// within a short time window. Requires DnsEvents table (Windows DNS Server or Azure DNS logs).
DnsEvents
| where TimeGenerated > ago(24h)
| where SubType == "LookupQuery"
| where isnotempty(IPAddresses)
| mv-expand ParsedIP = split(IPAddresses, ";")
| extend CleanIP = trim(@"\s", tostring(ParsedIP))
| where CleanIP matches regex @"^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$"
// Exclude private and loopback ranges
| where CleanIP !startswith "10." and CleanIP !startswith "172." and CleanIP !startswith "192.168." and CleanIP != "127.0.0.1"
| summarize
    UniqueIPs = dcount(CleanIP),
    IPList = make_set(CleanIP, 30),
    QueryCount = count(),
    UniqueClients = dcount(ClientIP)
    by Name, bin(TimeGenerated, 1h)
| where UniqueIPs >= 5
| extend IsFastFlux = iff(UniqueIPs >= 10, true, false)
| sort by UniqueIPs desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| rex field=QueryResults max_match=30 "type:\s*\d+\s+(?P<resolved_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})"
| where NOT match(resolved_ip, "^(10\.|172\.(1[6-9]|2\d|3[01])\.|192\.168\.|127\.)") AND isnotnull(resolved_ip)
| stats dc(resolved_ip) as UniqueIPs, values(resolved_ip) as IPList, count as QueryCount, dc(host) as UniqueHosts by QueryName
| where UniqueIPs >= 5
| eval IsFastFlux=if(UniqueIPs>=10, "YES", "POSSIBLE")
| sort - UniqueIPs

Hunt for DNS queries containing long, low-vowel-density subdomain labels indicative of DGA-generated domain names. Human-readable words and hostnames have vowel ratios of 0.35–0.45; algorithmically generated strings from DGA malware (Conficker, SUNBURST, Zeus, Dridex variants) typically fall below 0.25 because they draw from character distributions that don't respect natural language phonetics. This query finds labels that are long enough to carry entropy and statistically unpronounceable — a pattern absent from legitimate application DNS usage.

Hunting — KQL
kql 
// Hunt for high-entropy subdomain labels that may indicate DGA-generated domain names
// SUNBURST used patterns like 'r8stkst7i2s0amdb29dlq9b3dn'.avsvmcloud.com
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where ActionType in ("ConnectionSuccess", "ConnectionAttempted", "ConnectionFailed")
| where isnotempty(RemoteUrl)
// Extract the leftmost subdomain label
| extend DomainParts = split(RemoteUrl, ".")
| extend SubdomainLabel = tostring(DomainParts[0])
| extend LabelLength = strlen(SubdomainLabel)
// Focus on labels long enough to be DGA but not matching obvious legitimate patterns
| where LabelLength between (12 .. 45)
// Remove purely numeric labels (would indicate IP address parsing)
| where SubdomainLabel !matches regex @"^\d+$"
// Remove known-legitimate long subdomain conventions
| where SubdomainLabel !in~ (
    "autodiscover", "webmail", "remote", "vpngateway", "sslvpn",
    "clientconfig", "enterpriseenrollment", "enterpriseregistration"
)
// Flag labels with low vowel density (DGA domains are often unpronounceable)
| extend VowelMatches = array_length(extract_all(@"[aeiouAEIOU]", SubdomainLabel))
| extend VowelRatio = todouble(VowelMatches) / LabelLength
| where VowelRatio < 0.25
| summarize
    MatchCount = count(),
    UniqueDevices = dcount(DeviceName),
    SampleProcesses = make_set(InitiatingProcessFileName, 5),
    SampleDomains = make_set(RemoteUrl, 10)
    by SubdomainLabel, VowelRatio, LabelLength
| sort by LabelLength desc, VowelRatio asc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| rex field=QueryName "^(?P<subdomain_label>[^\.]+)\."
| eval label_length=len(subdomain_label)
| where label_length >= 12 AND label_length <= 45
| where NOT match(subdomain_label, "^(autodiscover|webmail|remote|vpngateway|sslvpn|clientconfig|enterpriseenrollment|enterpriseregistration|localhost)$")
| where NOT match(subdomain_label, "^[0-9]+$")
| rex field=subdomain_label max_match=50 "(?P<vowel>[aeiouAEIOU])"
| stats count as vowel_count by subdomain_label, label_length, QueryName, Image, host
| eval vowel_ratio=round(vowel_count/label_length, 2)
| where vowel_ratio < 0.25
| stats count as MatchCount, dc(host) as UniqueHosts, values(Image) as Processes, values(QueryName) as SampleDomains by subdomain_label, label_length, vowel_ratio
| sort - label_length vowel_ratio

Atomic Red Team Tests

Test 1 Windows - Non-Browser DDNS Resolution via PowerShell
windows

Simulates a malware implant using PowerShell to resolve a DDNS-hosted C2 domain. This tests that Sysmon Event ID 22 captures non-browser DDNS DNS queries and that DeviceNetworkEvents logs the connection. PowerShell is a commonly abused process for DDNS C2 resolution in frameworks such as AsyncRAT and PowerShell-based RATs. The resolution will return NXDOMAIN or an IP — the DNS query telemetry fires regardless of whether the domain is registered.

Command

powershell 
powershell.exe -NoProfile -Command "Resolve-DnsName -Name 'atomictest-c2.duckdns.org' -Type A -ErrorAction SilentlyContinue; [System.Net.Dns]::GetHostAddresses('atomictest-beacon.ddns.net') | Out-Null"

Expected Telemetry

Sysmon Event ID 22 (DNS Query): Two events with QueryName='atomictest-c2.duckdns.org' and 'atomictest-beacon.ddns.net', Image='C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe', QueryResults showing NXDOMAIN or resolved IP. Sysmon Event ID 1 (Process Create): powershell.exe with '-NoProfile -Command' command line. DeviceNetworkEvents in MDE: RemoteUrl containing 'duckdns.org' or 'ddns.net' if HTTP-level connection occurs.

Expected Detection

KQL alert fires on RemoteUrl has_any (KnownDDNSProviders) with InitiatingProcessFileName='powershell.exe', IsHighRiskProcess=true, RiskScore=3. SPL alert fires on IsDDNSQuery=1 with IsHighRiskProcess=1, RiskScore=3. Process is identified as high-risk, maximizing alert priority score.

Test 2 Windows - DGA Simulation: Bulk Algorithmic Subdomain Resolution
windows

Simulates Domain Generation Algorithm behavior by issuing rapid sequential DNS lookups for algorithmically named subdomains from a non-browser process. This replicates the pattern seen in SUNBURST, Conficker, Zeus, and Dridex where malware cycles through hundreds of generated candidates per day seeking a registered C2 domain. The generated labels are intentionally unregistered (NXDOMAIN expected) and use low-vowel-density strings to trigger the DGA hunting query. nslookup.exe is used directly to generate Sysmon Event ID 3 (network connection to port 53) in addition to Event ID 22.

Command

powershell 
cmd.exe /c "for %d in (xj3kp9mq2rtv dw8vn1tz6sbl hn5mb4ql7cwr rk2pt8xw3dfg fg7vc1nq9mkz bz4xd6pw8tlr kx9mn3qt7vsc) do nslookup %d.dyndns.org 8.8.8.8"

Expected Telemetry

Sysmon Event ID 22: Seven DNS query events in rapid succession from nslookup.exe, QueryName matching 'xj3kp9mq2rtv.dyndns.org' through 'kx9mn3qt7vsc.dyndns.org', QueryResults=NXDOMAIN. Sysmon Event ID 3: UDP connections to 8.8.8.8:53 from nslookup.exe. Sysmon Event ID 1: cmd.exe with the for-loop command and nslookup.exe child processes. Security Event ID 4688 (with command-line auditing enabled).

Expected Detection

SPL alert fires on IsDDNSQuery=1 for each 'dyndns.org' query. DGA beaconing hunting query detects elevated DNS query count from cmd.exe/nslookup.exe to external resolver 8.8.8.8. DGA subdomain label hunting query flags all seven labels (length 12–13, vowel ratio ~0.15) as high-entropy algorithmic names. Defender for Endpoint behavioral rules may independently alert on bulk nslookup execution.

Test 3 Windows - DDNS Update API Callback (Adversary Infrastructure Registration)
windows

Simulates the DDNS update mechanism used by malware to register or refresh the IP address of C2 infrastructure. Many C2 frameworks (AsyncRAT, njRAT, various PowerShell RATs) embed a DDNS update routine that periodically calls the DDNS provider's API to associate the target environment's egress IP (or a relay IP) with the C2 hostname. This test uses DuckDNS's documented update API format — the invalid token causes an HTTP 'KO' response, but the connection and DNS query telemetry fire correctly. PowerShell is run with -WindowStyle Hidden to trigger additional T1059.001 detections.

Command

powershell 
powershell.exe -NoProfile -WindowStyle Hidden -Command "try { Invoke-WebRequest -Uri 'https://www.duckdns.org/update?domains=atomictest&token=00000000-0000-0000-0000-000000000000&ip=' -UseBasicParsing -TimeoutSec 10 -ErrorAction Stop } catch { Write-Output $_.Exception.Message }"

Expected Telemetry

Sysmon Event ID 22 (DNS Query): QueryName='www.duckdns.org', Image='powershell.exe'. Sysmon Event ID 3 (Network Connection): TCP connection to duckdns.org:443, DestinationHostname='www.duckdns.org', Image='powershell.exe'. Sysmon Event ID 1 (Process Create): powershell.exe with '-NoProfile -WindowStyle Hidden' in command line. DeviceNetworkEvents: RemoteUrl='www.duckdns.org', RemotePort=443, InitiatingProcessFileName='powershell.exe'.

Expected Detection

KQL DDNS detection fires on RemoteUrl has 'duckdns.org' with IsHighRiskProcess=true (powershell.exe), RiskScore=3. SPL DDNS detection fires on IsDDNSQuery=1, IsHighRiskProcess=1. T1059.001 PowerShell detection also fires on '-WindowStyle Hidden' in command line, providing correlated multi-technique alert. MDE may generate a separate behavioral alert for hidden-window PowerShell making outbound HTTPS connections.

Test 4 Linux - DDNS Domain Resolution from Shell Process
linux

Simulates a Linux malware implant (ELF backdoor or shell dropper) resolving DDNS-hosted C2 domains using common Linux system utilities. Linux malware using DDNS (Tomiris, various ELF backdoors targeting Linux servers) typically calls getaddrinfo() or executes system dig/curl/wget utilities for C2 resolution. This generates DNS resolution telemetry via auditd SYSCALL records and network connection events. Both dig and curl are used to produce multiple artifact types across different log sources.

Command

bash 
dig +short atomictest.hopto.org A @8.8.8.8 ; curl -s --max-time 5 --connect-timeout 3 http://atomictest.ddns.net/ -o /dev/null || true

Expected Telemetry

Auditd SYSCALL records: execve() calls for 'dig' and 'curl' binaries with full argument lists. Auditd SOCKADDR records (if network rules enabled): UDP connection to 8.8.8.8:53 from dig, TCP connection to ddns.net IP from curl. Syslog: DNS resolution events and connection attempts. If Sysmon for Linux is deployed: Sysmon EventCode 22 (DNS Query) for 'atomictest.hopto.org' and EventCode 3 (Network Connection) for connections to 8.8.8.8 and ddns.net IP. Network flow logs: UDP/53 to 8.8.8.8 from dig PID, TCP/80 to ddns.net IP from curl PID.

Expected Detection

Linux-specific Splunk SPL detection against syslog or linux_secure sourcetypes for outbound connections to DDNS provider domains from shell processes. Custom auditd rule alert for network connections from non-browser processes to known DDNS provider IPs. Proxy/firewall log detection via domain match. Sysmon for Linux EventCode 22 triggers the same SPL DDNS query as the Windows variant when both share the same index.

Related Detections

Tactic Hub

TA0011Command and Control

Sub-techniques (3)

Related Techniques

T1568.001Fast Flux DNST1568.002Domain Generation AlgorithmsT1568.003DNS CalculationT1071.004DNST1071.001Web ProtocolsT1008Fallback ChannelsT1583.001DomainsT1090ProxyT1027Obfuscated Files or InformationT1048Exfiltration Over Alternative Protocol

Same Tactic: Command and Control

Popular Detections