Cloud-Native Forensic Imaging Part 2

Part 1 of this series covered why cloud acquisition outpaces physical imaging and walked through how to create a snapshot and provision a forensic disk from it. You now have a forensic disk, an isolated, point-in-time copy of the compromised instance's storage, as well as two paths forward: mount it to a forensic VM inside the cloud, or export and download it for local analysis. The right choice depends on your investigation's custody requirements, on existing lab infrastructure, and — especially on GCP — on which path preserves the complete forensic record.

Why Cloud-Side Mounting is the Default Choice

Mounting the disk directly to a forensic VM in the same cloud environment is the operationally superior option for most investigations. There are no egress charges, no waiting on large transfers, and no cross-region latency. Your analysis environment sits in the same region as the evidence, which simplifies audit log correlation and avoids the jurisdictional complexity that can arise when data crosses cloud provider boundaries.

Cloud-native tooling runs without issue on forensic VMs in any of the three major clouds. The SIFT Workstation, Autopsy, The Sleuth Kit, and Volatility all operate the same on a forensic EC2, Azure VM, or GCP compute instance as they do on a local workstation. The added benefit: Every action against the evidence disk stays under the same cloud audit trail as the original incident, creating one consistent chain-of-custody record.

Option 1: Attaching the Evidence Disk to a Forensic VM

CLI — Attaching and Mounting Read-Only

AWS

The output of the disk creation event from Part 1 will include a volume ID that you will use in the following command. Additionally, you need to identify the instance ID of your forensics VM.

aws ec2 attach-volume --volume-id <VolID> --instance-id <InstanceID> --device /dev/sdf

AWS has no native read-only attach flag at the API level. Enforce read-only access at the OS mount layer on Linux, or via write-blocker software on Windows.

Azure

Identify the evidence disk’s name, the forensic VM’s name, and the resource group in which they live.

az vm disk attach -g <ResourceGroup> --vm-name <ForensicVM> --name <DiskName>

Like AWS, Azure has no native read-only attach flag at the API level. Enforce read-only access at the OS mount layer on Linux, or via write-blocker software on Windows. Keep the forensic VM in the same Azure region as the source evidence.

GCP

Before we go into the steps of mounting the evidence disk to the forensic VM in Google Cloud, we must note an important caveat with Google Cloud snapshotting. The snapshotting process in Google Cloud only captures allocated space. What this means from the DFIR perspective is that you won’t be able to carve deleted files from unallocated space. Just keep this limitation in mind when reporting your analysis.

Identify the name of the forensic VM and the evidence disk.

gcloud compute instances attach-disk <ForensicVM>  --disk <DiskName>  --mode=ro

GCP's --mode=ro is an API feature enforced at the hypervisor layer, not just the OS mount. This is the most robust read-only guarantee of the three clouds. The disk must not be currently attached to any instance in read-write mode, and both the disk and VM must be in the same zone. Multiple forensic VMs can attach the same disk simultaneously when all use --mode=ro. For Windows VMs attaching a disk read-only in GCP, before use you must mount the disk local and set the read-only attribute first via the following steps using diskpart:

1. Run Command Prompt as administrator.
2. Launch diskpart: diskpart
3. list volume and identify the evidence disk you mounted
4. select volume <volumeID>
5. attributes volume readonly

UI — Attaching the Disk (Console Walkthrough)

AWS Console

1. Navigate to EC2 → Volumes → locate the forensic volume created from your snapshot
2. Select the volume → Actions → Attach Volume
3. Select the forensic EC2 instance → specify the device name (e.g., /dev/sdf) → Attach Volume
4. SSH to the forensic instance → run lsblk to confirm device detection
5. Mount read-only: sudo mount -o ro,noatime,noexec /dev/<device> /mnt/forensics

Azure Portal

1. Navigate to Virtual Machines → select the forensic VM → Disks
2. Click Attach existing disks → select the disk created from the snapshot
3. Set Host caching to None — never cache writes on an evidence disk
4. Save → the disk appears as a new data disk
5. Within the forensic VM OS, mount read-only: sudo mount -o ro /dev/<device> /mnt/forensics

GCP Console

