How T1568 dynamic resolution hides command and control in DNS and other lookups
T1568 Dynamic resolution sits under the Command and Control tactic (MITRE ATT&CK tactic TA0011), where adversaries change how a name resolves so that the infrastructure they use to reach compromised systems is hard to pin down. It matters because a domain or address blocked yesterday may answer from a different place today, which makes static blocklists and one-off takedowns go stale quickly. For a SOC lead, the first signal is rarely a named threat. It is a host that resolves the same name every few minutes to a shifting set of answers, with traffic that looks like ordinary lookups but repeats on a rhythm no user would produce.
T1568 has three sub-techniques, and they explain why one detection rule rarely covers the whole technique. Fast flux DNS (T1568.001) describes resolution that rotates addresses behind a single name over short intervals. Domain generation algorithms (T1568.002) describe names produced by a repeatable calculation, so many candidate domains appear while only a few are ever registered. DNS calculation (T1568.003) describes resolution where the answer is computed from logic embedded in the lookup itself. Each one leaves a different trace in resolver logs, flow records and proxy data, so the detection plan should start by deciding which trace each sub-technique will be measured against.
Treat the ATT&CK version as part of the detection record. This page references Enterprise ATT&CK 20.0, and the bundle in the attack-stix-data repository is the place to confirm sub-technique names, data component IDs and mitigation mappings before writing rules. Ask your detection engineering lead to confirm which version the SIEM content and Sigma rules target, and record that version beside each rule. Releases can rename, deprecate or revoke techniques, so a rule written against an older version may stop matching what the framework now describes. Schedule a review each time the ATT&CK version changes.
Which telemetry reveals dynamic resolution and which open-source tool collects it
This table maps the data components most often tied to T1568 detection strategies to the signals they expose, the open-source tools that collect them, and the platforms where collection paths differ. Read each row as a question: what does the adversary's resolution behavior look like in this data, and which agent or sensor gives you that view. The main takeaway is that ESXi and network devices need their own collection paths, and that Network Traffic Content coverage must be confirmed per platform before you rely on it.
| Telemetry source | Signal relevant to T1568 | Collection path and open-source tooling | Platform notes |
|---|---|---|---|
| Network Connection Creation (DC0082) | New outbound connections that follow name lookups, including unusual timing or destinations tied to resolution behavior | Wazuh agent or Sysmon-equivalent logging on endpoints, correlated with DNS and proxy logs | Linux and Windows endpoints expose this through host telemetry; confirm macOS coverage in your agent version |
| Process Creation (DC0032) | Processes that initiate network activity or resolution-related requests shortly after starting | Wazuh agent with auditd on Linux, Sysmon-equivalent process logging on Windows | Confirm which process fields your agent captures on each platform before writing rules |
| Network Traffic Flow (DC0078) | Flow metadata showing connection pairs, volume, and periodic patterns associated with resolution changes | Zeek connection logs or Suricata flow records feeding Security Onion or a SIEM | Works at network boundaries and sensors; does not show which process made the request |
| Network Traffic Content (DC0085) | Payload or protocol fields in DNS and HTTP traffic that reflect resolution behavior | Zeek protocol analyzers or Suricata rules on monitored segments | Referenced by related detection strategies; confirm per platform and per encryption state before relying on it |
| ESXi hosts | Management and VM network connections originating from the hypervisor | Forward host logs with a syslog collector to Wazuh; capture traffic at a virtual or physical switch span point | Agents are not installed on ESXi in the usual way; plan a separate syslog and network sensor path |
| Network devices and other platforms | Resolver and gateway logs showing lookup patterns and destination changes | Syslog or flow export from the device into Zeek, Suricata or Wazuh | Device log formats and export options vary; confirm vendor capabilities during scoping |
| Resolver and DNS logs (supporting source) | Query names, response records and rate changes that line up with endpoint events | Forward resolver logs to Wazuh or a SIEM and join with endpoint and flow data | Log retention and query detail depend on the resolver product; confirm what your configuration records |
Detection logic for dynamic resolution that SOC engineers can tune
T1568 Dynamic resolution hides command and control behind domains that change quickly, so single indicators rarely settle a case. The cards below combine resolution volume, domain age, answer churn and process-to-network context, and each one lists the baseline and benign sources that should shape its thresholds before alerts reach an analyst.
Unusual resolution frequency per host
Count DNS queries per endpoint over a rolling window and compare each host against its own historical baseline rather than a fleet-wide number. Beaconing that uses dynamic domains often shows a steady query cadence to a small set of names, which is easier to see per host than in aggregate. Tune the window and multiplier against a baseline captured during normal business operations. Expect false positives from monitoring agents, update clients, CDN-heavy browsers, and load-balanced SaaS endpoints that re-resolve often, so maintain allowlists by destination owner and review them quarterly.
Short-lived domains with high answer churn
Flag names that return many distinct addresses or a changing answer set within a short period, and that were first seen recently. Content delivery networks and cloud load balancers also rotate addresses, so the signal is strongest when churn combines with a young registration and a low count of clients. Tune the age threshold and churn ratio using your own resolver logs, and confirm whether your threat intelligence feed supplies registration data. Legitimate dynamic DNS services, short-lived marketing campaigns and newly launched SaaS tenants will also match, so route these to enrichment rather than automatic blocking.
Resolution to newly seen infrastructure
Track destinations that appear in resolver answers or outbound connections for the first time in your environment and score them against asset criticality. This connects Network Connection Creation records to DNS answers, so an analyst can see which process reached an address that was never seen before. Set the novelty window from your baseline period and exclude known vendor ranges during onboarding. Common false positives include software releases, new SaaS regions, and cloud autoscaling events, which should be documented in change records so the rule can be suppressed with an audit trail.
Process-to-network correlation on Linux, macOS and Windows
Join each DNS lookup to the process that issued it, then to the network connection that followed, using Process Creation and Network Connection Creation telemetry. A resolution from an unexpected interpreter, a shell, or a process running from a temporary directory carries more weight than the domain alone. Tune the process allowlist per operating system, since browsers, package managers and endpoint agents differ across Linux, macOS and Windows. Confirm that your endpoint sensor records the originating process for DNS queries, because some collection methods only capture the resolver's view.
Baseline and benign source inventory
Build a written inventory of legitimate sources that resolve dynamically, including CDNs, cloud load balancers, email security gateways, authorized dynamic DNS, and internal split-horizon zones. Record the owner, expected query volume and review date for each entry. Without this inventory, thresholds from the other cards will either generate noise or hide real beaconing. Ask your team to confirm which vendors publish stable domain lists and which require periodic re-validation, and keep the inventory under change control so suppressions can be traced during an investigation.
How to validate that the T1568 detection fires
This sequence proves, in a private cyber range, that the T1568 Dynamic Resolution detections fire on the intended platforms, produce traceable evidence, and hold up when log sources are degraded. The output is a validation record that the detection owner can tune and an assessor can review.
Define the test scope and platforms
The detection owner and the threat team agree in writing which T1568 sub-techniques are in scope, which platforms are covered (ESXi, Linux, macOS and Windows), and which hosts in the cyber range will act as sources and targets. The scope names the ATT&CK version the detections map to, so every later result can be traced to one version of the technique. This step is complete when the scope document is signed off and every in-scope platform has a named test host. Confirm the targeted ATT&CK version against the MITRE ATT&CK updates page before the scope is final, since releases can rename or deprecate techniques.
Write the expected alert matrix
Before any activity runs, the team writes down what each detection should produce: the platform, the sub-technique, the data components expected to carry the signal (such as Network Connection Creation, Process Creation or Network Traffic Flow), the expected alert name, and the severity. Writing expectations first prevents the team from treating any alert as a pass after the fact. The matrix is complete when every in-scope detection has at least one expected alert and one stated reason it would be silent. Illustrative example: a Linux host producing a process-level signal but no network-level signal would be recorded as a partial match, not a full one.
Run the emulation plan in the range
A red or purple team member executes the agreed emulation plan in the isolated cyber range, following only the approved technique descriptions and never against systems outside the range. A second person observes the run and logs the start and end time of each scenario against the platform it targets. The step closes when every scenario in the plan has a recorded start and stop time and the operator has confirmed that the scenario ran as designed. Keep the emulation plan itself in the range records, not in the detection repository, so the tuning work does not depend on attack detail.
Record alerts and evidence per scenario
The analyst collects, for each scenario, the alert timestamps from the SIEM or Wazuh manager, the rule identifiers that fired, the source telemetry references, and the ATT&CK version and sub-technique labels attached to each alert. Each record is compared against the expected alert matrix and marked as matched, partial or missed. The step is complete when every scenario has one evidence record that a reviewer can open without asking the operator for context. Timestamps should be stored in one time zone and checked for clock drift between the range hosts and the collector.
Test detection survival under log loss
The team repeats selected scenarios while deliberately degrading the telemetry path, for example by pausing an agent, dropping one network sensor feed, or delaying log forwarding in the range. The goal is to learn which detections depend on a single data source and which still fire when a second source is available. The step is complete when each degraded run has a recorded outcome for every affected detection, and the team has written down which detections fail silently under loss. Any detection that fails silently is raised as a finding with a named owner, because silent failure is the outcome most likely to be missed in production.
Log misses and tuning actions
Every missed or partial result is entered in a tuning log with the scenario identifier, the expected alert, the observed telemetry, the suspected cause (such as a missing data component, a threshold, or a parsing gap), and a proposed change. The detection owner reviews the log and decides whether to adjust the rule, add a data source, or accept the gap with a documented reason. The step is complete when each miss has a disposition and a link to the change ticket. Re-run the affected scenarios after each change so the team can show the miss is closed rather than assumed closed.
Package the validation record for review
The team assembles a validation record containing the scope, the ATT&CK version targeted, the expected alert matrix, the per-scenario evidence, the log loss results, and the tuning log. Compliance and audit stakeholders receive the same record so that controls and evidence line up without duplicate work. The record is complete when an independent reviewer can trace one detection from its rule identifier to a range run and a dated alert. Confirm with the internal assessor or external auditor which format they expect, since DeployOpen prepares evidence but does not issue audit opinions or certifications.
Preventive controls mapped to ATT&CK mitigations for dynamic resolution
T1568 Dynamic resolution hides control infrastructure behind domains and addresses that change over time, so blocking a single indicator rarely holds. The two ATT&CK mitigations below, Network Intrusion Prevention (M1031) and Restrict Web-Based Content (M1021), act at different points: one inspects and blocks traffic on the wire, the other limits which web destinations hosts can reach at all. Their value depends on what each product in your environment actually inspects and enforces.
Network intrusion prevention (M1031)
M1031 covers systems that detect and block known-bad or suspicious network traffic inline. For T1568, the useful question is whether your IPS or next-generation firewall can act on DNS-level and connection-level signals, such as queries to newly registered or algorithmically generated domains, and not only on fixed IP addresses. Confirm with your vendor which signature sets, reputation feeds and behavioral rules run in prevention mode versus alert-only mode. Suricata and Zeek-based sensors can alert on this traffic, but blocking depends on how your deployment is placed and configured.
Restrict web-based content (M1021)
M1021 focuses on limiting which web content and destinations users and systems can reach. Against dynamic resolution, this reduces the set of domains a compromised host can contact at all, which matters most for servers and privileged workstations that have no business reason to browse. Check whether your secure web gateway or proxy enforces category-based and allow-list policies for server subnets, not only for user segments. Ask your vendor how new or uncategorized domains are handled, because that setting determines whether freshly generated domains are blocked by default.
Default-deny egress for servers
Restricting outbound web access is most effective when servers are placed on an egress policy that defaults to deny and permits only documented destinations. Dynamic resolution works by rotating through many names, so a default-deny stance forces an attacker to find a permitted path, which is harder to do quietly. Validate this by reviewing the egress rule set against actual business flows and recording each exception with an owner. Expect some operational friction when patch sources or update services change, so test changes in staging first.
DNS resolution policy
Dynamic resolution depends on DNS lookups, so controls over which resolvers hosts may use and how lookups are logged close an important gap. Confirm that workloads query only approved internal resolvers and that outbound DNS to arbitrary external servers is blocked or inspected. Your IPS or secure gateway may act on DNS categories, but whether it does so inline depends on your architecture, so verify that with the vendor and test the policy in a lab before enforcement.
Control validation and exceptions
A preventive control only reduces T1568 exposure if its rules are current and its exceptions are reviewed. Document which signatures, categories and allow-lists are active, who approves exceptions, and how often rules are reviewed against the ATT&CK version your detections target. Ask your vendor for evidence of rule update history and for logs showing blocked versus allowed decisions. Pair these checks with the detection content in your SIEM so that a blocked lookup still produces an alert for triage.
Triage and response when a dynamic resolution alert fires
The first decision on a dynamic resolution alert is whether the destination is hostile or merely unusual, and that call should be made on evidence, not on the alert severity alone. Confirm the alert against the raw DNS query and answer records in your resolver or sensor logs, then identify the host, the user context and the process that issued the lookup. Correlate the domain with Network Connection Creation records to see whether a connection actually followed the resolution. A lookup with no matching connection is a weaker signal than a lookup followed by traffic to the returned addresses, and your triage notes should record which of the two you found. Also confirm the domain is not a known content delivery or cloud service that legitimately rotates addresses, since many do.
Next, reconstruct the resolution history for the domain. Pull the sequence of answers returned over the surrounding window and check whether the addresses changed frequently, whether the time-to-live values were unusually short, and whether the same host kept querying after an answer went stale. Compare the observed history against your own baseline for that domain, and against any threat intelligence feed you subscribe to. Preserve the DNS query logs, the resolver configuration in effect at the time, and the Network Traffic Flow records for the affected host before any cleanup changes the state. If the destination is confirmed hostile, isolate the host at the network layer while keeping its memory and disk state intact for forensic review, and block the domain at the resolver so other hosts stop reaching it. Record who approved each step.
Finally, check whether the same host shows related Command and Control behavior. Review application layer protocol use (T1071) and proxy or relay traffic (T1090) from the same host over the same window, because a dynamic resolution fallback often sits alongside those techniques. Look at the process tree for the process that issued the lookup and note any other network activity it generated. Your incident owner should decide whether to widen the scope to other hosts that queried the same domain, based on the findings. Confirm with your incident response runbook and your own logging retention which DNS and flow records you hold, and how far back they go, before you commit to a containment date.
Rehearsing T1568 detection and response in a private cyber range
A private range for T1568 needs one segment per platform so that each platform's telemetry can be tested on its own before you compare results across them. The Linux and macOS segments should have host-level process and network logging on endpoints that resolve names through their normal resolver chain. The Windows segment should include DNS client logging and process creation auditing, and the ESXi segment should send its management and host logs to the same collector as the other segments. Place a recursive resolver, a controlled authoritative zone you own, and a network sensor on a mirror or tap between the endpoints and the resolver. Keep the range isolated from production networks and from the public internet, and confirm with your own environment owners how each platform's logs are forwarded and retained.
- Linux segment: Include one host with resolver and process logging enabled, plus a host where the agent's coverage is deliberately partial, so analysts see the gap.
- macOS segment: Confirm which unified log categories your endpoint agent collects, since coverage differs from Linux and Windows.
- Windows segment: Verify that DNS client and process creation events reach the SIEM with fields intact.
- ESXi segment: Confirm which host and management logs can be forwarded and whether network telemetry is available from the vSwitch path.
- Sensor placement: Position Zeek or Suricata where it can see DNS and connection metadata for every segment.
Before the first run, check that the range's clocks are synchronized across segments so that timelines can be compared.
Injects should change how a name resolves over the course of the exercise, using only names and infrastructure you control. The aim is to test whether your detections notice a shift in resolution pattern, such as a name that resolves to different addresses over short intervals, or a name whose answers change after a defined event. Write each inject as a scenario with an expected log footprint, so the exercise can later check what was actually recorded. Label every inject as illustrative in the exercise plan, and keep the set small enough that the exercise can be repeated after tuning.
- Resolution change: Have the controlled zone return different answers for one name across a defined window and record which endpoints queried it.
- Platform spread: Run the same pattern from each segment so that differences in telemetry are visible.
- Benign control: Include a name with normal, stable answers to measure false positives from CDNs and load-balanced services.
- Sub-technique variation: Vary the pattern across the three sub-techniques to confirm that each has its own detection path.
- Timed rollback: End the inject by restoring stable answers so analysts can confirm the alert clears.
Record the exact inject parameters in the exercise log, because the detection tuning work depends on knowing what was sent.
A good alert for T1568 should identify the host, the process or service that made the lookups, the name queried, and the set of answers observed over the window. The case timeline should show when the first unusual answer appeared, when the second differing answer appeared, and which downstream connections followed. Judge detections against the expected footprint written for each inject, not against whether something fired. An alert that fires on every segment but lacks the process context is less useful than one that fires on fewer segments with full attribution.
- Attribution: The alert names the originating host and process, and links to the connection records that followed the lookup.
- Window logic: The detection evaluates changing answers over a defined time window, and the window is documented.
- Coverage gaps: The case notes state which segments produced no telemetry, and why.
- False positive review: Benign control names are checked to confirm they did not generate high-severity cases.
- Timeline accuracy: Event times from endpoints, resolver and sensor are normalized to one reference so the sequence is reliable.
After each run, compare alert output with the expected footprint and log every mismatch as a tuning item.
The response part of the rehearsal tests whether analysts can confirm the activity, contain affected hosts, and hand the case to the people who own the resolver and the endpoints without losing context. Define the roles before the exercise starts: who triages the alert, who decides on containment, who engages the platform team for the resolver and ESXi hosts, and who records the decisions. Measure how long each step takes against targets your organization sets, and note where handoffs stalled. Confirm containment steps with your change and incident procedures before running them in the range, so the exercise tests the real approvals path.
- Triage handoff: The analyst passes the alert with the host, name, and first answer change written in the ticket.
- Containment decision: The decision owner states which containment action is authorized for the segment in use.
- Resolver owner: The platform team confirms whether resolver logs and blocking changes can be made within the exercise window.
- Communication: Stakeholders receive status updates at agreed intervals, and the updates are logged.
- Closure: The case is closed only after the stable-answer rollback is confirmed in the logs.
Check whether your targets, approval paths, and on-call roles match what the team actually used during the exercise.
Questions SOC leads and detection engineers ask about T1568
How do I separate dynamic resolution from normal CDN behavior?
Dynamic resolution is suspicious when the pattern of lookups, not any single lookup, deviates from what the host normally does. CDNs also rotate IP addresses and short-lived names, so a useful baseline starts with the domains your estate reaches routinely and the processes that make those calls. Look at whether the name changes frequently for one process, whether answers point to infrastructure that is new to your environment, and whether the process is one that should not be resolving external names at all. Confirm with your CDN and cloud providers which domains and address ranges they publish, and build allowlists by owner and process rather than by domain alone.
Which logs do I need for T1568 on each platform?
The minimum set maps to the data components ATT&CK most often references for this technique: Network Connection Creation, Process Creation and Network Traffic Flow. Confirm the exact data components for your ATT&CK version in the STIX bundle before you write rules.
How should I tune detections for ESXi and network devices?
ESXi hosts and network devices usually have far fewer legitimate outbound name lookups than general-purpose servers, so even small deviations deserve review. The difficulty is coverage: many of these platforms do not ship endpoint agents, so you may depend on syslog, vendor logging or flow data. Confirm with each vendor which resolver and connection events their platform can export and at what detail. Tune by documenting the few expected update, monitoring and time-sync destinations, then alert on everything else.
How do I version detection mappings against ATT&CK 20.0?
Record the ATT&CK version, the technique and sub-technique IDs, and the detection strategy and analytic identifiers in each rule's metadata. ATT&CK v18 replaced detections in technique pages with detection strategies and analytics and changed data components, so older mappings may not match current pages. Because releases can rename, deprecate or revoke techniques, review the mapping against each new release notes page and the STIX bundle for the version you target. Keep a change log so auditors can see which mapping applied when.
How can I test T1568 detections without live adversary traffic?
Test in a private cyber range that generates benign name lookups with the same process, platform and network path as production, then confirm the rule fires with the expected fields. Use recorded or synthetic telemetry in a replay environment to check rule logic and thresholds, and measure how often benign CDN and update traffic triggers alerts. Document each test case with the expected result, the observed result and the ATT&CK version it targets. Run the tests again after any change to logging or rule content.
Can my team run this detection work without an outside partner?
Yes, many teams do, provided they have staff who know the platforms, the logging pipeline and the rule language in use. The work falls into four parts: building baselines, writing and tuning rules, building the range and running tests, and maintaining mappings as ATT&CK changes. DeployOpen implements and tests open-source platforms inside a client's own infrastructure and provides private cyber ranges and security testing under written, fixed scope. Confirm with your own staff which parts they can own and which need outside support before agreeing a scope.
What should my team confirm before rehearsing T1568 response?
Confirm who owns the decision to isolate a host or block a domain, how long your change process takes in practice, and which logs are retained long enough to reconstruct a lookup chain. Check that your SIEM and sensors can see the platforms in scope, including ESXi and network devices, and that analysts can reach the data without waiting on another team. Agree the exercise scope and success criteria in writing before the range session starts.
Why detection mappings should name the ATT&CK version they target
Every detection for T1568 Dynamic resolution should state the ATT&CK version it was written against, because the framework changes between releases in ways that affect rules directly. ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies (DET IDs) and analytics, made major updates to data components (DC IDs) and deprecated data sources. A rule that cites a v17 detection block or a retired data source name may still run, but its mapping no longer matches the framework the audit team will read. This page targets Enterprise ATT&CK 20.0, and that label belongs in the rule metadata, the test plan and the coverage report.
Releases can also rename, deprecate or revoke techniques and sub-techniques, so the mapping for T1568 and its three sub-techniques needs a recorded check at each update. The v19 and v20 release notes list the changes for those versions, and the STIX bundles in the attack-stix-data repository show which objects are active. Ask your detection engineering lead to record three things per rule: the ATT&CK version, the technique or sub-technique ID, and the data components the analytic reads, such as Network Connection Creation (DC0082) or Network Traffic Flow (DC0078). A rule without those fields cannot be re-validated after an upgrade.
Treat the version field as a change trigger. When a new ATT&CK release is adopted, review every rule tagged to T1568 and its sub-techniques, rerun the cyber range test records against the new mapping, and update the version label only after the test passes. Confirm with your own tooling, such as the Sigma rule metadata or the Wazuh rule mapping, that the version field is preserved through export and import. Keeping the version alongside each test record also lets you show an assessor which detection was live on a given date.
How DeployOpen builds T1568 detections and purple team exercises
DeployOpen approaches T1568 Dynamic resolution as a written, fixed-scope engagement inside your own infrastructure, covering the telemetry, detection logic and cyber range exercises your team needs. Each step is agreed in writing before work starts, so you know what will be built, tested and documented.
How we scope
- Confirm which platforms are in scope, such as ESXi, Linux, macOS or Windows, and which T1568 sub-techniques apply to your estate.
- Inventory the telemetry you already collect, including network connection creation, process creation and network traffic flow, and record any gaps.
- Agree the ATT&CK version the detections will target, and record the mitigations in scope such as Network Intrusion Prevention and Restrict Web-Based Content.
How we build
- Write detection logic for open-source tooling such as Wazuh, Zeek, Suricata or Sigma, described in words and tuned to your log sources.
- Map each detection to the relevant ATT&CK detection strategy and analytics so coverage can be traced back to the technique.
- Build a private cyber range replica of your environment so detection logic can be exercised without touching production systems.
How we hand over
- Deliver written detection documentation covering data sources, logic, known false positives and the ATT&CK version targeted.
- Run a purple team exercise with your analysts, recording which exercise steps were detected, missed or escalated.
- Provide a response runbook for T1568 alerts, including triage steps, containment options and evidence to preserve.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- Review detections when ATT&CK releases change techniques, sub-techniques or mitigations that affect your coverage.
- Ask us to confirm which deliverables a retainer includes and how changes to the written scope are priced and approved.
