CanExfiltrate

Redirecting an existing flow's destination to an attacker-controlled endpoint and triggering the flow exfiltrates the SaaS data it reads (Salesforce records, Zendesk tickets, Slack messages, etc.).

Creating a new AppFlow flow that references an existing connector profile and points to an attacker-controlled destination exfiltrates SaaS data without modifying any existing flow.

backup:StartCopyJob copies individual recovery points from a backup vault to a vault in a different AWS account, enabling complete data exfiltration by restoring the copied backups in the attacker's account.

A principal that can copy/share/restore a cluster backup duplicates the encrypted key material out of the source cluster.

rds:ModifyDBClusterSnapshotAttribute allows a principal to make a DocumentDB cluster snapshot shareable (publicly if ValuesToAdd=['all'], or to a specific account if ValuesToAdd=[<account-id>]). Any restoring account can then call rds:RestoreDBClusterFromSnapshot to exfiltrate a full database copy.

rds:CopyDBClusterSnapshot + rds:ModifyDBClusterSnapshotAttribute together enable exfiltration of automated DocumentDB cluster snapshots: copy an automated snapshot to manual, then share the manual copy cross-account or publicly.

dynamodb:ExportTableToPointInTime (requires PITR enabled) writes a complete table snapshot to a caller-specified S3 bucket - full table exfiltration in one API call.

dynamodb:UpdateContinuousBackups (enable PITR) + dynamodb:ExportTableToPointInTime yields full-table exfiltration even if PITR is currently disabled - two-step escalation.

CreateSnapshot + ModifySnapshotAttribute(add=<external account>) lets an attacker ship a full disk image to an account they control. The rule matches on the CanWrite capability on a volume and confirms effective IAM permissions for both snapshot creation and cross-account sharing.

ModifySnapshotAttribute on an existing snapshot to add a cross-account createVolumePermission entry - data exfiltration without CreateSnapshot.

ec2:CopySnapshot called from an attacker account (on a shared snapshot) or with a destination in another account copies snapshot data cross-boundary.

EBS direct API read on a cross-account shared snapshot constitutes data exfiltration: the caller reads another account's disk data from their own account without ever launching an EC2 instance in the source account. This rule chains CanReadData on a cross-account snapshot into CanExfiltrate.

elasticache:CreateSnapshot combined with elasticache:CopySnapshot allows creating a fresh Redis RDB snapshot from a running cache and immediately exporting it to an attacker-controlled S3 bucket. The RDB file is a complete serialized dump of all in-memory data at snapshot time, bypassing the need for scheduled snapshots. No live cluster access needed.

elasticache:CopySnapshot copies an existing Redis RDB snapshot to an S3 bucket. If the destination bucket is attacker-accessible, the RDB file - containing all cached in-memory data including application secrets - is exfiltrated. No live cluster access needed.

An EMR cluster whose instance profile has s3:PutObject on an attacker-controlled S3 bucket can exfiltrate data via Spark df.write or Hive INSERT OVERWRITE DIRECTORY.

An identity with fsx:CopyBackup on a source backup ARN in a foreign account can pull a complete copy into an attacker-controlled account; restoring via CreateFileSystemFromBackup gives full read of all data at backup time.

An identity with fsx:CreateDataRepositoryTask on an FSx for Lustre file system with a Data Repository Association (DRA) pointing to an attacker-accessible S3 bucket can trigger a data export from the Lustre FS to S3, exfiltrating all file data.

A principal who can read LF-governed table data (via Athena/Glue/EMR/Redshift Spectrum) and can write query output to an external S3 destination (UNLOAD / Glue job target / EMR write) can exfiltrate the governed data out of the account's LF-controlled boundary.

Standing up an instance from someone else's snapshot exposes the snapshot's on-disk contents within the account.

memorydb:CopySnapshot exports cluster snapshot to S3; attacker-accessible bucket yields full data exfiltration.

Neptune cluster snapshot with public restore attribute (restore=all) is immediately exfiltrable by any AWS account via RestoreDBClusterFromSnapshot.

Principal with rds:ModifyDBClusterSnapshotAttribute permission on a Neptune cluster snapshot can share it cross-account or make it publicly restorable, enabling full graph data exfiltration.

A principal with data-plane read access to an internet-exposed or reachable OpenSearch domain can exfiltrate search indices.

qldb:ExportJournalToS3 + iam:PassRole (for a role with s3:PutObject) allows the caller to exfiltrate the entire QLDB journal - all committed document revisions across all tables - to an S3 bucket, including cross-account buckets.

qldb:StreamJournalToKinesis + iam:PassRole (for a role with kinesis:PutRecord) allows the caller to continuously stream the entire QLDB journal - all committed document revisions across all tables - to a Kinesis Data Stream, including cross-account streams.

rds:ModifyDBSnapshotAttribute(AttributeName=restore, ValuesToAdd=[all]) makes a DB snapshot publicly restorable by any AWS account - full database exfiltration with no network access required.

A principal with query execution on a Redshift cluster can run UNLOAD using an attached IAM role that has s3:PutObject, exfiltrating warehouse data to an S3 location.

