Exfiltration via snapshot sharing is one of those vectors that surprises mature teams: it does not require dumping millions of rows over the network, nor triggering typical DLP patterns based on queries or data transfer. It is enough for someone to have seemingly “harmless” read/operational permissions on snapshots to turn a consistent copy of a database or volume into an asset exportable to another account.
In practice, the impact is that an attacker can take entire databases (or complete disks) with an operational trail that blends in with legitimate backup, DR, or migration tasks. And the most delicate part: many organizations monitor data access (queries, buckets, egress), but do not treat changes to snapshot permissions as a critical event.
What went wrong: “read” permissions that allow sharing snapshots
The typical scenario does not start with a “compromised admin”, but with a role with operational scope: someone who can list and describe resources, create snapshots for support reasons, or manage backups. In AWS, that role can operate on RDS snapshots or EBS snapshots; in Azure, on Managed Disk snapshots or Azure SQL copies depending on the backup/restore model used by the organization.
The twist is that exfiltration does not need a SELECT * nor an export to CSV. If the attacker can create a snapshot and then modify its permissions, they can share it with an external account (theirs) or, in the worst case, mark it as public temporarily. In enterprises this usually happens for two reasons: IAM policies that are too broad (“so as not to block operations”) or the absence of organization-level guardrails that prevent sharing outside the corporate perimeter.
How exfiltration materializes without triggering DLP
Instead of extracting data through the logical layer (queries), the attacker moves to the platform layer: they generate a consistent snapshot and change its visibility. DLP that inspects queries, application logs, or exfiltration patterns via endpoints often goes blind because the “data” travels encapsulated as an infrastructure artifact.
In AWS, the most common pattern is: snapshot (RDS or EBS) and then sharing (adding permissions to another account) or publishing (making it public). In an environment with multiple accounts, this can be camouflaged as account-to-account exchange for DR or analytics; the difference is the destination: an account outside the organization. In real incidents, the attacker usually chooses maintenance windows or activity peaks so that the event dissolves into operational noise.
- Share with an external account: a principal (another account) is added as authorized to restore/copy the snapshot. In the attacker’s account, it is restored to a resource under their control, outside your visibility.
- Make it temporarily public: the visibility attribute is changed, it is copied/restored from outside and then reverted. If there are no real-time alerts, the “public” state can last minutes and still be enough.
Practical consequence: even with egress controlled, the attacker does not need to “send” data out over your network; they move a cloud artifact to another account and consume it there. The cost to the attacker is low and the risk of detection, if you do not look at attribute changes, is also low.
Early signals in logs: what does leave a trail (and how to correlate it)
The good news is that snapshot sharing is auditable: the permission change is not “magic”, it leaves events in control logs. The bad news is operational: many organizations have not defined specific rules and those events are not prioritized. The result is that the SIEM ingests them, but no one investigates them.
In AWS, a critical signal is the CloudTrail event associated with the snapshot attribute/permission change. In incidents with RDS, the relevant event is usually ModifyDBSnapshotAttribute (commonly cited as “ModifySnapshotAttribute” in generic detections). For EBS snapshots there are equivalent operations to modify create/dump permissions. At the investigation level, the important thing is to answer: who executed it, from where (IP/user agent), which snapshot it affected, and to which account access was granted.
- Permission-change event: create a high-severity alert when the payload includes sharing attributes or public visibility. In enterprises, this reduces false positives if you require that the change be “outward” (non-allowed accounts) or that the attribute switches to “public”.
- Correlation with recent snapshot creation: if you see a snapshot created and, within a short window, permissions are modified, the pattern is suspicious unless it is justified by a known pipeline. This “chaining” often gives away the abuse.
In Azure/GCP the logic is the same: monitor permission changes on snapshots/managed disks and correlate with identities and destination projects/subscriptions. The operational lesson here is not to stop at “there was a snapshot”: what is decisive is the ACL/Sharing change and the destination outside the perimeter.
How to do it in practice: detection and real-time alerts
If I had to prioritize a single action, it would be to set up a near-real-time alert when a snapshot moves to “shared” or “public”, or when an external principal is added. This turns a silent vector into a detectable one before the attacker completes the copy/restore in their account.
In AWS, implement detection on CloudTrail (ideally Organization Trail) and route to EventBridge/SIEM. At minimum, filter snapshot attribute modification events and trigger an alarm if the change implies:
- Addition of non-allowed accounts: validate against an allowlist of organization accounts (or a set of DR/analytics accounts). In enterprises with multiple OUs, this allowlist is managed as central configuration, not “in the code” of each team.
- Public visibility: treat any attempt at “public” as an incident, even if it is reverted quickly. In real scenarios, the attacker does not need hours; minutes are enough.
To reduce noise, add automatic context to the ticket/alert: resource tags, owner (Owner/CostCenter), region, snapshot ARN, identity (principalId), and whether the role comes from a known pipeline. That “enrichment” is the difference between an actionable alert and one that gets ignored.
Validation: run a controlled test in a non-production environment by creating a snapshot and simulating a sharing attempt. Verify that CloudTrail records the event, that your rule detects it, that the alert includes the destination principal, and that the runbook indicates how to revert permissions and freeze credentials.
Recommendations for corporate environments
This vector works because it shifts exfiltration from the data plane (queries) to the control plane (snapshot permissions). In real operations, that means a “read” or “backup” role can become an exit channel if there is no explicit guardrail that prevents sharing outside the organization.
Effective defense combines two layers: blocking and rapid detection. Block external sharing with SCPs in AWS Organizations or Azure Policy (depending on the platform) to deny permission changes toward non-corporate accounts/subscriptions, and pair it with real-time alerts for any transition to “shared/public”. When these two pieces are well tuned, the snapshot stops being a silent method and becomes a clearly visible and actionable security event.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.