AN2023: Analytic 2023
Monitor for queried domain name system (DNS) registry data that may compromise third-party DNS servers that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for logged domain name system (DNS) registry data that may compromise third-party DNS servers that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control.
Analyst context for executives and security teams
This analytic matters because it points to adversary preparation that may happen before an organization sees direct intrusion activity: querying or logging DNS registry data connected to third-party DNS infrastructure that could later support targeting. For leaders, the key issue is visibility: much of this behavior occurs outside the target organization’s environment, so internal SOC tooling may not see it until later lifecycle activity such as command and control appears.
Executive priority
Treat this as a reminder to separate what can be detected internally from what requires external visibility, threat intelligence, or third-party monitoring. Security leaders should ask whether DNS-related threat intelligence, domain monitoring, and command-and-control detection are sufficient to support incident decisions when pre-compromise activity is not directly observable. This is relevant to resilience planning, third-party risk discussions, and evidence that the organization understands visibility limits around external infrastructure abuse.
Technical view
ATT&CK lists the platform as PRE and provides no tactic or standalone detection logic. SOC and detection teams should validate whether they collect and review DNS registry-related intelligence, domain registration changes, registrar/registry data where available, and downstream DNS/C2 telemetry. Because MITRE notes that much activity may occur outside the target’s visibility, this analytic should not be treated as a high-confidence internal detection by itself. Use it to enrich later-stage investigations, especially suspected command-and-control activity involving suspicious domains or DNS infrastructure.
Likely telemetry
- DNS registry or registrar data available through threat intelligence or external monitoring
- Domain registration, ownership, nameserver, and DNS record change history where available
- Internal DNS query logs for later-stage correlation
- Network security telemetry related to command-and-control investigation
- Threat intelligence reporting on suspicious third-party DNS infrastructure
Detection direction
- Validate whether the SOC has any external DNS registry visibility or depends entirely on internal DNS logs.
- Correlate suspicious domain infrastructure with later-stage command-and-control detections rather than expecting reliable direct observation of PRE activity.
- Tune detections to account for common benign domain registration and DNS change activity, especially for legitimate third-party providers.
- Document blind spots where third-party DNS infrastructure activity occurs outside organizational logging and cannot be independently confirmed.
- Use this analytic as enrichment and investigation context when suspicious domains, nameservers, or DNS infrastructure appear in incidents.
Mitigation priorities
- Prioritize visibility planning: identify which DNS registry, domain monitoring, and threat intelligence sources are available and who reviews them.
- Strengthen internal DNS and network logging so later-stage command-and-control activity can be investigated when external pre-compromise activity is not visible.
- Define incident response playbooks for suspicious DNS infrastructure, including enrichment, scoping, and escalation criteria.
- Include third-party DNS and domain infrastructure considerations in risk reviews where business-critical domains or providers are involved.
- Maintain clear evidence of visibility limitations for audit, risk acceptance, and executive reporting.
Analyst notes and limits
The supplied object is a detection analytic, not a technique description. It emphasizes DNS registry data and third-party DNS servers during targeting, with a stated visibility challenge and a suggested focus on related lifecycle stages such as command and control. No relationships, tactics, aliases, or detailed detection logic were supplied.
The official detection field is not provided, the platform is only listed as PRE, and no relationship context is supplied. Local conclusions require environment-specific evidence about DNS logging, external monitoring, threat intelligence access, and incident response workflows.
Analytic 2023
Monitor for queried domain name system (DNS) registry data that may compromise third-party DNS servers that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control. Monitor for logged domain name system (DNS) registry data that may compromise third-party DNS servers that can be used during targeting. Much of this activity will take place outside the visibility of the target organization, making detection of this behavior difficult. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Command and Control.
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 | 1.0 | Current bundle | bd10399500f1… |
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 AN2023Open 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.