---
{
  "title": "Transfer Data to Cloud Account",
  "summary": "Cross-account cloud transfer moves data to another account through provider features.",
  "topic": "networking",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    2
  ],
  "aliases": [
    "T1537"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1537: Transfer Data to Cloud Account",
      "url": "https://attack.mitre.org/techniques/T1537"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Cross-account cloud transfer moves data to another account through provider features. The activity may not appear as ordinary traffic leaving a corporate network.


## An investigation example

A sensitive snapshot or storage resource becomes shared with an unapproved external account.

## Evidence to examine

Review sharing permissions, recipient identifiers, export or copy events, object versions, and originating identity.

## A common analytical pitfall

A provider-internal transfer can still cross an organizational data boundary even without an unusual gateway connection.

## Response considerations

Revoke unauthorized sharing, preserve recipient and resource details, and assess copies or access that cannot be reversed by removing the original grant.


## Cloud control-plane actions can move information

Data can cross an organizational boundary through cloud sharing, copying, or resource-transfer capabilities. The movement may occur within provider infrastructure rather than through an obvious large download to a workstation. Investigation should therefore include management and data-access records, destination account context, and permission changes where available.

A cloud destination is not automatically unauthorized. Organizations use approved backup accounts, partners, and cross-account workflows. Determine who owns the destination, why the transfer occurred, and whether its scope matches an approved purpose. A familiar provider domain alone does not establish that the receiving account is trusted.

## A fictional snapshot-sharing incident

An academy finds that a data snapshot was shared with an unfamiliar account. Analysts preserve the sharing event, initiating identity, resource identity, permission outcome, and subsequent access records. The share operation establishes a change in availability; evidence of copying or reading addresses what happened afterward. Those claims should remain distinct.

Revoking the share may prevent further access but cannot necessarily undo information already copied. The response must assess exposure, the initiating identity's access path, and other resources affected by the same authority. Recovery and notification decisions belong to the responsible incident, privacy, and business owners using the available evidence.

## Map a cross-account boundary

Draw a fictional production account, approved backup account, and unfamiliar destination. Mark which identities can share or copy a resource and which logs record the action. Explain how you would verify destination ownership and authorization. Use a paper exercise or harmless training data rather than sharing real records.

The exercise should include both permission and data consequences. A failed transfer request differs from a successful share, and a successful share differs from demonstrated retrieval. Accurate distinctions help responders avoid understating exposure or claiming a completed leak that the evidence does not yet establish.

## Related concepts

- [[packet-analysis]]
- [[exfiltration]]
- [[network-segmentation]]