redshift:AuthorizeSnapshotAccess grants another AWS account the ability to restore a cluster snapshot, exfiltrating a full copy of warehouse data to that account.

redshift-serverless:UpdateSnapshot allows sharing a Redshift Serverless snapshot with another AWS account, enabling full data exfiltration via restore.

s3:ListBucket + s3:GetObject on a bucket enables enumeration and download of all objects - a complete bucket exfiltration.

s3:PutReplicationConfiguration sets up continuous S3 Replication to an external/attacker-controlled destination bucket, establishing a persistent data exfiltration channel.

Account key (from listKeys) grants full data-plane read and SAS generation - enabling complete data exfiltration.

listKeys/action returns full master keys enabling complete data exfiltration (read/write/delete all items across all databases and containers).

listConnectionStrings/action returns connection strings embedding full master keys - equivalent complete data exfiltration as listKeys.

Read-only keys (from readonlykeys/action) enable read-only data exfiltration across all databases and containers.

Creating a Delta Sharing share with OPEN recipients produces publicly downloadable signed URLs for the shared data, enabling unauthenticated data exfiltration.

ADF Copy activity configured with an external or cross-boundary sink (HTTP, public blob, SFTP) can move data outside the authorized boundary.

beginGetAccess/action on a disk with AllowAll (default) network access policy mints an internet-routable anonymous SAS download URL for the full VHD.

beginGetAccess/action on a disk with AllowPrivate network access policy mints a SAS download URL accessible only via the private endpoint.

beginGetAccess/action on a snapshot with AllowAll (default) network access policy mints an internet-routable anonymous SAS download URL.

beginGetAccess/action on a snapshot with AllowPrivate network access policy or publicNetworkAccess: Disabled mints a SAS URL accessible only via private endpoint.

snapshots/write permission enables snapshot creation/restore, allowing within-subscription data exfiltration.

Admin read access to the database (CanReadData) enables full exfiltration via pg_dump (PostgreSQL) or mysqldump (MySQL).

databases/export/action exports the full DB as a BACPAC to a caller-specified storage URL, enabling complete data exfiltration outside the tenant.

backupLongTermRetentionPolicies/write allows redirecting SQL MI database backups to an attacker-controlled storage account, enabling full database exfiltration outside the tenant.

CREATE EXTERNAL TABLE AS SELECT (CETAS) on the serverless SQL pool exports query results to an external storage location; if the workspace MI holds write access on attacker-controlled storage, data is exfiltrated.

An EXPORT DATA statement or bq extract job copies BigQuery table contents to a GCS bucket - effective data exfiltration across the project boundary.

A principal with bigtable.backups.read on a source backup AND bigtable.backups.create + bigtable.backups.restore in a destination instance (any project) can copy the backup cross-project and restore the full table contents in the destination, exfiltrating all data outside the source project boundary.

cloudsql.instances.export triggers the Cloud SQL service agent to write a full SQL dump (or CSV export) to a GCS bucket; when the destination bucket is attacker-accessible, this constitutes data exfiltration.

cloudsql.instances.clone creates a full copy of a Cloud SQL instance (with all databases and data) accessible to the cloning principal in the same project - direct data exfiltration without external GCS access.

A Dataflow worker SA with storage.objects.create on an external GCS bucket can stream pipeline output (data records, query results) to that external location.

datastream.streams.update lets a principal redirect the stream's destination (BigQuery dataset or GCS path) to an attacker-controlled sink, exfiltrating all CDC data from the source database.

datastream.streams.create + datastream.connectionProfiles.create lets a principal create a new CDC stream from an existing source database to an attacker-controlled destination, exfiltrating source data.

A principal holding file.backups.get in the source project plus file.instances.create or file.instances.update in an attacker-controlled destination project can restore a Filestore backup to the destination, exfiltrating all data. This is a multi-project, multi-permission escalation path documented as one of the three central attack primitives for Filestore.

A principal holding file.snapshots.get in the source project plus file.instances.create or file.instances.update in an attacker-controlled destination project can restore a Filestore snapshot to the destination, exfiltrating all data. Snapshots are point-in-time copies of a share and can be restored cross-project exactly as with backups, making this an equally viable cross-boundary data exfiltration path.

datastore.databases.export + storage.objects.create on a destination GCS bucket constitutes effective Firestore data exfiltration: the entire database is copied to an attacker-controlled or cross-project GCS bucket.

Snapshot a disk and reuse it from another project.

storage.objects.get on the source bucket + storage.objects.create on a destination bucket (cross-project or attacker-controlled) constitute effective data exfiltration; achievable via storage.objects.copy (rewriteObject) which combines read+write permissions.

Create a snapshot of a disk and grant a cross-project principal access to it, enabling the attacker to restore it as a disk in their own project and read all on-disk data (secrets, credentials, database files).

Creating a Spanner backup (spanner.backups.create) then setting the backup's IAM policy (spanner.backups.setIamPolicy) to grant a cross-project principal spanner.backups.restoreDatabase copies the full database contents across the project boundary - effective exfiltration.