Now That We Found It, What Do We Do With It?

So, we found some evidence in the shadow volumes.  The next step is gathering the relevant files so that we can present the evidence to our audience.  There is more than one way to do this, and I’ll present one.

Before venturing into the subject matter of this post, I want to bring my audience up to date on enhancements to VSS.  Dan Mares has been making our jobs easier!  Dan also has updated the Help file, so be sure to pick up both at http://www.dmares.com/pub/nt_32/vss.exe and http://www.dmares.com/maresware/tz.htm#VSS, respectively.  Let’s start by mounting every shadow volume.

VSS now produces  log file named MOUNTED_LOG.TXT in the path from which we run VSS.  This handy file records the shadow volumes that we mounted in a simple string: H:I:J:K:L:, etc.  Now, to unmount them all at once, we need only enter the following command vss MOUNTED_LOG.TXT

You still can mount and unmount individual shadow volumes in the other ways that I described in an earlier post.  In addition, users can rename respective copies of VSS to VSSMount and VSSUnmount, which obviates the need to type the mount or unmount commands in the respective mounting and unmounting scenarios.

Okay, back to the main topic.  We’ll begin by opening out X-Ways Forensics (XWF) case in our SEAT workstation.  The next screen shot shows our XWF case, together with the VSS command box and our text file list of mounted shadow volumes.  We’ll presume that every file in the window is relevant to our case, and we want to document and export those files.

Every volume in our case is a shadow volume: H:, K:, N:, Q:, U:  Every shadow volume is tied to a ShadowCopy number.  If we follow the arrows, we can see that H: is ShadowCopy6, which was created on 11/19/2011.  Here’s another representation, and we can see how every file is tied to a specific shadow volume.

We can export our files, but let’s use a neat feature of XWF to document and report the shadow volume evidence.  We’re going to create XWF Report Tables to segregate our relevant files and document their origins.  We start with all relevant files from ShadowCopy6 (Volume H:) highlighted.  As usual, there are X way to do this, but here’s one.  I’ll explain more after you watch the video.

We’ll repeat the Report Table creation process by highlighting and creating a Report Table for each group (by volume) of relevant files.  When we’re done, it looks like this:

We have five Report Tables that include the respective, relevant files.  Once we create Report Tables, we can filter our case to present or exclude any combination of such objects. As one alternative, I could have included every file in a single Report Table and then added Comments to each file to designate the source shadow volume.  The Comments option also is available from the context menu and can be applied to selected files.

We’ve seen how to find noteworthy files among any number of shadow volumes.  Now, we need to save them in a presentable format.  My approach is to extract the files from the shadow volumes and incorporate them into my primary case, which is based on the current system.  Although you can simply copy the files out of the shadow volumes to your host system, I suggest a better way to preserve the evidence and its integrity.  I use   X-Ways Forensics Evidence File Containers.

A Container, as its name suggests, is a place to store objects.  However, it is a lot more, in that we can include the original object metadata, such as date stamps, paths, deletion status, etc.  Files can be hashed to ensure authenticity after they leave the shadow volumes. A Container is built on the X-Ways File  System (XWFS), which also is readable by most forensics tools.  I’ll explain a little more after we view the following video, which shows how I create and add files to a Container.

We filtered Volume H: for Report Table files.  We can leave all Report Tables highlighted because we selected only Volume H: in the case tree.  We’ll create one Container for each shadow volume and name them accordingly.  When I created the Container, I kept the default settings, with the exception of exporting hash values.  Then, I elected to retain full path information for each shadow volume.  As you saw, there are lots of options as well as space to add comments and the like.  As I create each container, I filter each shadow volume by the Report Tables, and that presents each volume’s files of interest.  I select each volume’s files, right-click, and add the files to the appropriate Container.

That’s it for now.  Next, I’ll post my method for incorporating our Containers (shadow volume evidence) into our main case.

 

5 comments

  1. fpi says:

    Hi Jimmy,
    nice posts, thank you very much!

    Just a question: why not using the VSS feature included in X-Ways?
    As you know, X-Ways is able to point out VSS files and moreover you can filter for files which are different in VSS, avoiding those files which didn’t change.

    • jimmyweg says:

      Thanks, Francesco. Maybe I’m confused, but do you mean Refine Volume Snapshot? I refined my snapshot to identify files in each shadow volume that met the hash cireteria. Then, I filtered on notable files. I know that there are many files in the “relevant” group that are identical. My goal was to show the process of working in a VM. In a real case, I would go further and either remove duplicates or limit their inclusion.

      • fpi says:

        Sorry Jimmy, I was not clear. I sometimes use the same process to access VSC that you described perfectly in your posts, especially when I want to use other tools than the great XWF (for example when I check its results).

        But XWF has the native capability to parse VSCs and to extract files from them. Quoting from the manual:
        “existing or previously existing VSC host files are examined [...] such as files that cannot be found in the current $MFT anymore or previous versions of files whose contents have changed. XWF makes an extra effort to prevent duplicates from being added to the volume snapshot. [...] Files found in volume shadow copies are specially marked with “SC” in the Attr. column, or “SC, prev. version” if they are previous versions of files that were known to the volume snapshot already before the thorough file system data structure search, so that it is easy to filter them in or out. Remember you can sort by ID to see the files they are a previous version of next to them.”

        So I wanted to ask if there is a reason to prefer one approach over the other. Thank you very much!

        • jimmyweg says:

          Thanks for the clarification, Francesco. It’s a very useful feature, and I may post about it later. First, I think that I get a better “picture’ in the method that I described. The Particularly Thorough Search (PTS) feature of XWF is incredible, and recovers files (or at least metadata) to the extent that it is possible in NTFS. In my approach, you see the files in their native environment and can export/report them with their tie to a specific shadow volume. While XWF may identify the same files, in the XWF report the path is listed as the original. I want to identify the files being tied to specific shadow volumes. The shadow volumes also are “difference” files, so a given shadow volume may contain only a portion of a file. When you rebuild a shadow volume, the service takes that into account and can rebuild a given file. XWF traverses the difference files, but, AFAIK, isn’t reassembling an actual file where a given shadow volume contains a portion only.

          I did a test, and the results are based on hash values. In a case, I used my method to identify 57 unique videos that “existed” only in shadow volumes. Each video also was unique among the shadow volumes, themselves. I then ran a PTS on the volume and elected not to avoid SC previous versions. XWF recovered 81 files with either of the SC attributes. Of the 81 files, 13 matched files that were in my original group of 57. Of the 13 files, 6 were unique. So, I recovered 51 files more than the XWF PTS. I think the outcome is a function of the re-assembly of difference files that I mentioned above. If that’s correct, you’re only going to recover so much by traversing raw shadow volumes.

          Addendum: After Francesco asked another good question, I went back and tested the recovery by name. XWF did recover (at least the metadata) for 56 of my 57 files, by name. Only a few were viewable. This could, however, be related to the specifics of this case.

          • fpi says:

            Your detailed comment it’s really interesting!

            Let me say I share what you wrote “First, I think that I get a better ‘picture’ in the method that I described.”

            I’m surprised of the your tests result, I think it’s worth doing another post (sorry if I dare ;)).

            Jimmy, thank you very much for your explanation and your close examination!

Leave a Reply

Your email address will not be published. Required fields are marked *

Blue Captcha Image
Refresh

*