There has been a great deal written about volume shadow copy forensics lately, much of it very technical. The purpose of this post is to provide some of this information in an abridged form and to document a methodology to investigate them that works for me. I work in an Encase shop so much of what follows is tailored for Encase users. It is a followup to my earlier post.
What is a Volume Shadow Copy?
It is a snapshot of a NTFS formatted volume. Typically they are created every day or two in Vista and on a weekly basis in Windows 7. Both operating systems will also create volume shadow copies prior to the installation of new software (including Windows updates). The Volume Shadow Copy Service (VSS) monitors all the changes made to a volume from the time that a shadow copy was created until the creation of the next one. For the purpose of monitoring a volume is divided into 16 kilobyte blocks. When a block is about to be overwritten it is backed up in the shadow copy. Only changed blocks are backed up. If there is a requirement to revert to a snapshot the original blocks are restored, replacing the changed ones, in a sense reconstituting the volume back to its state when the snapshot was taken. Certain versions of Vista and Windows 7 allow users to revert to previous versions of files and folders, not just at the volume level.
Where are Volume Shadow Copies stored?
In the System Volume Information folder stored at the root of each protected volume.
Why might I need to investigate the contents of a Volume Shadow Copy?
You might not, but I am seeing many cases now where the Shadow Copies contain relevant evidence. For instance, during your IPOC cases the file finder or the C4P graphics extractor enscript or Blade have identified pictures within the shadow copy file which do not exist on the live volume. At that stage you simply do not know for example, whether these pictures were part of a web page accidentally viewed and then immediately closed down, embedded within an unsolicited email message, or there as a result of the intended actions of your suspect. Or you may have experienced cases where Encase lists many files as deleted and overwritten but that have very very dodgyfile names.
The following screenshot is from an Encase case which contains a live volume and images of two shadow copies of the same volume. Four deleted and overwritten files are listed, the metadata of which has been recovered by Encase from the MFT on the live volume. It can be seen that these files are intact within the shadow copies which allows your file carver of choice to recover them.
It has been suggested that, because each shadow copy is effectively a volume in it's own right which mirrors the size of the source volume, that if you have twenty shadow copies you will have to investigate twenty times as much data. In Production Line forensics this simply is not going to happen. Therefore we need to make some educated guesses as to which shadow copies to look at. Have our file carvers flagged any as meriting further investigation? Do keyword searches point to any? Were any shadow copies created just before or just after a particular event we are looking at? Are there a rash of shadow copies created within a short time of each other by software installation or windows updates which we can exclude? Once we have made our choices we can proceed further but it is not the case that the amount of data to be investigated is a multiplied by the number of shadow copies you chose to investigate. This is because the majority of data within each shadow copy is exactly the same as the data on the live volume. We are really only interested in the differences and I will discuss a method to do this later in this blog post.
What are we going to need?
For what follows we will need a Windows 7 box, Encase with the PDE module and some storage space formatted NTFS and ideally with File and Folder compression enabled. We will also need George Garner's Forensic Acquisition Utility.
Method
You will already have an Encase image of the drive you wish to investigate. When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further. You will need to note the File Creation date and if you wish to be more precise establish the Shadow Copy ID stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase.
I am using Windows 7 - every thing that follows should work in Vista and has worked for many people. However for me, in testing using Vista it did not always work as expected -generating various permissions related errors -so far - touch wood- Windows 7 just works.
Run a Command Prompt as Administrator and type the command (substituting I for the drive letter allocated to your mounted volume)
vssadmin list shadows /for=I:
This will result in a list of all available shadow copies on the selected volume
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.
Contents of shadow copy set ID: {2202d8a9-1326-4254-9818-252ece858b17}
Contained 1 shadow copies at creation time: 10/12/2009 13:41:25
Shadow Copy ID: {ad2e71d0-48d6-44b9-9715-f5ff6b5a5643}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered
Contents of shadow copy set ID: {e13bb9d9-c522-422b-b92a-37f6d12363d9}
Contained 1 shadow copies at creation time: 15/12/2009 11:17:37
Shadow Copy ID: {d0e1c613-7892-47e1-9b7e-f638adac9d16}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered
Contents of shadow copy set ID: {4db5347c-214a-4e5c-b785-0fd993f1dc33}
Contained 1 shadow copies at creation time: 15/12/2009 11:18:25
Shadow Copy ID: {b7621ae2-5efb-4929-aa35-39af3d6e39ac}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy6
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered
Contents of shadow copy set ID: {2445d9b6-58fd-4ac6-b73e-7bd0ebbec6cc}
Contained 1 shadow copies at creation time: 15/12/2009 12:14:44
Shadow Copy ID: {709f74d5-ded2-4294-a292-c7cc4db0e67b}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy7
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered
Contents of shadow copy set ID: {c9e7850a-87db-4dbc-9d72-40749665d80d}
Contained 1 shadow copies at creation time: 09/02/2010 07:26:39
Shadow Copy ID: {2a871fe5-21f7-4fb6-b8e9-65e194a62901}
Original Volume: (?)\\?\Volume{34e5a98a-1a1d-11df-a259-00236cb6de69}\
Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8
Originating Machine: Richard-MBP-Vis
Service Machine: Richard-MBP-Vis
Provider: 'Microsoft Software Shadow Copy provider 1.0'
Type: ClientAccessibleWriters
Attributes: Persistent, Client-accessible, No auto release, Differentia
l, Auto recovered
It can be seen that the Shadow Copy ID number I bookmarked as a GUID is identified by VSSAdmin as HarddiskVolumeShadowCopy5. The next step is to image this shadow copy using the Forensic Acquisition Utility (a version of dd that works in Windows). At the command prompt navigate to the path of the utility and type the command
C:\FAU.x64>dd if=\\.\HarddiskVolumeShadowCopy5 of=G:\shadow5.img --localwrt
It can be seen that the input file is referenced as \\.\HarddiskVolumeShadowCopy5 and the output file which I chose to name shadow5.img is located on G:. This volume is an NTFS formatted volume with file and folder compression enabled. --localwrt is a switch required to allow the utility to write to the G drive. The response at the command prompt will be similar to
The VistaFirewall Firewall is active with exceptions.
Copying \\.\HarddiskVolumeShadowCopy5 to G:\shadow5.img
Output: G:\shadow5.img
44048285696/57868808192 bytes (compressed/uncompressed)
55187+1 records in
55187+1 records out
57868808192 bytes written
Succeeded!
Enabling file and folder compression reduced the dd image from about 59GB to 44GB. Whilst imaging make sure that you have carried out an hash analysis in Encase of your source volume and create a hash set from it. Add only this hash set to your library.
The following screen shot shows that there are 237024 files contained within the image of HarddiskVolumeShadowCopy5 (broadly the same as the source volume)
Apply the condition which filters out files that have the same hash value as those in the original image and it can be seen that the amount of new or different files is considerably reduced to 7864 files (with the caveat that some of the original files may have been moved -which may or may not be relevant in your case).
I think it can be seen therefore that it is possible to reduce the number of files you need to consider by filtering out the duplication between the original volume and the shadow copy.
A Note of Caution about the Shadow Copy Images
When you image a Shadow Copy and add it into an Encase case as described above it is easy to think of the image as a point in time snapshot of the entire volume including the areas of the volume we refer to as unallocated clusters. Unfortunately it does not appear to be. However your forensic tool (Encase in my case) is likely to process it as if it was the entire volume. In my test case used to illustrate this blog post I imaged at 14:47hrs on 9th February 2010 two shadow copies -one created at 15/12/2009 11:17:37 and one created at 09/02/2010 07:26:39. At 15/12/2009 11:35 I copied a folder entitled Sony from an external device to the desktop of my user account on this Vista box. It can be seen in the screen shot below. It is a live folder containing files and has not been deleted.
It can also be seen within the shadow copy created on 9th February 2010 as expected.
The Encase Recover Folders feature parses unallocated clusters looking for folder metadata. It seems that it found data in unallocated clusters relating to the current volume. Therefore I believe that any deleted but recoverable data within the shadow copies needs to be treated with caution.
Other Methods
So far in this post I have discussed imaging the shadow copy pseudo-device. It is possible to mount the shadow copy as a symbolic link. There are various methods discussed using VMs etc. The most streamlined approach seems to me to be:
- Mount shadow copy with Encase PDE
- create a symbolic link (in this example at the root of C) using the command
mklink /d c:\shadow_copy5 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5\
- drag the created symbolic link into a separate instance of Encase (for me using the same instance as the one running PDE blue screened my box) which causes Encase to treat the files and folders accessed via the symbolic link as Single files
- Create a logical evidence file of these Single files (you may encounter some permissions issues along the way)
References
http://blogs.sans.org/computer-forensics/2008/10/10/shadow-forensics/
http://www.digital-detective.co.uk/cgi-bin/digitalboard/YaBB.pl?num=1251461771
http://blog.szynalski.com/2009/11/23/volume-shadow-copy-system-restore/
http://windowsir.blogspot.com/2009/11/working-with-volume-shadow-copies.html
http://blogs.technet.com/filecab/archive/2006/09/01/452845.aspx
http://en.wikipedia.org/wiki/Shadow_Copy
Posts
