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:
- the names and full paths of all shortcuts ever present in the Start Menu of the guest;
- the date and time the shortcut were placed in the Start Menu;
- the icon used by the shortcut;
- the date on which the guest application was first run in Unity Mode (if applicable).
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
When a VMware guest VM is created, the associated .vmdk and other files are stored in a location selected by the user. The files and subdirectories related to the guest VM might look like the example below:
In this article, I'll refer to this user-selected location as <VMHome>. For example, the caches subdirectory would be written as <VMHome>\caches.
In the example above, note that the .vmdk was created on 7/17/14 at 08:34. This was the time I began the creation of the VM. <VMHome>\caches was created at about 09:05. This directory is one of the last things to be created when a new Windows guest VM is being created. After the guest OS has been fully installed from the installation media, but before the desktop is made available to the user for the first time, the guest will install VMware Tools. During the installation of VMware Tools on the guest, <VMHome>\caches is created on the host. This shows that the full process of setting up the VM and completing the initial OS install in this example took about 31 minutes.
At this point, <VMHome>\caches has a subdirectory GuestAppsCache, which has two subdirectories, appData and launchMenu. These are very interesting. In my example scenario, before I take any action in the VM, <VMHome>\caches\GuestAppsCache\appdata contains 137 files, each named with a long hex value and the extension .appicon or .appinfo. For example, in my test I find files named d519ed74fe960c1632c30a1ccb969f74.appinfo and d519ed74fe960c1632c30a1ccb969f74.appicon. Opening d519ed74fe960c1632c30a1ccb969f74.appinfo in a hex editor gives us this:
As you can see, this file contains the path to the Wordpad application and some additional information. Opening the sister file d519ed74fe960c1632c30a1ccb969f74.appicon in a hex editor shows:
Obviously, this is a PNG file with some additional data prepended. Removing the prepended data and saving the file as a PNG, you get:
In addition, similar information on the contents of the Start Menu is maintained in a file named launchMenu.metadata, which can be found in <VMHome>\caches\GuestAppsCache\launchMenu. This is a single file that contains information on every shortcut in the Start Menu. For example, we can find the path for Wordpad there as well:
When a user opens an application within the context of the guest VM, there is no change to either of the .appinfo/appicon pair of files. I tested this with a couple of applications, including Wordpad, and as long as I stayed in the VM, the contents of <VMHome>\caches\GuestAppsCache were untouched.
These files together apparently provide the host OS information to manage the Unity Mode function. I suspect they are primarily used to generate the Unity Mode Start Menu the user see on the host system:
Interestingly, though, the cache files present after the initial install are still not modified when the user executes a guest application in Unity Mode. However, a new .appinfo/appicon pair is created in the appData directory. To demonstrate, I ran Wordpad in Unity mode. As soon as I opened it, two new cache files appeared in <VMHome>\caches\GuestAppsCache\appdata:
Note that now there is a new pair of cache files, c95516d296b335b0b087b5c555d2c32a.appinfo and .appicon. These files are created at the time that I opened Wordpad in Unity Mode. Here, the .appinfo file contains slightly more information than the original .appinfo file associated with the Wordpad shortcut:
The .appicon file is, as before, a copy of the Start Menu icon image with some data prepended to the header.
Both pairs of files -- the pair that was created upon initial install, and the pair created upon the first use of the application in Unity Mode -- are not modified by any subsequent action that I could find. That is, no matter how many times I open Wordpad in Unity Mode, these two pairs of files remain the same, as far I can tell.
Also at the time the application is first launched in Unity Mode, a copy of the application's icon is placed in <VMHome>\caches\LinkIcons:
This file is likewise unmodified by subsequent launches of the application in Unity Mode.
It gets more interesting for the forensic examiner, of course, when a new application is installed. When a new application is installed, VMware will create a pair of cache files for each shortcut placed in the Start Menu. For example, I installed venerable text editor GWD on the guest VM:
And, as expected, this created a pair of cache files on the host for the new shortcut...
...And updated <VMHome>\caches\GuestAppsCache\launchMenu\launchMenu.metadata...
Also as expected, once I opened GWD in Unity Mode, VMware created the second .appinfo/.appicon pair and placed the icon in the LinkIcon directory.
The same behavior is seen when a shortcut is added to the Start Menu manually. I created a batch file in the VM and placed it in the Startup menu. As soon as I did, VMware created the .appinfo/.appicon pair in the appData directory.
Note that this is entirely a function of placing a file in the Start Menu. I tested the install of HxD hex editor on the guest VM, choosing the option not to create a Start Menu folder at the time of install. The application installed as expected, without placing a shortcut in the Start Menu. And, there were no corresponding cache files in <VMHome>\caches\GuestAppsCache\appdata, and there was no update to <VMHome>\caches\GuestAppsCache\launchMenu\launchMenu.metadata. However, once I launched HxD in Unity Mode, the .appinfo/.appicon pair associated with an application's first use in Unity Mode was created:
The HxD icon was also created in the LinkIcon directory As with the other examples, subsequent use of HxD in Unity Mode did not affect the pair of cache files or the icon in the LinkIcon directory.
The good news for forensic examiners is that the cache files are not cleaned up when the associated application is removed from the guest VM. In my test, I uninstalled GWD and HxD:
After the uninstall, all the related cache and icon files were left on the host:
I have not discovered anything that triggers VMware to clean up these files. Based on my testing so far, it appears that these files will stay on the host until they are deleted manually by the user.
Once the Start Menu items are cleared, however, the related entries are taken out of launchMenu.metadata.
This suggests that launchMenu.metadata is the central index VMware uses to populate the Unity Mode Start Menu, and although references to uninstalled guest applications are cleared from it, the cache and icon files it pointed to are left in place
The files contained in <VMHome>\caches gives the forensic examiner a wealth of information about what applications have been present on a VM, when they were installed, and if they were ever executed in Unity Mode. The fact that these artifacts persist after the application is uninstalled from the VM can be used to help establish what actions were taken even after the user has attempted to cover his or her tracks
In the corporate environment, servers and even workstations are increasingly virtualized. A user might connect to a server remotely without even realizing it is a VM. And, some organizations provide users a virtual workstation that they connect to through a thin client or a personal device in a BYOD infrastructure. In these cases, user actions may leave traces on a host machine the user has no access to. That is, a user might RDP into a virtual workstation without having console access to the server that's hosting it. The user might install an unapproved application, take inappropriate action, and then uninstall the application. Even if the user does a thorough job of cleaning up the VM, there is a good chance the related cache files on the host server can establish the presence of the application.
In a home environment, a user might use a VM for illicit or risky activity as a way to segregate that activity from his or her primary user environment. The user might remove applications from the VM as an antiforensic tactic without being aware of the presence of artifacts in the caches directory.
An examiner investigating activity on a VM should keep in mind that much of what happens inside the VM has to leave some trace on the host. As virtualization becomes more common, finding artifacts of guest activity on the host is increasingly important to the forensic community.