Archive for October 2012

Other Tools & Approaches to Access Shadow Volumes

I. Shadow Scanner

In the first section of this post, I’m going to review another way to examine shadow volumes, by using a commercial tool named Shadow Scanner, which is produced by EKLsoftware.  One of our esteemed colleagues, Rob Erdely, is on the EKLsoftware team and is very well versed in Shadow Volumes.  The link above also guides the reader to a couple of videos that nicely explain Shadow Volume basics and the Shadow Scanner application.

Please keep in mind that I’m not going to present a tutorial on Shadow Scanner (SS), beyond a simple demonstration.  The guys at EKLsoftware already have done that through their videos and PDF documentation.  My aim is to show that you can avail yourself of SS’s powerful features right in your SEAT workstation.  You don’t need to restore the image (which is unnecessary with respect to almost any shadow volume exam).

As we’ve seen, accessing the Shadow Volumes from an image or mounted image (volume) directly on forensic workstation, through Windows, generally is not possible.  While we can do so by converting our image to VHD format, doing so requires editing our dd image file as I described in a previous post.

In a nutshell, SS allows an examiner to compare Shadow Volumes with the target’s current system to see whether files were changed, deleted, or added.  I’ll start with a video in which I set up a scenario.  Previously, I added the virtual disk (vmdk file), which I created from my image of the target system, to my SEAT workstation.  It’s Volume F:

As you saw, I added a file to, and deleted some files from, an arbitrarily chosen folder.  Next, we”’ run SS.

As we saw, SS compared the target folder with the current volume and noted files that had been deleted, i.e., not present in the current volume, but present in the selected shadow volume.  SS also noted the created file, i.e., present today, but not in the selected shadow volume.  Using your SEAT VM allows you to employ SS without restoring the image file or installing SS in a booted image of the target.

Again, there are all kinds of options that SS affords an examiner.  For one, you’re not limited to selecting only one shadow volume to scan and compare.  Visit the SS site and have a look.  The publishers also are kind enough to offer a trial version.

II. Another Approach

One last point on getting your image file into your SEAT workstation.  In an earlier post, I described how we add a custom-built, virtual disk to our SEAT workstation.  Generally, I create VMs from my target image files because I want to boot the target and kind of immerse (pun on Windows 8 intended) myself in the user’s system.  However, you don’t have to create a vmdk disk.  You can mount an image (any format) in your host and add the mounted image to your SEAT workstation.  Watch.

Note that, in FTK Imager, I selected the Block Device / Writable method.  This allow “writes” to the disk to be cached, as opposed to actually being written to the mounted image.  I also left the Mount Type as Physical & Logical, although I could have chosen Physical Only.

Next, we’ll add the mounted, physical disk to our SEAT workstation.

If we mount the image as Block Device / Read Only with FTK imager, we have to take a snapshot of the SEAT workstation before we boot it with the mounted disk attached.  When you boot your VM, you may see a couple of things that catch your attention.

Insofar as the SCSI disk warning is concerned, you may ignore it and click OK.  The second screenshot reveals that Windows wants to check one of our disks, which is the newly added physical disk, for consistency (CHKDSK).  You may just let it proceed, or canceling likely will have no effect.

Virtual Resurrection

I think most of us agree that, in addition to shadow volume exams, one of the most useful features of building a VM from an image is to determine the configurations of various programs.  Although details of configuration files are available for a number of frequently encountered applications, it’s often easier to simply run the program in a VM and determine the setup of the program.  For example, I found this approach to be especially useful in peer-to-peer (P2P) exams, with respect to programs like LimeWire, FrostWire, etc.  More specifically, while config files can tell us which individual files are shared, parsing through them is quite an undertaking.  Anytime we start parsing complex files, the chances  of error also increase.  If we run the application in a VM, we can review the configuration in a virtually (no pun intended) fail-safe environment.

Obviously, to run an application in a VM, the application must exist.  What about a case in which you know that the subject employed a particular application, but your exam of the acquired image reveals that the program no longer exists?  A VM will only afford access to those objects that exist, although we always can explore shadow volumes.  However, we can’t run most applications from a shadow volume folder or mounted shadow volume.  It’s analogous to trying to run an application from a mapped volume; it may work with some, but not all, applications.  I’m going to review a couple of approaches to “bring back the dead.”  I’ll say up front that these methods are somewhat experimental and don’t always work.  There also may be other approaches to this project, but mine assumes that you want to run the previously existing application in its native system.

Much depends on the complexity of the application that you want to restore and the method by which it was removed.  I’ve found that most users employ the application uninstaller to remove an unwanted program.  Some applications, particularly  P2Ps, remove the application folder from the Program Files directory, but leave behind the configuration files, which usually are in the user’s AppData tree.  The first approach is a simple copy and paste where we copy the application folder from the most recent shadow volume in which the program existed.  We can start by using the quick shadow volume exam approach that I outlined previously.

When I undertake a program resurrection, I usually start with a base VM of the target, before I install VMware Tools or do anything that may disrupt the system.  In my example, we know that the subject used a P2P program named LimeZilla.  However, a look at the image file revealed that the application’s program folder was not present in Program Folders (x86).

Here are a couple of screenshots of the target VM to illustrate the point.  The first shows the AppData\Roaming folder for the LimeZilla config files.

Next, here’s a look at the Program Files (x86) folder.  The LimeZilla folder is missing.

Next, we’ll navigate to our available shadow volumes and look for the previously existing LimeZilla program folder.  Here’s a video.

It’s always best to get as recent a copy of the application as possible.  Applications, particularly P2Ps, are fussy about matching the executable with the proper version of the configuration files.  Next, let’s see whether we are successful.

We now have access to the most recent version of the application.  At this point, we can install VMware tools depending upon our goals.

We’re apt to find cases in which a simple copy and paste won’t work.  In those instances, we resort again to the shadow volumes and try a system restore.  Before I present a few warnings, I’ll demo the process.

The process may take quite a bit longer than the video made it appear.  In case you didn’t notice, my desktop background reverted to what it was at the time of my selected restore point.  In my example, I had installed VMware tools, although I usually don’t if I want to restore a system.  By going back in time, I lost my VMware Tools as well as my installation of FTK Imager.

I did manage to recover my Skype installation. Frankly, this process isn’t successful very often, and the old BSOD presents regularly.  For one, by going back in time, we probably returned to a time before we edited the drivers through the registry services.  If that happens, you can try to fix the VM by returning the restored VM system’s registry to boot from the LSI SCSI drive.  Even so, I’ve had some failures in this approach.

I do have a couple of other approaches in the testing phase of my research.  When I make them a little more reliable, I’ll add a post.