Shadow Copy Volume forensics will enable an investigator to examine data at many different time snapshots during a forensic examination. While XP Restore Point snapshots only gather key files including the registry, the shadow copy volume will allow access to them all. Investigating shadow copy volumes in organizations might become a key investigative tool for both e-Discovery and traditional forensics. First off, a hats off to Troy Larson, Senior Forensic Investigator from Microsoft, who just put this information out into the forensic community. In addition to his own research, Troy was able to query the Microsoft development team of the Volume Shadow Copy for additional capabilities. As a result, I have been a happy forensic investigator all day long playing with the capability.
Shadow Copy Volume Background
Shadow copy is an exciting new possibility for forensic investigators looking for an additional edge in computer forensics. Restore point data, similar to what is found in Windows XP, does not exist in the same format in Windows 2003, VISTA, or Server 2008. 2003, VISTA, and Server 2008 now log changes to the entire volume and keep track of the specific clusters that are changed between each snapshot in the new Volume Shadow Copy Service or VSS.
Volume Shadow Copy Service (or Shadow Copy) is very similar to the “Time Machine” service for Macs. It performs a cluster by cluster diffing/backup and stores that information. In a nutshell, you can rewind a file, a directory, or even an entire volume to a previous state. This is wonderful for incident response and forensic investigators.
All versions of VISTA have Shadow Copy enabled by default, however, only Business, Enterprise, and Ultimate have a way to access it easily. In a way, it is very similar in concept to VMware snapshot where it backs up differential changes in the volume into a snapshot file. Note: the following techniques have only been tested on VISTA Business version. Further testing would need to be accomplished on other versions of Microsoft products with Shadow Copy enabled.
.
This is a snapshot of the of the restoration points created by VSS. If you notice the entire volume of C can be backed up to earlier dates. This would mean that if a user wiped a file today it could be recoverable at an earlier point in time that was where a shadow copy snapshot took place. If an investigator examined the shadow volume created from the previous day’s snapshot, the file is recoverable from that volume. The shadow volume that can be examined is an exact duplicate backup of the entire volume including unallocated space.
How many shadow volumes will an investigator have access to? It depends on disk size. Generally 15% of disk space is allocated for the volume shadow, however, upwards of 30% of disk space could be utilized.
Which versions of VISTA are VSS enabled? For all versions, system restore will utilize the VSS in order to back the computer up to a previous snapshot. For Business, Enterprise, and Ultimate versions, “Previous Versions” is enabled that will allow a user to “rewind” a file, a directory, or an entire volume. However, the VSS service is up and running on the basic and home versions of VISTA, but the previous versions option is not displayed.
Important: Currently, you can only examine shadow copy volumes if you have the original device the shadow copy volumes are on. You cannot examine or recover shadow copy volumes from a disk image file mounted on your workstation via ntfs-3g, Encase, vdk, or mount image pro. However, you can examine a volume image duplicated from the Shadow Copy Volume. More on this shortly…
You have to mount, in read-only mode, your original hard drive that contains the shadow copy volumes on an VISTA machine. This might change as more capability is developed, but it is important to note that the best way to analyze/examine shadow copy volumes is by having access to the original drive or machine where they were created from.
List the Shadow Copy Volumes
How many Volumes are stored on the system you are examining? You can obtain a list of existing shadow volumes in the Volume Shadow copy Service by executing the tool, vssadmin.
To obtain a list of the shadows execute: C:> vssadmin list shadows /for=C:
.
Things to notice.
-
The Shadow Copy Volume is the name of the volume that we will use to examine the contents of that specific volume. You might want to write the exact name down.
-
The originating machine would be noteworthy if you have plugged in an NTFS drive from another shadow copy enabled machine.
-
The system time at the moment the volume was created. This time is important as it may indicate which shadow copy volume may contain your data.
From the output of vssadmin, note the total number of shadow copy volumes from the machine. In this example, it only shows three. But there were 15 total shadow copy volumes that were listed as a result of running the “vssadmin list shadows” command. This particular machine had a 700 GB partition volume allocated for the C drive. If you decide to image the shadow copy volumes, you could theoretically have over 16 separate 700 GB logical images created from this one machine, each one from a different point in time.
Live Shadow Volume Examination
On a live machine it might be useful to manually browse or scan a directory that contains a shadow copy volume. It is relatively easy to do this from an administrator enabled command prompt using the tool mklink. mklink creates symbolic links, which are new to VISTA, from the command line. You can create a symbolic link from a shadow copy volume to your desktop easily by executing the following command.
From your previous output of vssadmin, select one of the “Shadow Copy Volume” names based off of the date in time you would like to examine. Then create the symbolic link using mklink pointing it at a directory followed by the device name of the shadow copy volume you wish to parse.
C:> mklink /d C:shadow_copy21 \?GLOBALROOTDeviceHarddiskVolumeShadowCopy21
Very important! It is important you do NOT forget the trailing slash at the end of the mklink command!!! Without it you will receive a permission error.
This capability would be incredibly useful in situations where a bad guy might have wiped a file. You could recover it by going back a day or two in the shadow copy volume to retrieve the file from allocated space.
Imaging a Shadow Volume
It is also rather simple to image the full volume of a specific shadow by utilizing one of the latest versions of the dd.exe command by George Garner and the output from the vssadmin list shadows command.
Using the “vssadmin list shadows” output, identify the shadow copy volume number you wish to image. In this situation, you would utilize the part of the device name that includes “HarddiskVolumeShadowcopy#” The # (number) is the number of the shadow copy volume you wish to acquire a full disk image from.
All the regular options in dd apply, but to image execute a command similar to the following on your machine that contains the volume shadow copy or the read-only original drive containing the volume shadow copy.
In this command F: is a USB drive plugged into bn.;’the machine. The – -localwrt option allows the dd.exe tool write to a local mounted drive.
dd.exe if=\.HarddiskVolumeShadowCopy4 of=F:snapshot4.img –localwrt
Shadow Forensics
Mounting your collected shadow copy volume image is easy using the ntfs-3g command from your SIFT workstation.
Commands typed:
# ntfs-3g –o ro,loop,show_sys_files snapshot4.img /mnt/hack/snapshot4
In addition, you can examine the image utilizing any of the sleuthkit tools, perform unallocated space analysis, and perform file carves as you would a normal image. Remember we had 15 shadow copy volumes and the original volume. We could theoretically examine 16 total images from a single machine. Each one a full disk volume from that moment in time.







