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
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