11. Beyond the workstation

16. Preservation, acquisition

Beyond the workstation: servers, virtual machines, cloud, mobile and removable media

In short: the same principles apply to every source; what changes is what can be acquired, who controls it and what authority you need.

The platform chapters go deep on workstations because that is where the hardest live decisions arise. This section sets out how the other sources differ.

Servers: agree, acquire live, keep the logs

• 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 first, as in section 7, then image at the level that preserves the evidence.
• RAID: image each member disk physically and also the logical volume the array presents. Reconstructing the array from members later depends on knowing the controller's layout, which is recorded from the controller itself.
• Too big to image in time? 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.
• Preserve the logs, local and central. Authentication, web, database, mail and application logs often have short retention and are often forwarded to a central log platform. Preserve both copies, with hashes, and record the retention policy.
• Record the clock. Clocks matter more here than anywhere: note the server's time source, its offset and whether it is synchronised, because everything correlated against its logs depends on it (section 21).

Virtual machines: go through the hypervisor

• 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 everything: the virtual disk files (vmdk, vhdx, qcow2, raw), the snapshot chain in its entirety, the memory and saved-state files, and the configuration file.
• 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.
• Preserve the host's logs. 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.
• A VM 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: hold, then export

You do not control the storage. Acquisition is by one of:

• Export through the provider's administrative tools.
• The provider's discovery or compliance features.
• A documented API.

That is under the organisation's own authority for its tenancy, or under legal process for anything else.

1. 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.
2. Export audit logs at the outset (sign-ins, file access, sharing, downloads, administrative changes). They are usually the most valuable cloud evidence and the shortest lived.
3. Export content 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.
4. Record the export: 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.
5. Export the audit logs again at the end, to capture the investigation's own footprint.

Mobile devices: shield, charge, do not guess

• Isolate from radios at seizure with a tested shielded enclosure, and keep the device charged. Do not assume airplane mode is enough: verify Wi-Fi and Bluetooth are off, and keep the power source inside the shield so the cable cannot act as an antenna.
• 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.
• Found unlocked and in use? It 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.
• Specialist tools are the norm (Cellebrite, GrayKey, Oxygen, Magnet and others). Their reports are tool-reported information, validated like any other, with the extraction's hash and the tool's version recorded.
• Look at the cloud too. 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.

Extraction is tiered, and each tier is a different scope. Record which you obtained and what it excludes.

Data protected by the device's encryption classes may be absent from lower tiers.

Removable media: image all of it

• 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 is not a magnetic disk. 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 serial number from the descriptor as well as the casing. The descriptor is what host systems recorded when it was connected, and it is how the device is matched to them (section 21).
• Keep readers, adaptors and cables with the device. 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: ask early, correlate always

• Ask for records at the outset, with a stated time window. 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.
• Receive them as files, with hashes and a note of who produced them and how.
• Taking your own capture? (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.
• Never use network records alone. Correlate them against host evidence: an address in a log is a device on a network at a time, and the step from there to a person is interpretation.