Monday, June 16, 2014

Daily Blog #358: Sunday Funday WInner 6/15/14

Hello Reader,
         I wasn't sure what to expect when I put out this challenge, I've always failed a predicting what will resonate with you. I was very pleasantly surprised to not only get multiple entries this week but several that went beyond just what I've blogged about and into the heart of the VSC service. While there we a few outstanding entries this week the clear winner was Troy Larson who made an amazing entry, please read on.




The Challenge:

For a Windows 7 system, list out all sources of data regarding volume shadow copies that are stored and can be accessed from a forensic image, without booting it.

The Winning Answer:
Troy Larson


I never understood why people believed they needed to boot an image to get at shadow copies.  It is not necessary if the analyst has access to a working Windows 7 or better system.  Everything necessary to access and consume shadow copies is available in the NTFS volume that has been imaged.  If the volume (in the image) can be made properly available to a sufficiently modern Windows system, the volume shadow copy service and volsnap drivers in the Windows system can read the volume, which gives as complete an access to the shadow copies on the volume as can be had by booting an image.   Actually, I would say that not booting an image is a generally better way to get at shadow copy data because, unless the image was made while the volume was offline, the image may not be bootable.   Even if the image was not bootable, the shadow copies should be accessible.

There is much that can be learned about shadow copies contained within an image of a volume (or disk containing one of more NTFS/ReFS volumes) simply by examining an image in a good disk/hex editor or forensics tool.  That is, one can learn a lot about the shadow copies on a volume without mounting the image as a volume. 

All the information provided in this response came from public resources or from what can be seen (and tested or verified) in a hex editor.  No information internal to Microsoft was used.

Examining an image for information about shadow copies:

The first question that needs to be answered is whether there are there viable (i.e., usable) shadow copies in an imaged volume?

The easiest way to determine if there are viable shadow copies is to look in the \System Volume Information folder for volume shadow copy difference files.  Difference files are identified by looking for files whose name consists of what appears to be {GUID}{GUID}, as shown below:





The second GUID in the shadow copy difference file name, {3808876b-c176-4e48-b7ae-04046e6cc752}, identifies the file as belonging to volume shadow.  Above, one can see that there are three difference files.  There is also a deleted difference file.  The above tells us that there are three viable shadow copies on this volume.  The created date of each difference file corresponds to the created date of each shadow copy.  The size of the difference file is indicative of the amount of data backed up within it—larger difference files contain more data.  Examining the internals of the difference files can provide even more information, so internals are discussed below.  First, however, we verify that difference files provide correct information about the number and date of the shadow copies on a volume.

If we were to mount the volume and run vssadmin, we would see that there are in fact three shadow copies available on this volume, and their dates correspond to the creation date of their respective difference files:

C:\Windows\system32>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.

Contents of shadow copy set ID: {dc076348-41a8-4e3a-a5e5-a88983ee56d4}
   Contained 1 shadow copies at creation time: 6/10/2014 11:16:32 PM
      Shadow Copy ID: {652f7312-d68e-4a3b-9a53-503ee2346e2c}
         Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1
         Originating Machine: TRex-IV
         Service Machine: TRex-IV
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

Contents of shadow copy set ID: {a0fdc68a-41c9-4e16-b211-46824209fb8a}
   Contained 1 shadow copies at creation time: 6/11/2014 8:22:41 AM
      Shadow Copy ID: {5bd40ec7-20e0-4786-a562-438dd34fb63e}
         Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
         Originating Machine: TRex-IV
         Service Machine: TRex-IV
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

Contents of shadow copy set ID: {be4e4582-9582-49c7-9908-1e58846aa694}
   Contained 1 shadow copies at creation time: 6/15/2014 7:36:09 AM
      Shadow Copy ID: {406ed655-8bee-4ea5-87ec-f1c5e5b67889}
         Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3
         Originating Machine: TRex-IV
         Service Machine: TRex-IV
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

Other artifacts indicating viable shadow copies, or lack thereof:

