Examining Volume Shadow Copies – The Easy Way!

Simon Key

INTRODUCTION

The Volume Shadow Copy Service (VSS) is a framework that allows volume-backups to be created while file system writes continue to take place.

Originally implemented in Windows XP and Windows Server 2003, VSS was expanded with Windows Vista, resulting in an additional Windows Explorer Previous Versions properties-sheet.

This properties-sheet allows users to recover previous versions of files that were backed‐up using VSS at the time when a system-restore-point was created or a backup was made by the Windows Backup application.

It is very important to understand the VSS operation and be able to examine VSS data created by the system as part of system-restore operations. As we shall see, it may enable us to recover data that’s been deleted by the user.

Mode of Operation

While it is not the intention of the author to explore the technical details of the Volume Shadow Service, it is important to understand the basic principles under which it operates.

Firstly, when forensic examiners talk about VSS, they’re usually referring to the block-level shadow-copies of a volume created by the System Restore feature of compatible Microsoft Windows® operating systems.

System Restore uses VSS to take these copies whenever a restore point is created. The default settings under Windows 7® are such that restore points are created every seven days as well as just before significant operating system events, such as the installation of application software or device drivers.

VSS and System Restore have been around for some time now and most forensic examiners appreciate the fact that volume shadow copies may contain valuable data, data that’s been previously deleted but that has been captured during the creation of a restore point.

That said, the way in which volume shadow copies work is often misunderstood.

Many examiners think of a volume shadow copy as a logical, file or folder backup. They assume that the deleted files and folders that they are interested in exist within the rather large files maintained by System Restore in the System Volume Information folder. These files are highlighted in the following screenshot –

While these files may contain data relating to deleted files, to think of them as a location into which files and folders are put when they’re deleted is wrong. The reasons for saying this are as follows.

System Restore and VSS maintain differential or copy-on-write shadow-copies.

This type of copy works by monitoring changes to blocks on the volume in question. Any block that is about to be changed is backed-up to a differences area. By taking the unchanged blocks and the blocks in the differences area, a shadow copy of the volume can be constructed as it existed at a particular moment in time.

From a practical perspective, how would this apply to the deletion of a file, a picture perhaps?

Well let’s take the example of a file called passports.jpeg. We will demonstrate the recovery of such a file from a volume-shadow-copy later in this article.

If passports.jpeg resides on an NTFS volume, what will happen when the file is deleted by pressing SHIFT and DELETE in the Windows GUI?

Well the MFT record for the file will be modified to reflect the fact that it relates to a deleted file; the index entry relating to the file in the parent folder will also be deleted.

Other files, log files for instance, may also be changed but what happens to the clusters containing the file’s data on the NTFS volume?

Well nothing really, at least not until those clusters are reused by another file or folder on the volume.

So what data relating to passports.jpeg will be captured in the volume shadow copy files maintained by System Restore?

Well at a basic level, the only data that will be captured as part of the volume shadow copy will be the blocks containing the updated MFT record and the modified parent-directory data. The actual file-data itself will still exist in unallocated clusters. The blocks containing those clusters won’t be backed-up because they haven’t changed.

Note that we might recover passports.jpeg using file-signature and footer-based data trawling but this is not ideal for three main reasons

• Not all files have an identifiable signature.
• Files that are fragmented won’t be completely recovered.
• Valuable file-system metadata such as paths, file-names, file-system attributes and created/accessed/last-written/entry-modified date/time stamps will be lost.

This leads us to conclude that the best and most complete way to examine a volume shadow copy is to treat it as, well, a volume.

So how do we access volume shadow copies as volumes? Well, that’s not too difficult at all.

Accessing Volume Shadow Copies

If we have an evidence file containing a volume whose shadow copies we’d like to examine, the best way is to use the Physical Disk Emulator (PDE) to mount the parent-disk and make the volumes that it contains available to Windows.

Using the Physical Disk Emulator (PDE)

We will use an evidence file called Peterson’s HDD to demonstrate the use of PDE and its application with regards to the examination of volume-shadow-copies. The Peterson’s HDD evidence file is a copy of a physical disk containing a single, Windows 7 system volume.

