Cloud-Native Forensic Imaging Part 1

Physical disk forensics has a physical problem: the disk has to be in the room. When the target is a virtualized disk sitting in a cloud data center, you cannot attach a Tableau write-blocker to it. The acquisition model changes entirely in the cloud, and in most ways, it changes for the better.

This post covers what cloud-native acquisition gives you that physical acquisition does not, and how to create a forensic snapshot on AWS, Azure, and Google Cloud.

Physical Acquisition versus Cloud Acquisition

Physical acquisition chains responders to hardware. Write-blockers prevent writes during imaging but require physical co-location with the target drive. When that drive is a virtual disk inside a cloud provider's infrastructure, co-location is not an option, as you are not seizing hardware from a data center cage.

When physical access is feasible, the process still introduces friction: investigator travel, secure media shipment, and documented chain-of-custody at every handoff. Each step adds delay and creates an opportunity for evidentiary challenges.

Speed is another constraint. Physical imaging is bounded by the storage bus. A 1 TB drive over USB 3.0 takes 40 minutes at SSD speeds—and 1.5 to 3 hours for a typical spinning disk—before any analysis begins. Cloud snapshots are copy-on-write operations at the storage layer. They complete in seconds regardless of disk size, because the provider is not copying bytes synchronously at acquisition time.

Scale changes as well. Physical acquisition is one drive per investigator per imaging rig. Cloud snapshots can be automated across dozens of instances simultaneously. AWS Automated Forensics Orchestrator for Amazon EC2 is a published solution that demonstrates this pattern: event-driven, automated snapshot and isolation across an entire fleet in response to a GuardDuty finding.

Physical drives can sustain damage in transit, or contain bad sectors that cause inconsistent reads and complicate bit-for-bit verification. Cloud storage has no equivalent surface-level defect. A snapshot API call either succeeds or fails; there is no partial read corruption introduced by a degraded spindle.

Cloud VM snapshots were designed for backup continuity, not forensic investigation. But that same API gives responders capabilities that exceed a write-blocker in most IR scenarios: remote access, API-level logging of every action, immutable storage options, and cryptographic hash integration.

Creating a Forensic Snapshot: CLI and Console

The acquisition workflow is consistent across AWS, Azure, and Google Cloud:

1. Authenticate to the cloud environment
2. Identify the target disk or volume ID attached to the compromised instance
3. Create the snapshot
4. Create a new disk from the snapshot
5. Mount to a forensic VM or export (covered in Part 2)

Required IAM Permissions

Apply these permissions to a dedicated forensic IAM role, service account, or managed identity, not a named user account. Named accounts complicate attribution in audit logs and create credential-sharing risk.

AWS:

ec2:DescribeInstances 
ec2:DescribeVolumes 
ec2:CreateSnapshot 
ec2:DescribeSnapshots 
ec2:CreateVolume 
ec2:AttachVolume 

Azure:

Microsoft.Compute/virtualMachines/read 
Microsoft.Compute/disks/read 
Microsoft.Compute/snapshots/write 
Microsoft.Compute/disks/write 
Microsoft.Compute/snapshots/read 

Google Cloud:

compute.instances.list
compute.disks.list
compute.instances.get 
compute.disks.get 
compute.disks.createSnapshot 
compute.disks.create 
compute.snapshots.useReadOnly 
compute.instances.attachDisk 
compute.disks.use

AWS: CLI

Authenticate

aws login 

Identify target volume(s)

aws ec2 describe-volumes --filters Name=attachment.instance-id,Values=<InstanceID>

Create snapshot

aws ec2 create-snapshot --volume-id <VolID> 

Create a new volume from the snapshot (for mounting)

aws ec2 create-volume --snapshot-id <SnapID> --availability-zone <AZ> 

AWS: Console

1. EC2 Console → Instances → locate target instance
2. Storage tab → Block Devices → click the Volume ID
3. Actions → Create Snapshot
4. Add a description including date/time, a reference to the associated incident/case, and the instance ID
5. Create Snapshot → monitor progress in the Snapshots pane

Azure: CLI

Authenticate

az login

Identify the target managed disk

az vm show -g <ResourceGroup> -n <VMName> --query "storageProfile.osDisk.managedDisk.id" 

Create snapshot

az snapshot create -g <RG> -n <SnapName> --source <DiskResourceID> 

Create a new disk from the snapshot (for mounting)

az disk create -g <RG> -n <DiskName> --source <SnapID> 

Azure: Console

1. Create a resource → search "Snapshot" → Create
2. Select the resource group assigned to your SOC or forensics team — not the production resource group
3. Enter a name and select the region; the snapshot must be in the same region as the source disk
4. Select Snapshot type: Full
5. Select Source subscription and Source disk
6. Review + create → Create

Note: The VM does not need to be stopped to create a snapshot, but Microsoft recommends a clean shutdown for filesystem consistency. Document your choice either way.

Google Cloud: CLI

Authenticate

gcloud auth login 

Identify attached disks on the target instance

gcloud compute instances describe <VMName> --zone <Zone> --format="get(disks)" 

Create snapshot

gcloud compute disks snapshot <DiskName> --snapshot-names=<SnapName> --zone=<Zone>

Create a new disk from the snapshot (for mounting)

gcloud compute disks create <DiskName> --source-snapshot <SnapName> 

Google Cloud: Console

1. Compute Engine → Snapshots → Create Snapshot
2. Enter a name using lowercase letters, numbers, and hyphens only
3. Select Snapshot type: Standard
4. Select Source disk — snapshots can be taken from a running instance
5. Select Location: Multi-regional, Regional, or based on the source disk's location
6. Create

Note: Wait until snapshot status reaches UPLOADING before resuming any paused application writes on the source.

What Comes Next

A new disk based on the snapshot you took is the result of step one. Part 2 covers what to do with it: mounting a read-only evidence disk to a forensic VM within the cloud environment versus exporting or downloading the image for offline analysis.

Part 2 will also address a Google Cloud unallocated space caveat where we will see that a true full disk image capture is not possible.

Leveraging AWS, Azure, and Google Cloud resources to gather evidence during investigations is a capability analysts train in FOR509: Enterprise Cloud Forensics and Incident Response.