Event logs, specifically the system event log, can tell a bit about shadow copies.  As you have pointed out in some blog posts this past week, system event ID 33 can tell you when and why a shadow copy was deleted, including whether a shadow copy was deleted because it failed for some reason.  (Because the point of shadow copies is to create backups, including system restore backups, they have a lot of error checking around them to prevent a defective shadow copy from being used to over write parts of a volume during a restore operation.)  A quick Internet search for volsnap, vss, or volume shadow event IDs turns up several other event IDs that would be informative regarding shadow copies.  I would advise sorting the system event log on source, then looking at entries related to “volsnap” to identify all events relating to volume snapshot.

The application event log can also contain events relating to shadow copies, or the shadow copy service, including warnings and errors.  There are several possible event IDs, so again I recommend sorting source and examining entries relating to “VSS.”

Reviewing the AppLocker exe/DLL event log, if enabled, may also provide information.  For example, shadow copy behavior can be controlled, and shadow copies deleted, using FSUTIL.exe, VSSadmin.exe, or DiskShadow.exe (not on all versions of Windows).  If the AppLocker exe/DLL log shows any of these tools as having been run, their running may have impacted shadow copies.  Correlating relevant AppLocker activity to file system events, such as the creation, deletion, and last modified time of the difference files may allow the analyst to pin down how such tools were used.

The security event log can be used in the same way as the AppLocker event log, if process auditing is enabled.  If process auditing is enabled, review process start and end events (IDs 4688/4689) for FSUTIL.exe, VSSadmin.exe, or DiskShadow.exe, and correlate with file system metadata around the difference files.

Prefetch files have the potential to provide some of the same information relating to execution of programs that can be used to modify, create, or deleted shadow copies.  As with the security event log or the applocker event log, look for prefetch files relating to FSUTIL.exe, VSSadmin.exe, or DiskShadow.exe.  The prefetch file can tell you when such tools may have first been run, when they were last run, and how many times they were run.  There is also the possibility that the path and names of difference files may be listed in the files enumerated in a prefetch file.

The NTFS Boot Sector shows some information about shadow copies.  Below is a hex dump of a portion of the last sector on the a volume boot sector, with relevant strings highlighted and commented.  (Thanks to Joachim Metz)

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F

000001E00   6B 87 08 38 76 C1 48 4E  B7 AE 04 04 6E 6C C7 52   k‡ 8vÁHN·®  nlÇR     VSS Header
000001E10   01 00 00 00 01 00 00 00  00 1E 00 00 00 00 00 00                  
000001E20   00 1E 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
000001E30   00 C0 F2 02 00 00 00 00  CC 3C F9 DF 00 00 00 00    Àò     Ì<ùß                                   Offset to the catalog file from the start of the volume.
000001E40   52 B2 B5 2B 89 BD E0 11  9D B3 80 6E 6F 6E 69 63   R²µ+‰½à  ³€nonic
000001E50   52 B2 B5 2B 89 BD E0 11  9D B3 80 6E 6F 6E 69 63   R²µ+‰½à  ³€nonic
000001E60   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000001E70   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000001E80   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  

{GUID}_OnDiskSnapshotProp files, in the \System Volume Information\SPP\OnlineMetadataCache are another file type that can provide information about shadow copies.  You have pointed these out on your blog this past week.   The GUID portion of the file name will match the GUID of the shadow copy set ID that you see when you run VSSadmin.exe.  The file created date of the {GUID}_OnDiskSnapshotProp file will closely, but not exactly, match the date of the corresponding shadow copy.  As shown below, examining the internals of a {GUID}_OnDiskSnapshotProp file will indicate the the date and time of a shadow copy within a few seconds to a minute, as well as the reason the shadow copy was created. 

