Virtual Machine and Cloud-Backed Endpoint Forensics

Virtual machines are now everywhere on Indian field endpoints: malware analysts run guest VMs to detonate samples in isolation, developers run Linux guests on Windows hosts for tooling parity, the average Pune startup engineer keeps two or three saved-state VMs for different projects, and state cyber cell training labs build dedicated sandbox guests for every new IOC. The forensic implication is that the examiner who images the host's physical SSD is not, by default, looking at the user's working environment. The user's working environment is a guest, and the guest is a bundle of files on the host file system: one or more virtual disk files, a configuration file, a memory file (if suspended), and potentially a snapshot chain.

The nested case is harder. A Windows 11 host can run Hyper-V; inside Hyper-V it can run a Linux guest; inside the Linux guest, KVM can run another guest. Each layer adds a virtual disk file in the layer above. The examiner faces a recursive problem: image the host, find the guest's virtual disk, mount it, find the nested guest's virtual disk inside, mount that. Tools handle one or two levels routinely; three or more is rare in Indian field practice but is appearing in sophisticated malware sandbox environments at CFSL Hyderabad. The malware-detonation case is covered in depth at Malware Forensics: Static, Dynamic, Sandbox and Memory Analysis.

The on-disk fingerprint of a VM host is the directory of virtual machine files, usually under Documents\Virtual Machines\<name>\ on VMware Workstation, C:\Users\<user>\VirtualBox VMs\<name>\ for VirtualBox, C:\ProgramData\Microsoft\Windows\Hyper-V\ for Hyper-V, and /var/lib/libvirt/images/ for KVM on Linux. The examiner who lists a Windows disk image and finds a .vmdk or .vhdx file knows immediately that a parallel acquisition path is required.

The examiner meets four virtual disk formats with any frequency on Indian endpoints. Each comes from a different hypervisor lineage, each has a slightly different on-disk header, and each maps to a different mounting toolchain.

VMDK is dominant on Indian developer laptops because VMware Workstation Pro is widely licensed at corporate scale. Monolithic VMDK is a single large file containing the entire virtual disk; split VMDK breaks it into 2 GB chunks (an artifact of the FAT32 era that persists for cross-host portability). Sparse variants only allocate physical storage for blocks that contain data, so a 200 GB sparse VMDK with 60 GB of guest data occupies roughly 60 GB on the host file system.

VHDX is the Hyper-V format and the default for new Windows Server VMs since 2012. It supports up to 64 TB, includes block-level CRC32 for corruption detection, and handles 4K-sector physical media natively. VHDX is also used by Windows Server containers in process-isolated mode, which is increasingly seen on Indian fintech infrastructure.

VDI is VirtualBox's native format. Indian students and budget developers use VirtualBox because it is free; the examiner sees VDI on home machines and on academic lab setups. VirtualBox can also use VMDK, VHD and raw, so the format on disk is not always VDI even when VirtualBox is the hypervisor.

qcow2 is the QEMU and KVM format and dominates Indian Linux server infrastructure, including CERT-In's published malware sandbox stack and most state-FSL Linux training labs. The qcow2 file is itself sophisticated: it has internal snapshot support, optional zlib or zstd compression, and optional AES or LUKS encryption applied inside the format. An encrypted qcow2 file is opaque to libguestfs unless the key is supplied.

A snapshot is a hypervisor's way of capturing a VM's state at a point in time without copying the whole disk. After a snapshot, the original VMDK or VHDX becomes read-only (the parent), and a new differencing disk is created (the child). All subsequent guest writes go to the child. Reading from the snapshot's point of view means reading the parent for any block the child has not modified, and the child for blocks it has. Take a second snapshot and a second child appears; the chain is now parent, child1, child2. Reading the "current" state means walking parent then child1 then child2 in order, with each child masking the blocks it has written.

For forensic work, the snapshot chain is a timeline built into the VM itself. A malware analyst's VM with five snapshots taken at different investigation stages yields five distinct disk states. The same structure appears on attacker-controlled VMs used as workspaces; comparing the snapshot taken just before malware was introduced with the one taken just after provides a precise before-and-after record of file system changes.

1. Identify the chain
   On VMware, the .vmsd file in the VM directory describes the snapshot tree. On Hyper-V, the .avhdx differencing disks have parent IDs in their headers. On VirtualBox, the .vbox XML describes the snapshot graph. Map the parent-child relationships before mounting.
2. Copy the entire chain offline
   Copy parent and every child to the analysis workstation. Do not copy only the child; without the parent, the differencing disk holds only deltas and is not a complete disk image.
3. Mount each snapshot as a distinct disk view
   FTK Imager and Arsenal Image Mounter accept the chain by selecting the leaf (most recent child); the tool walks the chain backward to reconstruct that snapshot's view of the disk. To examine an earlier snapshot, mount that earlier child as the leaf and let the tool walk back from there.
4. Hash each mount independently
   Each snapshot's reconstructed disk view has its own SHA-256. Record all hashes in the case file. A snapshot chain produces N hashes for N snapshots.
5. Diff between snapshots for behaviour analysis
   Mount snapshot N and snapshot N+1, run a recursive comparison (PowerShell Compare-Object, rsync --dry-run, or a forensic diff tool) to enumerate every file created, modified or deleted between the two points.

Mounting a virtual disk read-only is the standard examination move. Once mounted, the guest file system appears as a logical drive on the analysis host, and the entire normal toolchain (Autopsy, FTK, Magnet AXIOM, plaso, EZ Tools, Volatility for memory) operates exactly as on a physical disk image. The variation across formats is which tool does the mounting.

Practical mount recipes:

