Detect 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.
Response Playbook
Triage
- Extract the added AWS account ID from the ModifySnapshotAttribute/ModifyImageAttribute/ModifyDBSnapshotAttribute event and check it against the organization's AWS Organizations member-account list and any documented partner-sharing allow list.
- If the account ID is unrecognized, look it up (where legally permissible) via public AWS account attribution resources and check whether it has appeared in any prior abuse reports or threat intel feeds.
- Identify the IAM principal (userIdentity.arn) that made the ModifySnapshotAttribute/ModifyImageAttribute call and review its recent CloudTrail activity for other suspicious control-plane actions (new access keys created, IAM policy changes, unusual console logins from new geolocations).
- Search CloudTrail in the source account for a corresponding CreateSnapshot/CreateImage call in the hours prior, establishing what data was staged before being shared out.
- If possible, correlate against the destination account's activity (via a cross-account CloudTrail Lake query or a shared organizational trail) for a CopySnapshot/CopyImage call immediately following the permission grant — this confirms the transfer actually completed rather than the permission grant being an isolated, unexploited change.
- Determine what data resided on the shared resource (production database volume, application server root disk, backup volume) to scope exposure — a shared root/data volume from a database host should be treated as a full data breach of that dataset.
Containment
- Immediately revoke the added account ID from the snapshot/image/DB-snapshot permission list (ec2:ModifySnapshotAttribute --operation-type remove, or the RDS/AMI equivalent) to stop any in-progress or future CopySnapshot/CopyImage calls.
- Disable or rotate the IAM credentials (access key or role) that performed the sharing action, and review the credential's full permission set for other exfiltration-capable actions (S3 GetObject, Secrets Manager GetSecretValue).
- If the transfer is confirmed already completed (a CopySnapshot/CopyImage was observed from the destination account), treat the underlying dataset as fully disclosed and begin data-breach assessment procedures regardless of further containment.
- Review and tighten the account's Service Control Policy (SCP) or IAM permission boundary to deny ec2:ModifySnapshotAttribute / ec2:ModifyImageAttribute / rds:ModifyDBSnapshotAttribute to all but a small break-glass admin group.
- Hunt across all accounts in the AWS Organization for the same destination account ID or the same source IAM principal performing similar sharing actions, since a compromised credential is rarely used against only one resource.
Evidence Collection
- The full CloudTrail event for the ModifySnapshotAttribute/ModifyImageAttribute/ModifyDBSnapshotAttribute call, including requestParameters (added account IDs), sourceIPAddress, userIdentity, and userAgent.
- The preceding CreateSnapshot/CreateImage/CreateDBSnapshot event that produced the resource which was subsequently shared, to establish exactly what data was targeted.
- Any available CloudTrail activity from the destination account (via CloudTrail Lake, an Organizations-wide trail, or a legal request to the provider) showing the CopySnapshot/CopyImage call that completed the exfiltration.
- IAM credential report and recent access-key/console-login history for the principal that performed the sharing action.
- AWS Config resource-configuration history for the snapshot/AMI/DB-snapshot showing the permission change over time.
Escalation Criteria
- !The added account ID does not match any documented partner, DR, or Organizations member account — treat as a confirmed or attempted cross-account exfiltration event and escalate to incident response immediately.
- !A corresponding CopySnapshot/CopyImage call from the destination account is confirmed, meaning the transfer has already completed and a data breach has occurred.
- !The shared resource contains a production database volume, secrets, or regulated data (PII, PCI, PHI) — escalate to legal/compliance for breach-notification assessment regardless of whether the copy step is confirmed.
- !The same source IAM principal or destination account ID is observed performing this pattern against multiple resources or across multiple accounts in the Organization, indicating broad and likely automated abuse of compromised credentials.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
AWS CloudTrail management events for ModifySnapshotAttribute, ModifyImageAttribute, and ModifyDBSnapshotAttribute, including the full requestParameters showing added account IDs. - >
AWS Config resource configuration timeline for the affected snapshot/AMI/DB snapshot, showing the permission change and any prior/subsequent state. - >
CloudTrail CreateSnapshot/CreateImage/CreateDBSnapshot events establishing when and by whom the source resource was created. - >
Cross-account CopySnapshot/CopyImage CloudTrail events (visible only from the destination account or an Organizations-wide trail) confirming completed exfiltration. - >
IAM access analyzer findings flagging the resource as externally shared, if AWS IAM Access Analyzer is enabled for the account.
Tuning Guidance
Maintain KnownPartnerAccountIds (KQL) and the equivalent allow list (SPL) as the full set of AWS account IDs your organization has knowingly authorized for snapshot/AMI/DB-snapshot sharing — every AWS Organizations member account, every DR/backup account, and every contracted partner account. Without this allow list the detection will fire on routine, approved cross-account workflows and quickly get tuned out. Prioritize alerts where the shared resource originates from a production account or contains a database/root volume over sharing events on scratch/sandbox accounts. Where available, enable AWS IAM Access Analyzer organization-wide and treat its CreateFinding events for snapshot/AMI/S3 resources as a corroborating signal that raises confidence on top of the raw ModifySnapshotAttribute/ModifyImageAttribute detection.
Hunting Queries
Hunts for S3 bucket policy or ACL modifications that may grant read access to an external AWS account principal — the object-storage sibling of snapshot/image sharing, and a common secondary channel for T1537-style cross-account exfiltration.
// Hunt for S3 bucket policy/ACL changes granting access to a non-allow-listed external AWS account principal
AWSCloudTrail
| where TimeGenerated > ago(14d)
| where EventName in ("PutBucketPolicy", "PutBucketAcl")
| extend RequestParams = parse_json(RequestParameters)
| project TimeGenerated, EventName, UserIdentityAccountId, RequestParameters, SourceIpAddress, UserIdentityArn
| sort by TimeGenerated descindex=cloudtrail sourcetype="aws:cloudtrail" (eventName="PutBucketPolicy" OR eventName="PutBucketAcl")
| table _time, eventName, userIdentity.accountId, requestParameters, sourceIPAddress, userIdentity.arn
| sort - _timeHunts for AWS IAM Access Analyzer findings, which natively flag resources (snapshots, AMIs, S3 buckets, KMS keys) that have been shared outside the account or organization boundary — a high-confidence corroborating signal for any snapshot/image sharing event under investigation.
// Hunt for IAM Access Analyzer findings indicating a resource is shared outside the AWS account/organization
AWSCloudTrail
| where TimeGenerated > ago(14d)
| where EventSource == "access-analyzer.amazonaws.com" and EventName == "CreateFinding"
| project TimeGenerated, EventName, RequestParameters, RecipientAccountId
| sort by TimeGenerated descindex=cloudtrail sourcetype="aws:cloudtrail" eventSource="access-analyzer.amazonaws.com" eventName="CreateFinding"
| table _time, eventName, requestParameters, recipientAccountId
| sort - _timeAtomic Red Team Tests
Simulates the core T1537 sharing step by invoking the AWS CLI to add a synthetic external account ID to a test EBS snapshot's createVolumePermission list, validating that the ModifySnapshotAttribute CloudTrail event is captured and flagged by the detection.
Command
SNAPSHOT_ID="snap-atomictest0000000"
FAKE_EXTERNAL_ACCOUNT="123456789012"
aws ec2 modify-snapshot-attribute --snapshot-id "$SNAPSHOT_ID" --attribute createVolumePermission --operation-type add --user-ids "$FAKE_EXTERNAL_ACCOUNT" --region us-east-1 2>&1 || true
echo 'Atomic test complete: simulated ModifySnapshotAttribute cross-account share call issued'Cleanup
aws ec2 modify-snapshot-attribute --snapshot-id "snap-atomictest0000000" --attribute createVolumePermission --operation-type remove --user-ids "123456789012" --region us-east-1 2>/dev/null || trueExpected Telemetry
AWS CloudTrail ModifySnapshotAttribute event with requestParameters.userIds containing the synthetic external account ID, ingested into AWSCloudTrail (Sentinel) or index=cloudtrail sourcetype=aws:cloudtrail (Splunk).
Expected Detection
KQL/SPL detection flags the ModifySnapshotAttribute event because the added account ID is absent from KnownPartnerAccountIds / the approved allow list.
Simulates sharing a custom AMI to an external account by invoking ModifyImageAttribute with a synthetic account ID, validating detection coverage for the image-sharing variant of this technique.
Command
AMI_ID="ami-atomictest0000000"
FAKE_EXTERNAL_ACCOUNT="123456789012"
aws ec2 modify-image-attribute --image-id "$AMI_ID" --launch-permission "Add=[{UserId=$FAKE_EXTERNAL_ACCOUNT}]" --region us-east-1 2>&1 || true
echo 'Atomic test complete: simulated ModifyImageAttribute cross-account launch-permission grant issued'Cleanup
aws ec2 modify-image-attribute --image-id "ami-atomictest0000000" --launch-permission "Remove=[{UserId=123456789012}]" --region us-east-1 2>/dev/null || trueExpected Telemetry
AWS CloudTrail ModifyImageAttribute event with requestParameters.launchPermission.add containing the synthetic external account ID.
Expected Detection
KQL/SPL detection flags the ModifyImageAttribute event via the same added-account-ID logic used for snapshot sharing.
Simulates sharing an RDS DB snapshot to an external account via ModifyDBSnapshotAttribute, validating detection coverage for the database-snapshot variant of cross-account exfiltration.
Command
DB_SNAPSHOT_ID="atomictest-db-snapshot-0000"
FAKE_EXTERNAL_ACCOUNT="123456789012"
aws rds modify-db-snapshot-attribute --db-snapshot-identifier "$DB_SNAPSHOT_ID" --attribute-name restore --values-to-add "$FAKE_EXTERNAL_ACCOUNT" --region us-east-1 2>&1 || true
echo 'Atomic test complete: simulated ModifyDBSnapshotAttribute cross-account share call issued'Cleanup
aws rds modify-db-snapshot-attribute --db-snapshot-identifier "atomictest-db-snapshot-0000" --attribute-name restore --values-to-remove "123456789012" --region us-east-1 2>/dev/null || trueExpected Telemetry
AWS CloudTrail ModifyDBSnapshotAttribute event with requestParameters.valuesToAdd containing the synthetic external account ID.
Expected Detection
KQL/SPL detection flags the ModifyDBSnapshotAttribute event under the same shared EventName-based logic covering all three resource-sharing variants.
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.