The shadow copy date and reason are highlighted in red in the hex of a {GUID}_OnDiskSnapshotProp file header:

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
000000000   1F 44 FA A0 8E F6 CC 4D  9D 91 2C 2E BE C0 BB 63    Dú ŽöÌM ‘,.¾À»c
000000010   38 6C E1 D1 00 00 00 00  01 10 08 00 CC CC CC CC   8láÑ        ÌÌÌÌ
000000020   50 43 00 00 00 00 00 00  82 45 4E BE 82 95 C7 49   PC      ‚EN¾‚•ÇI
000000030   99 08 1E 58 84 6A A6 94  3D 02 00 00 00 00 00 00   ™  X„j¦”=      
000000040   79 15 E6 14 A7 88 CF 01  12 00 00 00 00 00 02 00   y æ §ˆÏ           Timestamp: 6/15/2014 7:35:40
000000050   EE A1 3D CB A3 B9 5D 40  8D 55 A1 F5 7F 3D 1F EA   î¡=Ë£¹]@ U¡õ = ê
000000060   04 00 02 00 08 00 02 00  0C 00 02 00 00 00 00 00                  
000000070   01 00 00 00 10 00 02 00  02 00 00 00 24 00 02 00               $  
000000080   96 00 00 00 58 00 02 00  0F 00 00 00 00 00 00 00   –   X          
000000090   0F 00 00 00 57 00 69 00  6E 00 64 00 6F 00 77 00       W i n d o w
0000000A0   73 00 20 00 55 00 70 00  64 00 61 00 74 00 65 00   s   U p d a t e   Cause or reason for the shadow copy.
0000000B0   00 00 00 00 0C 00 00 00  00 00 00 00 0C 00 00 00                  
0000000C0   43 00 3A 00 5C 00 57 00  69 00 6E 00 64 00 6F 00   C : \ W i n d o
0000000D0   77 00 73 00 5C 00 00 00  08 00 00 00 00 00 00 00   w s \          
0000000E0   08 00 00 00 54 00 52 00  45 00 58 00 2D 00 49 00       T R E X - I   Computer name (in case you mix up your image and case files.
0000000F0   56 00 00 00 0A 00 00 00  00 00 00 00 0A 00 00 00   V              
000000100   57 00 4F 00 52 00 4B 00  47 00 52 00 4F 00 55 00   W O R K G R O U
000000110   50 00 00 00 01 00 00 00  55 D6 6E 40 EE 8B A5 4E   P       UÖn@î‹¥N
000000120   87 EC F1 C5 E5 B6 78 89  0C 00 00 00 14 00 02 00   ‡ìñÅå¶x‰       
000000130   02 00 00 00 18 00 02 00  0C 00 00 00 64 A6 1F 87               d¦ ‡
000000140   00 00 50 06 00 00 00 00  02 00 00 00 1C 00 02 00     P            
000000150   20 00 02 00 32 00 00 00  00 00 00 00 32 00 00 00       2       2  
000000160   5C 00 5C 00 3F 00 5C 00  56 00 6F 00 6C 00 75 00   \ \ ? \ V o l u
000000170   6D 00 65 00 7B 00 36 00  63 00 35 00 62 00 65 00   m e { 6 c 5 b e
000000180   61 00 66 00 39 00 2D 00  62 00 64 00 38 00 38 00   a f 9 - b d 8 8
000000190   2D 00 31 00 31 00 65 00  30 00 2D 00 38 00 39 00   - 1 1 e 0 - 8 9
0000001A0   66 00 39 00 2D 00 38 00  30 00 36 00 65 00 36 00   f 9 - 8 0 6 e 6
0000001B0   66 00 36 00 65 00 36 00  39 00 36 00 33 00 7D 00   f 6 e 6 9 6 3 }
0000001C0   5C 00 00 00 04 00 00 00  00 00 00 00 04 00 00 00   \              

The {GUID}_OnDiskSnapshotProp files are not actually part of the volume shadow component, but a different Windows component.   As such, there might be cases were things are broken and a {GUID}_OnDiskSnapshotProp does not exist for a shadow copy.  I haven’t tested this, but you can probably delete a {GUID}_OnDiskSnapshotProp  file without destroying the corresponding shadow copy.  A shadow copy, however, cannot exist without a corresponding difference file—i.e., a difference file having a creation date that matches a shadow copy.  In fact, a shadow copy cannot exist unless all of the difference files for a volume with creation dates equal to or more recent than the shadow copy exist and are viable (i.e., not corrupted, usable). 

This latter point is important and is based on how shadow copies are created and maintained.  A standard Windows shadow copy is a point-in-time differential backup of a volume.  When a shadow copy starts, the shadow copy system examines the volume and determines what files are going to be protected.  The clusters of these files are then mapped to what volume shadow copy will see has its protected space.  The volume shadow protected space is divided into 16KB blocks.  As the shadow copy is being created, it will use a copy-on-write procedure to copy the original of a protected block into the current difference file when it detects the first write to a block in its protected space.  Once the original block is preserved, the data in the protected space can be written to.  This is described in more detail in the latest edition of the Windows Internals books.

When you surface or read a shadow copy, the volume shadow copy service creates a picture of the volume at an earlier time by combining the blocks in the difference file with the unchanged blocks still on disk.  For any shadow copy older than the most recent, the volume shadow copy services create the snapshot-in-time of the volume by combining the blocks in its difference file with appropriate blocks in more recent difference files and with unchanged blocks on disk.  The difference files make a chain where deletion or damage to a more recent difference file can be fatal to any less recent shadow copy.  Thus, it is possible to see what appear to be existing and viable shadow copies in a volume image, but not see any or some of the expected shadow copies when the volume image is mounted and examined with VSSadmn—it means that one or more of difference files in the chain maybe corrupted or otherwise not usable.   

What a difference file tells me I might find:

Shadow copies present the volume as it appeared at the start of the shadow copy creation.  A shadow copy should preserve a copy of any file not specifically excluded from shadow copies (more on that below) that existed before the start of the shadow copy and was changed during the shadow copy creation period. 

To be preserved, a file must exist to be considered part of the protected space.  Deleted files and files created after the start of the shadow copy will not be taken into account during the computation of the protected space computation, and thus will not be directly preserved (although they may be incidentally preserved as describe below.)   If the clusters of the file are in the protected space, then the file will be preserved when a write occurs to any of the clusters in the block containing the file.  This means that what is preserved may only be a portion of the file, if the file spans clusters in a block the was copied to the difference file and more blocks that weren’t.  When the shadow copy is surfaced, the file will be put back together, even where some parts are in a difference file, and some not. 

Side note:  Since it is file modification that copies a protected file’s original data into the difference file, file wiping or encryption are more likely to ensure that a file lands in a shadow copy than simple deletion. 

Because shadow copies are built from 16KB blocks, which are four time larger than the default NTFS cluster size, it is possible for clusters to be captured in a difference file even though files owning the clusters containing  may have been excluded or not considered in generating the map of the protected space.  That is, there will be gaps and leaks in the mapping of 16KB protected blocks to clusters on disk.  Thus, files deleted prior to the creation of a shadow copy would not be considered by volume shadow copy in building the map of protected space.  The clusters of these deleted file, however, may fall into 16KB protected blocks, and such data will be copied to a difference file if a protected file in such blocks is changed. 

Normal forensics searches (string, hex, block hash, etc.) can identify data, possibly even whole files, inside the difference files.  Because the way volume shadow copy preserves files—in 16KB blocks—files will not necessarily be found whole in a continues set of sectors within a difference file.  Significant search results in a difference file may indicate the shadow copy it corresponds to should be imaged and examined as discussed below. 

What is excluded from shadow copies:

Certain files and data are excluded from shadow copies by default by Windows and Office.  Data is excluded from the shadow copy process by keys under the following registry node:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\BackupRestore. 

Sub keys FilesNotToBackUp and FileNotToSnapshot control what files are excluded from the volume shadow copy process.  These keys can be edited by users to add to or change the exclusions. Note that volume shadow copy files are excluded under the FileNotToBackUp key.

Other registry keys controlling or relating to volume shadow copies are:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\volsnap\
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\volsnap\Enum
which relate to the volume shadow copy driver, volsnap.sys, and
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\VSS and its sub keys. 

The Providers sub key under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\VSS should be reviewed in some instances, as it may show that special volume shadow providers, for SQL, for example, have been installed.  The basic volume shadow copy component in Windows promises consistent volume snapshots at the file system level.  It does not promise file level consistency.  Thus, to effectively snapshot files such as databases, special VSS providers must be installed to ensure that certain files are preserved in an internal consistent manner.  See http://technet.microsoft.com/en-us/library/cc785914(v=WS.10).aspx.

Going deep, the shadow copy catalog and difference files:

There is a great deal that can be learned about the shadow copies on a system by examining  the volume shadow copy catalog and difference files.  Joachim Metz has detailed this information quite well in his paper, Volume Shadow Snapshot (VSS): Analysis the Windows NT VSS format.  These files are the first and most definitive place to learn about the shadow copies on a system without booting or mounting an image of a volume.

The catalog file:  The catalog file is found in the \System Volume Information folder with the difference files.  Unlike the {GUID}{GUID} names of the difference files, the catalog file has a one {GUID} name: {3808876b-c176-4e48-b7ae-04046e6cc752}.  Its file system time stamps are not updated.

The catalog file will enumerate the difference files, provide a time stamp for each, and give the file record segment number of each corresponding difference file, among many other details.  Below is a hex dump of a portion of the catalog file that goes with the shadows copies mentioned above.  It is highlighted and commented to show useful information.   All this and much more is laid out in Joachim Metz paper.

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
000000000   6B 87 08 38 76 C1 48 4E  B7 AE 04 04 6E 6C C7 52   k‡ 8vÁHN·®  nlÇR     Header
000000010   01 00 00 00 02 00 00 00  00 00 00 00 00 00 00 00                  
000000020   00 C0 F2 02 00 00 00 00  00 00 F3 02 00 00 00 00    Àò       ó    
000000030   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000040   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000060   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000070   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                        Data for first shadow copy in the catalog (from the top of catalog file):
000000080   02 00 00 00 00 00 00 00  00 00 A0 E8 22 00 00 00              è"        Type 2 entry, per Metz.
000000090   D8 87 10 2B 72 F1 E3 11  BF 50 00 1F D0 81 E6 F9   ؇ +rñã ¿P  Ð æù     GUID used in the name, some of which is little endian: {2b1087d8-f172-11e3-bf50-001fd081e6f9}{3808876b-c176-4e48-b7ae-04046e6cc752} 
0000000A0   28 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00   (       @      
0000000B0   A0 0D 3B FC 88 85 CF 01  00 00 00 00 00 00 00 00     ;üˆ…Ï              Date of this shadow copy.
0000000C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000000D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000000E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000000F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000100   03 00 00 00 00 00 00 00  00 80 6D 80 11 00 00 00            €m€         Type 3 entry, per Metz.
000000110   D8 87 10 2B 72 F1 E3 11  BF 50 00 1F D0 81 E6 F9   ؇ +rñã ¿P  Ð æù     GUID used in the name, as discussed above.
000000120   00 40 6D 80 11 00 00 00  00 C0 6D 80 11 00 00 00    @m€     Àm€         Offset from the start of volume to the start of the difference file, for this shadow copy.
000000130   00 40 75 80 11 00 00 00  C8 10 02 00 00 00 3E 00    @u€    È     >      File record segment number and sequence number of difference file, for this shadow copy.
000000140   00 00 00 00 00 00 00 00  00 80 87 80 11 00 00 00            €‡€   
000000150   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000160   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000170   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                        Data for second shadow copy in the catalog (from the top of catalog file):
000000180   02 00 00 00 00 00 00 00  00 00 A0 E8 22 00 00 00              è"        Type 2 entry, per Metz.
000000190   13 7A F3 62 2E F1 E3 11  A3 B9 00 1F D0 81 E6 F9    zób.ñã £¹  Ð æù     GUID used in the name, as discussed above.
0000001A0   27 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00   '       @      
0000001B0   0E A5 75 B0 3C 85 CF 01  00 00 00 00 00 00 00 00    ¥u°<…Ï              Date of this shadow copy.
0000001C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000200   03 00 00 00 00 00 00 00  00 C0 36 AF 11 00 00 00            À6¯   
000000210   13 7A F3 62 2E F1 E3 11  A3 B9 00 1F D0 81 E6 F9    zób.ñã £¹  Ð æù     GUID used in the name, as discussed above.
000000220   00 80 36 AF 11 00 00 00  00 00 37 AF 11 00 00 00    €6¯      7¯         Offset from the start of volume to the start of the difference file, for this shadow copy.
000000230   00 C0 8D AF 11 00 00 00  F0 F3 00 00 00 00 9C 00    À ¯    ðó    œ      File record segment number and sequence number of difference file, for this shadow copy.
000000240   00 00 00 00 00 00 00 00  00 80 A2 AF 11 00 00 00            €¢¯   
000000250   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000260   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000270   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                        Data for third shadow copy in the catalog (from the top of catalog file):
000000280   02 00 00 00 00 00 00 00  00 00 A0 E8 22 00 00 00              è"        Type 2 entry, per Metz.
000000290   61 3A 51 A8 99 F4 E3 11  92 DB 00 1F D0 81 E6 F9   a:Q¨™ôã ’Û  Ð æù     GUID used in the name, as discussed above.
0000002A0   29 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00   )       @      
0000002B0   60 F4 BA 25 A7 88 CF 01  00 00 00 00 00 00 00 00   `ôº%§ˆÏ              Date of this shadow copy.
0000002C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000002D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000002E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000002F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000300   03 00 00 00 00 00 00 00  00 C0 69 86 12 00 00 00            Ài†         Type 3 entry, per Metz.
000000310   61 3A 51 A8 99 F4 E3 11  92 DB 00 1F D0 81 E6 F9   a:Q¨™ôã ’Û  Ð æù     GUID used in the name, as discussed above.
000000320   00 80 69 86 12 00 00 00  00 00 6A 86 12 00 00 00    €i†      j†         Offset from the start of volume to the start of the difference file, for this shadow copy.
000000330   00 80 79 86 12 00 00 00  D1 8A 02 00 00 00 03 00    €y†    ÑŠ           File record segment number and sequence number of difference file, for this shadow copy.
000000340   00 00 00 00 00 00 00 00  00 C0 8B 86 12 00 00 00            À‹†   
000000350   02 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000360   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000370   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000380   01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000390   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000003F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  

The difference files—{GUID}{3808876b-c176-4e48-b7ae-04046e6cc752}: The difference file contains the protected blocks preserved during a shadow copy creation. In addition to containing copied protected blocks, difference files contain important metadata information, some of which, as mentioned above, has been well documented for us by Joachim Metz.  Among other things, a difference file contains information to link it to its corresponding shadow copy.  Below is a hex dump of a portion of a difference file highlighted and commented to show useful information.  

Offset       0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
000000000   6B 87 08 38 76 C1 48 4E  B7 AE 04 04 6E 6C C7 52   k‡ 8vÁHN·®  nlÇR     Header
000000010   01 00 00 00 04 00 00 00  00 00 00 00 00 00 00 00                  
000000020   00 40 6D 80 11 00 00 00  00 00 00 00 00 00 00 00    @m€                 Offset from the start of the volume.   
000000030   60 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   `              
000000040   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000060   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000070   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000080   45 7D DE E5 F2 49 A4 40  81 7C 7D C8 2B 72 58 7F   E}ÞåòI¤@ |}È+rX
000000090   C7 0E D4 5B E0 20 86 47  A5 62 43 8D D3 4F B6 3E   Ç Ô[à †G¥bC ÓO¶>     Shadow copy ID: {5bd40ec7-20e0-4786-a562-438dd34fb63e} (per vssadmin). Note, some parts are little endian.
0000000A0   8A C6 FD A0 C9 41 16 4E  B2 11 46 82 42 09 FB 8A   ŠÆý ÉA N² F‚B ûŠ     Shadow copy set ID: {a0fdc68a-41c9-4e16-b211-46824209fb8a} (per vssadmin). Note, some parts are little endian.
0000000B0   0D 00 00 00 01 00 00 00  0D 00 42 00 00 00 00 00             B          Provider-here Windows default. 0xB8: Attribute flags.  See Metz.  Flags are added to get value.  See below.
0000000C0   0E 00 54 00 52 00 65 00  78 00 2D 00 49 00 56 00     T R e x - I V      Computer name.
0000000D0   0E 00 54 00 52 00 65 00  78 00 2D 00 49 00 56 00     T R e x - I V      Computer name.
0000000E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000000F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000100   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000110   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000120   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000130   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                   
000000140   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000150   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000160   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000170   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000180   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
000000190   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001A0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001B0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001C0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001D0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001E0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00                  
0000001F0   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 


Determining Attribute Flags:

Quoting Metz:

0x00000001 VSS_VOLSNAP_ATTR_PERSISTENT
0x00000004 VSS_VOLSNAP_ATTR_CLIENT_ACCESSIBLE
0x00000008 VSS_VOLSNAP_ATTR_NO_AUTO_RELEASE
0x00020000 VSS_VOLSNAP_ATTR_DIFFERENTIAL
0x00400000 VSS_VOLSNAP_ATTR_AUTORECOVER

From vssadmin:
Contents of shadow copy set ID: {a0fdc68a-41c9-4e16-b211-46824209fb8a}
   Contained 1 shadow copies at creation time: 6/11/2014 8:22:41 AM
      Shadow Copy ID: {5bd40ec7-20e0-4786-a562-438dd34fb63e}
         Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\
         Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2
         Originating Machine: TRex-IV
         Service Machine: TRex-IV
         Provider: 'Microsoft Software Shadow Copy provider 1.0'
         Type: ClientAccessibleWriters
         Attributes: Persistent, Client-accessible, No auto release, Differential, Auto recovered

Attribute flag value consists of the applicable attribute codes added together:
            00000001
            00000004
            00000008
            00020000
+          00400000

=          0042000D, which after taking into account little endian, matches our value above: 0D 00 42 00 00 00 00 00            


Mounting, but not booting:

As mentioned above, it should never be necessary to boot an image if the analyst has a suitable Windows machine to mount the imaged volume as volume.  Not all image mounting software is capable of mounting an image in a way that Windows takes it as a mounted volume.  I understand that the Arsenal Image Mounter mounts images via iSCSI, and that should work to create a true volume mount point (as opposed to a network share type mount point used by some image mounting software).   After mounting the image as a volume, one can use the native Windows API’s and programs to access files within shadow copies or use something like Metz’s VShadow.

My current procedure is to convert multi-file images into non-compressed, single file, dd type images.  I then convert those into VHD using a tool called VHDTool that until very recently was available for down load from MSDN.  Converting to VHD format means adding a VHD header and footer to the image, so it is something that could be done manually.  Once converted to VHD format, I mount the VHD, read only, as a volume on a Windows 7 or better machine.  At this point, the shadow copies on the image become objects that I can through normal Windows APIs and programs.

Side note: .  Shadow copies are objects you can see with the Sysinternals WinObj tool.:



With the VHD mounted as a volume, one can run vssadmin to identify the shadow copies:

                vssadmin list shadows /for=[volume]:

From there, one can use the object name  \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2 to create a symbolic link to surface the shadow copy as a symbolically linked folder:

                Mklink /d C:\{test-shadow} \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\

For a quick and dirty review of the files on a volume, the following two commands will 1) create a symbolic link to each shadow copy, and 2) create a directory listing of all the files on each shadow copy:

