Application Layer Protocol ranked #5 in the Picus Red Report 2026, present in 19% of all malware samples analyzed. It has remained in the top ten since the Red Report 2024 and continues to climb as threat actors shift from immediate encryption toward prolonged, stealthy data exfiltration campaigns that depend on undetected C2 channels.
T1071 falls under the Command and Control tactic in MITRE ATT&CK and describes how adversaries use protocols at Layer 7 of the OSI model — the application layer — to issue commands to compromised systems, receive results, and exfiltrate stolen data. These protocols include the ones that power web browsing (HTTP/S), name resolution (DNS), email delivery (SMTP, IMAP, POP3), file transfers (FTP, SMB), and increasingly, IoT messaging (MQTT, XMPP, AMQP).
The technique's effectiveness stems from a fundamental architectural reality: organizations cannot block these protocols without crippling their own operations. HTTP/S carries web traffic. DNS is required for virtually every network connection. SMTP delivers email. By embedding C2 traffic within these essential channels, adversaries force defenders into a position where blocking the communication channel would cause more damage than the intrusion itself.
The trend data reinforces an important strategic shift. The Picus Red Report 2026 found a 38% year-over-year decrease in Data Encrypted for Impact (T1486, the ransomware encryption technique) alongside the continued rise of application layer C2. The implication is clear: threat actors are moving away from smash-and-grab ransomware and toward prolonged, undetected residency — quietly exfiltrating targeted data, then leveraging proof of theft for extortion. This model depends entirely on maintaining a C2 channel that does not trigger security alerts, which is exactly what T1071 provides.
How Application Layer C2 Works
The fundamental mechanism follows a consistent pattern regardless of which specific protocol is used:
Phase 1 — Initial Beacon. After gaining initial access to a target system, the implant (malware, backdoor, or RAT) establishes its first outbound connection to the attacker's C2 infrastructure. This connection uses a protocol that the organization's firewalls and proxies already allow outbound — typically HTTPS on port 443, DNS on port 53, or HTTP on port 80. The initial beacon confirms the implant is active and registers the compromised system with the C2 server.
Phase 2 — Command Polling. The implant periodically contacts the C2 server to check for new instructions. In HTTP/S-based C2, this looks like a normal web request — a GET request to a URL that returns what appears to be a legitimate web page, an image file, or a JSON API response, with commands embedded in the response body, headers, or cookies. In DNS-based C2, the implant issues DNS queries for subdomains of an attacker-controlled domain, with commands encoded in the DNS response records. The polling interval (known as the "sleep time" or "jitter") is carefully tuned to match normal traffic patterns.
Phase 3 — Command Execution and Response. The implant decrypts and executes the received commands, then sends results back through the same protocol channel. Exfiltrated data, screenshots, credential dumps, and reconnaissance results are encoded and transmitted as what appears to be routine application traffic. HTTPS encryption makes the payload content invisible to network monitoring tools that do not perform TLS inspection.
Phase 4 — Persistence and Adaptation. Sophisticated C2 frameworks rotate domains, update encryption keys, change polling intervals, and shift between protocol channels to maintain persistent access even when individual indicators are discovered and blocked. Modern frameworks like Cobalt Strike, Sliver, and Havoc support multiple simultaneous C2 channels that can fail over automatically if one is disrupted.
Sub-Techniques
MITRE ATT&CK version 18 defines five sub-techniques under T1071, each targeting a different protocol family. Each sub-technique exploits the ubiquity of its respective protocol and the difficulty of distinguishing malicious usage from legitimate traffic.
T1071.001 — Web Protocols (HTTP/S, WebSocket)
This is the most widely observed sub-technique by a substantial margin. Adversaries use HTTP and HTTPS requests to communicate with C2 servers, embedding commands and data within standard web traffic. HTTPS is especially attractive because TLS encryption prevents security tools from inspecting payload contents without performing SSL/TLS interception — a capability that not all organizations deploy and that introduces its own operational complexity.
Modern C2 frameworks like Cobalt Strike use "malleable C2 profiles" that customize the appearance of their HTTP/S traffic to mimic specific legitimate services — Microsoft Azure management APIs, Google Cloud endpoints, Amazon Web Services calls, or CDN requests. The traffic uses the correct URI paths, headers, content types, and response structures of the impersonated service, making it virtually indistinguishable from real application traffic without behavioral analysis. WebSocket connections add another layer of capability by providing persistent, bidirectional communication channels that reduce the overhead of repeated HTTP requests and enable real-time command execution.
T1071.002 — File Transfer Protocols (FTP, SMB, SSH)
Adversaries abuse file transfer protocols for C2, particularly within internal network segments where protocols like SMB and SSH are expected. SMB-based C2 is especially effective for lateral movement because Windows environments generate enormous volumes of SMB traffic for file sharing, printer access, and domain authentication. An implant communicating over SMB named pipes looks identical to legitimate Windows inter-process communication. SSH provides encrypted channels that are routinely used for server administration, making SSH-based C2 difficult to distinguish from normal operations in Linux and Unix environments.
T1071.003 — Mail Protocols (SMTP, IMAP, POP3)
Adversaries leverage email protocols to send commands and receive exfiltrated data. This can take several forms: the implant connects to a legitimate email service (Gmail, Outlook, corporate Exchange) using stolen credentials and checks a designated inbox for commands stored in email drafts or messages. Alternatively, the implant sends data out as email attachments. OilRig (APT34) pioneered the use of email draft-based C2 — commands are placed in draft messages that the implant reads and deletes, never actually sending email and therefore avoiding email gateway inspection. The Trojan.Win32.Injuke malware family, identified in 2024, uses SMTP for C2 exfiltration alongside keylogging and screen capture capabilities.
T1071.004 — DNS
DNS-based C2 encodes commands and data within DNS queries and responses. Because DNS resolution is required for virtually every network operation, DNS traffic is almost universally allowed through firewalls — and rarely inspected at the content level. Adversaries encode data in subdomain strings of attacker-controlled domains (e.g., encoded-data.attacker-domain.com), and the attacker's authoritative DNS server decodes the queries and returns commands encoded in DNS response records (A, AAAA, TXT, CNAME, MX).
DNS tunneling has evolved significantly. Traditional DNS tunneling tools like iodine and dnscat2 encode data in plaintext DNS queries that can be detected by their anomalous query length and frequency patterns. Modern variants use DNS-over-HTTPS (DoH) to encrypt the DNS queries themselves, routing them through legitimate resolvers like Cloudflare or Google, effectively hiding the tunneling traffic inside encrypted HTTPS sessions to trusted infrastructure. The Dohdoor backdoor, discovered by Cisco Talos in an ongoing campaign attributed to a North Korea-nexus actor (UAT-10027), uses DoH to resolve C2 domains through Cloudflare's DNS service, then establishes HTTPS tunnels to the C2 infrastructure hidden behind Cloudflare's edge network — making the C2 traffic appear as routine Cloudflare API calls.
Unit 42 research on DNS tunneling in the wild identified active campaigns using customized Cobalt Strike DNS beaconing formats targeting the finance and healthcare industries, with campaigns like FinHealthXDS using three-letter prefixes in DNS queries to indicate beaconing function types. Their analysis also found a separate campaign (FinSupport) where Cobalt Strike operators used C2 domains disguised as IT support services (identity-mgmt[.]com, internalsupport[.]info, cloud-enrollment[.]com) to blend with enterprise DNS traffic.
T1071.005 — Publish/Subscribe Protocols (MQTT, XMPP, AMQP, STOMP)
This sub-technique, added to ATT&CK in version 16, reflects an emerging trend: adversaries abusing IoT and messaging protocols for C2 communication. Publish/subscribe protocols use a centralized broker to route messages between publishers and subscribers based on topic channels. By communicating through a legitimate third-party broker, the attacker's C2 server address is never exposed to the compromised system, and the traffic blends with legitimate IoT device communication.
The WailingCrab malware family demonstrates this approach. Since mid-2023, its backdoor component has used the MQTT protocol to communicate with its C2 server through the legitimate broker broker.emqx[.]io. Because MQTT traffic is expected in environments with IoT devices, sensors, and industrial automation systems, the C2 communication blends with normal device telemetry. The IOCONTROL malware, targeting operational technology environments, similarly uses MQTT for encrypted C2 communication, specifically exploiting the fact that OT networks are designed around pub/sub messaging patterns.
Why Application Layer C2 Is So Difficult to Detect
The challenge of detecting T1071 is fundamentally different from detecting other ATT&CK techniques. With process injection (T1055), defenders look for API call sequences that deviate from normal behavior. With credential dumping (T1003), defenders monitor access to specific system files and memory regions. With application layer C2, the malicious activity uses the correct protocol implementation — there is no protocol violation to flag, no unexpected port to block, and often no anomalous traffic volume to alert on.
Encryption defeats inspection. HTTPS-based C2 encrypts all payload content. Without TLS interception (which requires deploying trusted CA certificates across all endpoints and accepting the performance and privacy implications), security tools can only see the destination IP/domain and traffic volume — not what is being communicated. Even with TLS inspection, sophisticated C2 profiles produce traffic that looks like legitimate API calls.
Cloud services provide cover. Adversaries increasingly route C2 traffic through legitimate cloud platforms — AWS, Azure, Google Cloud, Cloudflare, Akamai — rather than using dedicated C2 servers. Domain fronting (using the CDN's own domain in the TLS SNI field while routing to a different backend) and cloud function abuse make it impossible to distinguish C2 traffic from legitimate cloud service usage without application-layer visibility.
Legitimate services as C2 channels. APT41's use of Google Calendar for C2 in the TOUGHPROGRESS campaign demonstrates the cutting edge: commands are stored as Google Calendar events, polled by the malware, executed, and results written back as new calendar events. Google has disrupted multiple APT41 campaigns abusing Google Sheets, Google Drive, and Google Calendar. The traffic uses Google's own HTTPS endpoints, authenticates with valid Google credentials, and is indistinguishable from a user checking their calendar unless the content of the API calls is inspected at the application layer.
Real-World Case Studies
APT41 — Google Calendar as a Command-and-Control Channel
In October 2024, Google Threat Intelligence Group (GTIG) discovered an exploited government website distributing malware to other government entities. The payload, dubbed TOUGHPROGRESS, used Google Calendar as its C2 channel. The attack deployed three distinct modules in series: PLUSDROP (decrypts and loads the next stage in memory), PLUSINJECT (launches svchost.exe and performs process hollowing to inject the final payload), and TOUGHPROGRESS itself (the operational C2 component). TOUGHPROGRESS creates zero-minute Google Calendar events at hardcoded dates to store harvested data in event descriptions, polls predetermined Calendar dates for encrypted commands, executes those commands on the compromised host, and writes results back to new Calendar events for attacker retrieval. The C2 encryption uses a hardcoded 10-byte XOR key combined with a per-message 4-byte XOR key. Google disrupted the campaign by developing fingerprints to identify attacker-controlled Calendars, terminating the associated Workspace projects, and notifying affected organizations. This was not APT41's first abuse of Google services — the group had previously used Google Sheets and Google Drive for C2 in the VOLDEMORT and DUSTTRAP campaigns.
Silver Dragon — DNS Tunneling at Scale Across Southeast Asia
In March 2026, Check Point Research published research on Silver Dragon, a threat group targeting organizations in Southeast Asia and Europe. The group delivers Cobalt Strike beacons as its primary post-exploitation tool and conducts C2 communications predominantly through DNS tunneling. Across multiple infection chains — including AppDomain hijacking, phishing with malicious LNK files, and exploitation of the ToolShell vulnerability wave in July 2025 — Silver Dragon consistently configured implants for DNS-based C2 to evade network-level detection. Some implants used HTTP communication behind Cloudflare for an alternate channel, and others communicated over SMB with peer-to-peer lateral movement within compromised networks. The group also deployed a novel backdoor (GearDoor) that uses Google Drive as its C2 channel, along with SilverScreen (a covert screen-monitoring implant) and SSHCmd (an SSH-based remote execution utility). The campaign demonstrates how a well-resourced threat actor combines multiple application layer protocols across a single operation, selecting the channel best suited to each stage and network environment.
Dohdoor — DNS-over-HTTPS Meets Cloudflare Fronting
In early 2026, Cisco Talos disclosed an ongoing campaign by UAT-10027, a threat actor assessed with moderate-to-high confidence as North Korea-nexus based on tactical similarities to Lazarus Group. The campaign targeted education and healthcare organizations in the United States using a previously undisclosed backdoor called Dohdoor. The malware employs a sophisticated C2 chain: after initial access via batch script download and DLL sideloading, Dohdoor uses DNS-over-HTTPS (DoH) to resolve its C2 domains through Cloudflare's DNS service. It then establishes an HTTPS tunnel to communicate with the C2 infrastructure, which is positioned behind Cloudflare's edge network. This double-layered approach — encrypting the DNS resolution itself via DoH, then routing C2 through Cloudflare — means that network monitoring sees only encrypted HTTPS traffic to Cloudflare IP addresses. The associated C2 infrastructure showed JA3S hash signatures consistent with Cobalt Strike servers, suggesting the next-stage payload was a Cobalt Strike Beacon deployed reflectively in memory.
Cobalt Strike DNS Beaconing — Customized Campaigns in Finance and Healthcare
Unit 42 research identified multiple active DNS tunneling campaigns using customized Cobalt Strike configurations targeting financial institutions and healthcare providers. The FinHealthXDS campaign uses 12 domains with a custom DNS beaconing format that departs from Cobalt Strike's default malleable C2 profile. DNS queries use three-letter prefixes (such as xds) to indicate query function types, with C2 command responses encoded in returned IP addresses. After receiving a response like 40.112.72.62, the beacon calculates an XOR value from the final octet to determine the returned command. A separate campaign, FinSupport, used three domains designed to impersonate IT support services — identity-mgmt[.]com, internalsupport[.]info, and cloud-enrollment[.]com — to make Cobalt Strike DNS beaconing appear as legitimate enterprise service traffic. These campaigns demonstrate that even well-documented C2 frameworks like Cobalt Strike continue to evolve through customization that defeats signature-based detection.
WailingCrab — IoT Protocol Abuse for C2
Documented by IBM X-Force in late 2023, the WailingCrab malware family represents an early adopter of publish/subscribe protocol abuse for C2. Distributed through phishing emails with malicious attachments, WailingCrab's backdoor component communicates with its C2 server using the MQTT protocol through the legitimate third-party broker broker.emqx[.]io. This architecture provides two advantages: the compromised system never connects directly to the attacker's infrastructure (only to the MQTT broker), and the traffic profile matches legitimate IoT device communication patterns. The IOCONTROL malware, targeting operational technology environments, adopted a similar approach, using MQTT with encryption for C2 communication that blends with industrial control system telemetry. As IoT deployments grow across enterprise and OT networks, the attack surface for pub/sub protocol abuse expands accordingly.
Detection Strategies
Detecting application layer C2 requires moving beyond traditional signature-based and port-based monitoring toward behavioral analysis, protocol anomaly detection, and network traffic analytics. No single detection approach is sufficient — effective defense requires layered visibility across multiple data sources.
Key Network Monitoring Indicators
| Data Source | What to Monitor | Detection Value |
|---|---|---|
| DNS Query Logs | Query length, subdomain entropy, query volume per domain, TXT record requests, unusual NXDOMAIN rates | DNS tunneling generates queries with high subdomain entropy and abnormal query lengths (>50 characters). Legitimate domains rarely have deep subdomain nesting. |
| TLS/SSL Metadata | JA3/JA3S fingerprints, certificate anomalies, SNI mismatches, self-signed certificates | C2 frameworks produce distinctive TLS fingerprints. Cobalt Strike's default JA3S hash is well-documented. Mismatches between SNI and certificate CN indicate domain fronting. |
| HTTP/S Traffic Analysis | Periodic beaconing patterns, unusual user-agent strings, POST/GET ratio anomalies, traffic to newly registered domains | C2 beaconing creates periodic communication patterns with low jitter. Machine learning models can identify beaconing even when attackers add random sleep intervals. |
| Network Flow Data | Upload-to-download ratios, session duration, bytes transferred per connection, connection frequency | C2 sessions often show inverted upload/download ratios (compromised host sends more data than it receives). Long-duration, low-bandwidth connections to external IPs are suspicious. |
| DNS-over-HTTPS | HTTPS connections to known DoH resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8) from processes that do not normally use DoH | DoH bypasses traditional DNS monitoring entirely. Endpoint monitoring must detect when non-browser processes establish HTTPS connections to DoH resolver endpoints. |
| MQTT/IoT Traffic | Connections to public MQTT brokers from non-IoT endpoints, unexpected pub/sub topic patterns, unusual message sizes | Windows workstations and servers should not communicate with public MQTT brokers. Any such connection warrants immediate investigation. |
SIEM Detection Queries
DNS Tunneling Detection (Splunk) — identifies DNS queries with unusually long subdomains and high query volume to a single domain, characteristic of data exfiltration or C2 over DNS:
| DNS tunneling detection via subdomain length and query frequency index=dns sourcetype=dns | eval subdomain_length=len(mvindex(split(query,"."),0)) | where subdomain_length > 50 | stats count dc(query) as unique_queries by src_ip query_type values(query) as sample_queries | where count > 100 AND unique_queries > 50 | sort -count
HTTP/S Beaconing Detection (Splunk) — identifies periodic callback patterns by measuring the standard deviation of connection intervals to external destinations:
| Beaconing detection via connection interval analysis index=proxy OR index=firewall action=allowed dest_port=443 | sort src_ip dest_ip _time | streamstats current=f last(_time) as prev_time by src_ip dest_ip | eval interval=_time - prev_time | stats count avg(interval) as avg_interval stdev(interval) as stdev_interval dc(src_ip) as unique_sources by dest_ip | eval jitter_ratio=stdev_interval/avg_interval | where count > 50 AND jitter_ratio < 0.3 AND avg_interval < 900 | sort jitter_ratio
Anomalous Cloud Service Communication (Splunk) — detects processes making API-style HTTPS calls to cloud platforms that do not match normal usage patterns, potentially indicating C2 through legitimate cloud services:
| Cloud service C2 detection via process-to-destination anomaly index=sysmon EventCode=3 dest_port=443 (dest="*.googleapis.com" OR dest="*.cloudflare.com" OR dest="*.blob.core.windows.net") | where NOT match(process_name, "(?i)(chrome|firefox|edge|outlook|teams|onedrive|code)") | stats count earliest(_time) as first_seen latest(_time) as last_seen values(dest) as destinations by src_ip process_name process_id | where count > 20 | sort -count
Beaconing detection thresholds must be tuned per environment. Legitimate software (update checkers, monitoring agents, SaaS applications) generates periodic callbacks that can trigger false positives. Maintain an allowlist of known legitimate beaconing processes and destinations, and focus analysis on traffic to newly registered domains, low-reputation destinations, and IP addresses without associated domain names.
Known Threat Actors
| Threat Actor | Attribution | Application Layer C2 Usage |
|---|---|---|
| APT41 (Brass Typhoon) | China | Google Calendar, Google Sheets, Google Drive for C2 via TOUGHPROGRESS, VOLDEMORT, DUSTTRAP, and MoonWalk malware families. DNS-based C2 channels documented since 2019. |
| APT29 (Midnight Blizzard) | Russia (SVR) | HTTPS-based C2 with sophisticated domain fronting via cloud CDNs. SUNBURST backdoor used DNS for initial beaconing and HTTPS for operational C2. |
| Volt Typhoon | China | Fast Reverse Proxy (FRP) tooling over HTTPS, reverse SSH tunnels, and living-off-the-land C2 through compromised SOHO router infrastructure. |
| Silver Dragon | China | DNS tunneling via Cobalt Strike, HTTP behind Cloudflare, SMB peer-to-peer C2, and Google Drive via GearDoor backdoor. |
| OilRig (APT34) | Iran | Pioneered email draft-based C2 (SMTP/IMAP). DNS tunneling via custom tools including BONDUPDATER. Steganography combined with HTTP/S for exfiltration. |
| Lazarus Group | North Korea | HTTPS C2 via compromised websites and cloud infrastructure. Contagious Interview campaign distributed malicious npm packages with HTTP-based C2. Dohdoor (UAT-10027) uses DNS-over-HTTPS. |
| Velvet Ant | China | Reverse SSH tunnels through compromised F5 load balancers for persistent C2 access to victim networks. |
| TeamTNT | Financially motivated | IRC-based C2 for cryptomining operations targeting Kubernetes and cloud environments. |
| FIN8 | Financially motivated | HTTPS-based C2 via BADHATCH toolkit targeting POS systems and financial sector networks. |
| Sandworm (Unit 74455) | Russia (GRU) | HTTP/S C2 for destructive operations. Used application layer protocols in campaigns targeting Ukrainian critical infrastructure and energy sector. |
Beyond state-sponsored actors, application layer C2 is a standard feature of virtually every commercial C2 framework (Cobalt Strike, Sliver, Havoc, Brute Ratel, Mythic), commodity RAT (Agent Tesla, Remcos, AsyncRAT, NjRAT), and ransomware operator toolkit. This means defenders encounter T1071 across the entire threat spectrum — from script-kiddie installations of open-source C2 frameworks to the most sophisticated nation-state operations.
Defensive Recommendations
You cannot block application layer C2 by blocking application layer protocols — the organization depends on them. Defense requires behavioral analysis, encrypted traffic inspection, network segmentation, and endpoint-level visibility into which processes are communicating and why.
- Deploy TLS inspection at the network perimeter: Without TLS inspection, HTTPS-based C2 traffic is a black box. Deploy a forward proxy with trusted CA certificates distributed to all managed endpoints, enabling inspection of encrypted traffic to non-pinned destinations. Maintain a bypass list for known certificate-pinned applications and privacy-sensitive domains. Accept the operational overhead — it is the single highest-impact control for detecting T1071.001.
- Implement DNS security with logging and analytics: Deploy a DNS security solution that performs real-time analysis of DNS query patterns, subdomain entropy, and response anomalies. Log all DNS queries centrally and retain them for at least 90 days. Block direct DNS to external resolvers (port 53 outbound to anything other than your designated recursive resolvers) and monitor for DNS-over-HTTPS connections from non-browser processes. Advanced DNS Security subscriptions from providers like Palo Alto Networks and Infoblox use machine learning to detect DNS tunneling in near real-time.
- Enforce egress filtering and segmentation: Restrict outbound connections to only the protocols, ports, and destinations required for each network segment. Servers that do not need internet access should not have it. Workstations should route all web traffic through an inspecting proxy. OT/IoT segments should have strict egress allowlists that prevent connections to public MQTT brokers, arbitrary cloud endpoints, and unrecognized external IP addresses.
- Deploy network detection and response (NDR): NDR platforms analyze network metadata and traffic patterns to identify beaconing behavior, anomalous data transfers, and C2 communication signatures. The most effective NDR solutions use machine learning to establish baseline communication patterns per host and alert on deviations. Focus on NDR solutions that analyze encrypted traffic metadata (JA3/JA3S, certificate properties, connection timing) without requiring decryption.
- Monitor cloud service access patterns: Track which processes and users access cloud services (Google APIs, Azure endpoints, AWS services, Cloudflare). Non-browser processes making repeated HTTPS calls to cloud service APIs are suspicious unless specifically expected. Restrict OAuth application consent to administrator-approved applications, and audit third-party application access to organizational cloud resources regularly.
- Implement certificate and domain reputation scoring: Block or alert on connections to domains registered within the past 30 days, domains with low reputation scores, and IP addresses without reverse DNS records. Use certificate transparency logs to identify suspicious certificates impersonating internal or well-known services. Domain age alone is an effective first-pass filter — the majority of malicious C2 domains are younger than 90 days.
- Monitor for protocol anomalies at the endpoint: Use endpoint telemetry (Sysmon Event ID 3 for network connections, EDR process-network correlation) to identify which processes are establishing outbound connections and whether those connections match expected behavior for that process. A
svchost.exeinstance making HTTPS calls to a cloud API, or anotepad.exeprocess establishing DNS queries to high-entropy subdomains, should trigger immediate investigation. - Validate defenses through simulation: Use adversary simulation tools (Atomic Red Team, Caldera, commercial BAS platforms) to test your detection capabilities against specific T1071 sub-techniques. Simulate HTTPS beaconing with common C2 profiles, DNS tunneling with dnscat2 and Cobalt Strike, and cloud service abuse patterns. Measure which simulations trigger alerts, which reach the SOC, and which generate actionable response. The gap between "we have NDR" and "our NDR detects DNS tunneling" is where attackers live.
MITRE ATT&CK Mapping
| Field | Value |
|---|---|
| Technique ID | T1071 |
| Technique Name | Application Layer Protocol |
| Tactics | Command and Control |
| Platforms | Windows, Linux, macOS, Network Devices, ESXi |
| Sub-Techniques | T1071.001 Web Protocols, T1071.002 File Transfer Protocols, T1071.003 Mail Protocols, T1071.004 DNS, T1071.005 Publish/Subscribe Protocols |
| Data Sources | Network Traffic (Content, Flow) |
| MITRE Version | v18 (last modified October 2025) |
| MITRE Reference | attack.mitre.org/techniques/T1071 |
Sources and References
- MITRE ATT&CK — T1071 Application Layer Protocol: attack.mitre.org
- Picus Security — Red Report 2026 and T1071 Technique Explained: picussecurity.com
- Google Threat Intelligence Group — APT41 TOUGHPROGRESS Campaign (May 2025): cloud.google.com
- Check Point Research — Silver Dragon Campaign (March 2026): research.checkpoint.com
- Cisco Talos — Dohdoor Malware Campaign (2026): blog.talosintelligence.com
- Unit 42 — Detecting DNS Tunneling Campaigns (2024): unit42.paloaltonetworks.com
- Unit 42 — Understanding DNS Tunneling Traffic in the Wild (2024): unit42.paloaltonetworks.com