DET0862: Detection of DNS Server
DET0862 is a detection strategy tied to adversaries setting up their own DNS servers. For leaders, the value is not just “spot DNS,” but recognizing advers...
Analyst context for executives and security teams
DET0862 is a detection strategy tied to adversaries setting up their own DNS servers. For leaders, the value is not just “spot DNS,” but recognizing adversary infrastructure before or during operations that may support targeting, command and control, or other activity. Because this is resource-development behavior, useful evidence often comes from DNS infrastructure intelligence and network/DNS telemetry, not only from endpoint alerts after compromise.
Executive priority
Treat this as a control-validation question: can the organization see when users, systems, or suspicious domains interact with DNS infrastructure outside expected patterns? This matters for SOC readiness, incident scoping, and resilience because adversary-controlled DNS can support later intrusion activity. Executives should ask whether DNS logging, egress policy, threat intelligence enrichment, and investigation workflows are sufficient to turn DNS infrastructure observations into timely decisions.
Technical view
The ATT&CK object has no official detection text and no specified platforms, but it detects T1583.002, DNS Server, under resource development on PRE. SOC and threat intelligence teams should validate visibility into DNS infrastructure relationships such as authoritative name servers, NS/SOA records, resolver activity, passive DNS, and domains associated with suspicious infrastructure. IR teams should be able to pivot from a suspicious domain to its DNS servers and then to related domains, IPs, hosting, and observed internal lookups.
Likely telemetry
- Internal DNS resolver query and response logs
- Recursive resolver logs and DNS security gateway events
- Network egress telemetry for DNS traffic, including attempts to use non-approved resolvers
- Passive DNS or external DNS intelligence records
- Domain registration and RDAP/WHOIS-style enrichment where available
Detection direction
- Validate that DNS logs retain enough detail to connect internal activity to queried domains, resolved IPs, and name server infrastructure.
- Look for domains or infrastructure using unusual, newly observed, or suspicious authoritative DNS servers, especially when linked to other suspicious indicators.
- Tune for false positives from legitimate managed DNS providers, CDNs, marketing campaigns, developer test domains, and planned infrastructure migrations.
- Do not rely only on endpoint telemetry; this behavior may occur before compromise and may be visible first through external DNS intelligence or network DNS patterns.
- Check for internal hosts bypassing approved resolvers, because direct DNS egress can reduce central visibility and policy enforcement.
Mitigation priorities
- Enforce use of approved recursive DNS resolvers where operationally feasible.
- Restrict or monitor direct outbound DNS traffic to unapproved external DNS servers.
- Maintain DNS logging retention and enrichment sufficient for incident investigation and compliance evidence.
- Use DNS filtering or policy controls to reduce exposure to suspicious domains and infrastructure, while recognizing this does not prevent adversaries from creating DNS servers.
- Integrate threat intelligence review of suspicious domains, name servers, and related infrastructure into SOC triage and IR scoping.
Analyst notes and limits
The supplied ATT&CK detection strategy is sparse: it has no official description, detection guidance, tactics, or platforms. The practical interpretation is based on its explicit relationship to T1583.002, DNS Server, which describes adversaries configuring and running their own DNS servers in support of operations.
This take does not assert active exploitation, attribution, or guaranteed detection coverage. Local DNS architecture, logging retention, resolver policy, and access to passive DNS or threat intelligence will determine what can actually be detected.
Detection of DNS Server
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 | T1583.002 | DNS Server Sub-technique | This object detects DNS Server. |
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 | 4c4a98ca6368… |
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 DET0862Open 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.