Detect Cloud-Native Data Exfiltration via Cross-Account Resource Sharing in Sumo Logic CSE
Adversaries with cloud administrative access can exfiltrate data without ever touching an endpoint agent or crossing a monitored network egress point, by using the cloud provider's own control plane to grant an attacker-controlled account read access to victim data. Common patterns include modifying an S3 bucket policy or ACL to grant access to an external AWS account (or to 'AllUsers'), sharing an EBS or RDS snapshot with an external account ID via ModifySnapshotAttribute/ModifyDBSnapshotAttribute, and granting AMI launch permissions to an external account via ModifyImageAttribute. Because the resulting data transfer happens entirely within the cloud provider's backbone between the victim account and the attacker's own account, it never appears in DeviceNetworkEvents, proxy logs, or DLP tooling — the only telemetry is the management-plane API call itself, recorded in AWS CloudTrail (or the equivalent Azure Activity Log / GCP Admin Activity log). Scattered Spider has been observed enumerating and exporting cloud snapshots and VM images during intrusions to stage data outside victim-controlled infrastructure; LAPSUS$ operators have similarly abused overly permissive cloud IAM access to copy source repositories and storage buckets to attacker-owned tenants. Detection must live in cloud audit-log telemetry rather than host or network telemetry, and hinges on distinguishing grants to known organizational account IDs (legitimate cross-account architectures, DR replication) from grants to unrecognized account IDs or public principals.
MITRE ATT&CK
- Tactic
- Exfiltration
Sumo Detection Query
_sourceCategory="aws/cloudtrail"
(eventSource="s3.amazonaws.com" and (eventName="PutBucketPolicy" or eventName="PutBucketAcl"))
or (eventSource in ("ec2.amazonaws.com","rds.amazonaws.com") and (eventName="ModifySnapshotAttribute" or eventName="ModifyDBSnapshotAttribute" or eventName="ModifyImageAttribute"))
| json field=_raw "requestParameters" as requestParametersRaw nodrop
| where requestParametersRaw matches "*\"Principal\":\"*\"*"
or requestParametersRaw matches "*AllUsers*"
or requestParametersRaw matches "*\"group\":\"all\"*"
or (requestParametersRaw matches "*arn:aws:iam::*" and !(requestParametersRaw matches "*<YOUR_ORG_ACCOUNT_ID>*"))
| eval ThreatType = if(eventName="PutBucketPolicy" or eventName="PutBucketAcl", "S3_CrossAccount_PolicyExposure",
if(eventName="ModifyImageAttribute", "AMI_CrossAccount_Share",
if(eventName="ModifyDBSnapshotAttribute", "RDSSnapshot_CrossAccount_Share", "EBSSnapshot_CrossAccount_Share")))
| eval RiskScore = if(requestParametersRaw matches "*AllUsers*" or requestParametersRaw matches "*\"Principal\":\"*\"*", 95, 80)
| stats count as Events, max(RiskScore) as MaxRisk by eventName, userIdentity.arn, sourceIPAddress, recipientAccountId, ThreatType
| sort by MaxRisk descSumo Logic Cloud SIEM search over AWS CloudTrail events, identifying S3 bucket policy/ACL exposure and EBS/RDS snapshot or AMI permission grants to public groups or external account IDs. Extracts the requestParameters JSON payload and flags grants that reference an account ID outside the organization's known allowlist.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate cross-account DR/replication targeting a sibling account not yet reflected in the organization account allowlist — maintain the allowlist as a Sumo Logic lookup table synced from AWS Organizations
- Terraform/CloudFormation automation roles performing scheduled, approved bucket policy updates — exclude by userIdentity.arn matching known IaC service role ARNs
Other platforms for THREAT-CloudControlPlane-CrossAccountExfil
Testing Methodology
Validate this detection against 1 adversary technique 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 1Simulate S3 Bucket Policy Exposure to External Account
Expected signal: AWS CloudTrail management event: eventName=PutBucketPolicy, eventSource=s3.amazonaws.com, requestParameters containing the external account ARN 999999999999 and Principal grant.
Response Playbook
Triage
- Identify the calling identity (UserIdentityArn / userIdentity.arn): is this a human IAM user, a role assumed via SSO, or a CI/CD service role? An interactive human identity making this call outside change windows is the highest-priority scenario.
- Decode the RequestParameters/requestParameters payload to determine exactly what was shared and with whom: the target bucket/snapshot/AMI ID and the granted principal or account ID.
- Check whether the granted account ID appears anywhere in AWS Organizations, existing IAM cross-account trust policies, or documented DR/replication runbooks. If it does not appear anywhere, treat it as attacker-controlled until proven otherwise.
- Correlate the SourceIpAddress/sourceIPAddress and calling identity against recent authentication events (console login, AssumeRole, access key creation) to establish whether the identity itself was recently compromised.
- For snapshot/AMI shares, check whether the identity also called CreateSnapshot/CreateImage/CopySnapshot shortly beforehand — this indicates the attacker staged the resource before sharing it out.
Containment
- Immediately revert the exposure: remove the added principal/account from the S3 bucket policy or ACL, or call ModifySnapshotAttribute/ModifyDBSnapshotAttribute/ModifyImageAttribute with an Add/Remove operation to revoke the external account's access.
- Disable or rotate the credentials of the identity that made the call (IAM access keys, or force re-authentication of the assumed role/session).
- If the granted account ID is confirmed attacker-controlled, treat any data in the affected bucket/snapshot/AMI as exfiltrated — the provider's internal network does not log or allow retroactive blocking of the read that already occurred.
- Review and tighten the IAM policy or SCP that allowed this identity to call PutBucketPolicy/PutBucketAcl/ModifySnapshotAttribute/ModifyDBSnapshotAttribute/ModifyImageAttribute in the first place — least-privilege should restrict these actions to a small break-glass role.
- Notify the data protection officer/legal team if the exposed bucket, snapshot, or AMI contained personal or regulated data — breach notification obligations may apply.
Evidence Collection
- Full CloudTrail record for the PutBucketPolicy/PutBucketAcl/ModifySnapshotAttribute/ModifyDBSnapshotAttribute/ModifyImageAttribute event, including RequestParameters and ResponseElements
- CloudTrail history for the calling identity over the preceding 24-48 hours (console login, AssumeRole, CreateSnapshot/CreateImage, ListBuckets/GetBucketPolicy reconnaissance calls)
- S3 Server Access Logs or S3 Data Events (if enabled) showing whether the external account actually read objects from the bucket after the policy change
- AWS Config configuration history for the affected bucket/snapshot/AMI showing the before/after permission state
- IAM policy and SCP evaluation showing how the calling identity obtained permission to modify resource-sharing settings
Escalation Criteria
- !The granted account ID does not match any known organizational account, documented partner account, or DR target
- !Data Events or S3 access logs confirm the external account actually read/downloaded objects after the grant
- !The calling identity's credentials show signs of prior compromise (impossible travel, MFA fatigue, unfamiliar sign-in properties)
- !The affected bucket/snapshot/AMI is known to contain source code, customer data, credentials, or other sensitive material
- !Multiple resources across different services (S3, EBS, RDS, AMI) were shared externally by the same identity within a short window — indicates a scripted, campaign-level exfiltration rather than a one-off misconfiguration
Investigation Guide
Related Techniques
Forensic Artifacts
- >
CloudTrail event record: full RequestParameters JSON showing the exact policy statement or permission grant added - >
AWS Config resource configuration timeline: bucket policy/ACL or snapshot/AMI permission state before and after the change - >
IAM credential report and access key last-used data for the calling identity - >
CloudTrail data events (if S3 Data Events logging was enabled) showing GetObject calls from the external account after the grant - >
VPC Flow Logs or Access Analyzer findings flagging the resource as externally accessible
Tuning Guidance
The single highest-value control is maintaining an accurate, automatically-synced KnownOrgAccountIds/organization-account allowlist (pull live from the AWS Organizations ListAccounts API rather than a hand-maintained list) so legitimate multi-account architectures do not drown out true positives. Enable S3 Server Access Logging or CloudTrail Data Events on sensitive buckets so an alert on policy exposure can be immediately corroborated with 'was the bucket actually read afterward.' Treat any PutBucketPolicy/PutBucketAcl/ModifySnapshotAttribute/ModifyDBSnapshotAttribute/ModifyImageAttribute call made by a human console identity (rather than a recognized CI/CD or IaC service role) as high priority regardless of the destination account, since legitimate sharing is almost always automated through Terraform/CloudFormation. Consider requiring AWS Access Analyzer's external-access findings as a secondary confirmation signal to reduce noise from transient or already-remediated exposures.
Hunting Queries
Baseline hunt over the past 30 days for any resource-sharing API calls that reference an external account ID or a public group, to establish which identities and account IDs routinely perform legitimate cross-account sharing versus which appear only once (higher suspicion).
AWSCloudTrail
| where TimeGenerated > ago(30d)
| where EventName in ("PutBucketPolicy", "PutBucketAcl", "ModifySnapshotAttribute", "ModifyDBSnapshotAttribute", "ModifyImageAttribute")
| extend ParamsText = tostring(RequestParameters)
| where ParamsText matches regex @"arn:aws:iam::\d{12}:" or ParamsText has_any ("AllUsers", "\"group\":\"all\"")
| summarize Calls=count(), Events=make_set(EventName) by UserIdentityArn, RecipientAccountId
| sort by Calls descindex=aws sourcetype="aws:cloudtrail" (eventName=PutBucketPolicy OR eventName=PutBucketAcl OR eventName=ModifySnapshotAttribute OR eventName=ModifyDBSnapshotAttribute OR eventName=ModifyImageAttribute)
| eval RequestParams=requestParameters
| where match(RequestParams, "arn:aws:iam::[0-9]{12}:") OR match(RequestParams, "(?i)(allusers|\"group\":\"all\")")
| stats count AS Calls, values(eventName) AS Events BY userIdentity.arn, recipientAccountId
| sort - CallsAtomic Red Team Tests
Applies a bucket policy granting GetObject/ListBucket access to a non-organizational AWS account ID, simulating the cross-account exposure technique used to stage data for later retrieval by an attacker-controlled account. Use a disposable test bucket and a throwaway sandbox account ID, never a production bucket.
Command
aws s3api put-bucket-policy --bucket df00tech-atomic-test-bucket --policy '{"Version":"2012-10-17","Statement":[{"Sid":"AtomicTestExternalAccess","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::999999999999:root"},"Action":["s3:GetObject","s3:ListBucket"],"Resource":["arn:aws:s3:::df00tech-atomic-test-bucket","arn:aws:s3:::df00tech-atomic-test-bucket/*"]}]}'Cleanup
aws s3api delete-bucket-policy --bucket df00tech-atomic-test-bucketExpected Telemetry
AWS CloudTrail management event: eventName=PutBucketPolicy, eventSource=s3.amazonaws.com, requestParameters containing the external account ARN 999999999999 and Principal grant.
Expected Detection
Alert fires on S3_CrossAccount_PolicyExposure (RiskScore=85) because account 999999999999 is absent from the KnownOrgAccountIds allowlist.
Related Detections
Tactic Hub
Detection Variants (1)
Different telemetry and tradecraft for the same technique — pick the one that matches the data you collect.