Exfiltration to Cloud Storage

Cloud storage services like a file-sync client, a backup tool, or a document-sharing platform are a normal, heavily used part of most organizations' daily work. Because they are so common and already trusted by network defenses, they make an attractive destination for moving stolen data out of a network.

Rather than sending stolen data to infrastructure the attacker controls directly, which would be unusual and easier to flag, this technique uploads it to a legitimate, widely-used cloud storage service instead. The traffic blends into an enormous amount of genuine business use of the same platforms.

Once an attacker has collected data worth exfiltrating, uploading it to a mainstream cloud storage provider avoids the need to stand up and defend dedicated exfiltration infrastructure. The connection goes to a domain the network already permits and that appears constantly in ordinary traffic, and it is usually encrypted the same way any legitimate use of the service would be.

This is effective because it exploits trust rather than technical sophistication: the destination itself is not suspicious, so the technique's success depends entirely on the upload blending into a very large volume of unremarkable, legitimate use of the same services.

Data source: web proxy access logs: POST requests to external hosts, where the proxy's own policy-deny result code and the HTTP 403 it returned share one record

{
  "url": {
    "domain": "storage.example-provider.example"
  },
  "host": {
    "name": "proxy01"
  },
  "http": {
    "request": {
      "method": "POST"
    }
  },
  "event": {
    "action": "tcp_denied"
  },
  "source": {
    "ip": "10.0.0.101"
  }
}

Prebuilt Elastic rule: Unusual Network Connection to Suspicious Web Service, matching against known cloud storage and file-sharing domains

Filter outbound connections to known cloud storage and file-sharing domains, then look at direction and volume rather than the destination alone, since the destination is expected traffic for most environments. A large, one-directional upload is a very different story from the routine download-heavy pattern of normal cloud storage use.

Correlate with what preceded it where possible: a burst of file reads across sensitive locations followed shortly by a large upload to a cloud storage destination is a much stronger combined signal than either fact alone.

On this range, filter for http.request.method: "POST" toward known or unrecognized cloud storage domains and read event.action alongside it; a blocked attempt (tcp_denied, typically alongside a 403) is graded evidence here in its own right, not just a precursor to a successful upload. Given the unconfirmed byte-capture direction, do not build a hunt around transfer size on this range until that is verified; method, destination, and outcome are the dependable fields today.

Staff use cloud storage constantly for entirely legitimate reasons: file sync, backups, sharing documents with collaborators, and syncing between a work device and personal devices. Frequent connections to major providers are the expected baseline in most organizations, not an anomaly.

The distinguishing signal is not the act of upload but its shape: whether the account involved is the organization's own sanctioned instance or an unrecognized personal one, whether the transfer volume and direction fit this user's established pattern, and whether the destination service is even one this organization is known to use at all.

• MITRE ATT&CK: T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage
• Elastic Security: Unusual Network Connection to Suspicious Web Service

1 scenario in this catalog covers T1567.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →