Response playbooks, investigation guides, and Atomic Red Team tests are Pro-only. Upgrade to unlock the full detection package for THREAT-CloudSnapshot-CrossAccountExfil.
Upgrade to ProDetect Data Exfiltration via Cross-Account Cloud Snapshot/Image Sharing in Microsoft Sentinel
Adversaries with compromised cloud IAM credentials can exfiltrate entire volumes of data without ever moving a byte across a monitored network boundary by abusing native snapshot- and image-sharing primitives to hand a resource directly to an attacker-owned account on the same cloud provider. The canonical pattern (AWS): the operator calls ec2:ModifySnapshotAttribute or ec2:ModifyImageAttribute to add a foreign, attacker-controlled AWS account ID to the resource's launchPermission/createVolumePermission list, then — from that foreign account, using their own credentials — calls ec2:CopySnapshot or ec2:CopyImage to pull the shared EBS snapshot or AMI (and everything on the underlying disk: databases, secrets, source code, customer PII) into infrastructure the victim organization does not control and cannot subpoena. Because the transfer happens entirely inside the cloud provider's control plane and storage backend, it generates no NetFlow, no DNS query, no proxy log, and no EDR process telemetry — the only artifacts are cloud provider management-plane API calls (AWS CloudTrail, and the Azure/GCP equivalents: az snapshot grant-access issuing an cross-tenant SAS, or GCP disk/image IAM bindings adding an external principal). This is distinct from T1567.002 (Exfiltration to Cloud Storage, which moves data via an application-layer upload to a storage bucket/object endpoint) and from T1020 (Automated Exfiltration via a client tool like rclone, already covered elsewhere in this corpus): T1537 specifically covers using the provider's own account-to-account resource-sharing mechanism so the 'transfer' is really a permission grant plus a copy operation the victim's own logging often is never configured to alert on. RDS snapshot sharing (rds:ModifyDBSnapshotAttribute) and S3 cross-account bucket policy/ACL grants follow the identical pattern and are covered as secondary hunting signals below. The technique is a documented step in several cloud-native ransomware and data-theft intrusions (Scattered Spider AWS incidents, multiple Mandiant/Permiso cloud IR cases) precisely because it evades tooling built to watch egress traffic rather than the control plane.
MITRE ATT&CK
- Tactic
- Exfiltration
KQL Detection Query
let LookbackWindow = 24h;
let KnownPartnerAccountIds = dynamic([]); // Populate with your org's approved external AWS account IDs (DR, partner sharing, etc.)
AWSCloudTrail
| where TimeGenerated > ago(LookbackWindow)
| where EventName in ("ModifySnapshotAttribute", "ModifyImageAttribute", "ModifyDBSnapshotAttribute")
| extend RequestParams = parse_json(RequestParameters)
| extend AddedAccountIds = RequestParams.userIds
| mv-expand AddedAccount = AddedAccountIds
| where isnotempty(AddedAccount) and AddedAccount !in (KnownPartnerAccountIds)
| project TimeGenerated, EventName, UserIdentityAccountId, RecipientAccountId, AddedAccount, SourceIpAddress, UserIdentityArn, RequestParameters
| sort by TimeGenerated descDetects AWS API calls that add an external (non-allow-listed) AWS account ID to the share/launch permission list of an EBS snapshot, AMI, or RDS DB snapshot via AWSCloudTrail management events ingested into Sentinel through the AWS connector. Any AddedAccount value outside KnownPartnerAccountIds indicates a resource was made accessible to an account the organization does not control, the precursor step to cross-account CopySnapshot/CopyImage exfiltration.
Data Sources
Required Tables
False Positives & Tuning
- Approved disaster-recovery or backup replication jobs that intentionally share snapshots with a secondary AWS account owned by the same organization but not yet in KnownPartnerAccountIds
- Managed service provider or partner integrations that legitimately consume shared AMIs/snapshots as part of a contracted data pipeline
- Internal platform teams migrating workloads between AWS Organization member accounts using snapshot sharing rather than an Organizations-native transfer mechanism
- Security tooling vendors that require snapshot access to a scanning account for agentless vulnerability assessment
Other platforms for THREAT-CloudSnapshot-CrossAccountExfil
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulated EBS Snapshot Cross-Account Share
Expected signal: AWS CloudTrail ModifySnapshotAttribute event with requestParameters.userIds containing the synthetic external account ID, ingested into AWSCloudTrail (Sentinel) or index=cloudtrail sourcetype=aws:cloudtrail (Splunk).
- Test 2Simulated AMI Cross-Account Launch Permission Grant
Expected signal: AWS CloudTrail ModifyImageAttribute event with requestParameters.launchPermission.add containing the synthetic external account ID.
- Test 3Simulated RDS Snapshot Cross-Account Share
Expected signal: AWS CloudTrail ModifyDBSnapshotAttribute event with requestParameters.valuesToAdd containing the synthetic external account ID.
Unlock playbooks & atomic tests with Pro
Get the full detection package for THREAT-CloudSnapshot-CrossAccountExfil — response playbook and atomic red team tests, plus investigation guidance and hunting queries.
df00tech Pro — £29/user/month
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.