Forensically Determining the Presence and Use of Virtual ...Forensically Determining the Presence...

AccessData Virtual Machines in Windows 7

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.


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.


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.


Figure 3 – Creating a Custom File Identification in FTK


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.


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


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


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.


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


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


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


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.


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


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

Forensically Determining the Presence and Use of Virtual ...Forensically Determining the Presence...

Documents

Transcript of Forensically Determining the Presence and Use of Virtual ...Forensically Determining the Presence...