When an attacker shares a disk snapshot or a bucket with their own account on the same cloud provider, the data never crosses your network edge, so egress monitoring and data loss prevention on the perimeter see nothing at all. MITRE ATT&CK T1537 Transfer Data to Cloud Account covers exfiltration by transferring data, including through sharing, syncing and backups, to another cloud account the adversary controls on the same service. In ATT&CK v20 it sits in the Exfiltration tactic (TA0010) and applies to IaaS, SaaS and Office Suite platforms. Usage counts are low compared with other exfiltration methods, but almost every case is carried out by a cloud identity, often a role or service principal, with sharing permissions it did not need. This guide covers the sharing mechanisms defenders must watch, the control-plane events that reveal them, and the guardrails that stop them. It is for cloud security, detection engineering and platform teams. For exfiltration in general see the Data Exfiltration Guide.
Key takeaways
- The transfer is a permission change. Sharing a snapshot, image or bucket with another account is a single control-plane API call, logged by default, which makes T1537 more detectable than many people assume.
- Allow-list your own accounts. Any share to an account ID outside your organisation is the core alert; everything else is tuning.
- Encryption with customer keys adds a second gate. AWS only allows encrypted snapshots to be shared if the customer managed KMS key is shared too, so key policy changes are an early warning.
- SaaS sharing is the same technique. Anonymous links, guest invitations and Azure SAS URIs move data to accounts you do not control without a download.
- Guardrails beat detection. Organisation-wide policies that deny sharing outside the organisation remove most of the technique before anyone needs to respond.
How the attack works
ATT&CK explains why this works: a defender watching for large transfers out of the environment may not be watching for transfers to another account inside the same provider, and such transfers use provider APIs and the provider's internal address space. The mechanisms defenders should know:
| Mechanism | Provider API or setting | What the adversary gains |
|---|---|---|
| EBS snapshot sharing | ModifySnapshotAttribute, attribute createVolumePermission, adding account IDs or the group all | Recipients create their own volumes; AWS warns that sharing gives access to all data on the snapshot |
| RDS snapshot sharing | ModifyDBSnapshotAttribute, attribute restore, up to 20 accounts or all for unencrypted snapshots | A full copy of the database restored in the attacker's account |
| Machine image sharing | ModifyImageAttribute, launchPermission | Instances, disks and any secrets baked into the image |
| Bucket policy or replication | PutBucketPolicy granting an external principal; replication rules to another account | Ongoing read or a continuous copy of new objects |
| Storage keys and signed URIs | Azure listKeys, account or service SAS, AzCopy | Direct copy into attacker-held storage |
| SaaS sharing | SharePoint and OneDrive Anyone links and guest sharing; Google Drive permission add; Box collaboration invites | Files readable by an external tenant or anyone with the link |
| Backups | Instance or volume backups copied to another account | ATT&CK notes incidents where backups of cloud instances were transferred to separate accounts |
The data often comes from the stores described in the T1530 Data from Cloud Storage Defensive Guide, and attackers sometimes create the snapshot first, which ATT&CK tracks as T1578.001 Create Snapshot.
Where it shows up
- Cloud-native ransomware and extortion: ATT&CK records Storm-0501 copying data to its own infrastructure with the AzCopy CLI. Microsoft's August 2025 report describes the group enabling public access on storage accounts that were not internet-reachable, using its Owner role to list and steal storage keys, then copying data out before mass-deleting snapshots, restore points and storage accounts.
- Ransomware using cloud sync: ATT&CK records INC Ransom using MEGAsync and RedCurl using megatools to move data to the MEGA storage service. These are transfers to an attacker cloud account rather than the same provider, which shows how the boundary with web service channels blurs.
- Insiders and departing staff: personal accounts on the same SaaS platform are the simplest destination for an external share.
Impact
A shared snapshot or database copy is a complete, point-in-time copy of everything on that resource, including credentials, configuration files and customer records. Once the recipient has copied it, revoking the share does not recover the data. The transfer also tends to precede destructive actions: in the Storm-0501 activity, exfiltration was followed by deletion of backups and encryption with attacker-controlled keys. See the Cloud Ransomware Guide.
Detection
The ATT&CK v20 detection strategy for T1537 has three analytics: IaaS snapshot sharing, backup exports and bucket policy updates to other identities; Office Suite external sharing and anonymous links; and SaaS sharing to external tenants. Concretely:
| Source | Event | Alert when |
|---|---|---|
| AWS CloudTrail (management events) | ModifySnapshotAttribute, ModifyDBSnapshotAttribute, ModifyDBClusterSnapshotAttribute, ModifyImageAttribute | An account ID added that is not in your organisation, or the group all |
| AWS CloudTrail | PutBucketPolicy, PutBucketReplication, PutBucketAcl | The new policy or rule names an external principal or destination account |
| AWS CloudTrail (KMS) | PutKeyPolicy, CreateGrant | An external account gains use of a customer managed key that protects snapshots |
| AWS CloudTrail | CreateSnapshot, CopySnapshot, CopyDBSnapshot | Snapshot creation by an identity that does not normally take backups, especially followed by a share |
| Azure activity log and StorageBlobLogs | Microsoft.Storage/storageAccounts/listkeys/action, storageAccounts/write enabling public access; AzCopy user agents | Key listing or exposure changes by unusual principals; bulk copy from unfamiliar IPs |
| Microsoft 365 unified audit log | SharingSet, AnonymousLinkCreated, FileAccessed | Many files shared externally in a short window, or links created on sensitive sites |
| Google Workspace and Box | drive.permission.add, collaboration.invite | Ownership transfer or sharing of critical data to external domains |
- External access analysis: IAM Access Analyzer reports resources shared outside your zone of trust; review its findings for snapshots, buckets and keys. See the IAM Access Analyzer Guide.
- Recipient-side clues: CloudTrail records
SharedSnapshotCopyInitiatedandSharedSnapshotVolumeCreatedwhen shared snapshots are copied or used, which tells you a share was acted on. - Identity context: raise severity when the caller is a role or service principal that has never called a sharing API before. See the Detection Engineering for Non-Human Identities Guide.
Metrics
- External shares: number of snapshots, images, buckets and keys shared outside the organisation, each with an approved owner, trending down.
- Guardrail coverage: share of accounts and regions covered by organisation-level sharing restrictions.
- Sharing permission spread: count of principals allowed to call sharing APIs.
- Anyone links: count of active unauthenticated SaaS links on sensitive sites, and the share with an expiry.
- Time to revoke: minutes from an external-share alert to removal of the permission.
Prevention and hardening
- Least privilege on sharing actions (M1018): very few identities need
ec2:ModifySnapshotAttribute,rds:ModifyDBSnapshotAttribute,ec2:ModifyImageAttributeors3:PutBucketPolicy. Remove them from workload roles and broad admin groups. See the AWS IAM Policies and Roles Guide. - Build a data perimeter (M1037): AWS resource control policies set the maximum permissions on resources in member accounts for any principal, including external accounts, and cannot be bypassed by a resource policy. A deny on requests where
aws:PrincipalOrgIDis not your organisation keeps S3, KMS and other supported resources inside it; service control policies cover the outbound side. AWS recommends testing in a few accounts and reviewing Access Denied errors before attaching to the root. - Block public sharing: enable block public access for EBS snapshots in every region (the "block all sharing" mode also makes existing public snapshots private) and the separate setting for AMIs. Note that the EBS setting does not prevent private sharing with specific accounts, so it complements the perimeter rather than replacing it.
- Encrypt with customer managed keys (M1041): snapshots encrypted with the AWS managed default key cannot be shared, and customer managed key sharing requires a key policy change you can restrict and alert on.
- Restrict SaaS sharing (M1054): in SharePoint and OneDrive choose "Existing guests" or "Only people in your organization" for sensitive sites, limit sharing by domain, and require Anyone links to expire and be view-only.
- Retire storage account keys (M1018): set Azure
AllowSharedKeyAccessto false so key listing gives nothing usable, and protect backups with immutability, resource locks and Key Vault purge protection, as Microsoft recommends after Storm-0501. - Data loss prevention (M1057): DLP policies can prevent sensitive files being shared with people outside the organisation.
Choosing controls
| Situation | Best first control | Trade-off |
|---|---|---|
| AWS Organizations in use | RCP and SCP data perimeter plus EBS and AMI public access blocks | Legitimate partner shares need explicit exceptions |
| Single account or no organisation | Remove sharing permissions from roles, alert on every sharing call | Relies on detection speed rather than prevention |
| Azure-centred estate | Disable Shared Key, deny public access by policy, Defender for Storage alerts | Legacy clients using keys must migrate first |
| Microsoft 365 or Google Workspace heavy | Tenant sharing level, domain allow lists, link expiry, DLP | Collaboration friction with external partners |
Phased rollout
- Inventory current shares: list every snapshot, image, database snapshot, bucket and key shared outside the organisation and confirm an owner for each.
- Alert first: deploy the CloudTrail and SaaS audit rules above with an allow list of your account IDs and approved partners.
- Pilot guardrails: attach the perimeter policies to a test organisational unit, watch for Access Denied events for two to four weeks.
- Enforce broadly: attach to production units and enable public sharing blocks in every region. Rollback is detaching the policy from one unit, not deleting it.
- Exercise: in an authorised test, share a test snapshot with a non-organisation account and confirm the deny or the alert and revocation path.
Where identity fits
T1537 is executed by cloud identities: an IAM role, an access key, a service principal or a SaaS user token with permission to change sharing. The strongest defence is making sure no non-human identity holds sharing or key-listing permissions it does not use, and that every one has an owner who would notice. See the OWASP NHI Top 10 NHI5 Overprivileged NHI Guide and the Cloud PAM and CIEM Guide.
Lessons from incidents
- Exposure changes come first: in the Storm-0501 hybrid cloud attacks the group reached the tenant through stolen Entra Connect Sync credentials; Microsoft's later report shows it then changed storage settings and listed keys before copying data out, so alerting on those changes buys time.
- Revocation is not recovery: once a shared snapshot has been copied, the data is gone; prevention guardrails matter more here than for most techniques.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK mitigations | M1057 Data Loss Prevention, M1018 User Account Management, M1054 Software Configuration, M1037 Filter Network Traffic |
| NIST SP 800-53 Rev. 5 | AC-21 Information Sharing, AC-6 Least Privilege, AC-3 Access Enforcement, AU-6 Audit Record Review, Analysis, and Reporting |
| NIST CSF 2.0 | PR.DS-01 (data at rest protected), PR.AA-05 (least privilege), DE.CM-03 (technology usage monitored), DE.AE-02 (adverse events analysed) |
| CIS Controls v8.1 | Control 3 Data Protection, Control 6 Access Control Management, Control 8 Audit Log Management |
| MITRE D3FEND | D3-RAPA Resource Access Pattern Analysis, D3-NRAM Network Resource Access Mediation, D3-CRO Credential Rotation |
Practitioner checklist
- List every resource shared outside your organisation and remove those without an owner.
- Alert on snapshot, image, database snapshot, bucket policy, replication and KMS key policy changes that name external accounts.
- Remove sharing APIs from workload roles and default admin groups.
- Deploy a data perimeter with resource and service control policies, tested in audit units first.
- Enable block public access for EBS snapshots and AMIs in every region.
- Encrypt snapshots with customer managed keys and restrict key policy changes.
- Set SaaS sharing levels, domain allow lists and expiring view-only Anyone links.
- Disable Azure Shared Key access and protect backups with immutability and purge protection.
Standards and references
- MITRE ATT&CK: Transfer Data to Cloud Account (T1537)
- AWS: Share an Amazon EBS snapshot
- AWS: Block public access for Amazon EBS snapshots
- AWS: Sharing a DB snapshot for Amazon RDS
- AWS: Resource control policies (RCPs)
- Microsoft Learn: Manage sharing settings for SharePoint and OneDrive
- Microsoft Security Blog: Storm-0501's evolving techniques lead to cloud-based ransomware
- AWS: Understand shared AMI usage
Related NHI Mgmt Group resources: Data Exfiltration Guide · Data Exfiltration Playbook · AWS Multi-Account Security Reference Architecture Guide · Cloud Incident Response Guide · T1530 Data from Cloud Storage Defensive Guide