DET0262: Detection Strategy for Dynamic Resolution through DNS Calculation
DET0262 is a MITRE detection strategy object for identifying Dynamic Resolution through DNS Calculation, related to ATT&CK technique T1568.003. The busines...
Analyst context for executives and security teams
DET0262 is a MITRE detection strategy object for identifying Dynamic Resolution through DNS Calculation, related to ATT&CK technique T1568.003. The business significance is that DNS answers may not be used directly; an adversary can calculate the real command-and-control IP address or port from DNS results, which can reduce the value of simple blocklists or basic egress rules.
Executive priority
Treat this as a coverage-validation item for command-and-control resilience. Leaders should ask whether DNS, network egress, and endpoint telemetry can show not only suspicious DNS lookups, but also unusual follow-on connections that appear derived from DNS responses. This matters for incident response triage, SOC detection quality, and evidence that command-and-control monitoring is more than domain blocking.
Technical view
The supplied ATT&CK object has no official description, detection text, tactics, or platforms of its own. Its relationship to T1568.003 anchors the defensive scope: command-and-control behavior where addresses returned in DNS results are transformed into a different IP address and/or port for C2. SOC and detection teams should validate correlation between DNS query/response data and subsequent outbound connections across the related technique platforms: ESXi, Linux, macOS, and Windows, where those platforms exist in the environment.
Likely telemetry
- DNS query and response logs, including returned IP addresses
- Outbound network connection metadata, including destination IP, destination port, timestamp, and source host
- Endpoint network telemetry from Windows, Linux, macOS, and ESXi systems where available
- Firewall, proxy, NAT, and egress-control logs showing allowed and denied outbound traffic
- Time-correlated host identity, asset inventory, and process context when available
Detection direction
- Validate whether detections compare DNS responses with follow-on outbound destinations instead of only alerting on known malicious domains.
- Look for mismatches where a host queries a domain and then connects to an IP address or port that is plausibly derived from, but not equal to, the DNS answer.
- Tune carefully for legitimate software that performs unusual DNS-based routing, load balancing, or service discovery to reduce false positives.
- Confirm that DNS logs include response data; query-only logging may be insufficient for this behavior.
- Correlate across DNS, endpoint, and network egress telemetry because any single source may miss the calculation relationship.
Mitigation priorities
- Prioritize complete DNS response logging and retention before relying on analytic correlation.
- Enforce and review egress controls so outbound connections are limited to expected destinations and ports where operationally feasible.
- Maintain asset and platform coverage for systems in scope of the related technique: ESXi, Linux, macOS, and Windows.
- Use incident response playbooks that preserve DNS, firewall, and endpoint network evidence for suspected command-and-control activity.
- Review command-and-control detection evidence for audit and compliance readiness, especially where monitoring claims depend on DNS or egress visibility.
Analyst notes and limits
The detection strategy object itself is sparse: no official description, detection guidance, tactics, or platforms were supplied. The practical guidance above is derived from the explicit relationship to T1568.003 DNS Calculation and the related technique description, tactics, and platforms provided in the source context.
This take does not assert active exploitation, attribution, guaranteed detectability, or vendor-specific coverage. Local telemetry quality, DNS architecture, encrypted DNS use, NAT visibility, endpoint logging, and egress policy design will determine whether this behavior can be reliably detected.
Detection Strategy for Dynamic Resolution through DNS Calculation
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1568.003 | DNS Calculation Sub-technique | This object detects DNS Calculation. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 55df9dac6b4f… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0262Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.