Application Layer Protocol: DNS
- ID
- T1071.004
- Tactics
- TA0011 Command and Control
- Sub-technique of
- T1071 Application Layer Protocol
- Platforms
- ESXi, Linux, macOS, Network Devices, Windows
- Data sources
- Network Connection Creation, Network Traffic Content, Process Creation, Network Traffic Flow
- Source
- attack.mitre.org
- MITRE last modified
- 4 Sep 2026
Adversaries may communicate using the Domain Name System (DNS) application layer protocol to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.
The DNS protocol serves an administrative function in computer networking and thus may be very common in environments. DNS traffic may also be allowed even before network authentication is completed. DNS packets contain many fields and headers in which data can be concealed. Often known as DNS tunneling, adversaries may abuse DNS to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.[1][2]
DNS beaconing may be used to send commands to remote systems via DNS queries. A DNS beacon is created by tunneling DNS traffic (i.e. Protocol Tunneling). The commands may be embedded into different DNS records, for example, TXT or A records.[3] DNS beacons may be difficult to detect because the beacons infrequently communicate with infected devices.[4] Infrequent communication conceals the malicious DNS traffic with normal DNS traffic.
Detection
- DET0400 Behavioral Detection of DNS Tunneling and Application Layer Abuse
Data components: Network Connection Creation, Network Traffic Content, Process Creation, Network Traffic Flow
Mitigations (2)
- M1031 Network Intrusion Prevention
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level.
- M1037 Filter Network Traffic
Consider filtering DNS requests to unknown, untrusted, or known bad domains and resources. Resolving DNS requests with on-premise/proxy servers may also disrupt adversary attempts to conceal data within DNS packets.
Groups (11)
- G0004 Ke3chang
- G0026 APT18
- G0046 FIN7
- G0049 OilRig
- G0080 Cobalt Group
- G0081 Tropic Trooper
- G0087 APT39
- G0096 APT41
- G0114 Chimera
- G0140 LazyScripter
- G1003 Ember Bear
Software (44)
- S0013 PlugX
- S0022 Uroburos
- S0070 HTTPBrowser
- S0124 Pisloader
- S0125 Remsec
- S0145 POWERSOURCE
- S0146 TEXTMATE
- S0154 Cobalt Strike
- S0157 SOUNDBITE
- S0167 Matryoshka
- S0170 Helminth
- S0184 POWRUNER
- S0228 NanHaiShu
- S0260 InvisiMole
- S0269 QUADAGENT
- S0338 Cobian RAT
- S0354 Denis
- S0360 BONDUPDATER
- S0377 Ebury
- S0477 Goopy
- S0495 RDAT
- S0504 Anchor
- S0514 WellMess
- S0559 SUNBURST
- S0596 ShadowPad
- S0615 SombRAT
- S0633 Sliver
- S0663 SysUpdate
- S0666 Gelsemium
- S0690 Green Lambert
- S0699 Mythic
- S1014 DanBot
- S1015 Milan
- S1019 Shark
- S1020 Kevin
- S1021 DnsSystem
- S1027 Heyoka Backdoor
- S1047 Mori
- S1063 Brute Ratel C4
- S1090 NightClub
- S1111 DarkGate
- S9001 SystemBC
- S9015 BRICKSTORM
- S9050 Vidar
