---
{
  "title": "Dynamic Resolution",
  "summary": "Dynamic resolution changes how command destinations are found over time.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1568"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1568: Dynamic Resolution",
      "url": "https://attack.mitre.org/techniques/T1568"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Dynamic resolution changes how command destinations are found over time. Domain or address churn can complicate static blocking and correlation.


## An investigation example

A suspicious application repeatedly resolves changing names before contacting similarly behaving destinations.

## Evidence to examine

Review DNS queries, destination relationships, timing, process ownership, and the resolution logic where available.

## A common analytical pitfall

Changing destinations are common in legitimate content delivery; churn alone does not prove command infrastructure.

## Response considerations

Investigate the responsible application and resolution pattern and use corroborated behavior rather than only individual addresses for containment.


## A changing destination can complicate indicator-based defense

Dynamic resolution lets a component determine communication destinations at runtime rather than rely only on a fixed address. An intruder may use changing names or resolution mechanisms to maintain access and complicate blocking. Legitimate services also change addresses for availability, load balancing, and infrastructure management. Change by itself is not malicious.

Investigate the requesting process, names or lookup mechanism, response history, timing, and subsequent connections. DNS queries do not automatically establish successful contact with the returned address. Cached responses, failed connections, and shared infrastructure can complicate correlation. Preserve the relevant time window rather than use today's resolution as proof of an earlier destination.

## A fictional rotating endpoint

An academy's endpoint process repeatedly resolves different names and connects to changing addresses. Analysts compare the pattern with approved distributed services and correlate process ancestry and host behavior. They avoid treating every resolved address as exclusively controlled by an intruder because shared hosting may serve unrelated customers.

Blocking one address may have limited duration or broad collateral effect. Response should consider the client process, identity, and known mechanism, along with destination indicators. Preserve resolution records and explain which relationships are observed and which are hypotheses. A present-day lookup cannot fully reconstruct historical infrastructure without supporting records.

## Compare historical and current answers

Create fictional DNS responses for the same name at two different times and a later connection event. Explain which answer is relevant to the connection and what clock or cache context is needed. Add an approved content-delivery service as a benign comparison. Use prepared data rather than contacting suspicious infrastructure.

A useful detection question asks whether the resolution and connection behavior fits the application's role. Name structure, failure rates, destination changes, and endpoint context can contribute, but no single visual pattern guarantees intent. Keep the analysis grounded in the actual sequence and its evidence coverage.

## Related concepts

- [[packet-analysis]]
- [[exfiltration]]
- [[network-segmentation]]
- [[fallback-channels]]