First we mount the disk using PDE.

For our host Windows operating system to recognize and give us access to the volume shadow copies of the volume contained in the evidence file we must make use of the PDE caching feature. This enables us to simulate read/write-access to the emulated disk.

Using PDE in this fashion results in our host Windows operating system enumerating the partitions on the emulated disk and mounting the single NTFS volume that it contains.

We can then right-click on the drive representing that volume (drive E in this case) and use the Previous Versions properties dialog to view details of the volume-shadow-copies that are available.

Notwithstanding the fact that the Previous Versions tab has an Open option that allows us to browse each shadow-copy (in read-only mode), we can use the vssadmin command-line tool to obtain a file-system path allowing us to access each volume shadow copy so that we can mount and/or acquire it. Note that the vssadmin command ships with any version of Windows that supports the Previous Versions feature.

Using vssadmin

The way in which we use vssadmin to enumerate the available volume shadow copies for a given volume is shown in the following screenshot.

As we can see, the command used to enumerate the volume-shadow-copies on a mounted volume is as follows –

vssadmin list shadows /for=:

The vssadmin tool provides information about each volume shadow copy including a path that can be used to acquire and/or mount it. The first volume shadow copy listed in the above screenshot has the following path –

\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy13

EnCase doesn’t currently support this type of path but other forensic acquisition tools do. We could use one of these tools together with the above path to acquire the volume shadow copy as a forensic image and then load it into EnCase.

While this approach facilitates the best-possible access to volume-shadow-copy data, it’s let-down by the fact that acquiring each and every volume shadow copy will take a lot of time and disk space. This problem is compounded by the fact that a lot of data will be duplicated across the volume and all of its shadow copies. Multiply that by the fact that a typical case will contain many volumes each having their own set of volume-shadow-copies and we have a big headache!

So let’s say that we need a quick and easy way to examine volume-shadow-copies to see if they contain files that we’re interested in. If we can identify those files by path, file-name, file-size and/or file-extension then our quickest approach will be to examine the contents of a volume-shadow-copy at a logical level: in other words, by searching through the contents of the volume shadow copy without acquiring it first.

The best way to do this is mount each volume-shadow-copy into an empty NTFS folder. We can then use any one of a number of manual or automated methods to recurse down through those mount-points and identify the files we’re interested in.

Mounting Volume Shadow Copies Using the mklink Command

Mounting a volume shadow copy can be accomplished using the mklink command-line tool, as shown in the following screenshot -

The above screenshot shows the mklink tool being used to create a symbolic link from the folder C:\VSS\Folder0 to the volume-shadow-copy with the afore-mentioned path.

Note several things with regard to the use of this command –

