How do you detect EBS snapshot exfiltration in AWS?

What to look for in AWS activity when a snapshot may be leaving its boundary

ebs snapshot exfiltration usually shows up as a change in who can reach the snapshot, where it can be copied, or whether it has been exported into a new storage location. The core detection problem is not just the snapshot action itself, but the permission change that makes the data movable across accounts or outside the intended trust boundary.

Start with the snapshot events that change exposure: sharing a snapshot with another account, copying it into a different account or Region, or exporting it in a way that creates a new data path. Those actions are most suspicious when they touch snapshots containing sensitive workloads, or when the destination account is not a normal business dependency.

For broader exfiltration patterns, AWS snapshot abuse fits the same collection-and-exfiltration logic as other cloud data theft paths, so it helps to compare the snapshot event with egress, archive, and transfer indicators in the same investigation flow. NHIMG’s Data Exfiltration Guide is useful here because it frames the surrounding telemetry, not just the AWS API call.

Which identity and permission signals matter most

Snapshot exfiltration rarely happens in isolation. It is usually preceded by unusual identity behaviour, a new cross-account permission path, or a permissions change that was not part of an approved change window. That means you should correlate the snapshot action with who made it, from where, and whether that principal normally touches storage or backup operations.

Pay special attention when the actor is a newly active role, a rarely used automation identity, or a principal that suddenly gains the ability to modify snapshot sharing or copy permissions. If the same account also makes other unusual AWS changes, treat the snapshot event as part of a broader compromise until proven otherwise.

Identity context matters because AWS abuse often begins with stolen or overextended cloud credentials rather than with the snapshot API call itself. NHIMG’s TruffleNet stolen AWS keys campaign 2025 is a useful reminder that cloud credential abuse can be used to validate access and then pivot into theft or extortion.

How to confirm whether the snapshot is actually exposed

Once you see a suspicious snapshot event, confirm whether the snapshot is reachable outside the approved boundary. That means checking the current sharing state, the destination account or Region, and whether the copy or export target is expected for that workload. A benign backup workflow should usually map to a known account, a known pipeline, and a known owner.

Then inspect the content sensitivity of the snapshot itself. A snapshot may look like routine infrastructure state, but it can still contain application data, secrets, configuration details, or records that were never meant to move into a secondary account. If the destination is trusted but unusual, treat it as a governance issue; if the destination is unknown or external, treat it as a likely exfiltration path.

For validation, compare the snapshot event with surrounding control-plane activity, including volume creation, snapshot copy timing, permission changes, and any attempts to mask the source account. The MITRE ATT&CK Enterprise Matrix is useful for mapping those steps to attacker behaviour, while the NIST Cybersecurity Framework 2.0 is a practical reminder to tie detection, response, and recovery together.

Risk and Threat Considerations

Snapshot exfiltration is high-impact because it can bypass application-layer controls and move data through legitimate AWS functionality. If an attacker or insider gets snapshot-level access, they may be able to copy data quietly, preserve it outside the source account, and return later with a complete offline copy.

Failure mechanism: Excessive sharing, weak cross-account approval, or stolen AWS credentials let a principal copy or export the snapshot into a destination that is outside the organisation’s intended trust boundary.

Impact: Confidential data can be cloned into another account or storage location, increasing the risk of disclosure, reuse, extortion, or secondary compromise.

Practitioner Guidance

What to verify: Confirm whether the snapshot action matches an approved backup, migration, or recovery workflow, and whether the destination account is on an expected allowlist. If the answer is unclear, treat the event as suspicious until the business owner can explain it.

Decision rule: If the snapshot can authenticate a cross-account or cross-Region copy that was not pre-approved, prioritise access containment and evidence preservation before deep root-cause work. If the action is expected, validate the change record and owner rather than dismissing it as routine.

What practitioners underestimate: The most important signal is often not the snapshot API call itself, but the surrounding change in privilege, trust, or destination. A small permission change can turn an ordinary backup object into a data-exfiltration vector.

Practitioner takeaway: Detecting EBS snapshot exfiltration is mainly about proving that the snapshot stayed inside its intended boundary, not just about seeing a snapshot operation in CloudTrail.

Related resources from NHI Mgmt Group

• How should security teams respond when an AWS EBS snapshot is found to be public and unencrypted?
• How do you detect LLMjacking activity in AWS CloudTrail?
• How do you detect abuse of AWS console GetSigninToken?
• How do you detect AWS IMDS credentials being used outside AWS?