Does mounting an ext4 image with -o ro guarantee nothing is written?

No. If the ext4 journal needs recovery, the kernel may replay it even on a read-only mount, which writes to the underlying device. Add noload for ext4 (and norecovery for XFS), and attach the image through a read-only loop device so the block layer refuses writes as well.

Should I pull the plug or shut down a compromised Linux server?

Neither, until volatile data has been captured. Memory, network connections and running processes vanish on power-off, so collect them first. After that, a hard power-off preserves the disk state more faithfully than a graceful shutdown, which runs scripts and flushes logs that an attacker may have hooked.

Is a cloud volume snapshot a forensic image?

It is a crash-consistent, block-level copy of the volume at a point in time, which is usually acceptable as a source. Record the snapshot ID, source volume ID and timestamp, then create a volume from it, attach it to an isolated analysis instance and hash the device you image from it.

Acquiring Linux Evidence: Disk Imaging and Read-Only Mounts

Acquisition is the one step you cannot redo. A parser bug can be fixed and an analysis rerun, but an image taken after the attacker's cleanup script ran, or a journal that was replayed by a careless mount, is lost evidence. This guide covers how to capture Linux evidence in the right order, image disks with verifiable hashes, and mount the result without changing a single byte.

Order of volatility

RFC 3227 formalised a simple idea: collect the most short-lived data first. On a Linux host that translates roughly as follows (see the order of volatility glossary entry for the background).

Priority	Evidence	Typical lifetime	How to capture
1	CPU registers, kernel state, RAM	Until power-off or reuse	LiME, AVML
2	Network connections, routing, ARP cache	Seconds to minutes	`ss`, `ip`, triage tools
3	Running processes, open files, `/proc`	Until process exit	Live response, UAC
4	Temporary filesystems (`/tmp` on tmpfs, `/dev/shm`, `/run`)	Until reboot	Triage copy
5	Disk contents	Until overwritten	Full disk image
6	Remote logs, backups, SIEM data	Retention policy	Export from source

Two practical consequences. First, if memory matters (fileless malware, injected code, rootkits) it must be captured before anything else, as described in the LiME and Volatility guide. Second, tmpfs is RAM-backed on many modern distributions: /dev/shm and /run always are, and /tmp is tmpfs by default on Fedora and some other distros while Debian and Ubuntu have historically kept it on disk. A disk image will not contain what lived there.

Live versus dead acquisition

A dead acquisition images a powered-off system or detached disk. It is the most repeatable approach and the easiest to defend, but it loses everything volatile and is often impossible on production servers, encrypted volumes or cloud instances.

A live acquisition reads the disk while the OS is running. It is sometimes the only way to get decrypted data from a LUKS volume that is currently unlocked, but the filesystem keeps changing underneath you, so the image is not internally consistent and cannot be reproduced to the same hash. Document that clearly.

Every command you run on a live host leaves traces: new processes, file access times, shell history, possibly log entries. Minimise them, use trusted binaries from external media, and log your own actions (the live response guide covers this). Remember that a rootkit can lie to userland tools, including the ones you use to read the disk.

A pragmatic sequence for a suspected compromise:

Capture memory.
Run a triage collection for volatile state (processes, sockets, mounts, logged-in users).
Image the disks, live or after a hard power-off.

Imaging disks

Identify the source

On the acquisition workstation, identify the evidence disk before touching it and protect it at the block layer:

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINT
sudo blockdev --setro /dev/sdb
sudo blockdev --getro /dev/sdb   # 1 = read-only

A hardware write blocker remains the preferred control for physical disks. blockdev --setro is a software safeguard; it does not stop a desktop environment from auto-mounting partitions, so disable automounting on the forensic workstation.

dd, dc3dd and dcfldd

Plain dd works everywhere but hashes nothing and stops on read errors unless told otherwise:

sudo dd if=/dev/sdb of=/cases/2026-017/sdb.raw bs=4M conv=noerror,sync status=progress
sha256sum /dev/sdb /cases/2026-017/sdb.raw

conv=noerror,sync continues past bad sectors and pads them with zeros so offsets stay aligned. With a large block size, a single bad sector zeroes the whole block, so on failing media use a smaller bs or a dedicated recovery tool such as GNU ddrescue.

dc3dd and dcfldd are forensic forks that hash during acquisition and write a log:

sudo dc3dd if=/dev/sdb of=/cases/2026-017/sdb.raw hash=sha256 log=/cases/2026-017/sdb.dc3dd.log
sudo dcfldd if=/dev/sdb of=/cases/2026-017/sdb.raw hash=sha256 hashlog=/cases/2026-017/sdb.sha256

