16. Preservation, acquisition
Beyond the workstation: servers, virtual machines, cloud, mobile and removable media
The platform chapters go deep on workstations because that is where the hardest live decisions arise. The same principles apply to every other source of evidence; what changes is what can be acquired, who controls it and what authority is needed. This section sets out the differences.
Servers
- A production server is rarely yours to power off. Acquisition is usually live, agreed with the system owner, and scheduled; the authority to interrupt service is a separate decision from the authority to examine. Record who approved what.
- Capture memory and volatile state as in section 7, then image at the level that preserves the evidence: for a RAID set, image each member disk physically and also the logical volume the array presents, because reconstructing the array from members later depends on knowing the controller's layout, which is recorded from the controller itself.
- Large storage may make a full physical image impractical in the time available. A logical or targeted acquisition of the relevant filesystems, with unallocated space where possible, is acceptable if the scope and the reason are recorded and the image that could not be taken is named as a limitation.
- Servers are where the logs live: authentication, web, database, mail and application logs, often with short retention and often forwarded to a central log platform. Preserve both the local copy and the central copy, with hashes, and record the retention policy.
- Clocks matter more here than anywhere: record the server's time source and offset, and whether it is synchronised, because everything correlated against its logs depends on it (section 21).
Virtual machines and hypervisors
- Acquire from the hypervisor, not from inside the guest, whenever you can. A snapshot or suspend operation captures memory and disk state consistently without loading anything into the guest, and the guest's own evidence is untouched (section 7).
- Copy the virtual disk files (vmdk, vhdx, qcow2, raw), the snapshot chain in its entirety, the memory and saved-state files and the configuration file. A disk image without its snapshot chain is an earlier point in time than the running machine; record which.
- Hash each file as copied. Convert to a raw image for examination only on a copy, record the converter and version, and hash the result as a derived artefact.
- The hypervisor host is a system in its own right: its logs record when the guest was started, stopped, snapshotted, cloned or moved, and by whom. Preserve them.
- A virtual machine found inside a seized workstation image is examined the same way: extract the files from a working copy and treat them as a new device, including its own encryption.
Cloud services
- You do not control the storage. Acquisition is by export through the provider's administrative tools, the provider's discovery or compliance features, or a documented API, under the organisation's own authority for its tenancy or under legal process for anything else. Accessing an account with the user's credentials without authority is unlawful, whatever the investigation.
- Preserve before you export: most platforms have a legal hold or retention lock that stops deletion and version expiry. Apply it first, with authority, and record when.
- Export in the most complete form the platform offers (mailbox archives with folders and metadata, file exports with version history, audit logs in their native format), not screenshots or printed pages. Record the tool, the account used, the scope, the filters, the start and finish times and the platform's own export report. Hash every exported file on receipt.
- Audit logs (sign-ins, file access, sharing, downloads, administrative changes) are usually the most valuable cloud evidence and the shortest lived. Export them at the outset, then again at the end to capture the investigation's own footprint.
- Cloud exports are recovered evidence as presented by the provider; you cannot verify them against underlying storage. Say so, and corroborate against local artefacts (sync databases, cached copies, browser history) where the finding matters.
Mobile devices
- Isolate from radios at seizure with a shielded bag, keep the device charged, and do not attempt passcodes; failed attempts lengthen lockouts and can wipe the device. Record the lock state, the visible notifications and whether the device was unlocked when found.
- An unlocked device found in use is the mobile equivalent of an unlocked encrypted workstation: keep it awake if you can do so without interacting with its content (a screen tap on a neutral area, recorded), and get it to an examiner with extraction tools quickly.
- Extraction is tiered: a logical extraction (what the device will share through its backup and sync interfaces), a full filesystem extraction (requiring elevated access the tools obtain on some models), and a physical extraction (rare on current devices). Each tier is a different scope; record which was obtained and what it excludes. Data protected by the device's encryption classes may be absent from lower tiers.
- Specialist tools (Cellebrite, GrayKey, Oxygen, Magnet and others) are the norm; their reports are tool-reported information and are validated the same way as any other, with the extraction's hash and the tool's version recorded.
- The device's cloud backup, and the accounts it is signed into, are often a second copy of much of its content, acquired under the cloud guidance above.
Removable media
- Image every USB stick, card, external drive and optical disc physically through a write blocker (section 8). Small devices are quick and their evidential value is often out of proportion to their size.
- Flash devices behave differently from magnetic disks: wear levelling means deleted data may persist in areas the controller no longer presents, and may equally have been erased by the controller without any user action. Reason about what "unallocated" means on the device in question before interpreting its contents.
- Record the device's serial number from its descriptor as well as its casing; the descriptor is what the host systems recorded when it was connected, and it is how the device is matched to them (section 21).
- Card readers, adaptors and cables collected with a device stay with it. A card reader has a serial number of its own, and it is the reader, not the card, that appears in a host's device history.
Network evidence
- Traffic captures, firewall and proxy logs, DNS and DHCP records, VPN and wireless controller logs, and flow records are all short lived and all held by someone other than the examiner. Ask for them at the outset with a stated time window, and receive them as files with hashes and a note of who produced them and how.
- Where a capture is taken during the investigation (on a suspected compromised host, or at a network boundary), record the capture point, the interface, the filter, the tool and version, the start and finish times and the clock source. A capture is an observation of the network at a point; it says nothing about traffic that took a different path.
- Network records are correlated against host evidence, never used alone: an address in a log is a device on a network at a time, and the step from there to a person is interpretation.
Example. An investigation involves a workstation, a virtual machine on a shared host, a mailbox in a hosted platform and a phone. The examiner applies a legal hold to the mailbox and exports the audit log before anything else; asks the host administrator to snapshot the virtual machine and copies the snapshot files with hashes; isolates and bags the phone; and only then begins the workstation procedure. The four acquisitions arrive in four different forms, each recorded with its scope, and each is a separate exhibit with its own custody record before any of them is correlated.