±Forensic Focus Partners
|New Today: 0||Overall: 36212|
|New Yesterday: 2||Visitors: 167|
A Discussion of Virtual Machines Related to Forensics AnalysisBack to top Back to main Skip to menu
A Discussion of Virtual Machines Related to Forensics Analysis
Examination of the Virtual Machine
Traces of a Virtual Machine
Before analysis can be conducted on a VM, it must be found. In most instances, it is a simple as finding a folder named, "My Virtual Machines". In other cases, there may only be traces of a virtual machine indicating that the actual VM may reside elsewhere, such as on external media or may have been deleted from the source drive. If it is suspected that a VM should exist on your evidence but is not found, a search for traces of VM systems can be conducted to determine if that actually is the case.
Recovering traces of a VM or a VM application will typically not yield the contents of the data residing in the VM, as the trace remnants may only be references (.lnk files) to a VM/VM application. However, the occurrences of these traces may give investigative leads to either look for the actual VM on other media or as an indication of computer user activity related to virtual machines. The existence of a VM application is not typically considered unusual or illegal. However, given computer user statements that may be counter to the evidence discovered, the mere existence of a VM can be potentially important in establishing credibility of the computer user if that user is denying the current or past existence of a VM.
Quite simply, the easiest and clearest example of trace evidence consists of recoverable deleted VM files and applications. This can include the "My Virtual Machines" folder, specific VM files, or uninstalled VM applications. Although the target VM may not exist, these obvious references will indicate that you may need to recover additional media for analysis that may exist elsewhere.
There are a number of VM applications available commercially and through both open source and freeware. Many of these applications require an installation on the host machine in order to run a VM. From these types of applications, inferences that a VM may exist is clearly evident in that the application to run a VM exists on the hard drive. Even if these applications are uninstalled, there are remnants left behind that can give the same indication that a VM exists or existed.
One remnant that may be 'left behind' after an application is uninstalled or a folder being simply deleted is that of the program icon residing on the hard drive. As an example, Mojopac , may leave its icon (ringthree.ico) on the hard drive. System files, such as a shared dll file, may also exist, even after a 'complete' uninstall of a VM application. With Mojopac, the dll "RingThreeInstallerHelp.dll" may be found in a temp folder even if the application no longer exists. These types of files, extraneous to the operation the programs and sometimes inadvertently left behind by their own uninstall program, can give additional information as to the installation and use of the programs. This information may particularly be of importance concerning the dates and times associated with the files. This would apply to related system files as well. Unfortunately, without knowing which files may be left behind with every type of VM application, it is very likely that these will be missed if uncommon VM applications had been used or are unknown to the examiner. With this thought, it could be a valid expenditure of time to determine what programs had been/are installed and the purpose of unknown program types.
Lnk files, prefetch files, and MRU references will typically exist independent of the applications. These file types can give relevant information that a VM application/file did exist as well as additional information relating to their MACE metadata information.
The registry will most always contain remnants of program installs/uninstalls as well as other associated data referring to VM applications. File associations maintained in the registry will indicate which program will be started based upon a specific file being selected. In the Windows registry, under HKEY_CLASSES_ROOT, file associations can be seen. File extensions that exist which are identifiable as VM file extensions will show the application configured for opening that file. As an example, VM Player will be shown to run when files with the vmdk extension are accessed, so even if VM Player does not currently exist on the media, the file association may be indication that it did exist at one time.
Considering that a text list of known VM applications can be created (an online search quickly reveals that there are over 50 different applications currently available, and certainly, more to be developed), a keyword search of as many virtual applications that can be found may reveal trace VM information residing on the hard drive.
Several VM applications, such as VMware (Workstation/Server/Player), will install virtual adapters for use in their virtual machines. The existence of "VMware Network Adaptor" without the presence of a VMware application can be a strong indication that the application did exist on the computer in the past.
It is important to note, that although trace evidence may be found to indicate a VM application may have been accessed in some fashion on an electronic media, it does not necessary confirm that the application was actually installed on that media. Several VM applications can be accessed and run from externally attached media, to include USB flashdrives or even run from a CD. These externally accessed devices are sometimes considered 'throwaway' or 'disposable' operating systems due to the simplicity of use of having an extensive array of applications accessed virtually coupled with the ease of quickly throwing away the device to avoid detection or recovery as evidence. This use of a VM can be considered to be "anti-forensics" if intended by the user to avoid detection of computer use activity by forensic experts.
Collection and Recovery of Deleted or Encrypted Virtual Machines
Through data recovery/forensic means, many deleted files can be recovered, in part or whole, depending upon the severity of the fragmentation and method of deletion. Given a typical scenario whereby a user deletes a file to the recycle bin and empties the recycle bin, it is usually possible to recover those files in whole for review. Virtual machines, because of their typical sizes, may not have been sent to the recycle bin due to a file size limit of the Windows Recycle Bin. These files will be deleted directly by the system, but still may be recoverable for analysis. However, given a certain amount of fragmentation and inability to fully recover a VM, it may be impossible to examine the contents of that VM, at least to the extent of examining it as a physical system.
The encryption of a VM can be through several layers. The actual folder containing the VM can be encrypted by either basic Windows encryption (EFS , full disk encryption such as BitLocker , etc), or a by a 3rd party encryption application. Bypassing this encryption ranges from possible to highly improbable depending upon the level of encryption. Additionally, the virtual operating system itself may be encrypted. As a virtual machine behaves as if it is a physical machine, it enjoys the same benefits of being able to be encrypted as an operating system, just as its host system can be encrypted. The access of encrypted files or the access of encrypted operating systems (virtual or otherwise) is a study beyond the focus of this paper. The encryption of the VM files is like any encrypted file and must be handled in the same manner.
Imaging and Cloning of Virtual Machines
Traditional acquisition of physical operating systems has generally involved abruptly interrupting power to the computer and cloning (imaging) the hard drive by use of hardware or software write blockers with software imaging applications. As the forensic imaging of a physical hard drive includes all data on the hard drive, any VM that exists will be cloned in full, as it exists on that hard drive as well. In theory and practice, there could be more than one VM on a single hard drive, even to the extent that dozens of various types of VMs can exist on a single hard. In this type of scenario, the act of creating one image of a hard drive in fact may be creating one image containing dozens of (virtual) self contained operating systems.
Virtual machines of interest that exist on a physical media that is not of interest, can be acquired without the need to image the physical media by copying the files of the VM. This method, although workable in obtaining the VM files, may not be the preferred method in collecting best evidence, as additional data related to the VM existing on the physical media may be of vital importance to the examination. This additional evidence can be in the form of MACE dates and times of the actual files and VM application as well as files and activity that may have occurred between the host and virtual machine. It would be better evidence gained to forensically image the host media and export the VM files from the forensic image. As can be seen in Figure 2, there are several files associated with a virtual machine that are needed for the VM to function.