DET0400: Behavioral Detection of DNS Tunneling and Application Layer Abuse
DET0400 is a detection strategy for finding suspicious DNS-based command-and-control behavior, specifically related to ATT&CK technique T1071.004. Its busi...
Analyst context for executives and security teams
DET0400 is a detection strategy for finding suspicious DNS-based command-and-control behavior, specifically related to ATT&CK technique T1071.004. Its business significance is that DNS is often necessary, common, and sometimes permitted early in network access workflows, so malicious use can hide inside traffic that organizations may hesitate to block. Leaders should treat this as a coverage question: do we have enough DNS visibility to distinguish normal administrative name resolution from unusual tunneling or application-layer abuse?
Executive priority
Prioritize this where business operations depend on broad DNS availability, distributed infrastructure, or network devices, and where incident response would need rapid evidence of covert command-and-control. The key decision value is not whether DNS exists, but whether security teams can prove they collect, retain, and analyze DNS activity well enough to support detection, investigation, audit evidence, and containment decisions. Because the ATT&CK object provides no official detection logic, organizations should validate coverage locally rather than assuming a tool detects DET0400.
Technical view
This detection strategy is linked to T1071.004, DNS, under command-and-control. SOC and detection teams should validate DNS monitoring against environments relevant to the related technique: ESXi, Linux, macOS, and network devices. Practical validation should focus on whether DNS telemetry can show client, resolver, queried domain, timing, volume, response characteristics, and historical baseline context. Since no official detection text is supplied, detection engineering should derive local analytics from behavioral DNS abuse patterns and test them against normal enterprise DNS behavior to avoid excessive false positives.
Likely telemetry
- DNS query and response logs from resolvers or DNS security controls
- Network flow metadata showing DNS traffic patterns, volume, timing, and endpoints
- Endpoint or server logs that identify the process, host, or device generating DNS requests where available
- Network device telemetry for DNS traffic crossing infrastructure boundaries
- Asset and platform inventory for ESXi, Linux, macOS, and network devices tied to observed DNS sources
Detection direction
- Confirm that DNS visibility includes internal clients, recursive resolvers, and egress paths; blind spots often occur when only perimeter traffic is monitored.
- Baseline normal DNS behavior before tuning alerts, because DNS is high-volume and legitimate administrative traffic can be noisy.
- Correlate suspicious DNS activity with source asset role, authentication state, and network location, especially because DNS may be allowed before full network authentication.
- Use the relationship to T1071.004 as context: prioritize behaviors consistent with command-and-control over single anomalous lookups.
- Document analytic assumptions and exclusions because the supplied ATT&CK object does not provide official detection logic or platform scope.
Mitigation priorities
- Establish authoritative DNS logging and retention first so investigations can reconstruct activity.
- Reduce uncontrolled DNS egress by routing clients through approved resolvers where operationally feasible.
- Apply network filtering and monitoring policies that distinguish approved DNS infrastructure from direct external DNS use.
- Review DNS controls for systems and devices aligned to the related technique platforms, including ESXi, Linux, macOS, and network devices.
- Use incident response playbooks that define how to contain a suspected DNS command-and-control source without disrupting essential name resolution.
Analyst notes and limits
The supplied object is a detection strategy with sparse official fields: no description, no official detection text, no native platforms, and no tactics listed. The strongest usable context is the relationship showing it detects T1071.004 DNS, a command-and-control technique involving adversary communication over DNS to blend into common network traffic.
This take is limited to the provided ATT&CK fields, external reference, and relationship context. It does not assert active exploitation, actor use, guaranteed detection, or customer exposure. Local telemetry quality, resolver architecture, retention, and asset context are required to determine real coverage.
Behavioral Detection of DNS Tunneling and Application Layer Abuse
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.
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 | 1eb54fc7c7e9… |
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 DET0400Open 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.