Web Service (T1102) is a command and control technique in MITRE ATT&CK. It applies to ESXi, Linux, macOS and Windows, and it has three sub-techniques: dead drop resolver, bidirectional communication and one-way communication.
The premise is that your hosts already talk to big, trusted services all day. If malware does the same, a plain "block the bad domain" approach has little to grab. This post explains the technique at the level MITRE documents, what defenders can watch, and which controls help.
How attackers use it
MITRE describes the technique as using an existing, legitimate external web service to relay data to and from a compromised system. Popular websites, cloud services and social media can give a lot of cover, because hosts in your network are likely already communicating with them before any compromise. Services offered by large providers make it easier for an adversary to hide in expected noise.
Two more points from MITRE:
- Web service providers commonly use SSL/TLS encryption, which gives the adversary an added layer of protection. The content of the traffic is not visible to a defender who is not inspecting it.
- Using a web service may protect back-end command and control infrastructure from discovery through malware binary analysis, and it helps resilience, since the infrastructure behind the service can be changed dynamically.
The three sub-techniques describe how the channel is used:
- Dead drop resolver (T1102.001): the service hosts content that points to other command and control infrastructure.
- Bidirectional communication (T1102.002): commands and their output both travel over the service.
- One-way communication (T1102.003): commands arrive through the service, and output goes elsewhere or nowhere.
Each has its own post in this series.
How to detect it
MITRE's detection strategy is Suspicious Use of Web Services for C2. It describes four analytics by environment:
- Unusual outbound connections to web services from uncommon processes using TLS, particularly with high outbound data volume or persistence.
- Command line tools, agents or scripts making outbound HTTPS connections to popular web services, such as chat, file sharing or Graph API endpoints, in an unusual context.
- User agents or background services making unauthorized or unscheduled web API calls to cloud or web services over HTTPS.
- Guest virtual machines or management agents issuing HTTP or HTTPS traffic to external services without a valid patch management or backup reason.
The common thread is that the destination is not the signal. The source is. A browser talking to a collaboration service is normal. A scripting engine, a service account or a hypervisor guest agent doing so is worth a look.
Data to collect:
- Proxy or firewall logs with the process or user agent, destination, byte counts and timing.
- Endpoint process and network connection logs, so you can tie a connection to the process behind it. Sysmon event ID 3 records network connections on Windows.
- DNS logs, to see which hosts resolve which services.
Useful signals include regular, timed connections (a steady beat), small requests with larger responses, uploads of unusual size, and connections from processes that do not normally touch the internet.
How to reduce the risk
MITRE lists two mitigations:
- Restrict web-based content. Use web proxies to enforce an external communication policy that prevents use of unauthorized external services. If no one in the business needs a given paste site, file host or chat API from a server, it should not be reachable from there.
- Network intrusion prevention. Use network intrusion detection and prevention systems with signatures for specific adversary malware to mitigate activity at the network level.
Practical steps that follow from these:
- Route server egress through a proxy, and allow only the services each server class needs.
- Deny direct internet access from systems that have no reason for it, such as database servers and management planes.
- Inspect TLS where your policy and law allow, at least for non-user workloads.
- Tag approved service accounts and their destinations so exceptions are visible.
Check your own environment
Run through this list:
- Which server groups can reach arbitrary web services today? Is that intended?
- Does your proxy log the originating process or user agent, or only the destination?
- Can you answer "which processes on this host talk to the internet" from your endpoint logs?
- Is there an alert for a scripting engine or background service making outbound HTTPS calls to popular services?
- Do hypervisor guests and management agents have a defined egress allow list?
- Is outbound traffic from servers reviewed on a schedule, not only after an incident?
A simple Linux check for current outbound connections and the process behind each:
# Linux (iproute2): list established TCP connections with owning process (run with sudo for full detail)
sudo ss -tnp state established
Treat the result as a starting point. Unknown processes with long-lived HTTPS connections deserve follow-up.
Try it yourself
Policy only works if you know what is running and talking. This demo shows continuous monitoring across an environment.
Click through it at your own pace, or open it full screen.
Quick check
Why do attackers choose popular web services for command and control?
Hosts are likely already talking to those services, so the traffic blends in with expected noise, and TLS adds protection. The back-end infrastructure can also be changed dynamically behind the service.
What is the most useful signal when the destination looks normal?
The source: an uncommon process, script, service account or management agent making the connection, or connections with a regular beat and unusual data volume.
Which two mitigations does MITRE list?
Restrict web-based content with proxies that enforce an external communication policy, and network intrusion prevention using signatures for specific malware.
Sources
- MITRE ATT&CK, Web Service (T1102)
