The goal of this analysis, after completing the analysis I originally intended to do with the image, was to see if the hibernation file (hiberfil.sys) existed as a "previous version" in a VSC.
My original analysis involved creating a timeline in order to develop a detailed understanding of a malware infection associated with a targeted threat group. The system had been infected over a year ago, and at one point late this past summer, the AV had quarantined the malware and "cleaned" the persistence mechanisms.
|VSCs in FTK Imager|
I accessed the VSC of interest using the VHD method outlined here (note: this blog post contains the commands used). I still have a copy of vhdtool.exe (seems to no longer be available, possible replacement linked here), so I used the "convert" option to change the *.001 file to a VHD format; this operation essentially adds a footer to the image file. In order to attach the VHD via the Disk Management utility on my Win10 analysis system, I had to change the file extension from "*.001" to "*.vhd"; the file still opens just fine in FTK Imager.
Everything went fine using the vssadmin and mklink commands to access the VSC of interest, and I then added the resulting folder as an evidence item to FTK Imager (choosing 'contents of a folder'). I was able to extract the files I wanted at the time, but I did not that this method did not provide me with the necessary access to extract files such as the $MFT, etc. At the time, for the analysis I was doing, that was not an issue.
The issue came up later when I mentioned to Jamie Levy that I had Windows 7 system with VSCs available, and that the hibernation file within the image itself was not a useful source of information about the malware, because the malware had been quarantined about a month prior the hibernation file being created. Jamie said she was curious to see through testing if the hibernation file was covered by VSCs; that is, could I go back to the VSC of interest and retrieve/extract a previous version of hiberfil.sys?
Jimmy Weg has a good number of blog posts that address VSS; Jimmy's done a lot of great work and shared it. In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system. At the time that I did this, I was simply interested in collecting a copy of the $MFT, which is why I was pursing it...at the time, I wasn't interested in comparing hibernation files.
After attaching the VHD and running the vssadmin command to enumerate VSCs from the newly-attached volume, I used the following command:
D:\Tools>vss x: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
This resulted in a RAM disk being added to my analysis system. I didn't see it in Explorer, nor in the Disk Management utility, but I could add it as a logical volume to FTK Imager.
Removing the drive was easy:
Drive X: removed
If you're interested in mounting multiple VSCs sequentially, take a look at Jimmy's blog posts and consider using Dan Mare's vss.exe.
While chatting with David, he mentioned that the method used to access VSCs may have an effect on what I was seeing, or what I could access, and he suggested that I take a look at using libvshadow to access the VSCs.
Step 1: Get the tools..look for "...windows compiled version of libvshadow..."
Step 2: Install Dokan (I went with v.0.7.4, as David mentioned via chat that 0.7.something was the latest stable release)
Step 3: Run mmls to get the sector offset to the partition of interest
mmls -i raw -t dos z:\image.vhd
This gave me a sector offset of "0000002048" to the partition.
Step 4: Run vshadowinfo (not really necessary)
I'm including this step for completeness...vshadowinfo and vshadowmount require byte offsets, and 2048 x 512 = 1048576, so we will use 1048576 to designate the byte offset to the partition we're interested in:
vshadowinfo -o 1048576 z:\image.vhd
Step 5: Run vshadowmount
vshadowmount -o 1048576 -X allow_other z:\image.vhd x:
|X:\ volume contents|
Note: After hitting "enter" following the above command line, the command prompt did not return; this is normal. Don't do anything...don't hit "ctrl-C" and do not close the command prompt. You can minimize it, but do not forget that it's there.
Step 6: Access VSS1 using FTK Imager
I opened FTK Imager and added VSS1 as an image file. It parsed and opened a little slower than a "normal" image would (the image itself is on a USB drive, and the VSC had to be parsed...). However, I now have access to the VSC as a raw/dd image. This VSC was created on 13 July 2015, and I can not only extract files that were quarantined on 13 Aug 2015, but I can also extract a previous version of the $MFT and other system files. I can even mount the contents of the VSC by choosing "File->Image Mounting..." via FTK Imager.
If you left the command prompt up in the background, you'll see stuff scrolling by...when you're done doing what you want to do with the VSC and have closed FTK Imager, or just removed the evidence item, bring the command prompt into focus and hit "Ctrl-C"; the prompt will return, and you'll no longer have an X:\ volume on your system.
I opted to use libvshadow to access the VSC and extract hiberfil.sys. I did that, and use Volatility to convert the file to a raw memory dump, and then ran the imageinfo command; even though the VSC that I'd "extracted" the file from had been created on 13 July 2015, the output of the imageinfo command said that the file had been created on 13 Sept 2015. I then hashed both hiberfil.sys files and got the exact same hash.
As such, using this method it appears that the hibernation file is not "tracked" or affected by the Volume Shadow Service; that is, you don't get previous versions of the file.
Addendum: After publishing this post, David Cowen pointed me to this MSDN page that discusses files excluded from VSCs. Checking the Registry key HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup on my analysis system, I see that the hibernation file is listed (as is the pagefile).
Addendum, 29 Dec: I had a chance recently to work with another Windows 7 image file, and found that it contained two difference files. I then used Arsenal Image Mounter to mount the image read-only, and was able to enumerate VSCs using vssadmin.
If you perform your own testing and find something different, I'd greatly appreciate knowing the process and tools you used.
The research, testing, and most importantly, interaction with other analysts really demonstrates that there a number of methods available for accessing historical information on Windows systems that do not require dongles, and do not require the purchase of commercial applications. Also, you don't need to know Linux, or how to install and compile libraries. Using native Windows tools, you can access the contents of a VSC as you would any other folder, but with a couple of freely available tools, you can get even deeper access, to the point of accessing the $MFT within the shadow volume.
During my initial analysis (prior to the testing outlined here), I extracted a couple of specific files from the VSC and created a mini-timeline in order to add context to my original timeline, and develop a clearer picture. And it all took just a couple of minutes.
And it doesn't end there. David Cowen's been producing a series of blog posts on automating DFIR work, and he has a blog post that walks you through accessing VSCs within an acquired image programmatically, via Python. The final Python script that David makes available essentially accesses each VSC, searches across it for specific files, and collects information about those files.
VhdxTool - possible replacement to vhdtool (Note: I have not tried this tool)