Transfer Data to Cloud Account

This technique sits near the end of a cloud intrusion. The attacker needed valid credentials first, usually through phished SSO, a leaked access key in a public repository, or an over-permissioned instance role reached via SSRF, then enumerated the environment to find snapshots or buckets worth taking. AWS's own incident response guidance and multiple published breach post-mortems describe this exact pattern: reconnaissance with tools like Pacu or manual API calls, followed by ModifySnapshotAttribute or PutBucketReplication once the target data is identified, because it avoids downloading gigabytes through a monitored egress path.

It is functionally an alternative to T1567.002 (Exfiltration to Cloud Storage over a web service) rather than a strict predecessor or successor; both achieve the same outcome of getting data out of your control, but T1537 does it through the provider's own account boundary instead of an external HTTP upload, which is exactly why it evades network-layer DLP and web proxies. What typically follows, if the attacker completes the copy, is quiet: the shared snapshot or replicated bucket sits in the destination account until it is pulled down at the attacker's convenience, sometimes days later, which is also why the sharing event itself, not a suspected download, is the most reliable place to catch this.

Cross-account snapshot sharing and S3 replication are both legitimate, common patterns in mature AWS estates. Backup and disaster-recovery tooling regularly shares AMIs and snapshots into a dedicated backup account, DevOps teams replicate buckets between dev, staging, and prod accounts, and managed-service providers share snapshots with a customer's separate billing account for cost allocation. A rule that fires on every ModifySnapshotAttribute or PutBucketReplication call will be dominated by this traffic within the first day.

The fix is an account allow-list, not a suppression of the rule. Maintain the list of account IDs your organization legitimately shares into (backup account, DR account, known partner accounts) and alert only when the destination account is absent from it; that single change turns a noisy rule into a high-precision one. Layer in the caller's role: a scheduled backup Lambda or a named DR automation role sharing to its expected destination is routine, while an interactive user session or an unfamiliar role performing the same action, especially outside business hours or from an unusual source IP, deserves scrutiny even if the destination account happens to be on the allow-list, since credential theft can be used to replay a legitimate-looking share.

When this fires, first identify the destination account: is it on your organization's known-account list, and if so, does this caller normally share into it? Pull the identity that made the call, its recent CloudTrail history, and whether it has touched snapshot or replication permissions before. If the account is unrecognized, or the caller is not the expected backup or DR automation, treat this as active exfiltration, not a configuration drift, because the permission grant alone is often the only signal you get before the data is copied out from the other side.

If the destination account is unrecognized, act on the source side immediately: revert the permission change (remove the account from CREATE_VOLUME_PERMISSION or disable the replication rule), rotate the credentials or role trust policy that made the call, and check for other sharing events from the same identity in the surrounding hours, since attackers rarely share only one asset. Identify what the snapshot or bucket actually contained, since that scopes the breach notification and determines urgency. If you have visibility into the destination account (a sibling account you also monitor), check for CopySnapshot, volume creation, or object-copy activity there to confirm whether the transfer completed or was caught at the permission stage.