• The folder-names VSS and Folder0 are arbitrary ones: any Windows-compatible folder-names can be used in their place.
• The /d command-line switch must be used to signify a directory link.
• The path to the volume shadow copy must be terminated with a back-slash character.
• Whilst the folder C:\VSS must exist, the folder Folder0 must not: it has to be created by the mklink command.
  
  Creating this link gives us access to the contents of the volume-shadow-copy via the C:\VSS\Folder0 mount-point –
  
  
  
  
  We could mount any number of volume-shadow-copies from the PDE-emulated disk in this fashion but this methodology really comes into its own when used in an automated fashion. This leads us to the use of the VSS Examiner EnScript.
  
  Using the VSS Examiner EnScript
  
  Overview
  
  The VSS Examiner EnScript is designed to make it relatively easy to find files that don’t exist as individual file in the current case but that are contained within volume shadow copies.
  
  The script does this by enumerating and then mounting all of the volume-shadow-copies for nominated volumes originating from a PDE-emulated disk.
  
  It then parses through all of the files in the current case looking for files that match the criteria specified by the examiner. These criteria can be based on a combination of file-name, path, file-size and file-extension.
  
  The hash-values of files in the case that match these criteria are compiled into a list and the script then recurses through the mounted volume-shadow-copies looking for files matching the same criteria.
  
  If a matching file is found, its hash is checked against the list of hashes for the files contained in the current case. If the hash can’t be found in the list then the file is added to a logical evidence file; the hash of the newly found file is added to the list and the search continues. If the hash of a matching file is found in the list then the file is skipped.
  
  Once the search has completed, all of the volume-shadow-copies are dismounted; the examiner can then add the resultant logical evidence file to the case.
  
  Versions of the VSS Examiner EnScript are available for EnCase V6 and EnCase V7. Both can be downloaded from the Guidance Software Inc. Support Portal.
  
  Practical Demonstration
  
  We will demonstrate the use of the VSS Examiner EnScript using the Peterson’s HDD evidence file, which we’ve already mounted in cached mode using PDE. That disk, if you remember, contains a single NTFS volume, which has been recognized by Windows and mounted as volume E.
  
  Having deleted the Folder0 mount-point that we previously created in the C:\VSS folder we run the VSS Examiner EnScript.
  
  
  
  
  The above screenshot shows the VSS Examiner EnScript configured as follows –
  
  
  • The script has been instructed to use the C:\VSS folder as the root VSS mount-point. The script will create a sub-folder in this folder for each volume-shadow-copy that it mounts.
  • Note that the script can be told not to mount any volume shadow copies automatically. In such cases it will assume that the examiner has already mounted the desired shadow-copies into this folder themselves.
  • The script has been told to restrict its activities to the volume shadow copies for the E volume. This is the volume from within our case that we made accessible via PDE.
  • The LEF output path specifies where to create the logical evidence file that will contain files located in volume-shadow-copies, those that don’t exist as files in our current case.
  
  The next step is to configure the criteria we wish to use to identify files of interest. To do that we click the Edit target file condition button. This allows us to specify our criteria in the form of a condition, an example of which is shown in the following screenshot –
  
  
  
  
  The condition shown in the above screenshot targets the following files –
  
  
  • Files with one of the following file-extensions –
  
  
  • jpg
  • jpeg
  • gif
  • bmp
  • png
  • txt
  • zip
  • rar
  • rtf
  • pdf
  • doc
  • docx
  • xls
  • xlsx
  • pdf
  • NTUSER.DAT Registry hive files located somewhere in the Users folder.
  • SYSTEM and SOFTWARE Registry hive file located somewhere in the Windows\System32\config folder.
  
  The activities of the script can be monitored via the console window –
  
  
  
  
  The above screenshot shows how the script has successfully recovered a total of 28 files. These include a number of JPEG files, Registry files and a text file.
  
  We’re now in a position to bring the resultant logical evidence file back into EnCase.
  
  
  
  
  The above screenshot shows the contents of the logical evidence file produced by the VSS Examiner EnScript. In particular it shows a recovered JPEG file called passports.jpeg.
  
  It’s worth noting that not only has the file, its path and contents been preserved, the date/time stamps of the file have also been preserved.
  
  Note that it would be necessary to apply the same TZ and DST offsets to the logical evidence file as have already been applied to the source volume in our case. If we didn’t do this then the date/time stamps shown in our case wouldn’t reflect those having meaning to the person under investigation.
  
  Having identified files of note using the VSS Examiner EnScript, the examiner may decide to perform a full acquisition of the volume shadow copies in question. The LEF produced by the VSS Examiner EnScript includes the output of the vssadmin command so as to assist this.
  
  
  
  
  It’s worth pointing out that once the disk from the Peterson’s HDD evidence file had been mounted and the script configured, it took less than two minutes for the script to process three volume-shadow-copies of a 20-gigabyte volume. Not only that but it do so without creating anything other than a logical-evidence-file just 160-megabytes in size.
  
  Conclusion
  
  Data captured in volume-shadow-copies may be of great value to the forensic examiner and cannot be ignored.
  
  While the methodology documented in this article doesn’t provide full sector-by-sector, cluster-by-cluster copies of volume-shadow-copies, it does allow the examiner to quickly and easily triage such copies and recover files of particular note as identified by file-name, path, file-extension and file-size.
  
  The examiner may still resort to acquiring said shadow-copies should this be deemed necessary.
  
  Simon Key
  Master Instructor – GSI
  8^th June 2012