Daily Blog #365: The year of blogging complete and the stage 1 question

The year of blogging complete and the stage 1 question - by David Cowen

Hello Reader,
        Thank you to those of you have kept up for the last 365 days, it has been both challenging and rewarding to force myself to keep looking, researching, documenting and sharing what I know with all of you. I hope you found some benefit to the last year, but I have received enough personal satisfaction and knowledge to make it worthwhile regardless. I highly recommend anyone else out there who wants to push themselves forward in their understanding of all things DFIR to give the Zeltser challenge a shot.

Now for what you all came here for, the 1st stage challenge in the 5 stage Sunday Funday challenge for a free vLive class from SANS.

  • Email me your answers at dcowen@g-cpartners.com

  • The contest will run until July 6th

  • To get the 2nd stage you must successfully email me the answer to the 1st.


Stage 1 Question:
You are dealing with an attacker who has used the volume shadow service to create a a new copy of the volume and then exported the active directory database from it, a common tactic and one we use at NCCDC. If they cleared the security logs after doing this how could you recover where they logged in from.

FAQ:
1. Keep the answer to the server, no firewall logs here or SIEM accessible. The 1st stage is testing your knowledge of Windows Server 2008.
2. The attack happened a week ago
3. Keep re-reading the question if you haven't picked up the clue

Also Read: Daily Blog #364

Daily Blog #364: Sunday Funday 6/22/14 - Solve the Challenge for vLive DFIR Class from SANS

vLive DFIR Class Challenge by David Cowen - Hacking Exposed Computer Forensics Blog


Hello Reader,
 
The Prize:
A free vLive DFIR Class from SANS a prize worth $5,000, you can choose from the following:





The Rules, Have Changed!:


  1. This will be a multi stage contest lasting two weeks
  2. Final answers must be in by July 6th
  3. 6/23/14 The first question will be posted
  4. New questions will be given to those who answer the first question correctly
  5. You can start the contest at any point leading up to July 6th, there is no penalty for starting late
  6. All submissions must be sent to dcowen@g-cpartners.com, do not post answers in the comments
  7. In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post



The Challenge:     Will be announced tomorrow. The year of blogging ends tomorrow as do the restrictions I have in having to get up daily content for you. So let's change things up! Tomorrow on Daily Blog #365 the first question will be given. Your goal is to answer this question via email to me dcowen@g-cpartners.com. On receiving a correct answer you will be notified that you have entered stage 2 and that another question will be sent to you. There are 5 stages and the player who makes it the farthest with the most correct answer will win!

Make sure to watch the Forensic Lunch to get clues and good luck!

Also Read: Daily Blog #363 

Daily Blog #363: Saturday Reading 6/21/14

Saturday Reading by David Cowen - Hacking Exposed Computer Forensics Blog


Hello Reader,
         It's Saturday! I don't know about you but it's been a long week. While we both finishing tracking down those miscreants we've been hunting this week, here's some links to make you think while volatility runs in this weeks Saturday Reading!

1. We had a great forensic lunch this week.  We had (in order of appearance)

  • Blazer Catzen, of Catzen Forensics, talking all about File System Tunneling in an extensive piece of research that goes beyond the STDINFO and into the File Name attributes and Object IDs. Blazer has two presentations he has done on the subject so I hope to talk him into a guest blog about it, if he does not put up his own blog first.
  • Detective Cindy Murphy, with the Madison Wisconsin police talking all about Mobile Forensics and her journey in DFIR. 
For those who watched the link to the SANS Work Study program is here:
https://www.sans.org/work-study

You can watch it here:  https://www.youtube.com/watch?feature=player_embedded&list=UUZ7mQV3j4GNX-LU1IKPVQZg&v=bI9T2-bnbM0

2. AppleExaminer has updated the OSX and IOS focus lists, cheat sheets of where to look for artifacts. Get it here: http://www.appleexaminer.com/files/b79f4470195d89b9d6a6ec0e4f8799fa-68.html

3. Craig Ball has a new post up and his perspective as a special master is always interesting. This week he is talking about an issue he is facing where he's trying to understand someones motive for inflating their fees http://ballinyourcourt.wordpress.com/2014/06/19/unconscionable/

4. Corey Harrell has posted up a review of Harlan's updated WFA http://journeyintoir.blogspot.com/2014/06/review-of-windows-forensic-analysis-4th.html

5. Matthew, my partner in lunch, posted a new entry to his new blog. Talking all about additional fields stored within the prefetch files revealing file record numbers and sequence numbers http://forensicmatt.blogspot.com/2014/06/possible-new-field-identified-in.html

That's all for this week!

Also Read: Daily Blog #362

