Determining VHD s in Windows 7 Dustin Hurlbut

Transcription

1 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

2 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.

3 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

4 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 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

5 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.

6 Figure 3 Creating a Custom File Identification in FTK

7 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

8 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

9 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).

10 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

11 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.

12 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 E. 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 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.

13 Figure 9 MBR drive ID to MountedDevices to the GUID in MountPoints

14 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 E) in MountedDevices that has a value name of \??\Volume{<guid>}. In this example, it is just above the \DosDevices\T: Value: 0x 2F E 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>

15 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.

16 Figure 10 Mounted Virtual Drive and Mounted.vhd File

17 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.

18 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 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 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 store the creator application. In Windows 7.vhd files, the value win is placed here.

19 Offsets is the creator host for the OS. In Windows 7 test VHDs, the value Wi2k is stored here. Offsets 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 At offsets is stored a unique identifier for the hard disk. Its format is in the 128-bit Universally Unique Identifier (UUID). Figure 13 -.vhd Footer Offsets

20 References 1. Virtual Hard Disks in Windows Frequently Asked Questions, Microsoft, June 15, 2009, 2. Virtual Hard Disk Image Format Specification, Microsoft, October 11,