1. Navigate to Compute Engine → VM instances → click the forensic VM → Edit
2. Scroll to Additional disks → click Attach existing disk
3. Select the disk created from the snapshot → set Mode to Read-only
4. Save (the VM may need to restart to detect the new disk)
5. Verify with lsblk in the OS — the disk will appear as a read-only block device

Post-Mount Analysis

Run all file system analysis against the mounted read-only device. Never chown, chmod, or write to the evidence mount path. Autopsy, The Sleuth Kit (fls, icat, mactime), and SIFT provide full analysis capability directly on the block device. If a RAM capture was also collected from the compromised instance, Volatility can be run on the same forensic VM in parallel.

Option 2: Exporting the Snapshot for Local Analysis

Local analysis is appropriate when jurisdiction requires keeping evidence on-premises, when your existing lab infrastructure (EnCase, FTK, X-Ways) is on local hardware, or when a legal hold requires physical custody of the image file. Understand the export format and its limitations for each cloud before committing to this path.

CLI — Export Methods

AWS

EBS snapshots cannot be directly downloaded from AWS from the UI or CLI. The easiest method for downloading a snapshot to a disk image is to use AWS’s Coldsnap tool. Instead of creating a disk from the snapshot, as we saw in Part 1, take the snapshot ID, note the region it is in, and execute the following command:

coldsnap --region <region> download <snapshot ID> image.dd

Azure

While the evidence disk can be downloaded via a read-only SAS URI for the managed disk, due to the speed of this method, we instead recommend using Microsoft’s AzCopy. To do this, as with AWS, we are going to download the snapshot instead of the disk. First, create the SaaS URL from the UI with the following steps:

1. Navigate to the Snapshot in the Azure Portal
2. On the left-hand menu, select “Snapshot export”
3. Select “Generate URL” and copy the generated URL

Using the URL generated in the last step, execute the following command:

azcopy cp "< URL>" "c:\temp\snapshot.vhd" --check-md5 nochecksnapshot

AzCopy uses a multi-threaded approach which significantly outperforms directly downloading using the link in a browser.

GCP

First collect the image name from the Evidence disk, and then execute the following command and then choose a bucket that you want to store that disk in.

gcloud compute images export \
  --image <ImageName> \
  --destination-uri gs://<bucket>/image.tar.gz \
  --export-format vmdk  # optional; default is disk.raw

GCP's export process uses Daisy, Google's workflow orchestration tool. It creates an ephemeral VM, attaches the disk, converts the image, and uploads to Cloud Storage. Supported --export-format options include vmdk, vhdx, vpc, vdi, and qcow2. The default output without --export-format is a disk.raw file, tarred and gzipped. Read the next section before using this path.

UI — Export (Console Walkthrough)

AWS Console

As mentioned above, there is no direct UI download for EBS snapshots. Instead, the AWS API or their Coldsnap tool must be leveraged.

Azure Portal

The best method is to use a combination of the console and UI to leverage AzCopy, as described in the CLI walkthrough above. As a reminder, here are the steps if you are taking that approach:

1. Navigate to Snapshots → select the snapshot of the evidence disk
2. Click Generate SAS → set access level to Read, set duration (max 60 days)
3. Click Generate SAS URL → copy the URI
4. Use AzCopy or a comparable download tool to retrieve the VHD
5. After download, return to the snapshot in the UI and revoke SAS access

GCP Console

1. Navigate to Compute Engine → Images (create an image from the snapshot first if needed: Images → Create Image → Source: Snapshot)
2. Click the image → Export
3. Specify the destination GCS bucket and output format
4. Navigate to the exported image within the defined GCS bucket and download directly

Choosing Your Path

Two paths, one decision: if the investigation stays in the cloud, mount the disk read-only to a forensic VM. If local custody is legally required, export but document the method's limitations in your case notes.

One preparation recommendation that applies regardless of cloud: Build a forensic VM template with your forensic tools (SIFT, Autopsy, The Sleuth Kit, etc.) pre-installed in each cloud environment before you need it. Incident response is not the time to provision and configure analysis infrastructure.

Part 1 of this series: Creating a Forensic Snapshot of a Cloud VM (AWS, Azure, GCP)