Examining Volume Shadow Copies – The Easy Way!

Examining Volume Shadow Copies –
The Easy Way!
Simon Key <[email protected]>
Course Developer / Instructor III
www.encase.com/ceic
Objectives
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 applicationfreeze 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 pathlength problems but there may be insufficient driveletters 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 subfolders 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 PDEemulated 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

Download Report