Web Protocols (MITRE ATT&CK T1071.001) is a Command and Control technique. MITRE lists ESXi, Linux, macOS, network devices and Windows as platforms.
Adversaries use the application-layer protocols that carry web traffic to blend in with what is already on the network. Commands to the remote system, and often the results, ride inside the protocol traffic between client and server.
How attackers use it
MITRE points out that HTTP, HTTPS and WebSocket are common in almost every environment. HTTP and HTTPS packets have many fields and headers where data can be hidden. An adversary can abuse them to talk to systems under their control from inside the victim network, while the traffic mimics what a browser or app would normally send.
For defenders, that has an uncomfortable consequence. You cannot block web traffic outright, and a rule that only looks for known bad domains misses anything new.
How to detect it
MITRE's detection strategy has five analytics:
- Windows: unexpected or high-volume HTTP, HTTPS or WebSocket traffic from suspicious processes, such as PowerShell or rundll32, using uncommon user agents or mimicking browser traffic to unusual domains or IPs.
- Linux: curl, wget, Python requests or custom HTTP clients on non-standard ports, with repetitive or beacon-like patterns or POST-heavy behavior to rare domains.
- macOS: apps such as Automator, AppleScript or LaunchDaemons making HTTP or HTTPS requests to non-standard domains, or using suspicious headers such as Base64 in URIs or cookie fields.
- ESXi: HTTP or HTTPS started by shell-based scripts or management daemons, especially to public IPs on ports 80 and 443 using embedded curl or wget.
- Network devices: misuse of web protocols, such as encoded HTTP headers, WebSocket upgrade requests with abnormal payloads, or TLS handshake anomalies that suggest embedded C2.
A practical way to start is with these data sources:
- Proxy or secure web gateway logs, with user agent, destination, bytes and URL path length.
- Endpoint network telemetry, such as Sysmon Event ID 3, to name the process.
- DNS logs, to see how new the destination domain is and how often it is queried.
Then look for these patterns:
- Clients that connect at near-regular intervals, with small requests and small replies.
- Rare user agents, or a user agent that does not match the process that sent it.
- Long or Base64-looking values in URLs, cookies or custom headers.
- Servers, ESXi hosts and other non-user systems that make outbound web requests at all.
- WebSocket upgrades from processes that are not browsers.
How to reduce the risk
MITRE lists two mitigations:
- Network intrusion prevention. Intrusion detection and prevention systems that use network signatures can identify traffic from specific adversary malware and mitigate it at the network level.
- Filter network traffic. Restrict and monitor outbound HTTP and HTTPS from critical servers so they only reach approved destinations. MITRE notes that limiting the ability to start outbound web connections, especially from public-facing servers, can stop attackers from using tools such as curl or wget to reach external C2 servers or download payloads.
In plain steps:
- Default-deny outbound web traffic from servers, then add the specific destinations they need, such as update servers and APIs.
- Send all other web traffic through a proxy that logs the full request metadata.
- Inspect TLS where your policy and law allow, or at least log the server name and certificate details.
- Alert on new destinations for sensitive hosts.
Try it yourself
Click through it at your own pace, or open it full screen.
Check your own environment
# Linux: outbound HTTP and HTTPS connections with owning process (read only)
sudo ss -tnp state established '( dport = :80 or dport = :443 )'
# Windows PowerShell: processes with established connections to port 443 (read only)
Get-NetTCPConnection -State Established -RemotePort 443 |
Select-Object OwningProcess, RemoteAddress |
Sort-Object OwningProcess -Unique
Then work through this checklist:
- Which of your servers can reach the internet over HTTP or HTTPS today, and why?
- Can you see the user agent and bytes sent for every outbound request?
- Do you have a list of expected destinations per server role?
- Do you alert when a non-browser process uses WebSocket?
- Is DNS visibility good enough to tell a new domain from an old one?
Quick check
Why is a blocklist of bad domains not enough?
Web C2 mimics normal traffic and can use new destinations. Process, timing, volume and header anomalies matter as much as reputation.
What does MITRE suggest for outbound web traffic from critical servers?
Restrict and monitor it so servers only reach approved destinations, which prevents tools like curl or wget from reaching external C2 servers.
Name a header or field MITRE says may hide data.
HTTP and HTTPS packets have many fields and headers where data can be concealed. MITRE's analytics mention Base64 in URIs or cookie fields and encoded HTTP headers.