Expert Witness Format with ewfacquire

ewfacquire from libewf produces compressed, segmented E01 files that embed case metadata and a hash of the acquired media. It prompts interactively for case number, examiner, evidence number and compression. Verify afterwards:

sudo ewfacquire /dev/sdb
ewfverify /cases/2026-017/sdb.E01
ewfinfo /cases/2026-017/sdb.E01

Raw images are the most portable; E01 saves space and carries metadata. Either is fine if you hash and document consistently.

Cloud volumes

In the cloud, the equivalent of pulling a disk is a snapshot taken through the provider API, which does not touch the guest:

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "IR-2026-017 web-prod-03 root"
az snapshot create --resource-group ir-rg --name web-prod-03-os --source <disk-id>
gcloud compute snapshots create web-prod-03-os --source-disk=web-prod-03 --source-disk-zone=europe-west1-b

Snapshots are crash-consistent, like a hard power-off. Restrict access to them, tag them with the case number, then create a volume from the snapshot, attach it to an isolated analysis instance in the same region, and image or hash that attached device. Cloud control-plane logs (who created, attached or deleted what) are evidence in their own right; export them early, because retention is limited.

Mounting images read-only

Find the partitions

A full-disk image contains a partition table. Use mmls from The Sleuth Kit or fdisk to find start sectors:

mmls /cases/2026-017/sdb.raw
fdisk -l /cases/2026-017/sdb.raw

      Slot      Start        End          Length       Description
004:  000:000   0000002048   0001050623   0001048576   Linux filesystem
005:  000:001   0001050624   0104855551   0103804928   Linux filesystem

Multiply the start sector by the sector size (usually 512) to get the byte offset. Simpler and less error-prone is a read-only loop device with partition scanning:

sudo losetup --read-only --find --show --partscan /cases/2026-017/sdb.raw
# /dev/loop0 -> partitions appear as /dev/loop0p1, /dev/loop0p2

For E01 files, ewfmount sdb.E01 /mnt/ewf exposes a raw view at /mnt/ewf/ewf1 that you can attach the same way.

Mount options that actually prevent writes

-o ro alone is not enough. A filesystem that was not cleanly unmounted (every live or crash-consistent image) has a dirty journal, and the kernel may replay it even on a read-only mount.

# ext4: skip journal replay
sudo mount -o ro,noload,noexec,nodev /dev/loop0p2 /mnt/evidence

# XFS: skip log recovery (norecovery requires ro)
sudo mount -o ro,norecovery,noexec,nodev /dev/loop0p2 /mnt/evidence

# Without losetup, using a byte offset
sudo mount -o ro,noload,loop,offset=$((1050624*512)) sdb.raw /mnt/evidence

Because the journal is not replayed, the most recent metadata changes may be missing from the mounted view. That is the price of integrity; the journal itself remains available for analysis, as covered in the ext4 and XFS timestamps guide. XFS images from a cloned system may also refuse to mount because of a duplicate UUID; add nouuid in that case.

LVM volumes on the image appear after vgscan and vgchange -ay. Do this only on a read-only loop device, and beware of name clashes with volume groups on the analysis host (many distros use the same default VG names). LUKS volumes need the key or passphrase; cryptsetup open --readonly keeps the mapping read-only.

Once mounted, analyse in place with read-only-aware commands, for example journalctl --directory=/mnt/evidence/var/log/journal or last -f /mnt/evidence/var/log/wtmp.

Chain of custody and documentation

A hash only proves integrity if you can show when it was computed and who held the evidence since. For each item, record:

Unique evidence ID, description, make, model and serial number (or cloud volume and snapshot IDs).
Who acquired it, when (in UTC), where, and with which tool and version.
Acquisition hash and verification hash, with the algorithm.
Every transfer: from whom, to whom, date, purpose, and storage location.
Deviations: live acquisition, read errors, anything unexpected.

Record the system clock and time zone of the source (timedatectl on a live host, /etc/localtime and /etc/timezone from an image) against a reference clock. Clock skew and time zone confusion break timelines more often than any tool does.

Work on copies. Keep the original image on write-protected storage and verify its hash before and after each analysis session.

Key takeaways

Collect in order of volatility: memory first, then volatile system state, then disks.
Hash during acquisition (dc3dd, dcfldd, ewfacquire) and verify afterwards; plain dd needs a separate hash step.
Live images are not reproducible; document why you took one.
Cloud snapshots are crash-consistent and belong in the chain of custody with their IDs.
Mount with ro,noload (ext4) or ro,norecovery (XFS) on a read-only loop device; ro alone can still write.
Record time zone and clock offset of the source system for every acquisition.