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
10 comments:
Richard
Thanks for the useful write up, I like the idea of using the hash sets.
Your report about the recovered folders confirms my findings some while ago which was that any files that have been created post the shadow copy end up in unallocated in the shadow volume.
I recently looked at about 20 shadow copies using mklink method in a virtual machine of the target and then used FTKi to create a custom image of just the Mozilla folders that I was interested in for the internet history.
I also piped the list shadows to a text file for reference.
H
Very nice! From what I understand, the creation of shadow copies in 16KB blocks is likely to capture at least portions of free clusters that exist at the shadowing moment. These free clusters may contain files that were deleted, but not referenced by any metadata, i.e., carvable files, as well as files that were created and deleted pre-shadow. Still, I wouldn't be carving anything from "free" clusters on a shadow copy. I'm still a little hazy about why Sony ended up in your first shadow volume, if even its MFT record was not created at the time of shadow creation. Date stamps, when available, should provide clues
Concerning the triage of shadow volumes, I use Shadow Explorer (free) regularly. It's great when you need to look at only a few folders. I run it in a VM.
In your last post and my comment thereto, we spoke of permissions with mklink. I found that the permisssions issue resolved when I used the last trailing backslash.
Richard,
Great write-up - thanks. I tend to use an alternative method: ROBOCOPY to extract data from shadows mounted in a VM.
First mount all shadows using a MKLINK and a FOR loop, then ROBOCOPY all live pictures/movies from the user's directory from all the mounted shadows preserving the MAC info, again using a FOR command.
It only gets live pictures (rather than pics in compound files), but for an initial look, this is what we're after.
You can then load the output from ROBOCOPY into EnCase, depude all the files based on path - now you have a list of all the files that have passed through a users 'hands'.
IF it goes smoothly, not too onerous a task!
Works a treat!
James
PS> I depude on path rather than hash because if a pic appears on a user desktop AND in Internet cache, I want to see the 2 separate instances.
Thanks for the report Richard.
Have you had any success 'mounting' or recovering filesystem data from deleted Volume Shadow Copies that have been found to contain pertinent files via carving etc?
Hi,
Deleted file shadow copies do not seem to be mountable. There are probably many reasons for this but as a starter I suspect that because the SCs are incremental there must be some record of current SCs. The deleted ones are probably not included.
Regards Richard
Although it seems that blocks are copied just before they are changed, you cannot recover every version of every file that is changed from a subsequent shadow copy.
Save a Word document ten times and the only copy you will be able to revert to is the copy that was present when the shadow copy was triggered.
Any thoughts on what happens to the blocks that are copied and not used?
I am not sure that there are any blocks that are copied and not used.
What I think happens is:
At the point a SC is created lets say a word doc occupies blocks 1, 7, 8, 9 and 10 (keeping it very simple here). When the word doc is changed by the next save blocks 1, 8 and 9 are changed. at this point the original contents of these blocks are saved to the SC. The next and subsequent saves also change blocks 1, 8 and 9 however no further copy needs to be saved to the SC because the original blocks have already been saved. If this file is then reverted to, the original state at the the time of the SC was created is restored (i.e. All the unchanged blocks plus the original contents of blocks 1, 8 and 9). This restoration will overwrite the subsequently changed blocks because changes between SCs are not monitored.
Regards Richard
Hmm, I see what you are saying up to a point. Perhaps it's me just not getting it. Try this.
Shadow copy is triggered at midnight for example. The data contained in the shadow copy has aleady been written to it by this time (blocks being copied since the previous shadow copy). It is then 'finalised' or triggered by a system event.
Let's assume that on the next and subsequent saves post midnight, that blocks other than 1,8 and 9 are changed. The relevant blocks will be copied to the shadow copy that is currently being written to and not yet finalised.
Midnight the following night arrives and a shadow copy is triggered (containing all the changed blocks for the previous 24 hours).
You will only be able to revert to the Word document 'as was' at the previous two midnights and not the changes in between, despite all those other changed blocks potentially being present.
I think.
To clarify, shadow copies in Vista and Win7 are very useful for forensics but only provided that you are aware how they work. A "shadow copy" when first created is not really a copy of anything but just a set of pointers back to the real drive. Then, as blocks are overwritten, the original data (as at the time of the "snapshot") is stored in the diffs file.
Once it has stored a particular 16k block in the diffs file, Snapvol knows it does not need to store another copy if it changes again - it only cares about the contents at the time of the snapshot.
For efficiency, one of the developers of Snapvol told me that it does not bother to preserve the content of blocks which at the time of the snapshot were marked as free space, or those which were used by the swap file or hibernate file. So, as you noted, a search of "free space" in the shadow copy is pointless, as it will just show the current contents of that area of the drive. There is also a registry key which lists other files (such as Temp file) that should be treated the same way - not exactly sure how this is implemented but it seems that it marks any 16k block which is only occupied by these files as if it were free space.
Although Microsoft's documentation is silent or misleading (for example saying that previous versions of users files are only stored in Vista Business and above). The System Protection shadow copies contain the entire drive in all versions of Vista/Win7 including Home editions. So anyone trying to "secure erase" incriminating files will likely be unaware that he just copied them to the diffs file for you to find.
Finally a very nice feature of Shadow Copies is that they may enable you to find the file name and path of objects of interest that you first found using a scan of free space.
There is a free tool for mapping shadow copies @ http://code.google.com/p/shadow-map/
Post a Comment