Working with Volume Shadow Copies

To begin with, let me say right up front that most of the information in this post, particularly the latter half, is not something that I developed myself...consider this more of me being a secretary(albeit unpaid) for Rob Lee, Troy Larson, and apparently Jimmy Weg...apparently, these guys all knew about what I'm going to present here well before I started down this road.

That being said, away we go...

Based on something I saw in Troy Larson's presentation at DCC2009 regarding Volume Shadow Copies, I thought I'd try something...I wanted to see if I could mount an image of a Vista system from a Vista system, and access the Volume Shadow Copies within the image.

I started with a Vista Home Edition system and an image of that same system on a USB external HDD. I connected the USB external HDD to the live Vista system and mounted the acquired image with each of several tools. I used ImDisk, SmartMount v1.0.5, the 14 day trial copy of Mount Image Pro, and P2 Explorer.

In each instance I mounted the image as a drive letter, verified that I could access the volume, and ran vssadmin list shadows. In none of the instances did vssadmin recognize the mounted drive as a source of Volume Shadow Copies. Well, I take that back...I didn't even get that far with P2 Explorer...it automatically kicked off its MD5 hashing, and once that was done, reported that the image was corrupt.

Now, Troy had mentioned in his testing that only EnCase PDE will mount an image in a manner through which vssadmin can access Volume Shadow Copies within the image. Okay, well, that's not something I have available at this point.

Now, Troy, Jimmy, and Rob mentioned something in one of the lists recently that seemed interesting...basically, to summarize what was said...if you have a VMWare guest of Vista, for example, and you have an acquired raw/dd image of a Vista system, you can generate at .vmdk file for the image and add it to the Vista VM as a hard drive, and then you can 'see' the Volume Shadow Copies in the acquired image.

So I set out to see if this was something I could replicate. I used ProDiscover to create a .vmdk file for the acquired image (again...Vista Home OS), and I opened VMWare Workstation 6.5. I went to the settings for my Vista Ultimate VM and added the new .vmdk file to the properties for the VM as a hard drive. When I booted the Vista VM and logged in, I could see the acquired image right here as E:\. So far, so good.

I then ran vssadmin, like so:

C:\>vssadmin list shadows /for=e:

Lo and behold, I saw a list of Volume Shadow Copies for the E:\ drive! And yes, the entries for "Originating Machine" corresponded to the name of the system from which the image had been acquired.

The next step was to see if I could create symbolic links using mklink...the short version is that I could, but I could not access them, as I kept getting "The parameter is incorrect" messages. Suffice to say, I even created symbolic links for Volume Shadow Copies from the C:\ drive, and got the same message. It turns out that the issue with mklink is that the trailing \ is absolutely required (something that was also mentioned on the SANS blog). So the command looks like:

C:\>mklink /d C:\shadow \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy18\

With this, you can then run tools such as RegRipper against the hive files, or copy out selected files for analysis (or better yet, just run your tools to collect the information), etc. Once you're done, you can remove the symbolic link with:

C:\>rd C:\shadow

Before I go on, let me remind you...you MUST have a \ at the end of the Volume Shadow Copy in the mklink command.

Moving on, I downloaded George M. Garner, Jr.'s FAU tools and ran the following command:

C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6.dd --localwrt

HarddiskVolumeShadowCopy6 is one of the identified Volume Shadow Copies from the E:\ drive. I wanted to acquire an image of the Volume Shadow Copy to an attached USB external drive (G:\), hence the use of the --localwrt switch. For about 10 min, I let the command run, and kept running "dir g:\" from another command prompt, and kept seeing that shadow6.dd was 0 bytes. I stopped the imaging (Ctrl-C) and found that the output file was over 2.5GB! So I then re-ran the command, and just let it run...and it will run for a while, as I'm acquiring from a USB ext HDD to a USB ext HDD.

Here's the results of the 'dd' command:

C:\tools>dd if=\\.\HarddiskVolumeShadowCopy6 of=g:\shadow6_2.dd --localwrt
Copying \\.\HarddiskVolumeShadowCopy6 to g:\shadow6_2.dd
Output: g:\shadow6_2.dd
146526953472 bytes
139738+1 records in
139738+1 records out
146526953472 bytes written

Succeeded!

Now that the acquisition is complete, the next step is to verify the acquired image. Opening the image in FTK Imager, I was able to verify that I had a complete, readable file system. At this point, I can do everything with this image that I would with any other acquired image.

Again, let me remind you that this isn't something I came up with...apparently, others have known about this, I'm just writing it down.

Summary
1. Start with a raw/dd image of Vista or above
2. Create a .vmdk file for the image
3. Add the .vmdk as a hard drive to a VM of a like OS (if image is Vista, use a Vista VM)
4. Boot the VM, use vssadmin to locate VSC's on the image drive (or use WMI to get concise info)
5a. Use mklink to 'mount' the VSC's you're interested in, or...
5b. Acquire the full VSC using dd

Resources
Troy's Vista Forensics Slides (one version, anyway)
Shadow Copies on Wikipedia
Shadow Copy Client
Win32_ShadowCopy WMI Class

Mounting a DD image

