In a VMware environment, a virtual disk can be shrunk if it becomes too large. If the virtual disk has a large amount of unallocated space, the user can use VMware utilities to shrink it to the smallest size required. When the user does this, unallocated space from within the VM may be transferred to the unallocated space of the host. VMware shrinks the .vmdk file but does not effectively zero out the data on the virtual disk before returning it to the host. In some cases, this can result in relevant data being misleadingly placed on a host.
Interestingly, the reverse is not the case. When a new VM is created with a preallocated drive, VMware does zero out all the space assigned to the virtual drive prior to making it available for use. If you create a new VM and give it a 10 GB preallocated disk, you’ll get 10 GB of zeros before your OS starts to install.
However, if you shrink a virtual disk, the contents of the disk that are unallocated in the context of the VM will be excluded from the virtual disk without wiping. That data may be transferred to the unallocated space of the host largely intact.
The experiments leading to the findings described in this article were conducted with the following hardware and software:
Windows 7 Home Premium
Intel Core i7 2820QM 2.29 GHz CPU
12 GB RAM
VMWare Player 6.0.3 build-1895310
Windows XP Home
Default install from media (no patches applied)
512 MB RAM
VMDK stored as a single file
For this experiment, I wiped a removable drive and formatted it NTFS as drive F:. I then created a new Windows VM in the root of F:. I accepted the VMware defaults except for setting the virtual drive to be a single file and disabling networking. After the initial setup, the F: drive appeared as below:
At this point, the unallocated space on F: was, as expected, largely clean, with the exception of a few deleted temporary files used by VMware during the creation of the VM:
Next, I created a “filler” text file, full of # characters, on the guest VM. I then copied the file 1000 times to create a large amount of easily recognizable data.
After this, the unallocated space on F: was still largely clean, as expected. I then deleted the “filler” directory on the guest:
Having deleted the files, leaving a great number of # characters in the unallocated space of the VM, I used VMware’s compact utility to shrink the .vmdk file:
After the compacting operation completed, I used FTK imager to look at the unallocated space of the F: drive:
Note that here FTK is showing the unallocated space in the context of the F: drive, not the VM. The vast number of # characters that had been in the .vmdk as unallocated space in the context of the VM are now outside the .vmdk and in unallocated space in the context of the host.
Although VMware effectively insulates the guest from artifacts remaining in unallocated space on the host, the reverse is not necessarily the case. Shrinking a virtual hard drive in the VMware environment may transfer artifacts out of the guest and onto the host.
On the one hand, this might preserve some data of forensic value after a VM has been deleted on a host. For example, a user might compact a virtual disk, leaving traces on the host, and then later delete the VM entirely with a secure deletion tool as an antiforensic tactic. Artifacts from the VM might survive due to the compact operation.
On the other hand, this might be misleading if an examiner is looking at a host machine that houses one or more guest VMs. For example, in a corporate environment, a machine might host multiple virtualized workstations or servers. If the examiner is interested in the actions of someone with console access to the host, and the examiner finds potentially relevant artifacts in unallocated space on the host, the examiner should consider the possibility that those artifacts were previously contained within a guest VM that was compacted.