grandeduc - Fotolia
When dealing with running a possibly compromised virtual machine -- whether creating an image as a part of an e-discovery...
motion or for incident response -- a forensically sound method of imaging the virtual machine disk (*flat.vmdk) should be used.
While the virtual environment is much more complicated than a physical realm, VMware makes forensic acquisition and incident response tasks fairly easy. Simply put, everything associated with a running virtual machine is contained in its respective VMDK container, and all of the necessary tools to acquire the image are built into VMware ESX and ESXi.
Locating the VMDK container
In order to use VMware's more powerful features, such as VMotion, HA and DRS, the VMDK container will need to reside on shared storage. The VMDK container is not likely to be found on the host's hard drive.
To locate the respective VMDK, the built-in "Maps" tab in vSphere can be used, as seen in Figure 1.
The Maps view shows the relationship of the virtual machine and the respective storage that contains the virtual machine's VMDK container. In Figure 2, it is easy to see that the virtual machine SRV02 is operating on the host esx01, and its files are being stored on the shared storage device LABVMFS01.
Now that we know where the VMDK container is located, we will need to create a snapshot of the running virtual machine. A snapshot is created to literally freeze the virtual machine's parent disk. When creating a snapshot, a new child disk is created and all writes will now go to that child disk, leaving the parent disk in a static state. Additionally, the parent disk (*flat.vmdk) is essentially an abstraction of a physical disk, hence, it is the equivalent of a bit-by-bit copy (in dd or raw format) of a hard disk. In the simplest of terms, in forensics we always want a bit-by-bit copy, as it will provide both allocated and unallocated space of the disk. If a traditional file copy of a physical hard disk would only provide allocated space, you would not be able to recover deleted files.
With the snapshot created, the next step would be to create a hash of the original parent disk, *flat.vmdk. As we saw in the Maps view, the virtual machine is being hosted on esx01. Log into esx01 over SSH and navigate to /vmfs/volumes. Here you should see the VMDK container of the target virtual machine SRV02, along with the other virtual machines hosted on esx01. Navigate to the SRV02 folder, and you will see all the files associated with the respective virtual machine. Now it is simply a matter of using the built-in md5sum command in the host to create a hash value of the *flat.vmdk file and piping it to a file, for example, md5sum *flat.vmdk > srv02.md5.
Next step: It's time to copy the *flat.vmdk file
As noted earlier, the *flat.vmdk represents an abstraction of a physical disk in dd or raw format, meaning you already have your disk image in an acceptable format and can now copy it without any concern.
In vSphere, go to Home > Inventory > Storage views, and select the respective data store. Right click to bring up the Datastore Browser, as seen in Figure 3. Navigate to the respective virtual machine disk container and simply upload the *flat.vmdk file and the file containing the hash.
Since there is no native hash utility built into the Windows OS running vSphere, you will need a third-party tool to create a hash of the copy of *flat.vmdk. The HashTab tool makes hashing a file as easy as right clicking the file, bringing up the properties dialog and selecting the "File Hashes" tab. As long as the hash of the original file matches the hash of the copy you created, you now have a forensically sound image of the virtual machine disk (Figure 4).
With the disk properly imaged, you can now consolidate your running virtual machines snapshot and then begin your analysis of the forensically sound image of the virtual machine disk image.
About the author:
Paul Henry is a senior instructor with the SANS Institute and one of the world's foremost global information security and computer forensic experts with more than 30 years of experience covering all 10 domains of network security. Henry began his career in critical infrastructure/process control supporting power generation, and currently manages security initiatives and incident response for Global 2000 enterprises and government organizations worldwide. He is also a principal at vNet Security LLC, and serves as a retained security expert for multiple financial and healthcare firms.
Don't miss this intro to cloud forensics on SearchCloudSecurity
Find out how the VENOM zero-day vulnerability can affect virtual machines
Learn the basics of cloud VM risk scenarios