Virtual Server Investigations: VM Forensic Tools Remain MIA
Despite the increasing number of critical applications and secure data on virtual infrastructures, few forensics tools exist to be sure a VM is locked down, or find out why it wasn't once it's been compromised.
Mon, July 28, 2008
CIO — Computer forensics is an increasingly important field not only for investigating intrusions, hacks and data theft, but also to help analyze the security of a physical or virtual machine that has not yet been compromised.
Unfortunately, there is as great a dearth of forensic tools within the virtual environment as there are in other areas of virtual-server security.
Yes a Virtual Machine Disk File (VMDK) can be used by most if not all the forensics tools available from FTK, EnCase, Penguin SleuthKit, WinHex, etc.
Weak forensic capabilities are becoming more of a pressing issue, however.
Forensics can be broken up into two parts, one is acquisition, and the other is analysis. Some Forensics companies have tools that work within physical or virtual hosts to do on the fly analysis of data and usage. Those will still work within the virtual environment.
My concern is with the acquisition of data once it is determined that further investigation is required. How do you currently acquire a VMDK currently residing upon the Virtual Machine File System (VMFS)? If the VMDK resides on Windows or Linux file systems or is shared via NFS the acquisition is easier as those are well understood file systems.
On the other hand a VMFS is not well understood, largely because VMware has not yet released its format like as it has for the VMDK.
Do you acquire the entire VMFS just to get one VMDK?
Do you acquire the single VMDK, if so, how can you do this in a forensically sound method?
How do you handle the large data stores used by virtual infrastructures? What if the VM spans multiple data stores and includes Raw Disk Maps (direct LUN attachments), uses iSCSI Initiators, USB over IP, or NPIV SAN attachments?
If you do acquire the VMFS, how can you do it in a 100-percent read-only mode with no running VMs upon it? How can you ensure the VMFS or VMDK is not changing during acquisition?
Assuming all these questions are answered, now we begin the analysis. Assuming you are starting from a VMFS, how would you find the VMDK you want when the format is not known? Do we have to resort to trial and error?
Is it even possible for data to be hidden on a VMFS? If they are an administrator, of course it is. Thankfully a VM cannot hide data on a VMFS, only within the bounds of the VMDK.
There is a need for better tools and information from VMware to make forensic acquisition and analysis a reality within the virtual infrastructure.
