JustAskWeg

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.

At this point, we have all of the shadow volumes mounted, or at least those that we deem worthy of review.  I think that many folks delve into shadow volumes looking for things that don’t appear in the present system or which might have changed over time.  We all know that hashing is one of the most efficient ways in which to find objects of interest.  We can start with a hash set from our current system (target image) or dive in and hash all of the relevant file types “throughout history” and then compare and harvest what we need.  I usually start with a hash database crested from the current system.  That way, I can quickly filter out duplicates.

However, sometimes it’s important to look over dupes, as it may be noteworthy that two, identical files existed in different locations.  For example, let’s say that, in the current system, you find \<user>\Pictures\Dupe1.jpg, which is an evidentiary file.  That path is a default location to which graphics are downloaded. If you go back in the shadow volumes and find the same file at \MyIllegalFiles\Dupe1.jpg, the evidence may be enhanced.  The point is to use hashing as means to reduce the load, but use it wisely.

X-Ways Forensics (XWF) includes very robust hashing and filtering mechanisms.  It also affords an examiner the ability approach a task like hashing most efficiently by discriminating among the files of interest.  Maybe we want to exclude all graphics in the Windows tree.  If so, there is no need to hash-compare them.  I should mention that other XWF users might recognize approaches that differ from mine. One of the key features of XWF is that it allows any number (“X”) of ways to tackle a job.

I encourage readers to check Ted Smith’s library of XWF video tutorials at http://xwaysclips.blogspot.com/.  My premise is that many viewers are XWF users and have at least a modest degree of comfort with the application.  For those who are not XWF users, perhaps you’ll be impressed enough to pick up a copy or at least be able to adapt the techniques to your environment.

I usually start by creating a hash set from the current system.  In XWF, it’s as easy as a few clicks.  Watch the video:

▶

My aim is not to provide a primer on hashing, but to demonstrate the mechanics.  I marked the hash set as notable, but could have checked the opposite.  Depending on your needs, you choose the best option.

We created our hash set in our host system, so we’ll export it for use in our SEAT workstation.  The following screenshot shows where we begin the export process.

Next, the Hash Database manager box opens.  We select the hash set and click Export.  XWF then exports the hash list in a delimited text file that can be used by other applications as well.

Once we have our hash set, we’re ready to examine the shadow volumes to see whether the files exist in them.  Again, there are X ways to approach a task.  Let’s now go back to our SEAT workstation, which contains our mounted shadow volumes.

Next, we’ll run XWF in the SEAT workstation and create a case.  XWF users should configure their general options for case and data locations.  Also, remember to make your dongle active in VMware, and copy your hash set to your VM.  First, I create a case, which I name MyImage, from the Case Data window’s File menu:

From the case name (MyImage), the context menu provides the objects that I can select and add to my case.  This is similar to all forensics tools in which we add the objects that we want to examine.  We’ll select the Add Medium option, which presents the physical and logical media that are available on the system (SEAT VM):

We can see a partial list of mounted shadow volumes in the above screenshot.  Now, we choose which shadow volumes to add to our case.  As I discussed in an earlier post, we should approach our exam intelligently.  While we can add all 19 shadow volumes to our case, we may not need to do so.  Consider your processing overhead, too.  After all, setting aside shadow volumes, how many times do you add 19 E01/dd image files to a single case?  To choose my target volumes, I find it helpful to create a text file that’s the output of the vssadmin command by directing it to a file:

Now, we have a reference of shadow volumes by date.  We also have the output of Danny Mares’ VSS:

For my demonstration, I’m going to add only a few shadow volumes to my case.  XWF easily can handle them all, as it does a great job of processing cases with hundreds of thousands of objects.  In my case, XWF took about 35 seconds to mount each shadow volume and identify its contents.  Speed, of course, is a factor of size and object numbers.  The next screenshot shows XWF adding one of the shadow volumes:

I added five shadow volumes, and my case tree looks like this:

In XWF, go back to the Tools menu, select Hash Database, and then Import Hash Set.  Then navigate to the hash set that you copied to your SEAT VM.  Once you select your hash set, you may elect to categorize it as irrelevant or notable.  I’ll leave mine as notable.

After importing, the hash set will appear in the Hash Database box that we saw before.  There are a number of things we can do at this point before searching for files.  XWF has a very powerful feature known as Refine Volume Snapshot (RVS).  I present the RVS box below, just to show its features.  Powerful as it is, it is also remarkably simple to employ.  I can invoke any of the options and direct XWF to refine every shadow volume at once.

