For today’s post I’m going to take a look at the Volume Shadow Copy Service (“VSS”). While not a new artifact, this service is an integral part to the Windows Operating System and is essential for DFIR analysts to understand. They can even sometimes make the difference between finishing the puzzle or only having a few pieces!
What’s this Volume Shadow Copy business?
Volume Shadow Copies (“VSC”) are a result of VSS doing it’s job, which is essentially the snapshotting of data at a particular point in time. As replicating the entire state of a system at a point in time is a huge undertaking — especially one that often takes place behind the scenes and hidden from the user — this service handles the coordination that happens in the background. The VSS has multiple components, such as writers, providers, and requestors, that all work together to provide this service.
There are two types of shadow copies, clones and copy-on-write.
- Clone copies are exactly as they sound — a duplicate of the original data, similar to cloning a VM.
- Copy-on-write shadow copies are essentially differences maintained from the previous shadow copy. As changes are being made to a live system, the data being changed is tracked and copied, in case it needs to be rolled back.
For this post, and for analysis discussions, I’m only going to focus on copy-on-write shadow copies, where applicable.
If you’ve been using Windows long enough, you most likely have interacted with volume shadow copies in some way, shape, or form. You may not have even realized you were! As I mentioned in my post last week about AppCompatCache, there are a lot of compatibility and easy-of-use “features” built into Windows that become forensic artifacts for us. VSS/VSC certainly falls within that category.
Volume Shadow Copies in Use
One of the more popular uses of Volume Shadows, on newer (post-XP) operating systems, is for System Restore points. In fact, in Windows this is largely how the user is exposed to Volume Shadows — a typical user may not ever see a dialog box with the words ‘Volume Shadow’, but they may see ‘System Restore’. While System Restore points are not the only feature that utilize VSS, I’m going to pick this one to focus on and provide an example.
System Restore
System Restore is a feature that allows a user to roll back to a state prior to ${some_level_of_significance} changes being made. These changes often include installation of a new application or system configuration changes (OS updates, etc). When you roll back, you’re actually utilizing the Volume Shadow Copy Service to go back to that known-good state (or, “Last Known Good Configuration”). System Restore points often also include notes on what happened, so that the user can determine what significant change caused the error.
The following screenshot shows my Windows 10 System Restore dialog box after I installed new printer drivers:
If I selected ‘Choose a different restore point’, I can actually see multiple time-stamped copies and their respective descriptions:
Additionally, you can force Windows to create a restore point if you anticipate a change causing issues. The following dialog box shows the options available:
Lastly, a user could also peek into some configuration options and see what much data Restore Points are taking up. Here’s an example from my test system:
Additional features such as Previous Versions and Backups also utilize the VSS to gain access to blocked files or give users a chance to “peek back in time” at files that have been modified or deleted.
Mounting VSCs — Live Systems
Despite the wonderful GUI options discussed above, some DFIR analysts want to interact with Volume Shadows via CLI. I know I’m in that group. Windows includes the tool vssadmin to do just this:
Using the CLI tool, the user is provided options to delete, list various details, and resize the storage used by Volume Shadows. Very similar to the options we were provided in the GUI. For example, to list all shadows, the command vssadmin.exe list shadows will do just that. It is possible to throw a /For flag and specify a drive. I always recommend being as specific as possible, if possible. Our output looks like the following:
Note that our timestamps are relatively close to the previous GUI output we saw.
Authors Note: I am still testing the discrepancy between the two timestamps, as it is not a static period of time.
Mounting a VSC on a Live System
While I’d discourage doing this — in favor of collecting a forensic image — you can also mount a Volume Shadow Copy and browse it like any normal folder. Remember that you’re looking at the underlying files at a specific point in time. Here’s how:
Notice from the output of vssadmin that the Shadow Copy Volumes actually have device objects. They are sequential with respect to the system, and in my experience, typically have static paths (if you wanted to script this). I’m going to mount the newest VSC I have, which has a device object of \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4 . The command is as follows:
mklink /d C:\VSC_Test \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\ Before attempting this command, do not forget to append a backslash to the end of the path!
Navigating over to C:\VSC_Test, I see that I now have a representation of the C drive at that point in time:
Please remember: You are looking at a representation of a system at a point in time, which is provided via the differences stored within the Volume Shadow Copy. This is not a full copy of a system, and you must have the original data to view full files. Remember: VSS tracks block-level changes, and is not a full copy of a volume.
Mounting VSCs— Dead Systems
If you’ve been provided a forensic image to analyze, don’t worry, Volume Shadows are not out of your reach. My go-to tool for accessing this is libvshadow, written by Joachim Metz. This tool ships by default within the SIFT Workstation or can be downloaded and built into your own distro if you’d like.
Libvshadow allows an analyst to work with the shadow copies contained within an image. Installing libvshadow gives you two commands, the purposes of each are fairly easy to discern:
- vshadowinfo: Provides information on the shadow copies within an image
- vshadowmount: Mounts each volume shadow copy to a separate mount point.
Here’s some examples:
Notice vshadowinfo gives us much of the same data as vssadmin list shadows. Now, for vshadowmount, we have to provide a mount point that will have several objects inside:
root@batman-forensics:/mnt/ewf# vshadowmount ewf1 /mnt/vss
vshadowmount 20161111root@batman-forensics:/mnt/ewf# cd /mnt/vss
root@batman-forensics:/mnt/vss# ls
vss1 vss2 vss3 vss4
If there are no errors, the analyst can mount each one of the vss* files to a separate point, or simply interact with the device. For example, we can run a fls against vss1 (a representation of the Volume Shadow Copy from the image on March 15, 2012), and get a recognizable folder structure:
Volume Shadow Copies in the Registry
We can also recover information about our Volume Shadow Copies, and their characteristics, from the Windows Registry. There are multiple locations of interest, especially as this is a Windows service. The following registry key provides information on the service itself:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSSFor this post, I’ll focus on the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestoreWithin this path, we’ve got three subkeys:
- FilesNotToBackup — specifies files that should not be backed up or restored.
- FilesNotToSnapshot (only Vista/2008+)— Specify files that should be deleted from newly-created shadow copies
- KeysNotToRestore — Provides the names of registry keys and values that backup applications should not restore.
If you ever find any discrepancies on a system that you are analyzing, I’d recommend pulling these registry keys and determining if there was a configuration change that altered data within a VSC.
Analyzing Volume Shadow Copies
If you’re a DFIR analyst, and are not using Volume Shadow Copies in your investigations, I’m hoping that something has clicked in that post and your arsenal has just grown. Regardless of what platform you do analysis in, they are not out of reach. On principal, I didn’t cover any commercial tools, but good forensic commercial tools can also handle Volume Shadow Copies.
When incorporating VSCs into your analysis, consider the following possibilities:
- When using tools such as
libvshadow, that can give you a representation of the Volume Shadow Copy as a logical volume, you can apply secondary-analysis tools such as log2timeline/Plaso, and create massive, MEGA supertimelines that peek further back in history. Just note you might have an excess of the same data; use tools to de-dupe and you’ll be in a good spot. - If you have indicators to assist in analysis, such as malware or timeframes of interest, observe how your volume shadow copies interact with these timeframes. You may find yourself in a situation where you can peek at the system prior to infection. Additionally, if you have suspicions of timestomping, see if your Volume Shadow Copies back up that theory.
- Just because data is within a Volume Shadow Copy, it doesn’t mean analysis techniques have to change. We can still run automated scripts, hash files, perform keyword searches, etc. This is just another data source!
Until tomorrow, happy forensicating!
References
- Microsoft SysInternals, 6th Edition: Part 2
- https://msdn.microsoft.com/en-us/library/windows/desktop/bb891959(v=vs.85).aspx#filesnottobackup