• VMDK on Windows analysis host. FTK Imager → Add Evidence Item → Image File → select the .vmdk. Arsenal Image Mounter is the second-choice tool and supports more recent VMDK variants. Both mount read-only by default. For split VMDK, point the tool at the descriptor .vmdk; the tool follows to the extents.
• VHDX on Windows. PowerShell Mount-VHD -Path C:\evidence\sample.vhdx -ReadOnly exposes the disk as a logical drive. Dismount with Dismount-VHD. Hyper-V Manager can also do this graphically.
• qcow2 on Linux. qemu-nbd --read-only --connect=/dev/nbd0 evidence.qcow2, then kpartx -av /dev/nbd0 to expose partitions, then mount -o ro,noload /dev/mapper/nbd0p2 /mnt/evidence. libguestfs (guestfish --ro -a evidence.qcow2) gives a higher-level shell that does not require the host kernel's NBD support.
• VDI on any host. VBoxManage clonemedium disk evidence.vdi evidence.vmdk --format VMDK converts to VMDK; mount that with FTK Imager or Arsenal Image Mounter.

VM memory acquisition is uniquely tractable. On a physical machine, capturing RAM requires running a live tool against a powered system. On a VM, the hypervisor already exposes guest RAM as a file: .vmem for VMware, .vmss and .vmsn for VMware suspended state, .bin for Hyper-V saved state. A clean way to capture running-VM memory is to take a snapshot of the running VM; VMware writes the guest's RAM contents to a .vmem at snapshot time, producing a consistent memory image without disrupting the guest. Volatility 3 then processes the .vmem with a Windows or Linux profile to extract running processes, network connections, decrypted keys, and clipboard contents exactly as for a physical-machine RAM dump.

Modern operating systems ship with cloud file sync as a first-class feature. OneDrive Files On-Demand on Windows, Drive for Desktop on Windows and macOS, iCloud Drive Optimised Storage on macOS, and Dropbox Smart Sync all share a common architecture: present files in the local file browser as if they live on the local disk, but actually fetch the content from the cloud on demand. The on-disk artifact is a placeholder, not the file.

The forensic implication is direct: a file shown in Explorer or Finder with the user's name and a modification date may have never resided on the local SSD. The on-disk image captured by the examiner contains a reparse point or a clone marker plus an entry in a sync SQLite database. The actual bytes live in a Microsoft, Google, Apple or Dropbox data centre. A disk image alone does not contain the file's contents.

How to identify cloud-stored files on a local endpoint, in field-practical order:

• Visual cue first. Windows 10 and 11 File Explorer shows a cloud icon on placeholders. Finder on macOS shows a downward-arrow cloud icon on iCloud Drive Optimised Storage files. On a live system, the user's desktop screenshot from seizure photographs this.
• Reparse tag enumeration on Windows. fsutil reparsepoint query <path> reports the reparse tag. IO_REPARSE_TAG_CLOUD and its variants identify OneDrive placeholders. A PowerShell sweep enumerates every placeholder across a volume.
• Extended attributes on macOS. xattr -l <path> lists all extended attributes. com.apple.iCloud, com.apple.brokenAlias, and the various com.apple.metadata:kMDItem* cloud attributes identify iCloud Drive items.
• Sync database parsing. OneDriveExplorer parses Cloud State.sqlite and the OneDrive .dat files to list every cloud-only file in the user's tenant. GoogleDriveExtractor handles Drive for Desktop. These tools are increasingly used by Indian state cyber cells in fraud cases involving exfiltration to personal cloud accounts.

Container forensics is a distinct and more demanding problem than VM forensics. A container is not a complete VM; it is a process group on the host kernel, isolated by namespaces and cgroups but sharing the host's kernel, kernel memory, and a large portion of the host file system. There is no guest disk file to image; there are file system layers, a thin overlay of writeable changes, and runtime metadata.

Docker on Linux uses the overlay2 storage driver by default. The root of the storage is /var/lib/docker/overlay2/, with one subdirectory per image layer or container layer. Each container has an <id>/ directory containing: lower (a file listing the parent layers, read-only), upper/ (the writeable layer where the container's runtime changes accumulate), merged/ (the unified view the container actually sees while running), and work/ (overlay2 housekeeping). The running container's process logs and metadata live in /var/lib/docker/containers/<id>/, including config.v2.json and <id>-json.log for container stdout and stderr.

For a forensic examiner, the practical implications are sharp. First, stopping the container freezes the upper layer at its current state, which is a usable disk image of the writeable layer. Second, the image layers in /var/lib/docker/overlay2/ are themselves examinable; an attacker who built a malicious image left fingerprints in the layer manifests and in the image's manifest.json and config.json. Third, the container's namespace-isolated process memory is reachable from the host via /proc/<pid>/maps and /proc/<pid>/mem, so Volatility-style RAM forensics works on the host with the container's PID rather than as a guest.

Kubernetes adds ephemerality on top. A pod can be scheduled, run for ninety seconds, and be killed by the scheduler. The container's file system layer is then garbage-collected on the node within minutes. Any forensic evidence has to be captured from the orchestration layer's logs (Fluentd, Fluent Bit, Loki, or the CRI runtime's journal) or from a persistent volume claim that the pod wrote to. The pod itself is gone.

Tools and methods seen in Indian incident-response practice:

• vmkfstools for direct VMFS-level operations on VMware ESXi datastores when imaging running production VMs.
• VMware vSphere Forensics for hypervisor-side acquisition of running VM memory and disk via the management API.
• Magnet AXIOM Cloud for OneDrive, Google Drive and iCloud cloud-side acquisition once the user credential or vendor API access is in hand.
• OneDriveExplorer for parsing OneDrive sync databases offline from a disk image.
• GoogleDriveExtractor for the Drive for Desktop sync metadata.
• Docker inspect, docker diff, docker save for read-only inspection of stopped containers in incident response.