Snapshot

Volume/DB snapshot - often exportable cross-account.

class: Storage

Realizing resources

aws aws

resourcescopeenumeraterequired permissions
aws:ebs:snapshot regional ebs:DescribeSnapshots ec2:DescribeSnapshots

azure azure

resourcescopeenumeraterequired permissions
azure:compute:snapshot global arg:microsoft.compute/snapshots Microsoft.Compute/snapshots/read

Rules that touch Snapshot 43

DocumentDB cluster snapshot is shared for restore with a specific external AWS account via rds:DescribeDBClusterSnapshotAttributes (restore attribute contains account ID).
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.
DocumentDB cluster snapshot is publicly restorable (restore attribute contains 'all') via rds:DescribeDBClusterSnapshotAttributes.
A principal in the snapshot's restore-authorized account with rds:RestoreDBClusterFromSnapshot can restore a shared DocumentDB cluster snapshot to a new cluster, obtaining full read access to all original data without network access to the source cluster.
ec2:CopySnapshot called from an attacker account (on a shared snapshot) or with a destination in another account copies snapshot data cross-boundary.
A snapshot is shared to an external AWS account via ec2:DescribeSnapshotAttribute.
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.
ebs:ListSnapshotBlocks + ebs:GetSnapshotBlock give block-level read of snapshot data without mounting - no EC2 footprint required. This rule matches on direct IAM capability evaluation, not on materialized HasPermission edges (which may not exist for wildcard-scoped ebs: permissions).
ebs:StartSnapshot + ebs:PutSnapshotBlock + ebs:CompleteSnapshot allows an attacker to synthesize a malicious disk image for supply-chain attacks (trojanized AMI distribution). The written snapshot can be shared via ModifySnapshotAttribute to distribute the malicious disk cross-account. This rule matches on direct IAM capability evaluation, not on PENDING snapshot nodes (which are transient and not present in the graph at rule-evaluation time).
A principal with ec2:ModifySnapshotAttribute can make a snapshot world-readable (any AWS account can CreateVolume from it).
ModifySnapshotAttribute on an existing snapshot to add a cross-account createVolumePermission entry - data exfiltration without CreateSnapshot.
A snapshot of a volume from an instance with an instance profile (IAM role) may contain credentials, SSH keys, or other secrets on the disk. This edge is ONLY emitted when forensic evidence confirms credential material on the disk image, not from structural probability alone. The preconditions are: (1) the volume was attached to an instance with an ExecutesAs role, (2) a snapshot exists of that volume, and (3) forensic scanning or manual inspection has detected credential patterns on the disk.
Reading snapshot data (CanReadData) that contains secrets (ContainsSecret) lets the principal extract and authenticate as the identity those secrets belong to - shorthand for the CanReadData → ContainsSecret → CredentialsFor chain into the CanReadSecret pivot. This rule feeds credential-chains.yaml: read-secret-yields-identity.
CreateVolume from an existing snapshot + AttachVolume to an attacker- controlled instance yields full filesystem read of the snapshot's data. This rule matches on direct IAM capability evaluation for both volume creation and attachment.
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.
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.
Neptune cluster snapshot is shared for restore with a specific external AWS account via neptune:DescribeDBClusterSnapshotAttributes (restore attribute contains account ID).
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.
Neptune cluster snapshot with public restore attribute (restore=all) is exposed to the internet via CrossAccountTrust to external Account.
Neptune cluster snapshot is publicly restorable (restore attribute contains 'all') via neptune:DescribeDBClusterSnapshotAttributes, establishing a CrossAccountTrust.
rds:RestoreDBInstanceFromDBSnapshot or rds:RestoreDBClusterFromSnapshot with a shared or public snapshot allows a principal to restore a full database copy as the master user - gaining superuser access to all data.
rds:ModifyDBSnapshotAttribute(AttributeName=restore, ValuesToAdd=[all]) makes a DB snapshot publicly restorable by any AWS account - full database exfiltration with no network access required.
redshift-serverless:UpdateSnapshot allows sharing a Redshift Serverless snapshot with another AWS account, enabling full data exfiltration via restore.
redshift:AuthorizeSnapshotAccess grants another AWS account the ability to restore a cluster snapshot, exfiltrating a full copy of warehouse data to that account.
A principal with CanModifyConfiguration(DES) can upgrade a CONDITIONAL(key_permission) CanReadData edge to ACTIVE by pointing the DES at an attacker-controlled Key Vault key and triggering VM lifecycle (re-encrypt under attacker key on next attach/detach).
A disk that can be SAS-exported and contains secrets exposes those credentials as accessible to external parties. The state (ACTIVE vs CONDITIONAL) depends on the CanExfiltrate edge state.
snapshots/write permission enables snapshot creation/restore, allowing within-subscription data exfiltration.
Wildcard permission on snapshots grants full control of the snapshot resource.
An attacker who can SAS-export a CMK-encrypted snapshot downloads encrypted blobs; plaintext read requires decrypt on the wrapping DES key (CONDITIONAL). When the same principal also holds CanDecrypt on the DES Key Vault key the decrypt-gates-secret-read rule in credential-chains.yaml upgrades to ACTIVE.
A snapshot of an OS-type disk inherits the OS-disk ContainsSecret classification when the source disk is identified.
An attacker who can SAS-export a PMK-encrypted or unencrypted snapshot can read the plaintext data immediately upon download (no key gate).
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 allows setting publicNetworkAccess and networkAccessPolicy on a snapshot, enabling cross-subscription SAS download.
azure CanModify
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.
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).
A snapshot with allAuthenticatedUsers or allUsers in its IAM policy is exposed to all GCP identities (authenticated or nominally public) across all projects/organizations.
A principal with compute.snapshots.setIamPolicy can grant themselves or a cross-project principal access to the snapshot, enabling data exfiltration or unauthorized cross-project reads.
A principal with compute.snapshots.useReadOnly on a shared snapshot and compute.disks.create can restore it as a disk and read all on-disk data across project boundaries.
A principal within the same project with compute.snapshots.useReadOnly and compute.disks.create can restore any project snapshot as a disk and read all on-disk data, escalating access to disks they don't directly have read permissions on.
move · open · esc close