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.
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 shadowsvssadmin 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 PMShadow Copy ID: {652f7312-d68e-4a3b-9a53-503ee2346e2c}Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1Originating Machine: TRex-IVService Machine: TRex-IVProvider: 'Microsoft Software Shadow Copy provider 1.0'Type: ClientAccessibleWritersAttributes: Persistent, Client-accessible, No auto release, Differential, Auto recoveredContents of shadow copy set ID: {a0fdc68a-41c9-4e16-b211-46824209fb8a}Contained 1 shadow copies at creation time: 6/11/2014 8:22:41 AMShadow Copy ID: {5bd40ec7-20e0-4786-a562-438dd34fb63e}Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2Originating Machine: TRex-IVService Machine: TRex-IVProvider: 'Microsoft Software Shadow Copy provider 1.0'Type: ClientAccessibleWritersAttributes: Persistent, Client-accessible, No auto release, Differential, Auto recoveredContents of shadow copy set ID: {be4e4582-9582-49c7-9908-1e58846aa694}Contained 1 shadow copies at creation time: 6/15/2014 7:36:09 AMShadow Copy ID: {406ed655-8bee-4ea5-87ec-f1c5e5b67889}Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3Originating Machine: TRex-IVService Machine: TRex-IVProvider: 'Microsoft Software Shadow Copy provider 1.0'Type: ClientAccessibleWritersAttributes: Persistent, Client-accessible, No auto release, Differential, Auto recoveredOther 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 F000001E00 6B 87 08 38 76 C1 48 4E B7 AE 04 04 6E 6C C7 52 k‡ 8vÁHN·® nlÇR VSS Header000001E10 01 00 00 00 01 00 00 00 00 1E 00 00 00 00 00 00000001E20 00 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00000001E30 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²µ+‰½à ³€nonic000001E50 52 B2 B5 2B 89 BD E0 11 9D B3 80 6E 6F 6E 69 63 R²µ+‰½à ³€nonic000001E60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000001E70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000001E80 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 F000000000 1F 44 FA A0 8E F6 CC 4D 9D 91 2C 2E BE C0 BB 63 Dú ŽöÌM ‘,.¾À»c000000010 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¾‚•ÇI000000030 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:40000000050 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 00000000070 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 – X000000090 0F 00 00 00 57 00 69 00 6E 00 64 00 6F 00 77 00 W i n d o w0000000A0 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 000000000C0 43 00 3A 00 5C 00 57 00 69 00 6E 00 64 00 6F 00 C : \ W i n d o0000000D0 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 V000000100 57 00 4F 00 52 00 4B 00 47 00 52 00 4F 00 55 00 W O R K G R O U000000110 50 00 00 00 01 00 00 00 55 D6 6E 40 EE 8B A5 4E P UÖn@î‹¥N000000120 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 P000000150 20 00 02 00 32 00 00 00 00 00 00 00 32 00 00 00 2 2000000160 5C 00 5C 00 3F 00 5C 00 56 00 6F 00 6C 00 75 00 \ \ ? \ V o l u000000170 6D 00 65 00 7B 00 36 00 63 00 35 00 62 00 65 00 m e { 6 c 5 b e000000180 61 00 66 00 39 00 2D 00 62 00 64 00 38 00 38 00 a f 9 - b d 8 8000000190 2D 00 31 00 31 00 65 00 30 00 2D 00 38 00 39 00 - 1 1 e 0 - 8 90000001A0 66 00 39 00 2D 00 38 00 30 00 36 00 65 00 36 00 f 9 - 8 0 6 e 60000001B0 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\Enumwhich relate to the volume shadow copy driver, volsnap.sys, andHKEY_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 F000000000 6B 87 08 38 76 C1 48 4E B7 AE 04 04 6E 6C C7 52 k‡ 8vÁHN·® nlÇR Header000000010 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00000000020 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 00000000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000070 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 000000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000100 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 00000000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000170 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 000000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000200 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 00000000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000270 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 000000002D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000002E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000002F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000300 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 00000000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000370 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000380 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000003F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00The 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 F000000000 6B 87 08 38 76 C1 48 4E B7 AE 04 04 6E 6C C7 52 k‡ 8vÁHN·® nlÇR Header000000010 01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00000000020 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 00000000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000080 45 7D DE E5 F2 49 A4 40 81 7C 7D C8 2B 72 58 7F E}ÞåòI¤@ |}È+rX000000090 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 000000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Determining Attribute Flags:Quoting Metz:0x00000001 VSS_VOLSNAP_ATTR_PERSISTENT0x00000004 VSS_VOLSNAP_ATTR_CLIENT_ACCESSIBLE0x00000008 VSS_VOLSNAP_ATTR_NO_AUTO_RELEASE0x00020000 VSS_VOLSNAP_ATTR_DIFFERENTIAL0x00400000 VSS_VOLSNAP_ATTR_AUTORECOVERFrom 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 AMShadow Copy ID: {5bd40ec7-20e0-4786-a562-438dd34fb63e}Original Volume: (C:)\\?\Volume{6c5beaf9-bd88-11e0-89f9-806e6f6e6963}\Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2Originating Machine: TRex-IVService Machine: TRex-IVProvider: 'Microsoft Software Shadow Copy provider 1.0'Type: ClientAccessibleWritersAttributes: Persistent, Client-accessible, No auto release, Differential, Auto recoveredAttribute flag value consists of the applicable attribute codes added together:00000001000000040000000800020000+ 00400000= 0042000D, which after taking into account little endian, matches our value above: 0D 00 42 00 00 00 00 00Mounting, 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.txtBy 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 --localwrtThe 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.
Also Read: Daily Blog #357
Post a Comment