Create a link to every shadows copy:
                for /f "tokens=4" %f in ('vssadmin list shadows ^| findstr GLOBALROOT') do @for /f "tokens=4 delims=\" %g in ("%f") do @mklink /d %SYSTEMDRIVE%\%g %f\

Create a dir listing of all the files and directories in the shadow copy:
                for /f "tokens=1" %f in ('dir C:\ /B /A:D ^| findstr HarddiskVolumeShadowCopy') do @dir C:\%f /B /O:N /S > E:\%f-fileList.txt

By using simple but complete file lists, one can quickly identify files added to or subtracted from a volume.  Below is a difference between two file lists showing files added to a volume by stuxnet:



Imaging:

When I need to thoroughly examine or recover data from a shadow copy, I image it so that I can  examine the shadow copy volume is detail with my forensics tools of choice.  To do this, the image is converted to a VHD, as above, and then examined by vssadmin to identify the shadow copies I am interested in..  Because shadow copies are objects, I can pass them to an appropriate tool to create an image—a volume image—from a shadow copy.  George Garner’s FAU contains dd.exe, which works well as the imaging software.  To image, just feed the shadow copy object name to dd.exe:

                D:\fau-1.3.0.2390a\fau\FAU.x64>dd if=\\.\HarddiskVolumeShadowCopy11 of=E:\shadow11.dd --localwrt

The resulting image is a snapshot of the volume at an earlier time.  The image can now be processed in forensics tools just as an original disk image, and should result in being able to see things and recover data that you just could not see or recover on the original disk image.