Artifacts of Host-to-Guest File Copy in the VMWare Environment


In a virtualization environment using VMWare, one method of introducing a file onto a guest virtual machine is to simply copy and paste the file from the host system into the VMWare window. From the user’s perspective, this is a typical copy-and-paste operation, resulting in a new file in the context of the guest system that the user can then manipulate normally from inside the guest system.

Of interest to the forensic examiner, however, is the fact that a host-to-guest copy-and-paste operation in the VMWare Player environment leaves a temporary copy of the source file in %tmp%VMWareDnD on the guest. This temporary file may be valuable in recovering the prior contents of the copied file after the live file is manipulated by the user. In addition, the temporary file retains the file creation timestamp of the original file on the host machine, potentially providing valuable information for timeline reconstruction. The temporary file persists when the guest is suspended or shut down. It is cleared when the guest is booted up.

Experimental Platform

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


VMWare Player 3.1.4 build-385536

Access Data FTK Imager


Windows XP Home, Service Pack 3

512 MB RAM

Fully patched and activated

Networking disabled

VMDK stored as a single file

Experimental Process

First, I created a new virtual machine through VMWare Player, using a Windows XP install CD. I assigned 512 MB of RAM to the VM and set it to store the virtual disk as one file. I accepted all defaults during the Windows setup. After completing the Windows setup, I applied all patches and completed the online Windows activation. I installed no other software. After patching the system, I disabled the guest machine’s network adapter in the VM configuration.

After taking these steps, I created a backup copy of the clean VM. VMWare Player does not provide a snapshot option, so I used a manual copy-and-paste process to preserve the pristine test environment and begin each iteration of testing from that point. I conducted multiple rounds of testing, each time copying the base VM image to a new location and starting the testing from scratch.

Detailed Findings

I used public domain e-books downloaded from Project Gutenberg as test files to be copied from my host machine to the guest. On November 2, 2012 at around 8:40 PM Central Time, I downloaded four books in MOBI format from Project Gutenberg to my host machine. As expected, the Date Created and Date Modified timestamps reflected the time at which I downloaded the files (see Figure 1 and Figure 2). I placed three of the files into a directory to test how VMWare Player handled copying an entire directory.

The temporary directory on the guest machine that we’re concerned with is %tmp%VMWareDnD, that is, C:Documents and Settings<username>Local SettingsTempVMWareDnD on a default installation of Windows XP. DnD is presumably an abbreviation of “drag and drop”. On the experimental VM before any copy-and-paste operation was attempted, %tmp%VMWareDnD was not present (Figure 3). Additional testing indicated that %tmp%VMWareDnD is created on the guest the first time the user executes a copy and paste from the host to the guest.

When a file, group of files, or directory is copied from the host to the guest, VMWare creates a subdirectory under %tmp%VMWareDnD to store the items being copied. One directory is created for each discrete copy-and-paste operation. The subdirectory is given an eight-character name, which appears to be a random hexadecimal string. VMWare source code found online supports this supposition.

Online research revealed that VMWare participates in the open source community and makes some of its source code publicly available. According to VMWare’s website, source code for Open Virtual Machine Tools, including file transfer operations, is made available through Sourceforge. This code is for Linux and Unix-like guest operating systems, but I think it sheds some light on how the VMWare code likely handles copy-and-pastes in Windows guests as well.

Among the code available through Sourceforge is the module dndCommon.c. This module contains the following comment:



* DnD_CreateStagingDirectory --


* Generate a unique staging directory name, create the directory, and

* return the name. The caller is responsible for freeing the returned

* string.


* Our staging directory structure is comprised of a "root" staging

* directory that itself contains multiple staging directories that are

* intended to be used on a per-DnD and per-user basis. That is, each DnD

* by a particular user will have its own staging directory within the root.

* Sometimes these directories are emptied after the DnD (either because it

* was cancelled or the destination application told us to), and we resuse

* any empty directories that we can. This function will return a directory

* to be reused if possible and fall back on creating a new one if

* necessary.


* Results:

* A string containing the newly created name, or NULL on failure.


* Side effects:

* A directory is created




