Examining Volume Shadow Copies – The Easy Way!
Simon Key
Page 2 Objectives
• To clarify exactly what volume shadow copies are. • To explain the way in which they work. • To provide an overview of how volume shadow data is stored. • To demonstrate a methodology for quickly triaging volume shadow copy data. • To explore the different types of data that the examiner might consider recovering as part of this process. • To discuss the limitations of this methodology. • To examine validation options and alternate examination methodologies.
Page 3 Agenda
Page 4 Agenda
• Overview of the volume shadow copy service (VSS). • How volume shadow copies (VSCs) are created. • Overview of VSC differential files and their contents. • Accessing VSC data using EnCase, PDE and Microsoft Windows. • Using the VSS Examiner EnScript to target and recover notable data at a logical level. • Limitations. • Consequences of Windows 8. • Validation options • Alternative examination methods.
Page 5 Volume Shadow Copy Service (VSS) Overview
Page 6 VSS Overview
• Designed to allow backups to be created of a volume without taking the volume offline. • Originally implemented in WindowsXP and Win2K3 server. • Used in Windows Vista to provide a Previous Versions feature and associated Windows Explorer property sheet, which we will see shortly. • Most people are referring to Previous Versions when talking about VSS and VSCs.
Page 7 VSS Overview (cont.)
• There are four components to VSS – • The VSS Service visible in the Microsoft Windows Services management console. • VSS writers are applications that coordinate their I/O operations with the backup and restore operations of VSS. • VSS requestors. These represent software that issue backup requests to VSS. Examples of VSS requestors are System Restore and Windows Backup.
Page 8
VSS Overview (cont.)
• VSS components (continued) – • VSS providers. These provide the mechanism by which backup data is actually stored.
Page 9 VSS Overview (cont.)
• The way that these four components interact is as follows – • The requestor contacts VSS and asks that it prepare for a volume shadow copy to be created. • VSS builds a list of writers, which are asked to provide a list of the data that may need to be backed-up. This list is passed to the requestor, which is responsible for choosing the items to be backed-up from the list.
Page 10
VSS Overview (cont.)
• Each writer freezes data I/O at which point VSS flushes all file-system buffers and tells the provider to create the volume shadow copy. The application- freeze is not allowed to last for more than 60 seconds. • Once the copy has been made, writers are told to resume file-system operations and information about the backup is returned to the requestor.
Page 11
VSS Overview (cont.)
• VSS providers can use several methods to create volume snapshots – • Complete copy – effectively a mirrored copy of a volume. • Copy-on-write – monitors changes to blocks on the volume capturing the original data to a differential file on the same volume. • Redirect-on-write – similar to copy-on-write except that the original data is written to a separate volume.
Page 12
VSS Overview (cont.)
• Microsoft Windows’ own internal system-provider is responsible for backing-up the data made available via the Previous Versions property-sheet. • It uses copy-on-write to preserve the original data from any 16KB block that is modified after a volume-snapshot has been taken. • This data is written into a differential file created at the time the snapshot was taken. • Overlaying a differential file on top of a volume will recreate the structure of the volume as it was at the time the snapshot was taken.
Page 13
VSS Overview (cont.)
• The following diagram shows a symbolic representation of a volume with three snapshots each with its own differential file. • The grey markers indicate blocks that have changed between snapshots. • Taking the volume back to the state it was at when snapshot 1 was taken will require use of all three differential files. Only Block A remained unchanged throughout.
Page 14
VSS Overview (cont.)
Page 15 VSS Overview (cont.)
• It’s important to remember that a volume shadow copy is exactly that – a read-only, shadow-copy of a volume made accessible by taking the volume in it’s current state and overlaying one or more differential files. • It’s common to hear examiners talking about VSS differential-files as containers for deleted/modified files and folders but things aren’t that straightforward. • It’s quite often the case that the only thing that gets captured initially by VSS for a deleted file is it’s MFT record. The file’s data won’t be written to a VSS differential file until the clusters it occupied are modified. Until then the file’s data will remain in unallocated clusters. • Files can be excluded from volume shadow service operations but this often takes place at the point of restore, not at the point of backup.
Page 16 Previous Versions Demonstration
Page 17 Previous Versions Demonstration
• For the purpose of this demonstration we will – • Check system protection settings • Create a folder on our system volume • Create a text file in that folder with some sample text • Create a restore point manually • Modify the text file • View the original text-file using the Windows Explorer Previous Versions property-dialog.
Page 18
Previous Versions Demonstration (cont.)
Page 19 Previous Versions Demonstration (cont.)
Page 20 Previous Versions Demonstration (cont.)
Page 21 Previous Versions Demonstration (cont.)
Page 22 Previous Versions Demonstration (cont.)
Page 23 Previous Versions Demonstration (cont.)
Page 24 Previous Versions Demonstration (cont.)
Page 25 Previous Versions Demonstration
Page 26 Accessing VSC Data Using EnCase, PDE & MS Windows
Page 27 Accessing VSC Data Using EnCase & MS Windows
• EnCase does not currently have native support for VSS • Sorry - • The majority of VSS data can still be made accessible to Windows using the Physical Disk Emulator (PDE) • This requires simulated read/write support through the use of write-caching and a differential evidence file (D01) • Once mounted in this fashion, the volume shadow copy data for each volume can be accessed from MS Windows, either as individual files/folders or at the volume level
Page 28 Accessing VSC Data Using EnCase & MS Windows
Page 29 Accessing VSC Data Using EnCase & MS Windows
Page 30 Accessing VSC Data Using EnCase & MS Windows
Page 31 Accessing VSC Data Using EnCase & MS Windows
Page 32 Accessing VSC Data Using EnCase & MS Windows
Page 33 Accessing VSC Data Using EnCase & MS Windows
Page 34 Accessing VSC Data Using EnCase & MS Windows
• A number of well documented VSS examination methodologies use the vssadmin command-line tool to enumerate the volume shadow copies for a mounted volume. • This allows the examiner to determine the Windows device path to each volume shadow copy so that it can be assigned a drive-letter, mounted into an empty NTFS folder or acquired using a suitable tool (such as George Garner’s FAU dd tool) • Not EnCase – sorry again!
Page 35 Accessing VSC Data Using EnCase & MS Windows
Page 36 Accessing VSC Data Using EnCase & MS Windows
• The next step would be to do one or both of the following – • Acquire each volume shadow copy as a separate volume, add the resultant images to EnCase and examine them exhaustively. • View and/or acquire data from each volume shadow copy at a logical level by mounting each one as a DOS drive letter or into an empty NTFS folder.
Page 37 Accessing VSC Data Using EnCase & MS Windows
• The first of these two options would be the more thorough but would take a lot of time and disk space, particularly if there are multiple volumes each having multiple shadow copies. It would be difficult to justify this time and effort for all but the most serious cases. • The second option, whilst not as thorough, is more suited for triage purposes because – • It’s quicker. • A VSC mounted in Windows can be browsed by an investigator who has little or no knowledge of EnCase and digital forensics.
Page 38 Accessing VSC Data Using EnCase & MS Windows
• Mounting a volume shadow copy so that its contents are accessible via a drive letter can be accomplished using the Microsoft dosdev utility. This minimizes path- length problems but there may be insufficient drive- letters to mount all of the volume shadow copies to be examined. • Mounting a volume shadow copy so that its contents can be accessed logically via an NTFS folder can be accomplished using the mklink command-line tool, as demonstrated in the following screenshots.
Page 39 Accessing VSC Data Using EnCase & MS Windows
Page 40 Accessing VSC Data Using EnCase & MS Windows
Page 41 Accessing VSC Data Using EnCase & MS Windows
• Once mounted in this way files/folders can be copied and preserved using a number of manual and semi-automated methods (copy/paste, xcopy, robocopy, etc.). • The trouble with this type of triage is that identifying and mounting the volume shadow copies in question is time consuming; it’s also difficult to identify and preserve those files that exist in VSCs but that aren’t in the current case. • This is where the VSS Examiner EnScript was designed to help.
Page 42 Using the VSS Examiner EnScript
Page 43 Using the VSS Examiner EnScript
• The VSS Examiner EnScript was developed in order to allow the examiner to answer the following types of questions quickly and easily for even the most trivial of cases – • Are there any pictures or documents in VSCs that I don’t see within my current case? • I wonder if there are older versions of files (such as Registry files) that contain valuable information since deleted?
Page 44 Using the VSS Examiner EnScript (cont.)
• It’s important to realize that the script is not, and was never intended to be, a panacea for all VSS examinations. • It is meant to be used as a quick, easy and free (!) triage tool for the targeted recovery of files based on name, path and file-extension. • You, as the examiner, will have to assess if the script is sufficient for your needs or if you will need to dig a little deeper taking into account what it can and can’t do.
Page 45 Using the VSS Examiner EnScript (cont.)
• Basic overview of the VSS Examiner EnScript’s operation – • The script iterates through a given folder structure looking for files matching a given criteria that don’t exist in the current case. It does this using hash analysis. • The folder structure in question would normally consist of a root folder containing one or more sub- folders each acting as a mount-point for a given VSC.
Page 46 Using the VSS Examiner EnScript (cont.)
• The script can, optionally, mount those VSCs automatically using Windows Management Instrumentation (WMI – language independent unlike vssadmin) and mklink. • These VSCs can originate from any NTFS volume on the host system but will usually be located on a PDE- emulated disk from the current case. • It’s important to note that the script does not read any of the VSC differential files on any of the volumes in the current case: it is acting purely as a helper designed to find files contained within mounted VSCs that don’t exist in the current case.
Page 47 Using the VSS Examiner EnScript (cont.)
Page 48 Using the VSS Examiner EnScript (cont.)
Page 49 Using the VSS Examiner EnScript (cont.)
Page 50 Using the VSS Examiner EnScript (cont.)
Page 51 Using the VSS Examiner EnScript (cont.)
Page 52 Using the VSS Examiner EnScript (cont.)
• Before we go any further let’s consider where the data for the passports.jpeg file is actually located. • The file is to be found in all three volume shadow copies of Peterson’s C volume and must therefore have been deleted at some time after the last snapshot was created but before the host disk was acquired. • A full structural analysis of the VSC differential files is beyond the scope of this presentation but a simple keyword search reveals the MFT record for passports.jpeg in the last snapshot’s differential file. • The single NTFS data-run in that record provides us with the file’s starting cluster (1,460,374) and the number of clusters occupied (24). • Checking this location reveals that these clusters still form part of unallocated clusters. • None of the file’s clusters have since been re-used so the picture is still visible in that location.
Page 53 Using the VSS Examiner EnScript (cont.)
Page 54 Using the VSS Examiner EnScript (cont.)
Page 55 Using the VSS Examiner EnScript (cont.)
Page 56 Using the VSS Examiner EnScript (cont.)
Page 57 Using the VSS Examiner EnScript (cont.)
Page 58 Limitations
Page 59 Limitations
• The VSS Examiner EnScript is meant for targeted recovery only. Recovery of all files from volume shadow copies would be time consuming and is not recommended. • File-signatures are not taken into account because of the time it would take (every file in every VSC would have to be checked). • Alternate data streams are not processed.
Page 60
Limitations (cont.)
• For reasons already explained, the script does not provide the location of a file’s data or MFT record. • The script can only recover data made available to it via Windows (the same applies to every other methodology that relies on Windows reading the VSC data, including those that acquire VSCs as volume-images).
Page 61
Limitations (cont.)
• Some files may be masked by Windows at the point of restore even if the VSC in question is acquired as a volume. • NTFS internal files (such as $MFT) cannot be captured into the resultant LEF. • Whichever way you look at it – • More data = more work
Page 62
Consequences of Windows 8
Page 63 Windows 8 Consequences
• Windows 8 continues to create volume shadow copies and store previous versions of files. • The main difference is in the GUI in that- • There are only two options for system protection: on or off. There is no option just to store previous versions of files. • The Restore Previous Versions option has been removed from local files, folders and volumes.
Page 64
Windows 8 Consequences (cont.)
• The Restore Previous Versions option still exists for local and remote network shares. The network shares in question must be located on a server that supports the Previous Versions feature.
Page 65 Windows 8 Consequences (cont.)
Page 66 Windows 8 Consequences (cont.)
Page 67 Windows 8 Consequences (cont.)
Page 68 Windows 8 Consequences (cont.)
• Windows 7 cannot read VSC data created by Windows 8. • The VSS Examiner EnScript can still be used to view such data provided that the examination is performed on a Windows 8 machine. • Remember that the script is purely a helper - it doesn’t read VSC differential data directly.
Page 69
Validation Options
Page 70 Validation Options
• The VSS Examiner EnScript cannot display the physical location of a recovered file and its associated file-system metadata in EnCase – as already mentioned the script is acting purely as a helper. • This is sometimes raised as a sticking-point – • “I can’t produce a file recovered from a VSC if I can’t show it in EnCase.” • This point of view is understandable but questionable.
Page 71 Validation Options (cont.)
• MS Windows, EnCase and many other tools/applications interpret data that is otherwise unintelligible when viewed in its raw, on-disk state – • Compressed data (ZIP/RAR/PDF) • Encrypted data (EFS) • Encoded/obfuscated data (PST/OST/PLIST) • The examiner does not need to demonstrate manual recovery of this data before he/she can present it in evidence!
Page 72 Validation Options (cont.)
• Being able to perform an at-will demonstration of the way in which VSS and Previous Versions operates is proof in itself that these features work.
Page 73 Alternative Methodologies
Page 74 Alternative Methodologies
• Up until recently most VSS methodologies rely on exposing VSC in MS Windows using VSSADMIN and/or WMI. These are well documented on the Internet. • Paul Sanderson from Sanderson Forensics has since produced the following tool – • Reconnoitre
Page 75 Alternative Methodologies (cont.)
• Reconnoitre – • Three years in development. • Reads disks, volumes and E01 disk-image files directly. • Reads VSC differential files and interprets each volume snapshot at an NTFS file-system level. • Provides full extent-information for files contained in the current volume and its VSCs. • Well suited for in-depth VSS examinations.
Page 76 Alternative Methodologies (cont.)
• Reconnoitre (cont.) – • Alternate data-stream support. • Support for reading internal NTFS files directly. • NSRL hash-set support. • C4P image-categorization support. • Integral image viewer with Exif (inc. GPS) support.
Page 77 Alternative Methodologies (cont.)
Page 78 Alternative Methodologies (cont.)
• Reconnoitre (cont.) – • Demonstration version available from – • www.sandersonforensics.com • The demo version will process the three latest VSCs for a volume and display a maximum of 500 graphics files.
Page 79 Questions?
Page 80 Thank you for your time!
Page 81