The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics",
as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".

Tuesday, January 04, 2011

Accessing Volume Shadow Copies

Over the past months, I've had some work that involved Windows systems beyond XP...specifically, one Windows 7 system, and I had some work involving a Vista system. Now, most of what I looked at had to do with timelines, but that got me to thinking...with the number of systems now available with Windows 7 pre-installed (which is pretty much everything that comes with Windows pre-installed), how much do we really know about accessing Volume Shadow Copies (VSCs)?

Troy Larson, the senior forensic-y dude from Microsoft, has been talking about Volume Shadow Copies for quite some time. In his presentations, Troy has talked about accessing and acquiring VSCs on live systems, using George M. Garner, Jr's FAU dd.exe; however, this requires considerable available disk space.

Troy's SANS Forensic Summit 2010 presentation can be found here. In his presentation, Troy demonstrates (among other things) how to access VSCs remotely on live systems, using freely available tools.

ProDiscover - Chris Brown has a presentation available online (from TechnoSecurity 2010) in which he discusses using ProDiscover to access and mount Volume Shadow Copies on live systems...remotely. Pretty cool.

I ran across a QCCIS whitepaper recently that discusses mounting an acquired image using EnCase with the PDE module, accessing the VSCs using the same method Troy pointed out, and then copying files from the VSCs using robocopy. There are also a number of posts over at the Forensics from the sausage factory blog that address VSCs, and a couple that include the use of robocopy. As I often work with acquired images, being able to access VSCs within those images is something I'm very interested in being able to do. However, most of my online research points to folks using EnCase with the PDE module to mount their acquired images when demonstrating how to access VSCs within those images...and I don't have EnCase.

So...what if you don't have access to EnCase or the PDE module? How could you then access Volume Shadow Copies within an acquired image?

TestingI started out with a host system that is a fresh install of Windows 7 Professional, 64-bit. The acquired image I started with is of a physical disk of from a 32-bit Vista system; as it's an image from the physical disk, it has several partitions, including a maintenance partition. The acquired image is called "disk0.001". I also extracted the active Vista partition as a separate raw/dd image, calling it "system.001". I verified the file systems of both of these images using FTK Imager to ensure that I could 'see' the files.

So the first thing I did was mount the image using FTK Imager 3.0, and noted the drive letter for the third partition...in this case, I:\. I opened a command prompt and used the 'dir' command to verify that I could access the volume. I then typed the following command:

vssadmin list shadows /for=i:

This got me an error message:

Error: Either the specified volume was not found or it is not a local volume.

Okay. I fired up ShadowExplorer, but the I:\ drive was not one of the options available for viewing.

I tried mounting the system.001 file, and then tried both image files again using ImDisk, and each time got the same result...running the vssadmin command I got the above error message. I also tried using the "Logical Only" option in FTK Imager 3.0's "Mount Type" option, and that didn't work, either. So, at this point, I was failing to even identify the VSCs, so I could forget accessing them.

I reached out the QCCIS guys and John responded that FTK Imager 3.0 seems to mount images so that they appear as remote/network drives to the host OS; as such, vssadmin doesn't 'see' VSCs on these drives. This also explains why ShadowExplorer doesn't 'see' the volumes, and why I get the same error message when using ImDisk. I also got in touch with Olof, the creator of ImDisk, and he said that ImDisk was written using the method for creating drive letters available in NT 4.0, prior to the Volume Mount Manger being included in Windows; as such, getting ImDisk to mount the volumes as local disks would require a re-write. Thanks to Olof for ImDisk, and thanks to Olof and the QCCIS guys for responding!

I then installed the VMWare VDDK 1.2 in order to get a version of vmware-mount that would run on Windows 7. I had booted the acquired image using LiveView, so I had a .vmdk file on my drive for this image. After installing the VDDK, I ran "vmware-mount /p", and clearly saw the 4 volumes within the image...I knew that I wanted to access volume 3. I then ran the following command:

vmware-mount /v:3 x: f:\vista\disk0.001.vmdk

This resulted in an error message stating that vmware-mount could not mount the virtual disk. Checking the log file that was produced, the first message I see is that the image file, disk0.001, "failed to open (38): AIOMgr_Open failed." I'm still researching this one...

