Most command and control traffic does not invent a protocol: it rides on HTTPS, DNS, SMB, mail or a message broker that the network already allows, so the question is never "is this protocol permitted" but "should this process, on this host, be speaking it to that destination". MITRE ATT&CK T1071 Application Layer Protocol covers adversaries embedding commands and results in application layer traffic to blend in with normal flows. In ATT&CK v20 it sits in Command and Control (TA0011), applies to Windows, Linux, macOS, network devices and ESXi, and has five sub-techniques: T1071.001 Web Protocols, T1071.002 File Transfer Protocols, T1071.003 Mail Protocols, T1071.004 DNS and T1071.005 Publish/Subscribe Protocols. This guide is the technique-level reference: per sub-technique detection logic and log sources from the ATT&CK v20 detection strategies, the workload and identity angle, and response. It contains no C2 build or use steps. For C2 as a whole and frameworks, see the Command and Control (C2) Guide; for beacon scoring, see the Beaconing and C2 Detection Guide.
Key takeaways
- Process plus protocol plus destination. Every T1071 analytic in ATT&CK v20 has the same shape: an application protocol used by a process or host that does not normally use it, to a destination outside its baseline.
- Each sub-technique has its own log. Web C2 shows in proxy,
http.logandssl.log; DNS in resolver logs anddns.log; mail insmtp.log; file transfer inftp.logand SMB logs; pub/sub needs broker logs or custom parsers. - Servers and workloads are the easy win. A database server, container or ESXi host has a short, knowable list of destinations, so any new application layer conversation from it is high signal.
- Only two mitigations, both network. ATT&CK lists M1037 Filter Network Traffic and M1031 Network Intrusion Prevention, which in practice means default-deny egress, forced proxying and controlled DNS resolution.
- Internal C2 uses admin protocols. ATT&CK notes that inside an enclave, pivot nodes commonly use SMB, SSH or RDP, so internal east-west monitoring matters as much as the perimeter.
How the technique works
ATT&CK describes commands "and often the results of those commands" being embedded within protocol traffic between client and server. The sub-techniques differ in which fields hide the data and how much traffic exists to hide in:
| Sub-technique | Protocols named by ATT&CK | Where data hides | Groups in ATT&CK v20 (examples) |
|---|---|---|---|
| T1071.001 Web Protocols | HTTP/S, WebSocket | Headers, cookies, URIs, bodies; 58 groups recorded | OilRig, APT37, Magic Hound, Moonstone Sleet |
| T1071.002 File Transfer Protocols | SMB, FTP, FTPS, TFTP | Protocol fields and the transferred files | APT41, Salt Typhoon, Kimsuky, Dragonfly |
| T1071.003 Mail Protocols | SMTP/S, POP3/S, IMAP | Headers and message bodies | APT28, Turla, Kimsuky, Contagious Interview |
| T1071.004 DNS | DNS queries and records such as TXT or A | Encoded subdomains and record data; low-frequency DNS beacons | OilRig, APT41, FIN7, Chimera |
| T1071.005 Publish/Subscribe | MQTT, XMPP, AMQP, STOMP | Topics and messages through a central broker | Recorded mainly against malware families |
The parent technique is also recorded for TeamTNT, Rocke, INC Ransom and Velvet Ant, and for container malware such as Hildegard and Siloscape. Closely related techniques have their own pages in ATT&CK: T1102 Web Service Defensive Guide (C2 through legitimate SaaS), T1572 Protocol Tunnelling Defensive Guide, T1573 Encrypted Channel, T1095 Non-Application Layer Protocol and T1568 Dynamic Resolution.
Detection by sub-technique
ATT&CK v20 gives the parent technique detection strategy DET0444 and each sub-technique its own: DET0027 (web), DET0416 (file transfer), DET0135 (mail), DET0400 (DNS) and DET0002 (pub/sub). The log sources they name are consistent: Sysmon Event ID 3 (network connection) and 22 (DNS query) on Windows, auditd execve on Linux, osquery socket_events and the unified log on macOS, ESXi shell history and syslog, and network security monitoring logs such as Zeek. Note that Sysmon Event ID 3 is disabled by default and must be enabled in your configuration.
| Sub-technique | Detection logic (from the ATT&CK analytics) | Primary logs | Tuning tip |
|---|---|---|---|
| Web (DET0027) | HTTP/S or WebSocket from processes such as PowerShell or rundll32, uncommon or browser-mimicking user agents, POST-heavy or beacon-like traffic to rare domains, encoded data in URIs or cookies, ESXi scripts calling public IPs on 80/443 | Proxy logs, Zeek http.log and ssl.log, Sysmon 3 and 22 | Baseline by process image and host role; forced proxying makes direct-to-IP HTTPS itself an alert |
| File transfer (DET0416) | FTP, SMB or TFTP started by shells or script hosts, large or unbalanced outbound transfers, FTP on non-standard ports, transfers from ESXi scratch partitions or /tmp | Zeek ftp.log, SMB logs, conn.log; Sysmon 1 and 3; auditd | Outbound SMB (TCP 445) and TFTP (UDP 69) to the internet should be blocked and alerted |
| Mail (DET0135) | SMTP, IMAP or POP3 used by non-mail binaries or background scripts (sendmail, mailx, custom clients), mail traffic to relays outside the enterprise mail infrastructure | Zeek smtp.log, conn.log; Sysmon 1, 3; mail gateway | Only mail servers and the gateway should talk SMTP (TCP 25, 465, 587) outbound |
| DNS (DET0400) | High-frequency or anomalous queries from non-browser, non-system processes; long or encoded subdomains; high volume to one parent domain; unusual DNS from ESXi hosts | Resolver query logs, Zeek dns.log, Sysmon 22 | Force all clients to internal resolvers and block direct UDP/TCP 53 and unsanctioned DNS over HTTPS |
| Pub/sub (DET0002) | Non-standard processes connecting to MQTT or AMQP brokers, unusual topic names, high publication rates, brokers outside allowlisted infrastructure or on unusual ports | Broker logs, custom NSM parsers, Sysmon 3, auditd | Inventory legitimate brokers (IoT, telemetry) first; anything else is suspect |
Rules to build first
- Server egress outside allowlist: any application layer session from a server, container node or ESXi host to an internet destination not on its role's allowlist.
- Scripting host network activity: PowerShell, wscript, mshta, rundll32, python or curl making external HTTP/S, DNS or SMTP connections on hosts where that is not normal.
- Direct DNS and DoH bypass: port 53 traffic to anything other than internal resolvers, and DNS over HTTPS to providers you have not sanctioned.
- DNS tunnelling shape: one parent domain receiving many unique long subdomains or TXT queries from a single client.
- Mail from non-mail hosts: outbound SMTP or IMAP from workstations or servers other than mail infrastructure.
- Internal admin protocols from unusual sources: SMB, SSH or RDP between workstations or from servers that never initiate them, the pivot pattern ATT&CK describes.
Measuring it
- Egress posture: share of server and workload subnets on default-deny egress with documented allowlists.
- DNS control: percentage of clients whose DNS goes only through monitored internal resolvers.
- Telemetry coverage: hosts sending process-attributed network events (Sysmon 3 and 22, auditd, EDR) and sites with NSM sensors.
- Detection test pass rate: benign emulation of each sub-technique in a lab detected by at least one rule.
- Dwell time: median time from first C2 session to detection in exercises and real incidents.
Prevention and hardening
- Filter network traffic (M1037): default-deny egress for servers and workloads; user traffic forced through an authenticated proxy; outbound SMB, TFTP and direct SMTP blocked at the perimeter. See the Secure Web Gateway and Web Filtering Guide.
- Control DNS: internal resolvers only, with logging and protective DNS; block external resolvers and unsanctioned DoH. See the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.
- Network intrusion prevention (M1031): signatures for known C2 frameworks and protocol anomalies at egress points, plus TLS inspection where policy and law allow.
- Workload egress: Kubernetes NetworkPolicy default deny, cloud security groups and egress gateways so containers reach only named services. See the Agent Egress Control and Network Isolation Guide.
- Brokers: require authentication and TLS on internal MQTT and AMQP brokers and block outbound connections to public brokers from corporate networks.
Rollout
- Enable Sysmon 3 and 22 (or EDR equivalents), resolver logging and NSM at egress points.
- Baseline destinations per host role for 30 days.
- Apply default-deny egress in report-only mode to one server tier, review hits, then enforce.
- Expand tier by tier; keep a documented exception path with expiry.
- Roll back a tier by reverting the firewall policy version; record the cause before retrying.
Where identity fits
The identity angle in T1071 is the workload. Servers, containers, CI runners and AI agents run as non-human identities whose legitimate network behaviour is narrow and predictable, which makes them the best place to catch C2: a build runner that starts sending DNS TXT queries or a service account's process opening an SMTP session is not normal. Tie network policy to workload identity (for example Kubernetes service accounts or cloud workload identity) rather than IP alone, so a compromised workload cannot borrow another's allowance. C2 is also often the channel through which stolen non-human credentials leave: in the 2020 TeamTNT worm, infected hosts ran a Tsunami IRC backdoor and uploaded AWS credential files to an attacker server. See the TeamTNT worm breach analysis and the Cloud Workload Identity Guide.
Responding to suspected application layer C2
- Confirm: attribute the traffic to a process and user or service account on the host; check for a parent chain that explains it.
- Contain at the network first: block the destination domain and IP at proxy, DNS and firewall, and sinkhole the domain internally so other infected hosts reveal themselves.
- Isolate the host with EDR network containment, preserving memory and disk.
- Scope: search proxy, DNS and NSM logs for the same domain, JA3 or JA4 fingerprint, user agent, URI pattern or broker topic across the estate.
- Rotate identities used on the host, including service account passwords, tokens and cloud keys. See the Command and Control (C2) Guide for the wider response flow.
Common failure patterns
- Allow 443 and 53 to anywhere: servers with unrestricted outbound HTTPS and DNS give C2 a free path.
- Network logs without process context: proxy and firewall logs that show the host but not which process or identity made the call.
- Sysmon 3 left off: the network connection event is disabled by default, so many Sysmon deployments have no process-attributed network data.
- Ignoring east-west: monitoring only the perimeter while pivot nodes relay C2 internally over SMB or SSH.
- Unmanaged DNS over HTTPS: browsers and malware resolve outside the corporate resolver and its logs.
- ESXi and appliances unmonitored: hypervisors and network devices excluded from egress policy and logging.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1071, T1071.001 to T1071.005; related T1102, T1572, T1573, T1095, T1568, T1008 | Technique, sub-techniques and adjacent C2 techniques |
| ATT&CK mitigations | M1037 Filter Network Traffic, M1031 Network Intrusion Prevention | Egress filtering and network IPS |
| NIST SP 800-53 Rev. 5 | SC-7, SC-7(5), SI-4, SI-4(4), AU-6, CM-7 | Boundary protection with deny by default, monitoring inbound and outbound traffic, review, least functionality |
| NIST CSF 2.0 | PR.IR-01, DE.CM-01, DE.AE-02 | Network protection, network monitoring, event analysis |
| CIS Controls v8.1 | Controls 9, 12 and 13 | DNS filtering and web protections, network infrastructure, network monitoring and defence |
| ISO/IEC 27001:2022 Annex A | A.8.16, A.8.20, A.8.22, A.8.23 | Monitoring, network security, segregation, web filtering |
Practitioner checklist
- Enable process-attributed network telemetry (Sysmon 3 and 22, auditd, EDR) on servers and workstations.
- Force DNS through logged internal resolvers and block direct 53 and unsanctioned DoH.
- Put servers, container nodes and ESXi hosts on default-deny egress with role allowlists.
- Block outbound SMB, TFTP and direct SMTP at the perimeter and alert on attempts.
- Build the DET0027, DET0416, DET0135, DET0400 and DET0002 analytics for your platforms.
- Inventory legitimate pub/sub brokers and alert on connections to any other broker.
- Bind workload egress policy to workload identity, not only IP addresses.
- Test each sub-technique with benign emulation in a lab and track the pass rate.
Standards and references
- MITRE ATT&CK: Application Layer Protocol (T1071)
- MITRE ATT&CK: Application Layer Protocol: DNS (T1071.004)
- MITRE ATT&CK: Application Layer Protocol: Publish/Subscribe Protocols (T1071.005)
- Microsoft Sysinternals: Sysmon
- Zeek: Log files
- MITRE ATT&CK: Filter Network Traffic (M1037)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Command and Control (C2) Guide · Beaconing and C2 Detection Guide · T1102 Web Service Defensive Guide · T1572 Protocol Tunnelling Defensive Guide · Cloud Workload Identity Guide