Disk Image Acquisition
A forensic disk image is a bit-for-bit copy of a storage device — every sector, including unallocated space and deleted content. This chapter covers acquisition methods, image formats, write protection, hash verification, and practical techniques for capturing images from live systems, physical media, and cloud environments.
You've captured a memory image. The system is now isolated. You have a window to take a full disk image before the business demands the server restored. The server has a 500 GB SSD (NVMe) connected via the Windows boot volume. You can't physically remove the drive without vendor hardware access. You need to image it remotely, across the network, to your evidence NAS — at 1 Gbps this will take approximately 70 minutes. The investigation can't wait for a 70-minute image transfer. This chapter covers how to handle this — full image in the background, targeted artifact collection in the first 30 minutes.
Forensic Image Formats
| Format | Extension | Notes | Best for |
|---|---|---|---|
| Raw / DD | .dd, .img, .001 | Simple bit-for-bit copy. No metadata. No compression. Every tool can read it. | Linux imaging, simple pipelines, direct dd analysis |
| E01 (Expert Witness Format) | .E01, .E02... | EnCase format. Built-in hash verification, compression, split segments, metadata. Most commonly used in professional forensics. | Windows investigations, court-admissible evidence, long-term storage |
| AFF4 | .aff4 | Open container format. Supports compression, encryption, metadata. Native format for WinPmem (memory) and GRR (remote forensics). | Modern toolchains, multi-evidence containers |
| VMDK / VHD | .vmdk, .vhd | Virtual machine disk formats. Can be mounted directly as VMs for analysis. Cloud VMs often export in these formats. | Cloud VM analysis, hypervisor-sourced evidence |
FTK Imager for Windows Disk Acquisition
FTK Imager Acquisition Workflow (Windows)
═══════════════════════════════════════════════════════════════════
FTK Imager (free from Exterro) — most common Windows imaging tool
Steps:
1. Launch FTK Imager
2. File → Create Disk Image
3. Select source type:
- Physical Drive: captures entire disk including all partitions + MBR
- Logical Drive: captures a single volume (C:, D:)
- Contents of a Folder: captures file-level, not forensic
→ Choose Physical Drive for full forensic image
4. Select the drive (\\.\PHYSICALDRIVE0 = primary disk)
5. Add Image Destination:
- Image type: E01
- Destination path: external drive (not the source!)
- Case info: fill in case number, examiner, etc.
- Fragment size: 2000 MB (splits to stay under FAT32 limits)
- Compression: 6 (good compression/speed balance)
6. Enable MD5 and SHA1 hash verification
7. Click Start — FTK calculates hash as it images
Remote imaging option:
FTK Imager has a "Capture Memory" CLI option
For remote disk: mount source drive read-only via PSRemoting
and pipe to network destination (see script below)
# Remote disk imaging via SSH (source is a Linux system)
# Pipe dd through SSH to write image directly to evidence NAS
TARGET_HOST="192.168.1.50"
EVIDENCE_PATH="/mnt/evidence/cases/CASE-2026-009/FINANCE-SRV01"
DISK="/dev/sda"
TIMESTAMP=$(date +%Y%m%d-%H%M)
OUTFILE="$EVIDENCE_PATH/FINANCE-SRV01-$TIMESTAMP.dd"
mkdir -p $EVIDENCE_PATH
# Pipe image via SSH — compresses in transit with gzip to save bandwidth
ssh root@$TARGET_HOST "dd if=$DISK bs=64k conv=noerror,sync status=progress" | \
gzip -1 > "${OUTFILE}.gz"
# Verify: get hash of the original (not the compressed copy)
# First: get hash on source
ssh root@$TARGET_HOST "sha256sum $DISK" > $EVIDENCE_PATH/source.sha256
# Get hash of decompressed image
zcat "${OUTFILE}.gz" | sha256sum > $EVIDENCE_PATH/image.sha256
echo "Source hash: $(cat $EVIDENCE_PATH/source.sha256)"
echo "Image hash: $(cat $EVIDENCE_PATH/image.sha256)"
# These should match if no transfer corruption occurred
# Remote Windows disk imaging using FTK Imager CLI
# Requires FTK Imager installed on the target or copied as portable
$target = "FINANCE-SRV01"
$outPath = "\\evidence-nas\cases\CASE-2026-009\$target"
$ftkPath = "\\tools-share\ftkimager\ftkimager.exe"
New-Item -ItemType Directory -Path $outPath -Force | Out-Null
# Remote imaging via PSRemoting — runs FTK on the target, writes to network path
Invoke-Command -ComputerName $target -ScriptBlock {
param($ftk, $out)
# List physical drives
& $ftk /list
# Image physical drive 0 to network share (E01 format)
& $ftk "\\.\PHYSICALDRIVE0" `
/a /e "$out\disk.E01" `
/hf /verify `
/unicode
} -ArgumentList $ftkPath, $outPath
Write-Host "Imaging initiated. Monitor $outPath for progress."
Linux E01 Acquisition with ewfacquire
# ewfacquire: create E01 images on Linux (libewf-tools)
# Available in SIFT Workstation
ewfacquire \
-t /mnt/evidence/FINANCE-SRV01 \
-f encase6 \
-C "FINANCE-SRV01.corp.local" \
-D "Finance server — confirmed Cobalt Strike compromise 2026-09-20" \
-e "analyst@corp.com" \
-N "Case 2026-009" \
-c best \ # compression: none, empty, fast, best
-S 2g \ # segment size: split at 2 GB
/dev/sda # source drive
# After acquisition, verify the E01 image:
ewfverify /mnt/evidence/FINANCE-SRV01.E01
# → Should report: Verification successful
# → Reports: MD5 and SHA1 hashes of the acquired image
Practical: Triage Artifacts First, Full Image Concurrently
In most IR scenarios you can run KAPE triage collection in parallel with the full disk image:
Parallel Collection Strategy
═══════════════════════════════════════════════════════════════════
T+0: Start full disk image (background, 60-90 min)
Start KAPE triage collection (foreground, 15-30 min)
T+15: KAPE triage complete → begin artifact analysis immediately
Full image still running in background
T+45: Full image complete → disk image available for deep analysis
Triage analysis already in progress → initial findings available
This gives you:
- Actionable evidence within 15-30 minutes (triage)
- Complete evidence within 60-90 minutes (full image)
- Business system can be restored at T+90 while analysis continues
on the preserved images
Never: wait for full image before starting analysis
Never: start analysis on live system (always use copies)
Q & A
Q: The disk is encrypted with BitLocker. Can you still image it forensically?
Yes — imaging a BitLocker-encrypted drive captures the encrypted sectors faithfully. The resulting image is forensically valid. But to analyze the contents, you need to decrypt it. Options: (1) Image the live system while it's unlocked (decrypted — the OS has mounted the encrypted volume). The logical volume inside the encrypted partition is accessible and you can collect artifacts. (2) Obtain the BitLocker recovery key from AD (stored at the computer object) or Microsoft 365/Entra ID (for Azure AD-joined devices). You can then decrypt the image offline with BitLocker or dislocker (Linux). (3) If the system is in a powered-on state when you acquire, the volume master key (VMK) may be in the memory image (also captured from a running BitLocker-encrypted system). Volatility can extract this with the appropriate plugin. Document in your case notes whether the image was acquired from an encrypted or decrypted state — it affects how the evidence was collected and chain of custody documentation.