Exfiltration Over Web Service (T1567)

What is exfiltration over web service?

Exfiltration over web service is an attacker moving stolen data out through a legitimate external service, such as Google Drive, Dropbox or a Discord webhook, instead of their own command and control channel. MITRE ATT&CK tracks it as T1567. The traffic blends in because the network was already talking to that service.

If you searched this technique and landed on three articles about data exfiltration in general, that is the state of the field rather than bad luck. This page is about the branch, not the tree.

The record is short and worth having straight. T1567 sits under the Exfiltration tactic, applies to ESXi, Linux, Office Suite, SaaS, Windows and macOS, and was last modified on 12 May 2026 at version 1.5. It has four sub-techniques, and they are not variations on a theme.

What follows is why this is a separate technique from exfiltration over the C2 channel, why those four sub-techniques are four different detection problems, what one of them actually looks like in telemetry, and what makes any of it detectable without burying your queue.

Explain It Like I'm 10

Imagine someone inside an office who wants to take documents home. They could try to sneak a box out the back door, where there is a guard. Or they could put the documents in the outgoing post tray, which is collected every afternoon and leaves the building without anyone opening it. Nothing about the tray is suspicious. It was always going to leave. That is the whole trick: the data goes out through something that was already leaving.

Why this is a separate technique from exfiltration over C2

MITRE's definition contains the distinction in its own first line: adversaries use a legitimate external web service "rather than their primary command and control channel".

That matters operationally, because it means detection built around command and control does not reach it. There is no implant beaconing to attacker infrastructure. There is a host talking to Google Drive.

MITRE gives three reasons it works, and they stack:

• The conversation already exists. Popular web services "may give a significant amount of cover due to the likelihood that hosts within a network are already communicating with them prior to compromise."
• The firewall already allows it. "Firewall rules may also already exist to permit traffic to these services."
• The payload is already encrypted. Providers "commonly use SSL/TLS encryption, giving adversaries an added level of protection."

That third point is routinely overstated, so read it precisely. MITRE says an added level of protection, not invisibility. TLS blinds payload inspection. It does not hide the destination, the volume, the timing, or which process opened the connection, and all four survive to be detected on. This is also the boundary with a command-and-control channel as a subject in its own right: same goal, different infrastructure, different evidence.

Four sub-techniques, four detection problems

The strongest argument that these are separate problems is structural: MITRE publishes a separate detection strategy for each one. That is the framework saying, in its own data model, that a repo push and a webhook POST are not the same hunt.

Two things follow. The artifacts have almost nothing in common: a transfer utility with a config file behaves nothing like a script firing a single POST. Second, the branch you should look at first is the one your environment actually runs. A software company with GitHub everywhere has a different first problem from a firm whose staff live in OneDrive.

One dating note. Three of the four sub-technique records were refreshed on 12 May 2026, but text storage sites was last modified on 15 April 2025.

What a cloud-storage exfiltration actually looks like

MITRE's procedure examples for the cloud-storage branch include a documented campaign, tracked as C0015, in which the threat actors moved files to MEGA using Rclone. The entry records the actual invocation, and the useful thing is not to reproduce it but to read it.

The observable elements are these:

• The process name of a legitimate transfer utility.
• The copy verb.
• A configured remote ending in a colon - meaning the operator had already set up and saved a destination.
• An age filter restricting the collection to files modified within a window.
• A UNC path to a file share as the source.
• Parallelism flags raising the number of simultaneous transfers.

Read as intent rather than as a string, those elements say a lot. The age filter is a scoping decision - someone decided that anything older than a couple of years was not worth the bandwidth. The UNC source says they had already found the share and were not working file by file. The parallelism flags say they were optimizing for throughput, which is what you do when you know how much you are taking and want it finished.

The other documented shapes

They are worth knowing because they look different from each other:

• Akira has exfiltrated victim data using Rclone.
• APT41's DUST activity sent collected information to OneDrive.
• BoomBox uploaded to dedicated per-victim folders in Dropbox.
• APT28 has exfiltrated over Google Drive, including in the Nearest Neighbor Campaign.
• BlackByte used file-sharing services such as file.io and anonymfiles.com, and APT41 used Cloudflare services in another campaign.

One detail in MITRE's detection guidance is quietly funny, and it is also the whole point of this article. Its cloud-storage analytic carries a tunable list called AllowedTools, described as "known tools used legitimately for backups (rclone, gsutil)", where deviations raise suspicion. The exfiltration tool is on the approved-software list. It is supposed to be.

For completeness and without drama: MITRE now also records a campaign, C0062, in which an adversary used Claude Code to summarize collected data before exfiltrating it over that service. It belongs here because it shows the breadth of what counts as a web service, not because it is startling.

This page is deliberately not a survey of every channel data can leave by. That is the job of our data exfiltration page, which covers the channel-level view.

What to actually detect

Start with the sequence rather than the destination. MITRE's cloud-storage analytics describe a behaviour chain: sensitive file reads, then compression, then an outbound upload. On Linux the analytic names it directly, looking for chained events where tar or gzip runs to compress files and is followed by HTTPS PUT or POST requests to known storage services. On Windows it looks for unusual processes accessing large local files and then initiating HTTPS POSTs to cloud storage domains.

