Wednesday, November 18, 2009

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

16 comments:

mjpinvestor said...

I tried this a few weeks ago using a Windows 7 Pro dd image, Windows 7 host and guest and VMWare 2.0 Server, and it worked as well.

Anonymous said...

As you know, VSS stores Volume ID with a snapshot to registry.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP\Clients
vssadmin can recognize a snapshot after Volume ID was registered with registry.
I confirmed it in VMware environment of Windows 7 & Vista.
However, I am still testing it ;-)

Jimmy_Weg said...

Looking at your summary, I'd shorten the process by just booting an image of the target system. Then, I'd run vssadmin in the VM. Next, I'd use Dan Mares' VSS to mount the shadow volume(s) of choice, and image them with FTK. I'd run FTK from a USB drive attached to the VM and image the shadows to that drive. It's slow, as Troy advised.

I haven't tried your outlined procedure, but I'm sure that it works if you've done it that way. In the 1-2 cases where I tried to use mklink, I was unable to access the linked image. I think that it's a permission problem, and others have found the same thing. I was unable to overcome the issue, but simply gave up when VSS worked so easily. If you find yourself in that boat, I'll be interested to see whether you can resolve the access problem.

Lee said...

I've found that booting the Vista disk image is a bit hit-and-miss. For cases where this doesn't work well I put the disk image in the VM and boot the VM with Windows FE. This allows me access to all the Shadow Volumes so I just DD the Shadow Volume out, as you've described Harlan.

As for Dan Mares' VSS. It looks like this tool has been discontinued and his site is shutting down. Does anyone know where I can get hold of this tool now?

Keydet89 said...

Jimmy,

In the 1-2 cases where I tried to use mklink, I was unable to access the linked image.

What do you mean? Did you receive an error message? If so, what was it?

Keydet89 said...

Lee,

Dan just posted to the CFID list this morning...you might try reaching out to Dan, rather than posting someplace where he may not be looking...

HTH

Jimmy_Weg said...

Did you receive an error message?

It wasn't an error, per se, but something like the message you get when you try to access a system-only folder.

Keydet89 said...

Jimmy,

Did you ensure that the trailing "\" was added to the GlobalRoot path?

JPS said...

Mounting the suspect drive via a write blocker to a vista system is the way to go on this. I have done it many times with great sucess

Jimmy_Weg said...

Did you ensure that the trailing "\" was added to the GlobalRoot path?
Yes. It wasn't an issue with creating the link, but accessing the link after it was mounted. Although the volume was "there," I could not access any object that it contained, nor could I image the volume.

du212 said...

For live images, I have used F-Response to connect my Vista target drive's VSC data to my Win7 analysis machine.

Troy has mentioned this too, and I tested that it works, you can also mount the VSS using cmds/tools like :

a) net share shadowcopy1=\\.HarddiskVolumeShadowCopy1\

or

b) Dosdev y: \\?\GLOBALROOT\Device\HArddiskVolumeShadowCopy1

du212 said...

Also of note re: booting VM images: if you stay virtually booted too long, you may run the risk of the VSS background process creating new VSC entries and thus deleting old ones. I had been playing with a Vista vm image 6+ monthes ago. I came back to it a two monthes ago to review something and noticed another user had "booted" my vm image for their testing of something. That period of activity (uptime) created new VSC entries and deleted my old ones.

iheartinfosec said...

Hi,

I'm not sure if you're still checking the comments on this posting, as it is a pretty old article...

But I recently followed all of your steps (which was VERY helpful for me) as part of a homework assignment. However, right now, my MD5 hashes of the images I have created from the Volume Shadow Copies are not matching the assignment's possible answers...

So I'm curious...in transforming the vmdk to a vhd...would that alter in any way the hash of the image that is created? Or is the --cryptsum function of FAU's dd.exe accurate? I'm stuck as to why the hashes of my VSC images would be off.

Thanks! I'm a big fan of all your posts!

Keydet89 said...

I receive an email whenever a new comment is added to any blog post...

...in transforming the vmdk to a vhd...

Perhaps. I know that using vhdtool.exe to convert a raw/dd image file to a VHD adds a 512 byte footer to the end of the file, which will change the hash. So it's very likely that converting your VMDK to a VHD file altered it enough to change the hash...after all, if all you did was flip a single bit, *that* would alter the hash...

iheartinfosec said...

Thank you for the quick reply.

If I wrap my head around whats actually happening, it does make sense that the hashes would be different. (Although I used vmdk2vhd as opposed to vhdtool, I imagine they work in similar ways.)

Thanks!

B!n@ry said...

Thank you for your great book and for this post. I was reading the book and did a test using Windows 7 64b running under Virtualbox, and when I didn't specify the "\\?" before the first "\" I couldn't get access to the VSC using the symbolic link.

Not sure if not using it on other systems might work or not. On mine I had to use the "\\?" and thought of checking with you and ask if you left it out from the book too.

Thanks again for your wonderful work.

Regards,