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.
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.
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}
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}
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}
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}
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]:
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.
