10- VMWare Forensics with Autopsy

Suppose that you will want to perform a more detailed forensics analysis of a system that was part of one of our class exercises. There are a number of tools that can be used, and in this short lesson we will discuss using Autopsy from The Sleuth Kit. The currently released version is 3.0.5, and runs only on Windows.

Autopsy works on raw disk images, and the process of obtaining these images is not as simple as one might first expect, especially given some of the limitations in our classroom environment. In the lab, all the work must be done on virtual machines, as you are not allowed to install software on the hosts. The sheer size of a disk image file makes using them in a virtual environment quite a challenge, and finally there is the nature of VMWare virtual machines themselves to add to the mix.

That said, there is a solution, and I will demonstrate it by applying it to the Exercise Control system that was used in Exercise 2 this past week. This is a Linux system (CentOS 6.2), running email, NTP, Nagios, and a PHP web application that let attackers score points for the shells they obtained on the students. Good times.

One thing about this process though- it will take some time. We will be moving and analyzing files of tens of gigabytes in size, and this does not happen quickly. You can do other things while the various tools churn on the data, but budget at least a few hours to let the automated tools do their things.

Preparing the Virtual Machine

Take the virtual machine to be analyzed, and copy the files to a convenient location on your hard drive. This is a duplicate of the original virtual machine, as we want to be careful not to modify the original.

Load the machine in VMWare, but do not start it. Before we can perform our analysis, we need to remove all of the snapshots that have been taken. Start Snapshot Manager in VMWare by navigating VM → Snapshot → Snapshot Manager, or simply pressing CTRL+M.

Each time a VMWare Snapshot is taken, VMWare records the state virtual disk as well. We need a single disk image to proceed, so we start by deleting all of the snapshots. As this is done, VMWare will merge the various virtual dist states into the needed single disk. In this example, I had five snapshots; deleting all five took about 20 minutes, deleting the most recent snapshot first and moving back in time.

Once all of the snapsnots are deleted, visit the directory that contains the virtual machine. There you will see a number of files, including the .vmx file that contains the configuration information for the virtual machine, and the various .vmdk files that contain the virtual disk.

As only the virtual disk is relevant to us, we can delete all but the .vmdk files (remember this is a copy of your original virtual machine). One of the .vmdkfiles dis a small (1KB) file that does not end with a number; that too can be deleted as it contains configuration information rather than the disk image. Go ahead and open that file in a text editor to see its contents before you delete it!

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=1758f873
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"

# Extent description
RW 4192256 SPARSE "CentOS 64-bit-s001.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s002.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s003.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s004.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s005.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s006.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s007.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s008.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s009.vmdk"
RW 4192256 SPARSE "CentOS 64-bit-s010.vmdk"
RW 20480 SPARSE "CentOS 64-bit-s011.vmdk"

# The Disk Data Base 
#DDB

ddb.virtualHWVersion = "7"
ddb.longContentID = "aa6c2274dab6dff20cf38a821758f873"
ddb.uuid = "60 00 C2 9f ee e0 1c d5-65 8b ce 41 73 6d 41 39"
ddb.geometry.cylinders = "2610"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.toolsVersion = "8328"

The Joy of DEFT

With the virtual disk of the target prepared, the next step is to convert the result to a raw disk image for analysis. The easiest tool to do so is called qemu-img, however this is a Linux based tool. To make your lives somewhat simpler, I have installed qemu-img on a DEFT virtual machine.

DEFT Linux is an Italian Linux distribution that focuses on computer forensics and incident response; it has a number of tools (including Autopsy) that can be used to analyze a system. You can even use DEFT to perform a live analysis of a system by booting it off a CD-ROM (or a CD-ROM .iso).

Log on to the provided virtual machine as root; the password is "deft".

Now I know what you are thinking- how can we copy the entire virtual hard drive from one virtual machine to another? Well, we are not going to do that at all, actually. Instead we are going to use VMWare’s Host-Guest File System (HGFS); this is the same tool we used back when we were configuring Ubuntu 10.04 server.

From the DEFT virtual machine, navigate VM → Settings, then select the Options tab, and highlight the Shared Folders entry.

Select Add, and use the Wizard. The Host path is the location on the host where we stored the copy of the .vmdk files for our virtual machine. The Name will be used to determine where the result will be on the DEFT Linux guest. If the Name is set to "Forensics", then the directory /mnt/hgfs/Forensics in the virtual machine will be mapped to the Host path location in the host; in this example to C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics.

Enable the share, and be sure you do not mark it read-only.

To make your lives even simpler, I have provided a short Bash script on the Desktop of the DEFT image on the labshare that will work convert each of the .vmdk files to a raw image. Just copy that file to the location inside /mnt/hgfs/Forensics that contains your virtual disk, and run it.

[On my system, I have separate directories inside C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics for each system to be analyzed, so the location of my virtual disk for the Exercise control system is C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics\ExerciseControl. You can organize your set-up as you see fit.]

Just run the script from the proper directory, and go get a coffee. Or lunch. Or something.