The fields are concrete:

• Windows: `WinEventLog:Security` event codes 4663, 4670 and 4656 for file access; `WinEventLog:Sysmon` event code 1 for process creation and 3 and 22 for network connections.
• Linux: `auditd:EXECVE` for command execution and `auditd:SYSCALL` for reads of sensitive directories, with network flow alongside.
• macOS: the unified log, where the analytic watches for sync clients and scripts invoking cloud storage APIs in unexpected contexts.

MITRE offers a starting volume threshold too, and frames it as an example rather than a rule: more than 10MB in a single session. Treat it as a place to begin tuning, not a number to adopt.

Then the part that decides whether any of this survives contact with production. The same analytic carries two more tunable lists beside the volume threshold: UserContext, the accounts permitted to use sanctioned cloud services, and AllowedTools, the utilities legitimately used for backups. Those two lists are not decoration. Without them, every rule written on this technique collapses into a list of domains - and a list of domains cannot tell your marketing team's Google Drive from an intruder's, because it is the same Google Drive.

Webhooks are a different hunt entirely

The webhook branch shares almost no artifacts with the cloud-storage one, which is why it has its own strategy. On Windows the analytic looks for unusual processes such as `powershell.exe`, `wscript.exe` or `mshta.exe` posting to webhook endpoints like Discord, Slack or webhook.site. On Linux it looks for `curl` or `wget` sending bulk or encoded data in a POST. On macOS it correlates clipboard or file read operations followed by an HTTPS POST to a webhook service.

That macOS detail only appears when someone has written a detection rather than a blog post. It also makes the branch concrete: no account, no client, no configuration. One request.

Do tenant restrictions actually work?

Tenant restriction is the control the field most often recommends for this technique, and it is a good one. The idea is to configure a proxy or secure web gateway to enforce corporate tenant boundaries, so staff can reach the organization's own Google Drive or OneDrive while transfers to personal accounts on the same platform are blocked.

It earns the endorsement for a specific reason: it is the authorization question implemented at the network edge. It does not try to decide whether a service is good or bad. It decides whether this instance of the service is yours, which is the same discriminator the detection side needs.

Its limits are equally specific. It addresses the sanctioned-service branch and does nothing for a code repository, a paste site or a webhook. It depends on the proxy seeing the traffic at all, which excludes anything off the corporate path. And it is a boundary control, not a content control: it governs where data may go, never what the data is.

Where this argument stops

Four bounds, because the material above is easy to over-read.

• A documented command line is one campaign, not a signature. The C0015 elements are useful for understanding, and brittle as a rule. Operators change flags, rename binaries and point at different remotes. MITRE built its analytic around tunable baselines rather than a fixed string for exactly this reason, and that is the durable form.
• The field's recommended controls are sound. Data loss prevention, tenant restrictions and cloud API monitoring are good advice. This article sharpens how to apply them; it does not replace them.
• The encryption point has a ceiling. "An added level of protection" is not invisibility, and treating TLS as a dead end is how teams talk themselves out of detections that would have worked.
• The sourcing has limits, stated rather than hidden. CISA's Eviction Strategies Tool carries an entry for this technique, but its countermeasure content does not render in the page as served, so this article does not characterize what it recommends. And no prevalence figure appears anywhere above, because none exists in a citable form. The one tooling figure that does exist - Rclone appearing in 57% of the incidents in one vendor's dataset - covers September 2023 to July 2024 and is the tool that kept turning up in that data, not a current rate.

Common questions

What is T1567.002? The cloud-storage sub-technique: exfiltrating to a service such as Dropbox, Google Drive, OneDrive or MEGA rather than over the C2 channel. It applies to ESXi, Linux, Windows and macOS, which is worth noting because the hypervisor case is often forgotten.

How is this different from T1041, T1048 and T1537? T1041 is exfiltration over the existing C2 channel. T1048 is exfiltration over an alternative protocol, such as DNS. T1537 is transferring data to another cloud account you control. T1567 is the one where the destination is a legitimate third-party web service your network already talks to.

What does an Rclone exfiltration look like in logs? A transfer utility executing with a copy verb and a saved remote, reading from a file share, with filters and parallelism set. Look in process creation and command-execution telemetry, then correlate with the outbound session.

Which branch should I detect first? The one your environment runs. If your staff live in OneDrive, start with cloud storage. If you are a software shop, code repositories will generate both the risk and the noise.

Do I need to block these services? Almost certainly not, and trying is how detections get switched off. The workable version is to decide which tenants and which tools are authorized, then alert on the deviation.

What to go check

Four sub-techniques, four hunts, and one discriminator running through all of them: not where the data went, but whether that destination and that tool were authorized.

Two checks, for whichever branch matches your environment:

1. Would your telemetry show the chain? Not the upload alone, but the sequence: sensitive file reads, then compression, then the outbound POST. If you only have the last step, you have a domain list.
2. Is there a baseline to compare against? Written down: which tenants are yours, and which transfer tools are sanctioned. MITRE's own analytic assumes both lists exist.

Most organizations have the first and not the second. The second is the one that turns a noisy rule into a working one.