DC0096: Passive DNS
"Domain Name: Passive DNS" captures logged historical and real-time domain name system (DNS) data. This includes records of domain-to-IP address resolutions over time, enabling analysts to track the evolution of domain infrastructure, uncover historical patterns of use, and detect malicious activities tied to domains and their associated IP addresses. Examples:
- Historical Resolutions - Shared IP Usage - Temporal Patterns - Malicious Domain Clustering - Historical Lookback
This data component can be collected through the following measures:
- Passive DNS Platforms: Use platforms that specialize in passive DNS collection and analysis: - Tools: Farsight DNSDB, RiskIQ PassiveTotal, PassiveDNS. - Threat Intelligence Feeds: Integrate passive DNS data from commercial or open-source threat intelligence providers. - Custom DNS Collectors: Deploy custom tools to capture DNS traffic at the network level for analysis. - Cloud DNS Services: Leverage cloud DNS services (e.g., AWS Route 53, Azure DNS) that maintain DNS query logs.
Analyst context for executives and security teams
Passive DNS is the historical record of how domains have resolved to IP addresses over time. For security leaders, its value is not that it detects an attack by itself, but that it gives investigators and threat intelligence teams context: whether a suspicious domain is new, what infrastructure it has used, what other domains shared that infrastructure, and how patterns changed over time.
Executive priority
Prioritize Passive DNS as an investigation and intelligence capability that supports faster incident scoping, domain and infrastructure risk analysis, and evidence for response decisions. The key business question is whether teams can reconstruct domain-to-IP history when investigating suspicious domains, third-party infrastructure, phishing-related indicators, or potential command-and-control infrastructure. Because ATT&CK provides no detection logic for this component, leadership should treat it as an evidence source to validate, not a standalone control.
Technical view
SOC, threat intelligence, and IR teams should validate access to passive DNS records that include historical resolutions, shared IP usage, temporal patterns, malicious domain clustering, and historical lookback. Collection may come from passive DNS platforms, threat intelligence feeds, custom DNS collectors, or cloud DNS services that maintain DNS query logs. Since no platforms, tactics, relationships, or detection analytics are supplied for this object, teams should map local use cases to the data: enrichment of alerts, retrospective searches, infrastructure pivoting, and scoping of domain-associated activity.
Likely telemetry
- Historical domain-to-IP resolution records
- Real-time or near-real-time DNS resolution observations
- DNS query logs from cloud DNS services where available
- Passive DNS provider datasets or threat intelligence feed data
- Network-level DNS captures from custom collectors
Detection direction
- Confirm that analysts can query historical resolutions for a domain and pivot from IP address to related domains.
- Validate retention depth, timestamp quality, and data freshness; passive DNS loses value if history is too short or delayed for incident timelines.
- Tune workflows to use passive DNS as enrichment and scoping context rather than as an alert source by itself, since no official detection is provided.
- Account for false associations from shared hosting, CDN use, cloud infrastructure, and reused IP space before escalating findings.
- Test whether passive DNS data is available during incidents from the chosen sources: passive DNS platforms, threat intelligence feeds, custom collectors, or cloud DNS logging.
Mitigation priorities
- Establish an approved source for passive DNS data, such as a specialized platform, intelligence feed, internal collector, or cloud DNS logging capability.
- Define retention, access, and investigation procedures so SOC and IR teams can use the data during time-sensitive cases.
- Integrate passive DNS enrichment into alert triage and incident response workflows without treating it as conclusive evidence on its own.
- Document how passive DNS evidence is preserved and cited for incident records, audit support, and post-incident review.
- Review privacy, logging, and data handling requirements before expanding DNS collection.
Analyst notes and limits
This ATT&CK object is a data component, not a technique. The supplied object has no tactics, platforms, relationships, or official detection text. Its practical value is in evidence collection and analytical enrichment: historical lookback, shared infrastructure analysis, and domain clustering.
Assessment is limited to the official ATT&CK fields supplied for DC0096. No active exploitation, adversary behavior, affected platforms, or detection coverage can be inferred from this object alone. Local architecture, DNS logging sources, retention, and provider coverage determine operational usefulness.
Passive DNS
"Domain Name: Passive DNS" captures logged historical and real-time domain name system (DNS) data. This includes records of domain-to-IP address resolutions over time, enabling analysts to track the evolution of domain infrastructure, uncover historical patterns of use, and detect malicious activities tied to domains and their associated IP addresses. Examples:
- Historical Resolutions - Shared IP Usage - Temporal Patterns - Malicious Domain Clustering - Historical Lookback
This data component can be collected through the following measures:
- Passive DNS Platforms: Use platforms that specialize in passive DNS collection and analysis: - Tools: Farsight DNSDB, RiskIQ PassiveTotal, PassiveDNS. - Threat Intelligence Feeds: Integrate passive DNS data from commercial or open-source threat intelligence providers. - Custom DNS Collectors: Deploy custom tools to capture DNS traffic at the network level for analysis. - Cloud DNS Services: Leverage cloud DNS services (e.g., AWS Route 53, Azure DNS) that maintain DNS query logs.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 2.0 | Current bundle | 519527759595… |
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 DC0096Open 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.