6 Comments
I’m having trouble following the method you describe. I have an Encase image of a Vista drive that I have restored to a hard drive, which is connected to a Vista machine via firewire. When I try to run the dd command it comes back with the error “fauerror_409.dll”. It may be with not being sure how to list the path to the shadow copy on the external drive. Do I need to create a symbolic link?
Interesting… I wasn’t able to test this technique… let us know if it works in the end.
Two questions:
1. Does vss list shadows command work on the drive?
2. Also do you have the LATEST release of FAU from George Garner’s site? Seems like older versions = fail.
Thanks… Rob
The list command works, and I get 15 shadows. I am using the dd dated Sept. 19, 2008. I will keep trying.
Thanks for the very informative post. Is there a difference between your imaging approach and restoring system restore points in a VM? It seems that there is volume shadow copy for each restore point, though I’m not sure whether that’s the rule. In a VM, you could employ snapshots and invoke system restore for selected points, and then use the resulting vmdk file(s) as your image.
Rob
Interesting post, Jimmy pointed out to me that you suggest that “The shadow volume that can be examined is an exact duplicate backup of the entire volume including unallocated space.”
This struck me as being a little unlikely; what would be the point of keeping a snapshot of all the unallocated on a volume every time. There would be such a huge overhead in processing time and disk space that it would not make sense.
I have done a couple of experiments by creating a small NTFS partition and switching on restore points (aka shadow copy) for that partition. I have imaged a shadow copy produced using FAU dd and it produces an image which is the size of the whole partition, and so it includes unallocated space.
Where files exist on the partition currently, i.e. they have been added after the time of the shadow copy and you then take an image of the shadow copy, the files currently existing appear in unallocated space on the image of the shadow copy. The MFT records for those files are zeroed out on the shadow copy MFT.
Where a FileOld in the shadow copy existed in the same location on the volume as a currently existing FileNew then the shadow copy FileOld overwrites as many of the current FileNew’s clusters as are needed and overwrites any cluster slack where any would exist. If the shadow copy FileOld does not occupy as many clusters as the current FileNew then the remaining clusters of the current FileNew will be in unallocated.
A shortened explanation of this might be – there doesn’t seem to be any point in imaging anything other than existing files from a shadow copy.
H
Here’s my experience…
I recently had a vista case where I was able to find indecent pictures of children in one of the shadow files. I followed the instructions above to image the relevant shadow file.
Once I had the shadow file loaded into EnCase I found that these pictures were in unallocated space.
Are we now saying that these were randomly put back here or is there a system to putting the pictures back exactly where they would have been?
My suspicion was that the portion of UC overwritten during use is saved to the shadow file but Harry seems to suggest that this is incorrect. ANy comments?