T1583.002: DNS Server
Adversaries may set up their own Domain Name System (DNS) servers that can be used during targeting. During post-compromise activity, adversaries may utilize DNS traffic for various tasks, including for Command and Control (ex: Application Layer Protocol). Instead of hijacking existing DNS servers, adversaries may opt to configure and run their own DNS servers in support of operations.
By running their own DNS servers, adversaries can have more control over how they administer server-side DNS C2 traffic (DNS). With control over a DNS server, adversaries can configure DNS applications to provide conditional responses to malware and, generally, have more flexibility in the structure of the DNS-based C2 channel.[1]
Analyst context for executives and security teams
This technique matters because adversaries can prepare their own DNS infrastructure before an intrusion and later use it to support targeting or DNS-based command-and-control. For leaders, the risk is not the DNS server alone; it is whether the organization can recognize when business systems are resolving or exchanging unusual DNS traffic with attacker-controlled infrastructure before an incident escalates.
Executive priority
Treat this as a pre-compromise and early-incident visibility issue. Security leaders should ask whether DNS activity is logged, retained, and reviewable across the enterprise, and whether threat intelligence and SOC workflows can connect suspicious domains, name servers, and DNS traffic to broader resource-development activity. Where the organization operates in sectors or regions aligned to ATT&CK-linked group reporting, this should inform intelligence prioritization without assuming current targeting.
Technical view
ATT&CK places DNS Server under Resource Development with platform PRE and as a sub-technique of Acquire Infrastructure. The practical validation point is whether defenders can identify suspicious DNS infrastructure before or during use, especially when DNS traffic may later support Application Layer Protocol or DNS command-and-control activity. Official detection text is not provided, but ATT&CK includes a detection-strategy relationship, so teams should map local DNS analytics to that strategy if available and test whether DNS server, domain, resolver, and endpoint telemetry can be correlated during investigations.
Likely telemetry
- Enterprise DNS resolver logs and query/response metadata
- Network telemetry showing DNS traffic patterns and destinations
- Passive DNS or threat-intelligence observations for domains and name servers
- Endpoint or EDR network connection records involving DNS activity
- Firewall, proxy, or secure web gateway records that can correlate hosts to DNS destinations
Detection direction
- Validate that DNS logging covers the assets and network paths that matter, including remote, cloud, and segmented environments where applicable.
- Look for unusual DNS destinations, newly observed or suspicious name-server infrastructure, and DNS traffic patterns that may indicate a structured C2 channel rather than ordinary resolution.
- Correlate DNS observations with endpoint and network events; DNS alone may be insufficient because legitimate organizations also operate authoritative DNS servers.
- Tune carefully for false positives from content delivery, SaaS, dynamic infrastructure, and legitimate internal or partner DNS operations.
- Use the ATT&CK relationships as context: this behavior is linked to Acquire Infrastructure and to named groups in ATT&CK, but local detection should be evidence-driven rather than attribution-driven.
Mitigation priorities
- Prioritize pre-compromise measures consistent with M1056: reduce exposed weaknesses, identify adversary preparation activity, and make successful operations harder before intrusion.
- Maintain an inventory of approved DNS services and expected DNS paths so anomalous DNS use is easier to investigate.
- Ensure DNS telemetry is retained long enough to support incident response and compliance evidence needs.
- Integrate DNS-related threat intelligence into SOC triage, while requiring corroborating telemetry before escalation or attribution.
- Review whether incident response playbooks include DNS infrastructure analysis when investigating suspected command-and-control.
Analyst notes and limits
This object is about adversaries setting up their own DNS servers, not necessarily hijacking existing DNS servers. The relationship set shows use by Axiom, HEXANE, and Sea Turtle, and a detection-strategy relationship named Detection of DNS Server, but no detailed official detection logic is supplied in the provided fields.
MITRE provides no official detection text for this object in the supplied data. The mitigation relationship is high-level pre-compromise guidance, so specific control design must be validated against the organization’s DNS architecture, logging coverage, and business use of DNS.
DNS Server
Adversaries may set up their own Domain Name System (DNS) servers that can be used during targeting. During post-compromise activity, adversaries may utilize DNS traffic for various tasks, including for Command and Control (ex: Application Layer Protocol). Instead of hijacking existing DNS servers, adversaries may opt to configure and run their own DNS servers in support of operations.
By running their own DNS servers, adversaries can have more control over how they administer server-side DNS C2 traffic (DNS). With control over a DNS server, adversaries can configure DNS applications to provide conditional responses to malware and, generally, have more flexibility in the structure of the DNS-based C2 channel.[1]
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.
Related techniques
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 | T1583 | Acquire Infrastructure | This object subtechnique of Acquire Infrastructure. |
Groups, software, and campaigns
G1041: Sea Turtle
Sea Turtle is a Türkiye-linked threat actor active since at least 2017 performing espionage and service provider compromise operations against victims in Asia, Europe, and North America. Sea Turtle is notable for targeting registrars managing ccTLDs and complex DNS-based intrusions where the threat actor compromised DNS providers to hijack DNS resolution for ultimate victims, enabling Sea Turtle to spoof log in portals and other applications for credential collection.[1][2][3][4]
G0001: Axiom
Axiom is a suspected Chinese cyber espionage group that has targeted the aerospace, defense, government, manufacturing, and media sectors since at least 2008. Some reporting suggests a degree of overlap between Axiom and Winnti Group but the two groups appear to be distinct based on differences in reporting on TTPs and targeting.[1][2][3]
G1001: HEXANE
HEXANE is a cyber espionage threat group that has targeted oil & gas, telecommunications, aviation, and internet service provider organizations since at least 2017. Targeted companies have been located in the Middle East and Africa, including Israel, Saudi Arabia, Kuwait, Morocco, and Tunisia. HEXANE's TTPs appear similar to APT33 and OilRig but due to differences in victims and tools it is tracked as a separate entity.[1][2][3][4]
All related ATT&CK context
Mitigation direction
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 | 35ef7973c915… |
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]
Unit42 DNS Mar 2019
Hinchliffe, A. (2019, March 15). DNS Tunneling: how DNS can be (ab)used by malicious actors. Retrieved October 3, 2020.
Open source URL -
[2]
mitre-attack T1583.002Open 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.