This aligns with my observations. When copying a file from a Windows host to a Windows guest, the temporary directory (here called a “staging directory”) is created under a “root” staging directory (i.e., %tmp%VMWareDnD in Windows) with a random name.

On November 5, 2012 at about 9:02 PM Central Time, I copied the file from the host machine and pasted it onto the Desktop of the guest. After the copy operation, I suspended the guest and examined it with FTK imager. Note the Date Created and Date Modified attributes of the file in the Desktop directory (Figure 4). The timestamps, given here in UTC, are what we’d expect – the time the files were pasted.

However, note the same attributes of the temporary file (Figure 5). Here, the Date Accessed is the time the file was pasted, but the Date Created matches the Date Created of the file on the host machine (Figure 1).

The same behavior is seen when a directory is copied. When I copied the directory MarkTwainfrom the host to the guest, the attributes of the directory and its files pasted to the desktop were what we’d expect (Figures 6 and 7), while the directory and files in %tmp%VMWareDnD retained the Date Created attributes they have on the host machine (Figures 8 and 9).

These artifacts could be useful in many situations. They could help resolve questions of the origin of files, help establish timelines of user activity, help resolve questions of clock drift on the guest, etc. Perhaps more significantly, the presence of a point-in-time snapshot of a file in question could help show what revisions were made to a file after the copy was made. Once the file is copied, changes to the live file, including file deletion, are not reflected in the temporary file. In cases in which establishing the original contents of a file or the prior presence of a file are relevant, the copy in %tmp%VMWareDnD could be very useful.

As noted above, I conducted my testing with VMWare Player, which does not provide a snapshot function. In cases involving the full version of VMWare Workstation, where snapshots might be available, the value of %tmp%VMWareDnD could potentially be much greater. A succession of snapshots, each capturing different copy-and-paste operations, could reveal a great deal about the user’s activities.

Unfortunately, the artifacts in %tmp%VMWareDnD can be short-lived. My testing indicates that the directory is cleared when the guest is booted up. The contents of the directory are untouched when the guest is suspended and when the guest is shut down. Upon boot up, though, the directory is cleared.

Interestingly, after booting up the VM after a copy-and-paste operation, the files previously in %tmp%VMWareDnD were not consistently recoverable by FTK Imager or ProDiscover Basic. In some of my tests, traces of the deleted temporary files were completely absent from the directory, as though their MFT entries had been cleared entirely, with a total loss of file attributes. In other tests, the temporary files were recoverable after a reboot. And, in my final test, some files were recoverable after a reboot while others were not. For example, see Figure 10, where the deleted directory from the copy of the Mark Twain e-books and from a subsequent test are recoverable, but the directory that had housed the temporary copy of Moby Dick (afe1aa57) is nowhere to be found.

The short lifespan of the files and their thorough deletion in some cases does limit the situations in which these artifacts would be available to the forensic examiner. However, I can imagine cases in which a guest VM is used in a production environment and is not power cycled frequently. Or, perhaps in a home setting, the user might habitually suspend the guest when he or she is done using it rather than shutting it down as a way to save a little time. Or, a guest VM may be shut down but not restarted before the host machine is collected, leaving the contents of %tmp%VMWareDnD available to the examiner.


This article demonstrates that a host-to-guest file copy in the VMWare Player environment leaves potentially useful artifacts in %tmp%VMWareDnD. In several realistic usage scenarios, artifacts of relevance to the forensic examiner may be present in this location for an extended period of time. The artifacts may help determine the origin of relevant files, establish patterns of user activity, and reveal the prior contents of files that have been altered or deleted.

Preliminary testing indicates that a guest-to-host file copy similarly leaves artifacts in %tmp%VMWareDnD on the host machine. Further testing is necessary to describe the behavior of guest-to-host file copy operations in more detail.

Testing for this article was conducted in a VMWare Player environment. I presume similar behavior would be observed in other VMWare environments, but I did not have the software available for testing that hypothesis at the time of writing. I would be very interested to see how other virtualization products handle this operation as well.

I hope that this article is useful to forensic examiners conducting investigations involving virtual machines and that it encourages others to conduct similar research in other virtual environments.


Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10