Daily Blog #362: Forensic Lunch 6/20/14 - Discussion with Blazer Catzen, Detective Cindy Murphy on File System Tunneling and More



Hello Reader,
          We had a great Forensic Lunch today, we had (in order of appearance)

  • Blazer Catzen, of Catzen Forensics, talking all about File System Tunneling in an extensive piece of research that goes beyond the STDINFO and into the File Name attributes and Object IDs. Blazer has two presentations he has done on the subject so I hope to talk him into a guest blog about it, if he does not put up his own blog first.
  • Detective Cindy Murphy, with the Madison Wisconsin police talking all about Mobile Forensics and her journey in DFIR. 
For those who watched the link to the SANS Work Study program is here:
https://www.sans.org/work-study

 You can watch the lunch below:


Daily Blog #361: SCCM and IR

SCCM and IR by David Cowen - Hacking Exposed Computer Forensics Blog


Hello Reader,
           You may not often combine the ideas of SCCM (System Center Configuration Manager) and Incident Response together, but you should. I wanted to pass a long something that I've used as a recurring script to track users to computers and in IR situations to find possible compromised system if the attacker is doing interactive logins.

Step 1. Ask the SCCM admin for read only access to the back end SCCM database. This is important, the SCCM MS SQL database and not the SCCM front end.

Step 2 .Get a MS SQL client, I like navicat for SQL Server, http://www.navicat.com/products/navicat-for-sqlserver, which has a free trial

Step 3. Access the database and find the computer table, I've seen it named 'v_GS_COMPUTER_SYSTEM' and 'COMPUTER_SYSTEM_HIST'. Look for something similar .

Step 4. Run the following query:

select Name0 from (COMPUTER_SYSTEM_TABLE_YOU_FOUND) where UserName0=

What will come back is a list of all the systems that recorded that the compromised account was the last account to have logged in. This will obviously get changed quickly once the next user logs in back can bring back a lot of intelligence to you as to where an active attacker has been hitting.

Also Read: Daily Blog #360

Daily Blog #360: NIST Mobile Forensics Workshop Streaming Live Today

NIST Mobile Forensics Workshop streaming live today


Hello Reader,
             As I type this I'm listening to the live webcast from the NIST Mobile Forensics workshop. There are some great speakers lined up and they are streaming all the presentations live, no registration required, to the world. So if you want to hear about some great mobile forensics research and state of the industry make sure to tune in.

You can read more about the event here:
http://www.nist.gov/forensics/mobile_forensics2.cfm

You can watch it live here:
http://www.nist.gov/forensics/nist-mobile-forensics-webcast.cfm

Daily Blog #359: Carving USN Records

Carving USN Records by David Cowen - Hacking Exposed Computer Forensics Blog


Hello Reader,
           Today I want to talk about something I find very exciting. You know how much we enjoy USN journals but as with all the best artifacts its limited in scope as to amount of time the journal goes back. We previously found joy in the fact that USN Journals are included in the Volume Shadow Copies meaning we could recover much more data about what happened in the past, but now we can get even more!

I was under the misconception in the past that USN Journals like the $logfile was a circular log, meaning the data at the beginning of the journal would be overwritten when the space allocated ran out. This belief though did not line up with what we saw in the journal itself, we just kept seeing blocks of 0's assigned and no overwritten records. After talking to Troy Larson though I now understand that this behavior is due to the fact that the journal is not circular but rather pages are allocated and deallocated as the journal grows.

Why is this exciting? This means that old records are not overwritten just deallocated and hanging out in the unallocated space in the partition. That means we can carve for these records and recover much more USN Journal data. USN Journal data when carved is especially useful as a record contains everything you need to know within (timestamp, file reference number, filename, etc...) nothing leading up to or proceeding a record will detract from the value of carving even a single record.

Currently I know X-ways Forensics supports carving these entries and we will be coming out with carving signatures for you to use as well. This is great news and will lead to even more great evidence! As we move forward with the commercial version of the Triforce you should expect to see this carving functionality built in as well.

Also Read: Daily Blog #358

Daily Blog #358: Sunday Funday Winner 6/15/14 - Windows 7 Shadow Copies Challenge

Windows 7 Shadow Copies Challenge by David Cowen - Hacking Exposed Computer Forensics Blog

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:

Windows 7 Shadow Copies Challenge by David Cowen - Hacking Exposed Computer Forensics Blog




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

Windows 7 Shadow Copies Challenge by David Cowen - Hacking Exposed Computer Forensics Blog


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:

Windows 7 Shadow Copies Challenge by David Cowen - Hacking Exposed Computer Forensics Blog


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.

Also Read: Daily Blog #357