forensically determining the presence and use of virtual ...forensically determining the presence...
TRANSCRIPT
AccessData Virtual Machines in Windows 7 Page 1
Forensically Determining the Presence and Use of
Virtual Machines in Windows 7
Dustin Hurlbut
Introduction
Windows 7 has the ability to create and mount virtual machines based upon launching a single file. The
Virtual Hard Disk (VHD) format permits creation of virtual drives that can be used for data storage,
backup, and testing. A user can place large amounts of data in a virtual drive and then copy the
representative unmounted file to any other computer. It appears most of the Windows 7 versions
support the creation of VHDs. The file that stores the VHD is stored with a .vhd extension. Besides
being able to create and attach virtual drives in the Manage utility, Windows 7 Ultimate, Enterprise and
Server 2008 R2 can also boot to a virtual drive. Microsoft also has a standalone version available.
The obvious forensic issues would be the use of virtual drives by suspects to store incriminating data.
Mounted drives can be used to store and backup data, and once detached will look like a large file with
the contents being visible only by remounting or use of forensics tools to view them. It’s nifty way to
hide things from another user. Data is carveable and keywords visible in an unprotected .vhd.
It would be easy for a user to create a virtual drive, mount it, place the data in it while it is mounted, and
once unmounted, change the name of the file’s extension from VHD to some other extension or just
hide the VHD in some area not likely to be noted by a casual user. Once unmounted, the .vhd file can be
copied and opened on any other system that supports the format.
Other options include the ability to nest a .vhd inside of another. The user can mount a virtual drive and
then mount another inside of it. Microsoft only permits two nested drives1.
Another important feature is when a system is shutdown, non-bootable mounted VHDs will not
remount automatically upon reboot. Thus if the system is powered down in a raid environment either
with power or by pulling the plug, it won’t be apparent that the virtual drives were mounted upon
forensic acquisition and analysis.
Of course, a user can mount and then encrypt a .vhd file using volume encryption like TrueCrypt or
BitLocker or non-volume like EFS or other file encrypting algorithms. The user can either place an
encrypted volume inside the mounted VHD using TrueCrypt or can choose to encrypt the VHD volume
which can then be auto mounted. This method would mask the data inside and render it impossible to
find data via text searching the raw unmounted .vhd file. BitLocker can also be used to encrypt a virtual
drive. All the same issues apply to decrypting the drive as a regularly encrypted BitLocker hard drive;
namely, the need for a recovery key and the necessity of imaging logically.
The testing for this document was conducted on Windows 2008 Server R2 and Windows 7 Ultimate
systems. In actual investigations of other versions, they should be tested for consistency and to confirm
these findings.
AccessData Virtual Machines in Windows 7 Page 2
Creating a VHD
Virtual machines can be created in the Manage Utility (right click on Computer and select Manage) by
selecting the Action drop down menu and clicking on Create VHD. Supply a location and filename for
the VHD and decide on fixed or dynamic sizes. Supply the file size if a fixed size is selected and click on
OK. See Figure 1. In fixed size creation, the file size will be the same as the selected size of the drive.
Figure 1 – Creating a VHD
Next, right click on the Disk# tab in the Manage utility to the left of the drive’s bar graph and select
Initialize Disk. Select the type of partition formatting desired; MBR or GPT and click OK.
AccessData Virtual Machines in Windows 7 Page 3
To finalize the drive and format it, right click on the drive’s bar indicator (to the right of the drive# tab)
and select New Simple Volume. This will start a wizard to allow assigning a drive letter, selecting a file
system, and formatting the drive.
Once completed, the drive will appear to be a physical drive in all respects from the point of view of the
operating system (See Figure 1, last frame). It will behave as a physical drive to Windows Explorer and
the MountedDevices registry entry in the System file will use the standard drive identifier located at
offset 440-443 in the Master Boot Record (MBR) of the virtual drive.
Forensic Determination of the Presence of VHDs
Trying to find virtual drives forensically isn’t normally too difficult. If a user is archiving data in a VHD,
they are easily discovered by sorting on the .vhd file extension in the user’s image. The usual operating
system file artifacts in a user’s NTUSER.DAT registry file may also be present in the form of RecentDocs
and in the ComDlg32 Most Recently Used (MRU) entries. Use of the internal virtual drive utility in
Windows 7 creates entries for each of these MRU lists (see Figure 2).
Figure 2 - RecentDocs List of .vhd files in the NTUSER.DAT
The only issue in locating .vhd files is if the suspect takes steps to hide them, such as changing or
removing the file extension to mask them. VHDs can be mounted after their file extension is removed.
In the example in Figure 4, FTK is used to process an image containing several .vhd files. Prior to
processing, a Custom File Identification can be created to identify all VHDs in the image by header. FTK
will then place them in a user named container. This speeds up the analysis by placing all the .vhd files
in one location, so they can be quickly analyzed for potential evidence by exporting and mounting.
The process to create a custom header identification is documented in Figure 3. During the case
creation process, click the Detailed Options button. This will bring up the Evidence Processing dialog
box. After the processes to perform are selected, click on the Custom File Identification button (upper
left corner below Evidence Processing). Click on the Manage Custom Identifiers and then Create New.
AccessData Virtual Machines in Windows 7 Page 4
Figure 3 – Creating a Custom File Identification in FTK
AccessData Virtual Machines in Windows 7 Page 5
Name the Custom Identifier and provide a description if desired. Double click the Value column at the
bottom to enter the desired header (See Figure 3). In the case of .vhd files, I have been using:
0x 33c08ed0bc007c8e
Note: If the beginning offset for a header is not zero, it can be set in the preceding Offset column. Once
completed, click on Close and save the custom identifier to a file. Once the custom identifier is stored as
a file, it can be called up on a case by case basis to classify files by header.
Figure 4 - Using FTK to identify .vhd files during processing
Forensic Determination of the Use of VHDs
There are a number of ways to demonstrate use of VHDs by a suspect. The above mentioned
examination of MRUs in the registry of the host system will show VHD activity.
The best method is to examine the Windows 7 event logs regarding the mounting and unmounting of
virtual drives. The event file is located in the Event Viewer left pane menu list at the following path:
Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\VHDMP\Operational
An Information Event ID of 1 indicates a surfacing of a .vhd file. Microsoft refers to mounting a VHD as
“surfacing” and unmounting as “unsurfacing”1. The log viewer will supply the path and filename
mounted, date/time of access, and the physical drive number assigned to the drive. See Figure 5.
An Event ID of 2 indicates a VHD has been unsurfaced and will also have the path, filename, and
date/time of unsurfacing. It interesting to note, that if a virtual drive is functioning when the system is
shutdown without a manual dismount, there will be no event identification (2) indicating it was
unsurfaced.
AccessData Virtual Machines in Windows 7 Page 6
Figure 5 – Windows 7 Event Log Viewer / VHD Event Logs
An examination of the link files of a user’s system may help ascertain if the .vhd files have been in use on
the system. Link files can contain a volume name and volume serial number to compare to those
contained in the mounted virtual drive. See Figure 6.
Figure 6 - Link File pointing to a virtual drive
AccessData Virtual Machines in Windows 7 Page 7
This would require mounting the .vhd file to determine its volume name and serial number. Mounting
can be accomplished with current forensic tools as most mount a .vhd as an image file (see Figure 7).
Figure 7 – Mounted .vhd file in FTK Imager showing the Volume Serial Number at offset 72
The image can also be mounted in Windows as a Read-Only drive by selecting the Read-Only check box
when attaching the device. See Figure 8.
Prior to mounting the first and third device
After mounting the first and third device
AccessData Virtual Machines in Windows 7 Page 8
Figure 8 – Selecting Read-Only when mounting a .vhd file in Windows 7
The top panel of Figure 8 is a list of hashes for three .vhd files prior to mounting. In the middle panel, is
a list of those hashes after mounting the first and third .vhd. One of the files was mounted and
changed by adding a folder to it. The second was only mounted, but otherwise not changed. Both the
hashes changed upon mounting the device. Both VHDs were NTFS file system formatted.
The bottom panel of Figure 8 shows the hashes after mounting the diffvhd.vhd file. In this case, prior to
mounting the Read-Only check box was selected. With limited testing, I have found the .vhd file’s hash
does not change when using read-only surfacing.
The drive letter assigned may be determined by an examination of the MountedDevices subkey in the
System registry file. In the example in Figure 9, the .vhd occupied the T drive. The first four bytes in the
\DosDevices\T: value are 0x 2F 03 43 5E. This is the drive identifier for this “physical” device located at
offset 440 in the MBR of the .vhd file.
Mounting the .vhd and viewing the drive identifier in its MBR will allow determination of which .vhd file
was used for this drive letter. The four values at offset 440-443 match to a file called BACKTRACK
VHD.vhd.
The drive letter at \DosDevices\<driveletter>: is volatile data. If this VHD was unsurfaced and another
VHD, HDD, or USB were mounted and used this drive letter, the drive identifier value will be overwritten
in favor of the new device’s identification. However, the drive will still be identifiable as having been
mounted as there is a persistent number assigned in MountedDevices as well as the volatile one. This
persistent entry is preceded with a \??\ <guid> value name with the drive identifier assigned in the same
first four bytes of its value. This data is not removed when the drive letter is used by another device.
AccessData Virtual Machines in Windows 7 Page 9
Figure 9 – MBR drive ID to MountedDevices to the GUID in MountPoints
Master Boot Record
of the VHD File
System Registry
File of the Host
NTUSER.DAT Registry
File of the Host System
Specific User
AccessData Virtual Machines in Windows 7 Page 10
It can also be determined which user launched BACKTRACK VHD.vhd and at what time it was mounted.
First, find the persistent Globally Unique Identifier (GUID) for the drive. This can be determined by
finding the drive identifier (in this case 0x 2F 03 43 5E) in MountedDevices that has a value name of
\??\Volume{<guid>}. In this example, it is just above the \DosDevices\T: Value: 0x 2F 03 43 5E with the
same value header. The GUID is:
68f3aeb8-a1ab-11df-b5da-a8aa87d6c78d
Open the NTUSER.DAT for the suspected user (in this case the NTUSER.DAT for user Dustin) and
navigate to the following path where <guid> is the GUID for this device:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\<guid>
Highlight the GUID assigned to this device by MountedDevices and note the Key Properties last written
time, shown in Figure 9 (bottom panel). This date/time is the last written date/time for the subkey
highlighted. This updates each time the user mounts the device. This method also works to determine
the time/date of mounting a USB device. When testing this value, be sure to account for lazy writes as
this value doesn’t always update immediately upon mounting of the device. Logging off or restarting
may be required to consistently update this value for testing purposes.
The storage artifacts that record the volumes mounted for .vhd files are kept in a number of places in
the registry similar to USB information. The drives are identified in the SCSI subkey at the following
location:
HKLM\System\ControlSet###\Enum\SCSI\Disk&Ven_Msft&Prod_Virtual_Disk
Each drive is identified with a number similar to the old Parent ID Prefix (pip) seen in Windows XP for
USB devices.
There are also references to them in the following path:
HKLM\System\ControlSet###\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b}\
##?#SCSI#Disk&Ven_Msft&Prod_Virtual_Disk#<pip from scsi subkey><classidguid>
This location is one of the class identifiers that specify device attachments that are used to identify the
last time a specific USB was connected. Note the Msft reference in each path. MSFT is the Microsoft
stock identifier and this reference is used in the virtual entries in the registry. MSFT is commonly used in
company blogs in place of the company name Microsoft.
Virtual drives are also referenced by their volume name in the ReadyBoost drive storage archive in the
Software registry file at:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\EMDMgmt
AccessData Virtual Machines in Windows 7 Page 11
Mounting a VHD for Analysis
When the virtual drive is mounted by the operating system, it is in all appearances a physical hard disk
drive. The first panel in Figure 10 shows the drive mounted while it is live. The second panel shows
mounting the .vhd file as an image file. The two views appear to be the same. VHD images can be
viewed and evaluated by mounting with your forensic tool of choice. As mentioned earlier, the issue is
finding them.
Many of the current forensic tools will mount .vhd files as an image file, so the structure can be
examined for relevant files to the investigation.
Figure 10 – Mounted Virtual Drive and Mounted .vhd File
AccessData Virtual Machines in Windows 7 Page 12
Once mounted, the examination will be a standard analysis of the file system for relevant data using
keyword searches, viewing user created and deleted files, and data carving.
Figure 11 – FTK Imager view of deleted files
Figure 11 shows a standard look at artifacts such as those deleted from the operating system and
recycle bin.
VHD Footer Offsets2
In addition to the analysis of the relevant data, the .vhd also contains a footer that may yield important
forensic information about its creation. This footer is located in the last sector of the physical .vhd file.
The header begins at the sector boundary of the last sector in the file. It is contained in offsets 0-7 and
contains the header word “conectix” to identify a Microsoft Virtual Server file. Data sets stored in this
footer appear to be in big endian format. See Figure 13 for Offset Table.
AccessData Virtual Machines in Windows 7 Page 13
Figure 12 – Footer information in a .vhd file
Offsets 24-27 contain a date/time stamp of when the VHD was created. This date and time, according
to Microsoft, is based upon the number of seconds since January 1, 2000, 12:00:00 AM UTC time. This
appears to be a new date/time stamp to convert (possibly an XFat date/time stamp). I couldn’t find a
converter for it, so for testing purposes, I added the hex value 0x 38 6D 43 80 to the stored value (the
number of seconds between 1970 and 2000) and used the Unix 32-bit, big endian converter to get in the
ballpark. This would not be forensically sound, so at some point, someone hopefully will build us a
converter for this date and time stamp.
Offsets 28-31 store the creator application. In Windows 7 .vhd files, the value “win” is placed here.
Offsets 36-39 is the creator host for the OS. In Windows 7 test VHDs, the value Wi2k is stored here.
Offsets 40-47 stores the size of the .vhd file in its original state. This value is in bytes and does not
include the last 512 bytes where this footer information is stored.
If the disk is expanded, the current size will be displayed in offsets 48-55.
At offsets 68-83 is stored a unique identifier for the hard disk. Its format is in the 128-bit Universally
Unique Identifier (UUID).
Field Type Offsets Size in Bytes Standard Value
Header 0-7 8 conectix
Date and Time Stamp 24-27 4
Creator Application 28-31 4 win
Creator Host OS 36-39 4 Wi2k
Original Size 40-47 8
Current Size 48-55 8
Unique ID (UUID) 68-83 16
Figure 13 - .vhd Footer Offsets
AccessData Virtual Machines in Windows 7 Page 14
References
1. “Virtual Hard Disks in Windows – Frequently Asked Questions”, Microsoft, June 15, 2009,
http://technet.microsoft.com/en-us/library/dd440865(WS.10).aspx
2. “Virtual Hard Disk Image Format Specification”, Microsoft, October 11, 2006
http://technet.microsoft.com/en-us/virtualserver/bb676673.aspx