One of the things I mentioned in my new book was an alternative analysis method for performing computer forensic analysis. I specifically mentioned the use of Mount Image Pro for mounting a dd image as a read-only file structure, which opens up some areas of analysis that many may benefit from using. For example, during an intrusion case, one thing you may want to do is scan the image with AV software. This may save you a great deal of time trying to locate hacker tools by hand. Also, this is something you may want to do when you may be faced with the "Trojan Defense".

Another thought/useful option is this - we all have things that we look for everytime we open an acquired image of a Windows system, and there are other things that we look for on a case-by-case basis. Most often we do this through our forensic analysis software package, such as ProDiscover or EnCase. However, even though these packages ship with scripts to do some initial data collection and parsing for us, sometimes, they aren't as complete as they could be, or we'd like them to be, and it takes forever to get scripts updated because the few folks that actually write their own scripts are busy with other things. Sometimes you may be in a rush or under pressure, and may forget something that you would normally look for. So what if we had a script or a tool that would run through an image, pulling things out for us each time...all automated so that we wouldn't have to remember all of the different places could look, but at the same time, its all documented? Say, the tool would check to see if the Recycle Bin had been disabled, and then move on to parsing the INFO2 file for one user, or all users. Or, the tool would collect the audit policy from the system, check the Registry entries for the Event Logs, and then collect statistics from the Event Log files themselves, or automatically parse the Event Log files to .csv format (or both). Would that be useful?

Another use of something like this is for forensic analysis training. Mounting the image as a drive letter lets you dig into aspects of forensic analysis that while accessible via commercial forensic analysis applications, may be somewhat easier to grasp and work with, particularly for new students, or junior members of an IR/CF team or CSIRT.

Okay, so now, how do we do this? How do we start with just a dd image, and get to a read-only drive letter (ie., F:\, G:\) so that we can point an AV scanner or some other tool at it?

To get the dd image to begin with, you can use ProDiscover, Helix, straight dd, or even FTK Imager Lite. If you're using ProDiscover, you can use the Tools -> Image Conversion Tools -> VMWare Support for DD Images... option to create the necessary .vmdk file.

Another option for creating the .vmdk file is to use LiveView. Point LiveView at the dd image, choose "Generate Config Only" in the GUI (maybe even designate the OS rather than having LiveView guess it) and you'll end up with several files, to include two .vmdk files and a snapshot. LiveView makes use of the VMWare DiskMount utility (don't forget the free VMPlayer), and even though this does not mount the image as a read-only file structure, you can set the read attribute on the image file itself (attrib +r imagefile) as a precaution. Use the vmware-mount.exe to mount the snapshot (imagefile-000001.vmdk)and all of the writes will end up in the snapshot.

Another option is to look at FileDisk. From the screenshot, FileDisk appears to have a read-only (/ro) option. I haven't tried this one yet...installation requires a reboot for the driver to be installed. However, FileDisk will also let you mount ISOs as CDs using the "/cd" switch.

Once you have your .vmdk file, take a look at VDK and VDKWin (scroll down to VDKWin). VDK gives you the .exe and .sys file for mounting image files as read-only file structures (according to the credits, VDK owes a great deal to FileDisk), and VDKWin gives you a GUI for managing it all. A nice thing I noticed about VDKWin is that it's simply a GUI for managing all of the command line switches in VDK. For example, let's say you image a Dell system that wasn't reformatted before being installed, and it has one of those Dell maintenance partitions at the beginning of the physical drive. VDK lets you list available partitions, and then select the one you want to mount. Rememer, when you grab VDKWin, don't forget to also get the core files from the top of the page.

I did test this out using a sample image. I started with the ProDiscover solution, and launched the .vmdk file via VDKWin with no problems. I tried LiveView, and though the DiskMount (vmware-mount.exe) approach worked fine, VDKWin balked at an "unknown extent type". The extent description section of the LiveView .vmdk file had two lines...simply deleting the second one caused VDKWin to hang. So, I removed the second line, and added the size entry to the first line, in essence replicating what I found in the .vmdk file produced by ProDiscover, and then everything worked just fine.

One caveat: I already have VMWare installed on my system...I read in a Google News post somewhere that in order to use some of these tools, you may need to have VMPlayer or one of the VMWare products installed, as the tools may use some of the DLLs. Just be aware of this if this is an avenue you're going to take.

So, what we're left with is a Windows-based solution, using freeware tools, to obtain an image, and then mount that image as a read-only file structure, for analysis. Many of the tools on the DVD that comes with my book, such as SAMParse, are designed to be run against raw Registry files and are perfect for use with this methodology. Sweet!

Addendum: I have an image that was created using FTK Imager Lite, broken into 2GB chunks. I opened the image in ProDiscover using the PDS file format, and started my analysis. Last night, I used the ProDiscover capability for creating .vmdk files ("VMWare support for DD images...") to create the .vmdk file by pointing the tool at the .pds file. Then, I installed VDK and VDKWin, but not any of the other VMWare tools. After setting the read-only bit on all of the image files (attrib +h), I ran VDKWin and successfully mounted the image as the K:\ drive, in read-only mode.

Even though I use a fully licensed version of ProDiscover IR, ProDiscover Basic is free (as in beer) and includes the ability to create the .vmdk files.