Getting It To WorkSo, at this point, I'm stuck...I want to access files within the VSCs in an acquired image, and I don't have EnCase/PDE. So far, my attempts to just see the VSCs have failed. So, I grabbed a copy of vhdtool.exe, which is available from MSDN (it is described as "unmanaged code"). Originally, I wanted to get a copy of this as I have XPMode installed on my Windows 7 Professional system, which means I have Virtual PC...but I don't want to boot the vhd file at this point, so that's not a required component. So I made a copy of system.001 to another storage location and ran the vhdtool.exe with the "/convert" switch. This apparently adds a footer to the file...which I'd read about during my research and is the reason I made a copy of system.001 to work with (don't want to muck up my original in case all of this doesn't work...know what I mean?). I should note here that running the tool adds the VHD footer to the file without changing the file name...so even though I apparently now have a VHD file, I can still see only "system.001".

Next, I opened the Computer Management interface in Windows 7 and fired up the Disk Manager. I then chose Action -> Attach VHD, and browsed to my new VHD file. Before clicking "OK", I made sure to check the "Read-only" box. I then had Disk2 added to Disk Manager, and the Volume listing included a new G:\ volume. In both instances, the drive icon was light blue, as opposed to the grey drive icon for the other drives on my system. When I ran the vssadmin command against the G:\ drive, I could see the VSCs! Oddly enough, the G:\ drive is NOT a visible option in ShadowExplorer.

Next, I ran the mklink command against the last VSC identified on the G:\ drive. To do this, I selected everything on the line following "Shadow Copy Name:"...the stuff that says "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy40".

mklink /d c:\vista \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy40\

Note: The final trailing "\" is EXTREMELY important!

