Detecting direct API access to EBS Snapshot content

David Cowen pointed out that the EBS API does not log to Cloud Trail that creates a risk of undetected access to sensitive data inside a snapshot.

Daily Blog #675: The curious case of cloud trail and AWS EBS Block API access

To continue taking advantage of the AWS native forensic acquisition capabilities, we need a solution to detect direct API access to EBS Snapshot content.


First, we need the Cloud Trail logs in a location that can be monitored and generate alerts for these IAM events.

  • CreatePolicy
  • CreatePolicyVersion
  • PutRolePolicy

The Elastic Block Store service specifically has these three actions to write rules to detect.

  • ebs:ListSnapshotBlocks
  • ebs:ListChangedBlocks
  • ebs:GetSnapshotBlocks

Second, we need to audit our AWS accounts to make sure these permissions do not exist already.

Third, we need a way to detect the usage of the EBS permissions in our accounts.

One option is to use AWS Config with Global Resources included that covers IAM assuming its enabled.

  • iam-policy-blacklisted-check
  • iam-policy-in-use

I needed another option as my goal is to keep Snapshot 4n6ir Imager available as a stand-alone option for incident responders without dependencies. I decided to use the AWS Security Token Service (STS) and restricted IAM permissions to create detection boundaries for the usage of the EBS permissions.


The location from where you execute the Snapshot 4n6ir Imager python script needs the following STS policy permissions available.


Now create a policy with the following Elastic Block Store permissions. Resources have the option to limit to specific ARNs of snapshots under investigation. You can also create request conditions that limit policy access to a specific IP address or CIDRs.


Finally, create a user role with the AWS account number where the snapshot needs imaging with a unique External ID defined that has the EBS policy attached.


The Maximum CLI/API session duration needs to be expanded from the default 15 minutes up to 12 hours to cover the imaging time requirements.


Now when the Snapshot 4n6ir Imager python script assumes the role with EBS access, it generates an ‘AssumeRole’ event in Cloud Trails for monitoring and detection.


An encrypted EBS volume generates KMS events in Cloud Trail that associates the Role Session Name from STS as the username with this method too.


Hopefully, Amazon can add EBS API logging to Cloud Trail natively soon!


Recently I added options to take advantage of the list_changed_blocks() method from the direct API access to Elastic Block Store (EBS) Snapshot content. It is providing the investigator with the blocks that have changed from the base to the current snapshot. The Snapshot 4n6ir Imager now outputs a change log to a text file in the root of the execution directory.

$ cat snap-0257fc4fc73cb27f2_changelog.txt
|blockindex|offset |length|
|0         |0      |524288|
|2         |1048576|524288|
|4         |2097152|524288|
|5         |2621440|524288|

Another feature that was needed was the ability to download a single block that failed the verification check. The list_snapshot_blocks() method would only allow me to pull a minimum of at least 100 block indexes that requires me to break the loop that starts at the required block.

$ python3 --region us-east-2 --snapshot snap-0de67428c1be121f4 --single --block 0
Snapshot 4n6ir Imager v0.2.0

Region: 	us-east-2
Snapshot: 	snap-0de67428c1be121f4


Happy Coding,

John Lukach

$ wget
$ wget
$ gunzip
$ shasum -a 256 


$ wget
$ wget
$ gunzip
$ shasum -a 256