LX1.7 Disk Imaging and Verification

Disk Imaging: Capturing the Complete Filesystem State

When You Need a Disk Image

A disk image captures the complete state of the filesystem — every file (including deleted files whose data blocks have not been overwritten), every directory, every inode, the journal, the superblock, and the unallocated space. Live response and UAC triage collect specific artifacts; a disk image captures everything. You need a disk image when:

The investigation requires deleted file recovery — files the attacker deleted from the filesystem may have their data blocks intact in unallocated space. The UAC triage cannot collect deleted files because they are not visible to userspace commands. A disk image preserves the unallocated space where deleted file data resides, enabling recovery with extundelete, photorec, and Sleuth Kit.

The investigation requires comprehensive timeline generation — plaso generates the most complete timeline from a full disk image because it can parse every artifact type (filesystem metadata, log files, application data, browser history, package manager databases). A triage collection provides only the artifacts that UAC explicitly collects.

Legal proceedings require evidence integrity — a full disk image with hash verification is the standard evidence format for court proceedings. Triage collections are accepted but a full image provides stronger evidence integrity because it captures the complete system state, not a selected subset.

Identifying the Target Device

Before imaging, identify the disk layout. Production Linux servers commonly use LVM (Logical Volume Manager) with one or more physical volumes, volume groups, and logical volumes. The imaging target is the logical volume containing the root filesystem, not the physical device.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# Identify block devices and partitions
lsblk -f

# Example output:
# NAME                  FSTYPE      MOUNTPOINT
# sda
# ├─sda1                ext4        /boot
# ├─sda2                crypto_LUKS
# │ └─sda2_crypt        LVM2_member
# │   ├─vg0-root        ext4        /
# │   ├─vg0-swap        swap        [SWAP]
# │   └─vg0-home        ext4        /home
# └─sda3

# For a full disk image (captures everything including partition table):
# Target: /dev/sda

# For individual partition/LV images:
# Target: /dev/mapper/vg0-root (root filesystem)
# Target: /dev/mapper/vg0-home (home directories)
# Target: /dev/sda1 (boot partition)

If the disk is encrypted with LUKS, the image must be acquired from the decrypted device (/dev/mapper/sda2_crypt or the LVM logical volumes on top of it), not from the encrypted block device (/dev/sda2). An image of the encrypted device is useless without the decryption key. During a live response where the encrypted volume is already unlocked and mounted, image from the decrypted device. If the system has been powered off and the encrypted volume is locked, you need the LUKS passphrase or key file to unlock it before imaging.

Acquisition with dc3dd

dc3dd is the forensic standard for Linux disk imaging. It is a patched version of dd that adds simultaneous hashing, logging, progress reporting, split output, and error handling.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# Full disk image — local output
sudo dc3dd if=/dev/sda \
  hash=sha256 \
  log=~/cases/IR-2026-0402/disk/acquisition.log \
  of=~/cases/IR-2026-0402/disk/bastion-nge01-sda.raw

# Full disk image — remote output (pipe over SSH)
sudo dc3dd if=/dev/sda hash=sha256 \
  log=/tmp/acquisition.log | \
  ssh forensics@workstation \
  "dc3dd of=/cases/IR-2026-0402/disk/bastion-nge01-sda.raw hash=sha256 log=/cases/IR-2026-0402/disk/acquisition-recv.log"

# Split image (for large disks, media size limits)
sudo dc3dd if=/dev/sda \
  hash=sha256 \
  log=~/cases/IR-2026-0402/disk/acquisition.log \
  ofs=~/cases/IR-2026-0402/disk/bastion-nge01-sda.raw \
  ofsz=4G

# Individual logical volume
sudo dc3dd if=/dev/mapper/vg0-root \
  hash=sha256 \
  log=~/cases/IR-2026-0402/disk/acquisition-root.log \
  of=~/cases/IR-2026-0402/disk/bastion-nge01-root.raw

The hash=sha256 parameter computes the SHA256 hash during acquisition — the hash appears in the log file when imaging completes. This is the acquisition hash — the reference value you will verify every time you access the image for analysis.

The dual-hash approach for legal proceedings: dc3dd if=/dev/sda hash=sha256 hash=md5 computes both SHA256 and MD5 simultaneously. Two independent hashes provide stronger integrity evidence.

The acquisition log records: source device, destination file, hash values, bytes transferred, transfer rate, start time, end time, and any errors encountered. Preserve this log as part of the evidence chain.

Cloud Disk Snapshots as Image Equivalent

For cloud VMs, a disk snapshot through the provider’s API is the functional equivalent of a disk image — but faster, easier, and forensically cleaner because it does not require any access to the running VM.

The snapshot captures the complete state of the virtual disk at the moment of snapshot creation. Unlike a live dc3dd image (which acquires blocks sequentially over minutes while the system continues writing), a cloud snapshot is a point-in-time capture — every block reflects the same instant. This is actually better evidence integrity than a live disk image.

After snapshot creation, attach the snapshot as a read-only volume to your forensic analysis VM:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# AWS — create volume from snapshot, attach to forensic VM
aws ec2 create-volume \
  --snapshot-id snap-0abc123 \
  --availability-zone eu-west-2a \
  --volume-type gp3 \
  --tag-specifications "ResourceType=volume,Tags=[{Key=Case,Value=IR-2026-0402}]"

# Attach to forensic VM
aws ec2 attach-volume \
  --volume-id vol-0xyz789 \
  --instance-id i-forensicvm \
  --device /dev/xvdf

# On the forensic VM — mount read-only
sudo mount -o ro,noexec,nosuid /dev/xvdf1 /mnt/evidence

The ro,noexec,nosuid mount options ensure: read-only (no writes that modify the evidence), no execution (prevents accidental execution of attacker binaries), and no SUID bit interpretation (prevents SUID binaries from escalating privileges on your forensic workstation).

Forensic Mounting of Disk Images

When analyzing a raw disk image on your forensic workstation, mount it read-only to prevent any modification:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Determine partition offsets in the image
mmls bastion-nge01-sda.raw
# Output shows partition start sectors

# Mount a specific partition (e.g., root at sector 2048, 512-byte sectors)
sudo mount -o ro,noexec,nosuid,loop,offset=$((2048*512)) \
  bastion-nge01-sda.raw /mnt/evidence

# For LVM-based images — set up loop device first
sudo losetup -rP /dev/loop0 bastion-nge01-sda.raw
sudo vgchange -ay
# The logical volumes appear as /dev/mapper/vg0-root etc.
sudo mount -o ro,noexec,nosuid /dev/mapper/vg0-root /mnt/evidence

# When done — clean up
sudo umount /mnt/evidence
sudo vgchange -an vg0
sudo losetup -d /dev/loop0

Beyond This Investigation

Disk images are the evidence source for LX2 (Filesystem Forensics) — inode analysis, deleted file recovery, and timeline generation all work against disk images or cloud snapshots. The imaging techniques in this subsection produce the raw material that LX2’s analysis tools consume.