I’m not going to refine my shadow volumes.  My goal is to identify “existing” files that match hash values from the current system.  To maximize efficiency, I’ll direct XWF to present a list of JPG files in the Directory Browser, which is analogous to Windows Explorer, but with many more options:

I should point out that, aside from the configurable fields and options available through the Directory Browser, XWF provides many more with respect to individual objects.  For example, MFT File Name date/time stamps are presented in the Details view for files.

The next video will take us to the point where XWF presents us a list of potentially notable files, based upon chosen criteria.

▶

I want to emphasize that the filtering possibilities are limitless.  For instance, if I were interested in files in only a given user’s account, I could filter the Path with the string users\jimmy. So, let’s move to complete our hash analysis:

▶

XWF traverses each volume and reports when the job is done.  We began with about 17,000 files, and the operation completed in about one minute.  Now that we finished the hash-match operation, let’s explore the results.

▶

The results of our filter revealed 505 notable files.  XWF again provides an exceptionally adaptable filtering mechanism when it comes to hashing.  Regardless of how we categorized our hash set, we can filter to present files on either side of the “fence.”  We can, of course, change the category of our hash in the database manager.

Let’s go through one more step that may make more sense with respect to shadow volumes specifically.  I want to find all graphics that are not in my hash set because I know already that my hash set contains notable files that are present in the current system.

▶

We can create additional hash sets right within our SEAT workstation and narrow down files quite a bit further. Again, I’m demonstrating techniques and not lecturing on hash analysis.  In the next post, I’ll show how we can export files securely and import them into our original case.  Oh, and be sure to get the latest VSS from Dan Mares’ site, as he’s added a number of very helpful enhancements http://www.dmares.com/pub/nt_32/vss.exe. Thanks for watching!

Updated: 7/18/2012

In almost the blink of an eye, Dan Mares added an enhancement to VSS.  Now, you can mount multiple, non-consecutive shadow volumes.  Here’s the new syntax:

The on-screen help explains the syntax and options quite well.  You start with the first shadow volume that you want to mount and then add any others, with each number separated by a comma (no space).  Ranges also are accepted, using a hyphen between numbers.  The output includes the volume summary as you can see.  Moreover, a log (MOUNTED_LOG) is produced in the forlder from which VSS is run.  The log is a text file that contains a simple string of the mounted volumes:

H:I:J:K:L:

When you want to unmount your volumes, just copy the string and paste and past it into the command, vss unmount H:I:J:K:L:  You can umount any or all volumes.

Get the latest version of VSS at http://www.dmares.com/pub/nt_32/vss.exe

We’ve built our SEAT VM and added our target image to it as a virtual disk.  The first thing that I do is verify that all of the shadow volumes are present.  My first post presented a screen shot from the image file (MyImage) and depicted the shadow volumes.  We can compare the shadow volumes from the image file with those in our VM.  The following video presents the steps we use to enumerate the shadow volumes with the native vssadmin command run from our administrative command prompt.

▶

The screen populates quite quickly, but the point is that we can identify the number of shadow volumes and their respective creation dates.  To make it easy to copy, here’s the syntax: vssadmin list shadows /for=[your target volume letter followed by a colon].  Note, too, that your beginning shadow volume number will be different from mine and does not necessarily start with the number one.  Another trick is to re-run the command and export the output to a text file, by adding a space at the end followed by >[path to your text file] [name of text file]. Creating a text file is handy for documenting your findings and for copying the shadow volume names, which we’ll do later.

Now we can mount any or all of our shadow volumes for examination.  We’re going to use VSS, which is a free, command line tool written by Dan Mares, who is a creative, long-time forensic software developer and examiner.  Dan also has developed free tools that are adjuncts to X-Ways Forensics and which help users customize certain reports.  You can pick up a copy of VSS at http://www.dmares.com/pub/nt_32/vss.exe.  Be sure to check for updates, as Dan is great about implementing suggestions.  You’ll also want to check out his other tools.  http://www.maresware.com/.  Thanks, Dan!

There are a few of ways in which we can use VSS.  We can mount one shadow volume; multiple shadow volumes that are numbered consecutively; or multiple, non-consecutive shadow volumes.  The following screenshot displays the syntax.

We already have a list of shadow volumes produced by vssadmin.  It’s now a matter of selecting the correct volume to provide to VSS.  Let’s go back to an abbreviated view of vssadmin’s output.  

The screenshot identifies one shadow volume.  It may not be terribly clear, but the shadow volume path is \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5. We’ll feed that path to VSS and mount the shadow volume.  We need only choose an unused volume letter, and we’ll pick H:

After executing the command, VSS will prompt us to hit <Return> one more time and then present what the screenshot depicts.  It includes the root directory listing.  Our shadow volume (#5) now is mounted as Volume H:  You can repeat that process and mount any, or as many, shadow volumes as remaining drive letters permit.

Hint: to repeat the process, use your up-arrow and simply replace the volume letter and shadow volume number (#), i.e., ShadowCopy[#].  There is no need to copy/paste the entire path repeatedly.

Next, we’ll mount a range of shadow volumes.  First, let’s look at the syntax, which is provided in VSS’ on-screen help.

We can start with a given shadow volume and mount every shadow volume that follows, up to our choice of the last shadow volume number.  In our case, there are 19 shadow volumes and the first is #5.  (I haven’t researched the question of why shadow volume numbers often start at a number greater than #1, but it doesn’t appear that it’s because there were X previous ones.  Windows authority Troy Larson probably knows!)  Before we go forth, I want to point out that you should study the dates of the shadow volumes in relation to your case.  Several restore points can be created on the same day, perhaps within hours of one another.  You’ll cut your exam and VM overhead if you exercise some judgment in picking the shadow volumes to mount and examine.

For demonstration purposes, let’s mount them all. I’ll start with no shadow volumes mounted and enter, vss h: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5 23 AUTO.  Note that AUTO is upper case.  The first shadow volume is #5, and the last is #23.  Watch:

▶

Actually, it was coincidental that I happened to have 19 shadow volumes and 19 open, consecutive drive letters   To unmap any or all of our shadow volumes, we proceed as in the following screenshot.  I’ll unmap them all.

Following the VSS command, you enter every volume letter, followed by a colon, which you want to unmap.  If unmapping seems to hang, just refresh your screen in Explorer with F5.

That’s it for this post.  Next time, I’ll demonstrate one or two exam approaches with X-Ways Forensics. In the meantime, if you get bored, you’re all set to examine your shadow volumes with any tools that you wish to install in your SEAT workstation.

In this step we’ll add our target system virtual disk to our SEAT VM.  We already have the target (MyImage) virtual disk that we created, and we’ll add it to our system as in the next video.

Add Virtual Disk

▶

As you saw, we chose to add the disk as an independent disk in non-persistent mode.  Any changes to the disk are discarded when we power off our SEAT VM.  Actually, as we’re going to examine shadow volumes, we’re not too concerned about routine changes that our operating system may make to volumes attached to our SEAT VM.  Nothing within the shadow volumes will be changed.  Remember, we’re not out to do a general exam; for that we can use our favorite tools on our image file.

When you add the disk, VMware may present a box that warns of a hardware compatibility issue.  If my SEAT VM was created in an earlier version, I’ll get the following warning.

If you encounter this, change your SEAT hardware compatibility as in the video.  Your hardware may differ from mine, but I bring my hardware up to my current version (Ver. 8).  Choose Alter this virtual machine as your last step.

▶

We’re ready to boot our SEAT workstation and get our target ready for a shadow volume exam.  In Windows, we can see our target system as Volumes E:, F:, and G:  Your volume letters may differ as may the number of partitions on your target.

A little exploring reveals that our target’s system partition is Volume F:  While the last screen shot is right above us, I want to point out a very handy feature of VMware, which is the Pause button. You can see it in the screen shot as the two, vertical bars right below the File menu item.  Pausing the VM freezes the action.  So, if you have a number of tasks underway and don’t want to shut down your SEAT VM, just pause it until you want to return to work.  Remember, too, that the VMware Snapshot feature is your friend.

The first thing that I do is write protect the target system disk.  Even though the disk is non-persistent, it can be written to during our session.  It’s also possible that the volume shadow service may delete one or more of the target’s shadow volumes.  To write protect our target, we’ll employ Windows Diskpart, which is a command line tool that’s part of Windows 7.  In the next video, I’ll step through the process.  We’ll begin at the point where I entered the Diskpart shell.

Diskpart

▶

To exit Diskpart, simply type the command exit. Note that the write protection survives a hot or cold reboot.  Nevertheless, you don’t have to shut down your SEAT VM, unless you want to make certain changes to its configuration in VMware.  Otherwise, you simply can use the Pause feature.  Should you want to remove write protection, go through the steps in the video, but enter the command attributes disk clear readonly as the final command.

That’s it for now.  In the next post, I’ll get down to mounting and accessing the shadow volumes.  Thanks for visiting!