Volume Shadow Copy – What Do We Have In The Shadows

My forensic guru and mentor once told me how he handled a tight spot using Volume Shadow Copy. He taught me how & when to make use of them and their significance. Those were the times that actually taught me, tested me, geared me up for challenges and made sure learning happens along the way. I always had this quirk of writing what I’m learning, jotting down what I’m thinking, which I can retrieve later on and vouch for I learned something or not at all. And I always believe learning happens if and only if it was applied and experienced rather than the theories I read or listen to.


This is the first post in a series on Volume Shadow Copy. I haven’t stressed on the technical aspects in this post and is more of a write-up kind of thing to acquaint you on what lies ahead. Volume Shadow Copies (VSC) is a valuable artifact for forensic investigators though they demand time consuming and ponderous techniques to analyze. Prior to Vista, there was System Restore on Win XP systems which provided backup of the system files only and never user files. In Windows Vista and Win 7, Volume Shadow Copy runs as a service namely Volume Shadow Service (VSS) that creates snapshots of all files on the volume including user files. In Windows 8, Microsoft has featured File History; it saves copies of your Libraries, Desktop, Favorites and Contacts alongside core system files. Again in Windows 10, the shadow copy feature has been restored. The difference between System Restore and File History lies in the fact that System Restore allows you to restore to an earlier state, whereas File History lets you restore your files and data from an earlier point of time.


In layman terms, the purpose of Shadow Copies is to feature automatic saving of copies of file and to allow the user to restore these in scenarios where you have lost them for any reason like file corruption or system failure, for instance. Volume Shadow Copies are not to be compared with traditional backup systems. VSCs operate at the block level within the file system, backing up and providing access to previous versions of system and user data files within a particular volume. Accessing these files can provide not just historical data but additional analysis can be conducted by comparing the available file versions over time. In order to create and store shadow copies, the file system should be NTFS. The VSS monitors all changes made to a VSS enabled volume and the monitoring is done in blocks of 16kb. Whenever a change is detected to any data inside the 16kb block, the entire block is copied to a volume shadow copy file. These 16kb blocks are divided either as Index Blocks or Data Blocks. As per the name, Index blocks are pointers to the 16kb data blocks that have been saved by the volume shadow service. These Shadow Copies can be created on local and external or network volumes. There are two methods for creating shadow copies, either make a complete copy or copy only the changes to the volume.


For each method applied the resultant is two data images — the original volume and the shadow copy volume. The difference between the two is that the original volume maintains full read/write capabilities, whereas the shadow copy volume is read-only. The process of creating the backup copy is known as taking a “Volume Snapshot” and the actual backup copy of the data is known as a “Shadow Volume”. This Shadow Volume is located on the logical drive volume. All volume shadow copy files are stored in the System Volume Information folder on the root of the volume.


The following three functions are executed by Volume Shadow Service to create snapshot

  • Freeze: Freezing the volume by marking the HDD to Read-Only for a quick moment so that nothing new can be written to it
  • Snap: Imaging the drive with parameters to reconstruct that snap whenever necessary in future
  • Unfreeze: Release the HDD from read-only mode to Read-Write so that new data can be written to it.

All the three steps happen in a fraction of time, normally a minute or two to create a snapshot and you can continue to work whatever you are doing on and don’t have to bother on pausing; again the time factor is directly proportional to the disk type.


Volume shadow copies may contain valuable data that has been previously deleted, but has been captured during the creation of a VSC. The volume shadow service maintains a record of every block that is changed and only backs up a block if it is about to be modified. Shadow copies are read-only, so there is no way to delete a file from all the shadow copies. This makes them a potential reserve of information. For instance, let’s consider a file that is residing on a system without volume shadow service enabled. The only data that can be viewed is what is currently on the document, though temporary files might be able to show the previous data but won’t completely show how the document changed over time. Now consider the same document for a volume that has VSC enabled; the document can be recovered from every VSC revealing that data in each of the copy and what are the changes that took over the period of time. The VSC makes copies of files and directories at various instances triggered either by the system or manually by user such as specific intervals of time or perform a system update, install or uninstall a software, registry modifications etc.,

VSC doesn’t require a large portion of the disk to save the files. Whenever a file is deleted, windows remove its entry from the MFT, but the blocks are still intact. As discuss earlier in this post, VSC works on block level (below file system level and above disk level), and all the data that was in the file is still there in the same blocks, until the blocks get overwritten by some other new file. VSC has a workaround for the overwritten blocks. Let’s assume you delete a 20 MB word document, VSC doesn’t have to copy the 20 MB of data, it backups only the blocks occupied by the MFT. When a new file starts overwriting some of the blocks formerly occupied by the 20 MB file, VSC will make backup of these blocks as they get overwritten.


Because a Shadow Volume is not located within the file-tree structure of the OS, the traditional forensic tools such as Encase and FTK doesn’t allows us to view them.

Though there are several methods for accessing, acquiring and extracting data from the Volume Shadow Copies in a forensically sound manner, the difficulty is that the volume shadow service has always been required to restore or examine any volume shadow copy that was stored on the volume. Accessing VSCs on live systems is a bit tricky, as VSCs follow the FIFO cycle, you may be attempting to examine data from a VSC that gets deleted during that process. Even within acquired images or live systems, double-clicking the wrong file can lead to your machine being compromised or infected as you never know what malware or virus is in the file as Anti-Virus software will not scan Volume Shadow Copies. Even if you mount the VSC and try to scan and delete the malware, the anti-virus application simply cannot do it as VSC are read-only. Also VSC are a trove of information, if so much of information is not treated in a wise manner, it becomes difficult to examine the data in each of the VSC. Hence many investigators ignore these artifacts due to their complexity; even acquiring these requires considerable disk space. In the coming posts, I’ll shed some light on the technical aspects, how to configure them, acquire and analyze them manually and with tools such as ShadowExplorer, Reconnoitre, OS Forensics, VSC Toolset and others alike.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.