Safeguard
Application Security•

Detecting and Mitigating Application Layer Protocol C2 (T1071)

Command and control that hides inside HTTP, DNS, mail or SMB blends with normal traffic. See what MITRE documents, what to log, and which filtering helps most.

Safeguard Security Team
4 min read

Application Layer Protocol (MITRE ATT&CK T1071) is a Command and Control technique. MITRE lists Linux, macOS, Windows, network devices and ESXi as platforms.

The idea is to talk to compromised systems using protocols that are already allowed. Adversaries embed commands to the remote system, and often the results, inside the traffic between client and server. Because the traffic is shaped like normal protocol use, it is more likely to pass network filtering unnoticed.

How attackers use it

MITRE says adversaries may use many protocols, including those for web browsing, file transfer, email, DNS or publish and subscribe messaging. For connections inside an enclave, such as those between a proxy or pivot node and other nodes, common protocols are SMB, SSH and RDP.

This parent technique has five sub-techniques, and each has its own post in this series:

  • T1071.001 Web Protocols
  • T1071.002 File Transfer Protocols
  • T1071.003 Mail Protocols
  • T1071.004 DNS
  • T1071.005 Publish/Subscribe Protocols

The lesson across all of them is the same. The channel is legitimate. What gives it away is who is using it, how often, and how much data moves in each direction.

How to detect it

MITRE's detection strategy has four analytics:

  • Windows: common application-layer protocols such as HTTP, HTTPS, DNS and SMB used by abnormal processes, with high outbound byte counts or irregular ports.
  • Linux: curl, wget or custom socket traffic that uses DNS, HTTPS or IRC-style protocols, with unbalanced traffic or beacon-like intervals.
  • macOS: applications using abnormal protocols or high traffic volume not seen before for that process image, such as Automator or AppleScript invoking curl or Python sockets.
  • Network devices: application-layer tunneling or unauthorized protocols, such as DNS-over-HTTPS, command and control embedded in TLS or HTTP headers, or misused SMB traffic crossing VLANs.

To act on that, you need two kinds of data that are often kept apart:

  1. Network flow and proxy logs, showing destination, bytes in and out, timing and protocol.
  2. Endpoint telemetry, showing which process opened the connection. On Windows, Sysmon Event ID 3 records network connections per process.

Joining them is what turns "a host talked to the internet" into "PowerShell talked to a rare domain every 60 seconds".

Signals worth a rule:

  • A process that does not normally use the network, or does not normally use that protocol.
  • Regular intervals between connections, which look like a beacon.
  • Traffic that is mostly outbound from a host that mostly receives.
  • Protocols on unusual ports, such as web traffic that is not on the usual web ports.

How to reduce the risk

MITRE lists two mitigations:

  1. Network intrusion prevention. Intrusion detection and prevention systems that use network signatures can identify traffic from specific adversary malware and stop it at the network level.
  2. Filter network traffic. Use network appliances to filter ingress or egress traffic and apply protocol-based filtering. Configure software on endpoints to filter traffic too.

Egress control is the strongest step you can take. Servers rarely need to reach arbitrary internet destinations. A default-deny outbound policy with a short allow list forces command and control to use a path you can see.

Try it yourself

Click through it at your own pace, or open it full screen.

Check your own environment

# Linux: established connections with owning process (read only; needs root to see all processes)
sudo ss -tnp state established

# Linux: listening sockets with owning process
sudo ss -tlnp
# Windows PowerShell: established TCP connections with owning process ID (read only)
Get-NetTCPConnection -State Established | Select-Object LocalPort, RemoteAddress, RemotePort, OwningProcess

Then ask these questions:

  • Which servers are allowed to start outbound connections to the internet, and to where?
  • Do your proxy logs show the requesting process or only the host?
  • Can you list every process that talked to a given destination in the past week?
  • Is DNS forced through resolvers you control?
  • Are alerts tuned for beacon-like timing and not only for known bad addresses?

Quick check

Why do adversaries use common protocols for C2?

To blend in with existing traffic and avoid detection or network filtering.

Which two data sets do you need to join to detect this well?

Network traffic data (flows, proxy, DNS) and endpoint telemetry that shows which process made the connection.

What is the strongest preventive control MITRE points to?

Filtering network traffic, including protocol-based filtering at egress and on endpoints.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.