Virtual Machine and Cloud-Backed Endpoint Forensics

Identify the actual host OS, hypervisor, storage locations and VM configuration. The host and guest can both contain relevant activity. Some guest disks are remote, passed through or encrypted rather than ordinary files in a default folder.

Preserve configuration, disk components, snapshot metadata, logs and any relevant saved state. Filename extensions are discovery clues; validate format headers and dependencies. The absence of a memory file does not prove a VM never ran.

Nested virtualisation requires repeating this mapping at each relevant layer. Do not assume every VM found was the user’s principal environment or that its existence proves malware execution.

Choose acquisition scope to retain needed context and accessible data. A host acquisition can preserve guest disk files, while a separately reconstructed guest view is a derived representation whose provenance must be documented.

Importing or booting an evidence VM changes state and can activate networking or malicious software. Examine preserved copies using appropriately isolated methods instead of running the original as a discovery shortcut.

Common disk formats include VMDK, VHD/VHDX, VDI, qcow2 and raw images. A hypervisor can support more than one format, and variants within a format can need different tools. Check actual support rather than infer capability from the extension.

Sparse allocation separates guest logical capacity from host storage consumption. Host file size does not necessarily equal guest used space because of metadata, snapshots, compression and discard behaviour.

Document any conversion with tool/version, inputs, options and output hashes. Preserve the originals. A format’s checksums for particular metadata are not an end-to-end forensic integrity guarantee for every guest byte.

For a differencing chain, resolve a requested block from the selected newest applicable layer, falling back through ancestors when needed. Branches and parent identifiers matter; filename order is not sufficient.

Map the actual snapshot tree and retain every required component before reconstructing a view. Internal qcow2 snapshots and hypervisor-managed external chains have different representations.

A snapshot is not necessarily a self-contained backup or a complete application-consistent state. Its creation can alter configuration, pause execution and omit memory depending on options. Record what was captured and how.

Compare validated views using a suitable method and retain the comparison scope. File changes between snapshots do not reveal every intermediate action, exact event time or responsible actor.

Hash component files and any exported logical disk views separately, stating which byte representation each hash describes. A reconstructed view’s hash does not replace the dependency map or source hashes.

Use supported read-only inspection on analysis copies. Validate both virtual-disk exposure and filesystem handling; a read-only virtual device does not make every parser interpretation correct. Do not assume every tool mounts read-only by default.

For example, libguestfs offers read-only access options and qemu-img can inspect or convert supported offline images. QEMU warns that querying an image being modified can observe inconsistent state, and modifying an in-use image can destroy it.

Acquisition from a running VM needs a supported coordination strategy. Disk, application and memory consistency are distinct; a snapshot is not automatically nondisruptive or memory-inclusive.

Memory formats and supporting files differ by hypervisor and version. Verify the actual capture and parser support. Volatility 3 uses its supported layers and symbols rather than simply applying a legacy Volatility 2 profile name.

Extracted processes, sockets and possible key material have their own interpretation limits. Guest memory does not guarantee recovery of every secret, clipboard item or completed network transaction.

Cloud-synchronised files may be online-only, partially hydrated, fully local or retained in other copies. Their logical size can be the full remote size while disk allocation is small. A placeholder does not prove the content never resided locally.

On Windows, cloud-file APIs use placeholder and hydration states; reparse points also serve unrelated features. On macOS, provider frameworks and storage layouts vary by release. Neither one extended attribute nor an APFS clone is a universal cloud-only marker.

Inspect actual availability flags, sync configuration and metadata with version-aware tools. Local sync records can be incomplete or stale; they are not necessarily an inventory of every remote account item.

Opening a placeholder can fetch remote content and change local state. Preserve the original metadata first where feasible, and record any authorised hydration or download as a separate acquisition with time, source and version context.

If remote content is needed, plan its scope using Cloud Forensics. Access, disclosure and cross-border requirements vary by jurisdiction. A local listing is not evidence that the listed content was acquired.

Containers commonly share a host kernel while using namespaces, resource controls and layered filesystems. Docker Desktop can introduce a VM layer, and other container isolation models exist. Identify the runtime, storage backend and actual host.

For Docker’s classic Linux overlay2 driver, mount options distinguish lower layers, a writable upper layer, merged view and work directory. The physical upper-layer path commonly uses a diff directory; do not hard-code a universal <id>/upper path.

Other drivers and containerd snapshotters use different layouts. Docker image exports, container filesystem exports, writable layers, mounted volumes, configuration, logs and memory are distinct evidence sources.

docker save exports images, not all current container changes, mounted volumes or memory. A stopped container can retain writable state, while removal, automatic cleanup and garbage collection have different effects. No universal minutes-to-deletion deadline applies.

Preserve relevant runtime inspect data, image digests, layer relationships, mounted volumes and process context through an appropriate method. Reading /proc/<pid>/maps is not equivalent to a complete host RAM acquisition.

Kubernetes evidence can span API audit records, workload definitions, node runtime data, container logs, persistent storage and central logging. Configuration, rotation, eviction and retention affect availability; a terminated pod does not imply every source has vanished.

Collection can affect production workloads. Record authorisation, commands, timestamps and operational changes. A retained application log mentioning a POST is not automatically a packet capture or proof of successful exfiltration.