deftvapp ~ % cp /root/Desktop/convert /mnt/hgfs/Forensics/ExerciseControl/
deftvapp ~ % cd /mnt/hgfs/Forensics/
deftvapp /mnt/hgfs/Forensics % ls
convert  ExerciseControl  Fermus  Trantor
deftvapp /mnt/hgfs/Forensics % cd ExerciseControl/
deftvapp ../ExerciseControl % ./convert 
CentOS 64-bit-s001.vmdk
CentOS 64-bit-s002.vmdk
CentOS 64-bit-s003.vmdk
CentOS 64-bit-s004.vmdk
CentOS 64-bit-s005.vmdk
CentOS 64-bit-s006.vmdk
CentOS 64-bit-s007.vmdk
CentOS 64-bit-s008.vmdk
CentOS 64-bit-s009.vmdk
CentOS 64-bit-s010.vmdk
CentOS 64-bit-s011.vmdk
deftvapp ../ExerciseControl % 

See, this part takes a while. It has some 25 G of data to generate, and that does not happen quickly. On my system, it took about 10 minutes to process each full .vmdk file. Since only the first two files were full, the whole process took half an hour. I have seen it take two or three times as long, especially when the disk is big.

At this point, your directory has both .vmdk and .raw files for the hard drive. You can dispose of the .vmdk files at this point, as all we need to do is to combine the various .raw files into a single whole.

[Why do I continually recommend deleting intermediate files in this lesson? Because if you do not, you can run out of disk space. At this point in the example, we have used 24 GB of space, and that does not include the virtual machines.]

Combining the files

You can use a simple cat command in Linux to combine all of these files, but my experience has been that the VM environment slows the process down considerably. Instead, I used the copy command from the Windows host, with the /b switch.

C:\Users\mike\Documents\2013 Case Studies\VMs\Forensics\ExerciseControl>copy /b
*.raw disk.img
CentOS 64-bit-s001.raw
CentOS 64-bit-s002.raw
CentOS 64-bit-s003.raw
CentOS 64-bit-s004.raw
CentOS 64-bit-s005.raw
CentOS 64-bit-s006.raw
CentOS 64-bit-s007.raw
CentOS 64-bit-s008.raw
CentOS 64-bit-s009.raw
CentOS 64-bit-s010.raw
CentOS 64-bit-s011.raw
        1 file(s) copied.

Again, be patient. This took about 20 minutes on my system.

Oh yes- don’t forget to delete the intermediate .raw files. We have our disk image, and that is all we need.

Now the smart among you have noticed a few things. We started by saying that we wanted to use Autopsy to do the analysis, and hey, it is one of the tools available in DEFT- navigate d → DEFT → Analisys tools. But didn’t we say that this is a Windows only tool? Well, it is, and frankly it does not run well on my Virtual Machine. There is the browser option though. I tried, it, but found it hard to use.

My recommendation is that we go back and load up the disk image in a Windows version of Autopsy. After trying the different alternatives, I think that you will agree.

Since we no longer need DEFT, we can shut that VM down, but before we leave it, let me encourage you to look around and try some of the other tools it provides. It is a nice distribution, and I wish we had more time to explore it all in detail.

Image Analysis with Autopsy

There is a virtual machine with Autopsy already installed available on the lab share. To use it, we again use VMWare shared folders. Proceed as we did before in VMWare. The only difference is the location of the shared folder in the guest. Because this is a Windows system, the shared folder is located in the directory \\vmware-host\Shared Folders.

Start Autopsy (there is an icon on the Desktop). Select "Create New Case". You may wish to consider all of the hosts from a single exercise as a single case, as Autopsy is able to analyze data from multiple hosts as part of the same case. This would better let you detect evidence that occurred across multiple systems.

The Base Directory will be used to store the information about the case; I simply set that you a folder on the desktop in this example. I did not choose a serial number or provide an examiner name.

With the case started, you will be asked to provide your first disk image. Give it the name of the full disk image you have created; be sure that you point it to the correct place! [The HGFS directory is considered a "Network Place" if you try to navigate by pressing buttons!]

I recommend that you enable all of the ingest modules.

Once the image is loaded, Autopsy will begin processing it. Again, this will take some time; you may want to budget roughly an hour for the whole process.

Once the analysis is complete, you will be able to search the entire drive for information.

The key here is that Autopsy indexes and searches the complete drive. Deleted and orphan files may still be present on the disk, even though they have been deleted from the file system; Autopsy still includes these files in its analysis.

You can also modify the list of keywords to be searched to include URLs, IP addresses, and email addresses. Remember though, that these are simple regular expression type searches, and as such they are vulnerable to returning many (many) false positives.

Note also that once these changes are made, Autopsy begins working through the disk image file again, and this can not only take some time, but it can lock up the program. That said, once the indexing is complete, you can find out quite a bit about the system. For example, here is a search for the IP address 10.1.2.33, and you can see from the screesnshot, that Autopsy picked up the use of that IP address in a deleted file, in what looks to be a snippet from a Nagios configuration.

If that is not sufficiently righteous and cool, you should navigate Tools →
Make Timeline (Beta). As you no doubt expect by now, this is not a speedy process. The results however, may prove helpful. Take a look at this screenshot, at notice how we can isolate what files were created, modified, or deleted on a day by day basis.

How much help this will provide to you depends on what Red Team did to your system- if the did not touch the hard drive, then this sort of analysis will not help. It will also depend on the types of questions you ask. Like all tools, especially all forensics tools, the tool does not provide the answers; it does not even provide the questions. However, it is a great resource.