Friday, July 18, 2014

VMware Leaves Artifacts of Guest Applications on the Host


In the VMware environment, Unity Mode presents guest VM applications to the host desktop.  This provides a convenient way for the user to access applications installed on the guest without switching back and forth from the host to the guest.  When a guest VM application is run in Unity Mode, the application appears in the host desktop just as a host application would.

To enable the guest-to-host communication required for Unity Mode, VMware stores information about guest applications in a directory called caches, nested within the directory where the .vmdk file is housed.  Significant information about guest VM applications is recorded in the caches directory.  This information is recorded whether or not the application is ever used in Unity Mode, and it persists after the application has been uninstalled from the guest VM.  By examining the caches directory, a forensic examiner may be able to recover information such as:
  1. the names and full paths of all shortcuts ever present in the Start Menu of the guest;
  2. the date and time the shortcut were placed in the Start Menu;
  3. the icon used by the shortcut;
  4. the date on which the guest application was first run in Unity Mode (if applicable).
The ubiquity of virtualization presents ample opportunity for the examiner to find useful artifacts in the caches directory of a subject workstation or server.  This article describes the behavior of VMware running a Windows XP guest on a Windows 7 host.  Other combinations of host and guest OSes may present somewhat different findings, but I presume the behavior will be broadly similar across platforms.  As always, the examiner should conduct his or her own tests to confirm these findings before drawing conclusions.

Cross-Contamination of Unallocated Space between VMware Guest and Host


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.