From here, I could now access the files within the VSC. Several folks have mentioned using robocopy to get copies of files from within the VSCs, using something as simple as a batch file. See the QCCIS whitepaper for some good examples of the batch file. This is a great way to achieve data reduction...rather than acquiring an image of the VSC, simply mount it and access the files you need. Another idea would be to use RegRipper (include RegRipper's rip.exe in a batch file) or a forensic scanner to access and retrieve only the data you want. For example, when you access a user's UserAssist key and parse the information, if they've taken an action before (launched an application, etc.), you only see the date/time that they last took that action, and how many times they've done this. By accessing VSCs and running RegRipper, you could get historical information including the previous dates that they took those actions. Let's say that you use something similar to the batch file outlined in the QCCIS whitepaper, and include a command similar to the following (you may need to modify this to meet your environment):

rip.exe -p userassist -r D:\vsc%n\ > user_ua%n.txt

Now, this assumes that your VSCs are mounted with mklink under D:\vsc; %n refers to the VSC number.

Something similar would also be true with respect to MRU lists within the Registry...we know that the LastWrite time for the key tells us when the most recently accessed file (for example) was accessed; accessing VSCs, we can see when the other files in the MRU list were accessed.

When you're done accessing the mounted VSC, simply remove the directory using rd or rmdir. Then go back to your Disk Manager, right-click the box to the left in the lower right pane, and select "Detach VHD".

If you need a command line method for doing this, take a look at diskpart...you can even include the list of commands you want to run in a script file (similar to ftp.exe) and run the script using:

diskpart /s

This, of course, leads to other questions. For example, we've seen how, if you have a full image, you can use vhdtool to convert the image file to a vhd file, or extract the pertinent partition (using FTK Imager) and convert that raw/dd image to a vhd file. But, what if you have a vmdk file from a virtual environment? One option would be to use FTK Imager to re-acquire the file to raw/dd format; FTK Imager opens vmdk files, as well as EnCase format images, just fine.

There's a tool available from the VMToolkit (produced by the VMWare folks) that will reportedly convert vmdk files to vhd format. Apparently, Starwind has a free converter, and some have mentioned that WinImage should work, as well. I haven't tried any of these, so YMMV.

Over and above what I blogged about in Forensics from the Sausage Factory and pertinent to the scenario detailed above in your post, I think you could add the vmdk you have as an additional drive to another Windows 7 VM in VMWare.

This additional drive will then get a drive letter and from then on the robocopy method may be carried out from within this additional VM.

Thanks, I tried that...added the vmdk file to my Windows 7 VM as an additional disk and clicked "Power on this virtual machine". I immediately got an error message about being unable to open the vmdk file due to "insufficient permission to access file". I'm an admin on the system I'm using, and should have full access to vmdk file, as well as the raw/dd file it points to, per the permissions I see.

When I added the disk file, under "Mode", I selected Independent, and Nonpersistent. That allowed me to boot the VM. I'll need to run the VM from a system with more RAM after I upgrade VMWare Workstation, but it appears to work.

I would still recommend using FTK Imager to make a raw/dd image of the vmdk file, as that would serve as your "working copy", leaving your original "evidence" untouched. Further, using vhdtool provides for a completely free solution, where you would need to purchase VMWare Workstation, or somehow obtain a valid Windows 7 VM to use in VMPlayer.

Disks mounted with vmware-mount also will not allow access to the shadow volumes with vssadmin. Only Encase/PDE. You also could take a snaphot of your vmdk and boot i, as an alternative to the change in persistence.

As I've suggested before, absent EnCase, it's easiest to access the shadows in a VM made from an image. Just make your image R/O, create a vmdk file in WordPad, snapshoot the machine, and boot. Your image will remain untouched. Shadow Explorer works well in an image, but mklink is handier. Shadow Explorer is painfully slow, too. Robobcopy probably works well, but you also can use FTK Imager to create image files from folders of interest, and that's probably a better approach insofar as maintaining evidence is concerned.

You could also run a command to mount all of the shadows at once. Otherwise, just arrow-up in your mklink command box and edit the shadow number to increment it upward to the next (I delete the finished shadow in explorer beforehand).

It's handy to run a tool like XWF in your VM to do a quick exam of a mounted shadow. For that matter, you can add objects to an XWF Container as an alternative to FTK Imager. Of course, you can image the shadow if neccessry, though you'll get a lot of unnecessary stuff.

What about not using VMWare at all? I'm not saying that you can't, but when you look at all of the steps required, if you have a Windows 7 system already, simply using vhdtool would seem to be much easier...I'm just sayin'...

As it relates to the registry, something I found useful was to make comparisons between ntuser.dat files in order to see what activity occurred on a certain day. I extract the ntuser.dat files from the VSS before and after the day of interest. I compare the files using the program you suggested in the Win4n6 group which was regdiff.pl in the Parse::Win32Registry module. This is just another option to help see what occurred on a certain day.

Perhaps, but I build a VM in almost every one of my cases. For one, it's a relatively quick and foolproof way to check config settings on current applications. It also give me a "feel" for the user that I just don't get from an image.

Oddly enough, the G:\ drive is NOT a visible option in ShadowExplorer.Shadow Explorer only will address shadow volumes from within the same volume as it is invoked. So, if you boot to C:\, that's where it will access the shadows.

Antoher option is to restore the image to a disk. Then, attach the disk to Vista/7, and go about the vssadmin/mklink process. (Or boot the original system with a VOOM.)

We have updated the procedure outlined in the QCC Whitepaper. Creating the hard links using the 'mklink' command was based on the shadow copy number shown in the vssadmin output i.e. VolumeShadowCopy1 (rp1). This is all very well but if you, or someone else, needs to repeat the analysis or provevance a particular file that you have extracted, knowing that it was from 'rp1' doesn't help. This is because when you remount the image in the same or another workstation it does not have the same shadow copy number.We now use a small script to name the hard link in accordance with the date that the shadow copy was created. This makes provenancing extracted files much easier.

Jimmy.It's been a while but I seem to remember finding little cross tool support for FTK Imager logical evidence files (particularly for EnCase users...). I haven't used FTK logical evidence files for a while so this may have changed. I would otherwise agree that it would in some ways be better than using robocopy. The method we have developed though is very good at quickly targeting particular file types, pictures, movies etc, albeit by extension. Of course, one of the limitations of this approach is the potential to miss files through the lack of signature analysis. Using wildcards to extract all folder files is one way to overcome this but I guess there is a trade off to be made between the time and space you have available and what sort of data you are looking for.

True. If you have FTK (I do, but use it rarely), it'll work fine. The other approach with using XWF and creating evidence containers also works, but you need XWF (perhaps only the Investigator version) thereafter. My exams of shadows volumes typically are quite focused, requiring information from select folders.

My last comment (in response to Gary's) hasn't posted yet, but I'll add another nonetheless. One other benefit of using a VM to access shadow volumes is the ability to repair the VSS when it's corrupt and you cannot access the volumes. Usually, the repair requires the editing of the system registry or registering DLLs that might have been missing.

If you add an image of a disk through PDE, or through a cloned drive, to your system, you still can't access the shadow volumes on the damaged target. I've had only a couple of cases like this, but the repairs seem to be required on the live system that contains the shadow volumes. Perhaps a far greater talent like Troy can explain this further.

Well, let's say that you're in a VM and run vssadmin list shadows /for=x: and you're presented with something like "Volume Shadow Copy Service error: Unexpected error calling routine CoCreateInstance. hr = ." The fix probably requires either edits to the registry and/or re-registering certain DLLs. Trolling through listserves and MS Tech can yield the answers. In my last case, the fix came from simply deleting a key and restarting the services.

I believe that you're going to have to do this type of repair on a live (VM) system. The VSS on your target is damaged; not on your host. From a test or two, I found that I could not access the shadows on a mounted drive (clone of original) when I attached it to a good system. I'll liken it to trying to run a typical program from an attached drive; it doesn't work. I suppose that you could test this by corrupting the registry on an image and going forth with the VHD approach.

By repair, I mean fixing the system so that VSS works. You can start by registering the DLLs and if that fails (and I haven't had much luck with that approach), I delete the above key. The DLL fix is as follows (run from %systemroot% after making sure that the services are stopped):regsvr32 ole32.dllregsvr32 vss_ps.dllvssvc /Registerregsvr32 /i swprv.dllregsvr32 /i eventcls.dllregsvr32 es.dllregsvr32 stdprov.dllregsvr32 vssui.dllregsvr32 msxml.dllregsvr32 msxml3.dllregsvr32 msxml4.dll

One more thing about working in a VM. You must take care that you don't lose the earliest shadow volume when the machine boots. That can happen if allowed disk space is near max and it's time to create a restore point. Just make sure that you study your image to be sure that they're all there in the VM.

I usually examine the earliest shadow before I install VMware Tools, as the install will create a restore point. Installing Shadow Explorer may do so, too. Plus, just lingering too long will have the same effect.

I wouldn't say that it's a "result" of booting the image. It's just going to happen at a certain time or upon a certain event. I'm not really sure what you mean, however. The image is added as a virtual disk. You're booting the virtual disk, which really is the image.

"I want to access files within the VSCs in an acquired image, and I don't have EnCase/PDE."

The iSCSI solution...

1) Expose the disk image as an iSCSI target on your host or a VM.2) Connect to the iSCSI target using iSCSI initiator from a Windows host or VM and access the VSC.

As an example:Setup an iSCSI target using a SIFT Workstation VM. Get the image setup as a linear file (e.g. "mount_ewf.py IMG.E01 /mnt/raw" or "affuse IMG.001 /mnt/raw"). So the file /mnt/raw/IMG appears as a dd/raw of the whole disk. Modify the iSCSI enterprise target daemon configuration (/etc/ietd.conf) as below and restart the daemon (service iscsitarget restart).

Sorry to raise and old thread but it was the best method I had for contacting you.

What i'd like to know is whether or not I could use FTKImager via psexec. ie copy ftkimager files, get shell, execute ftkimager to copy only registry and user hives and create dir listing.

I can see ways to image the complete physical drive but not just specific areas? The reason is that many of the machines i deal with a remote and we are unable to connect drives to the machine for imaging. So i need to limit to just what i need to create a solid timeline.

thanks for the reply harlan. Since speaking with you last I've found a number of tools that assist me to copy the required items.Firstly hobocopy-https://github.com/candera/hobocopy"It uses the Volume Shadow Service (VSS) to "snapshot" the disk before copying. It then copies from the snapshot rather than the "live" disk."

Do you see any issues with the above for gathering copies of the hives?

I noticed that FTKImager Lite has command line options for /CreateDirListing however i haven't had any success with this. Do you know if command works only on already taken images or does it work against live systems too? If so do you have an example of the command line you'd use for a physical drive.

Ha ha, yeah, it is slightly more work to get it running (even though his guide was spot-on, which is great for a still-fairly-n00b Linux user like me), however I like to have a few ways of doing the same things, especially since I've had a few occasions when P2 Explorer didn't want to mount the evidence.

Besides using mount_ewf.py, is there another way of mounting an .e01 image as a dd image? I want to go through the process you've described in this post, but all my evidence is in e01 format. Which brings me to a second question: do you have a preferred format to acquire to? Sorry to bombard you.