Memory Analysis
When I've had the opportunity to conduct memory analysis, Volatility and bulk_extractor have been invaluable.

Back when I started in the industry, oh, lo so many years ago, 'strings' was pretty much the tool for memory "analysis".  Thanks to Volatility's strings plugin, there's so much more you can do; run 'strings' (I use the one from SysInternals) with the "-o" switch, and parse out any strings of interest.  From there, using the Volatility strings plugin lets you see where those strings of interest are located within the memory sample, providing significant context.

I've run bulk_extractor across memory samples, and been able to get pcap files that contained connections not present in Volatility's netscan plugin output.  That is not to say that one tool is "better" than the other...not at all.  Both tools do something different, and look for data in different ways, so using them in conjunction provides a more comprehensive view of the data.

If you do get a pcap file (from memory or any other data source), be sure to take a look at Lorna's ISC handler diary entry regarding packet analysis; there are some great tips available.  When conducting packet analysis, remember that besides WireShark, you might also want to take a look at the free version of NetWitness Investigator.

Carving
Like most analysts, I've needed to carve unallocated space (or other data blobs) for various items, including (but not limited to) executable images.  Carving unallocated space, or any data blob (memory dump, pagefile, etc.) for individual records (web history, EVT records, etc.) is pretty straight forward, as in many cases, these items fit within a sector.

Most analysts who've been around for a while are familiar with foremost (possible Windows .exe here) and scalpel as carving solutions.  I did some looking around recently to see if there were any updates on the topic of carving executables, and found Brian Baskin's pe_carve.py tool.  I updated my Python 2.7 installation to version 2.7.13, because the pip package manager became part of the installation package as of version 2.7.9.  Updating the installation so that I could run pe_carve.py was as simple as "pip install bitstring" and "pip install pefile".  That was it.  From there, all I had to do was run Brian's script.  The result was a folder with files that had valid PE headers, files that tools such as PEView parsed, but there were sections of the files that were clearly not part of the file.  But then, such is the nature of carving files from unallocated space.

Addendum, 1 Feb: One of the techniques I used to try to optimize analysis was to run 'strings' across the carved PE files, in hopes of locating .pdb strings or other indicators.  Unfortunately, in this case, I had nothing to go on other than file names.  I did find several references to the file names, but those strings were found in the files that were clearly part of the sectors included in the file that likely had little to do with the original file.

Also, someone on Twitter recommended FireEye's FLOSS tool, something you'd want to use in addition to 'strings'.

Hindsight
Hindsight, from Obsidian Forensics, is an awesome tool for parsing Chrome browser history.  If you haven't tried it, take a look.  I've used it quite successfully during engagements, most times to get a deeper understanding of a user's browsing activity during a particular time frame.  However, in one instance, I found the "smoking gun" in a ransomware case, where the user specifically used Chrome (was also using IE on a regular basis) to browse to a third-party email portal, download and activate a malicious document, and then infect their system with ransomware.  Doing so by-passed the corporate email portal protections intended specifically to prevent systems from being infected with...well...ransomware.  ;-)

Hindsight has been particularly helpful, in that I've used it to get a small number of items to add to a timeline (via tln.pl/.exe) that provide a great deal of context.

Shadow Copies
Volume shadow copies (VSCs) and how DFIR analysts take advantage of them is something I've always found fascinating.  Something I saw recently on Twitter was a command line that can be used to access files within Volume Shadow Copies on live systems; the included comment was, "Random observation - if you browse c$ on a PC remotely and add @TIMEZONE-Snapshot-Time, you can browse VSS snapshots of a PC."

An image included within the tweet chain/thread appeared as follows:

Source: Twitter

I can't be the only one that finds this fascinating...not so much that it can be done, but more along the lines of, "...is anyone doing this on systems within my infrastructure?"

Now, I haven't gotten this to work on my own system.  I am on a Windows 10 laptop, and can list the available shadow copies, but can't copy files using the above approach.  If anyone has had this work, could you share what you did?  I'd like to test this in a Win7 VM with Sysmon running, but I haven't been able to get it working there, either.

Addendum, 1 Feb: Tun provided a tweet to Dan's blog post that might be helpful with this technique.  Another "Dan" said on Twitter that he wasn't able to get the above technique to work.

As a side note to this topic, remember this blog post?  Pretty sneaky technique for launching malware.  What does that look like, and how do you hunt for it on your network?

Windows Event Logs
I recently ran across a fascinating MSDN article entitled, "Recreating Windows Event Log Files"; kind of makes you wonder, how can this be used by a bad guy, and more importantly, has it?

Maybe the real question is, are you instrumented to catch this happening on endpoints in your environment?  I did some testing recently, and was simply fascinated with what I saw in the data.

I had an opportunity recently to do some interesting work with Volume Shadow Copies within an image acquired from a Windows 7 system.  In this instance, I got some great information from a specific VSC, and I wanted to go back and do some testing.  Through exchanges with David Cowen, I got access to some tools and decided to share my findings.

Goal
The goal of this analysis, after completing the analysis I originally intended to do with the image, was to see if the hibernation file (hiberfil.sys) existed as a "previous version" in a VSC.

My original analysis involved creating a timeline in order to develop a detailed understanding of a malware infection associated with a targeted threat group.  The system had been infected over a year ago, and at one point late this past summer, the AV had quarantined the malware and "cleaned" the persistence mechanisms.

VSCs in FTK Imager

During that initial analysis, I opened the image in FTK Imager, and at one point, I checked the "System Volume Information" folder and found that there were a number of difference files visible.  At that point, I knew that the image contained VSCs, and by examining the modification dates for the files in FTK Imager, I had a good idea of when each had been created.  I saw that there were one or two VSCs that had been created prior to the malware being quarantined, and I figured that I could extract specific data sources from that VSC in order to augment my timeline.

I accessed the VSC of interest using the VHD method outlined here (note: this blog post contains the commands used).  I still have a copy of vhdtool.exe (seems to no longer be available, possible replacement linked here), so I used the "convert" option to change the *.001 file to a VHD format; this operation essentially adds a footer to the image file.  In order to attach the VHD via the Disk Management utility on my Win10 analysis system, I had to change the file extension from "*.001" to "*.vhd"; the file still opens just fine in FTK Imager.

Everything went fine using the vssadmin and mklink commands to access the VSC of interest, and I then added the resulting folder as an evidence item to FTK Imager (choosing 'contents of a folder').  I was able to extract the files I wanted at the time, but I did not that this method did not provide me with the necessary access to extract files such as the $MFT, etc.  At the time, for the analysis I was doing, that was not an issue.

The issue came up later when I mentioned to Jamie Levy that I had Windows 7 system with VSCs available, and that the hibernation file within the image itself was not a useful source of information about the malware, because the malware had been quarantined about a month prior the hibernation file being created.  Jamie said she was curious to see through testing if the hibernation file was covered by VSCs; that is, could I go back to the VSC of interest and retrieve/extract a previous version of hiberfil.sys?

VSS
Jimmy Weg has a good number of blog posts that address VSS; Jimmy's done a lot of great work and shared it.  In fact, I initially used information from his 13 Jul 2012 blog post entitled Mounting Shadow Volumes to mount the VSC of interest as a RAM disk on my analysis system.  At the time that I did this, I was simply interested in collecting a copy of the $MFT, which is why I was pursing it...at the time, I wasn't interested in comparing hibernation files.

After attaching the VHD and running the vssadmin command to enumerate VSCs from the newly-attached volume, I used the following command:

D:\Tools>vss x: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16

This resulted in a RAM disk being added to my analysis system.  I didn't see it in Explorer, nor in the Disk Management utility, but I could add it as a logical volume to FTK Imager.

Removing the drive was easy:

D:\Tools>vss x:

Drive X: removed

If you're interested in mounting multiple VSCs sequentially, take a look at Jimmy's blog posts and consider using Dan Mare's vss.exe.

Libvshadow
While chatting with David, he mentioned that the method used to access VSCs may have an effect on what I was seeing, or what I could access, and he suggested that I take a look at using libvshadow to access the VSCs.

Step 1: Get the tools..look for "...windows compiled version of libvshadow..."

Step 2: Install Dokan (I went with v.0.7.4, as David mentioned via chat that 0.7.something was the latest stable release)

Step 3: Run mmls to get the sector offset to the partition of interest

mmls -i raw -t dos z:\image.vhd

This gave me a sector offset of "0000002048" to the partition.

Step 4: Run vshadowinfo (not really necessary)

I'm including this step for completeness...vshadowinfo and vshadowmount require byte offsets, and 2048 x 512 = 1048576, so we will use 1048576 to designate the byte offset to the partition we're interested in:

vshadowinfo -o 1048576 z:\image.vhd

Step 5: Run vshadowmount

vshadowmount -o 1048576 -X allow_other z:\image.vhd x:

X:\ volume contents

The result of running this command is that I now had an X:\ volume on my system (i.e., X: is the mount point added via the vshadowmount command line), with the contents of the volume illustrated in the figure to the right.

Note: After hitting "enter" following the above command line, the command prompt did not return; this is normal.  Don't do anything...don't hit "ctrl-C" and do not close the command prompt.  You can minimize it, but do not forget that it's there.

Step 6: Access VSS1 using FTK Imager

I opened FTK Imager and added VSS1 as an image file.  It parsed and opened a little slower than a "normal" image would (the image itself is on a USB drive, and the VSC had to be parsed...).  However, I now have access to the VSC as a raw/dd image.  This VSC was created on 13 July 2015, and I can not only extract files that were quarantined on 13 Aug 2015, but I can also extract a previous version of the $MFT and other system files.  I can even mount the contents of the VSC by choosing "File->Image Mounting..." via FTK Imager.

If you left the command prompt up in the background, you'll see stuff scrolling by...when you're done doing what you want to do with the VSC and have closed FTK Imager, or just removed the evidence item, bring the command prompt into focus and hit "Ctrl-C"; the prompt will return, and you'll no longer have an X:\ volume on your system.

Testing
I opted to use libvshadow to access the VSC and extract hiberfil.sys.  I did that, and use Volatility to convert the file to a raw memory dump, and then ran the imageinfo command; even though the VSC that I'd "extracted" the file from had been created on 13 July 2015, the output of the imageinfo command said that the file had been created on 13 Sept 2015.  I then hashed both hiberfil.sys files and got the exact same hash.

As such, using this method it appears that the hibernation file is not "tracked" or affected by the Volume Shadow Service; that is, you don't get previous versions of the file.

Addendum: After publishing this post, David Cowen pointed me to this MSDN page that discusses files excluded from VSCs.  Checking the Registry key HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup on my analysis system, I see that the hibernation file is listed (as is the pagefile).

Addendum, 29 Dec: I had a chance recently to work with another Windows 7 image file, and found that it contained two difference files.  I then used Arsenal Image Mounter to mount the image read-only, and was able to enumerate VSCs using vssadmin.

If you perform your own testing and find something different, I'd greatly appreciate knowing the process and tools you used.

Other Take-Aways
The research, testing, and most importantly, interaction with other analysts really demonstrates that there a number of methods available for accessing historical information on Windows systems that do not require dongles, and do not require the purchase of commercial applications.  Also, you don't need to know Linux, or how to install and compile libraries.  Using native Windows tools, you can access the contents of a VSC as you would any other folder, but with a couple of freely available tools, you can get even deeper access, to the point of accessing the $MFT within the shadow volume.

During my initial analysis (prior to the testing outlined here), I extracted a couple of specific files from the VSC and created a mini-timeline in order to add context to my original timeline, and develop a clearer picture.  And it all took just a couple of minutes.

And it doesn't end there.  David Cowen's been producing a series of blog posts on automating DFIR work, and he has a blog post that walks you through accessing VSCs within an acquired image programmatically, via Python.  The final Python script that David makes available essentially accesses each VSC, searches across it for specific files, and collects information about those files.

Resources
VhdxTool - possible replacement to vhdtool (Note: I have not tried this tool)

I recently listened to Ovie and Corey on the latest CyberSpeak podcast, and wanted to combine what I'd heard them discuss with respect to the latest release of RegRipper, and provide a technique for analysis that incorporates VSCs.

Now, one of the things we may run across during our analysis, if we create a timeline, is that we may have a Registry key that was modified in some way during a particular time window of interest.  There are a number of Registry keys for which all we have available is a LastWrite time (which is analogous to a files last modification time) but we do not know what that modification entailed.

For example, some keys maintain a "most recently used" (MRU) list, and we know that whatever the most recent activity was (user accessed/viewed a file, etc.), we can be pretty sure that, in most cases, the activity we see is associated with the key's LastWrite time.  However, we may see other keys that simply contain values and subkeys, with LastWrite times that occur during our window of interest.  Examples of these keys include the Run key (in both the Software and NTUSER.DAT hives), the MUICache key, etc.  We don't know, simply by looking at the contents of the key, what change may have occurred; was a value or subkey added  or deleted? 

So, given that we have an image of a Windows 7 (or Vista) system, which may have a number of VSCs available, how can we attempt to determine what that change may have been? 

Well, the first thing you want to do is mount the image as a volume on your Windows 7 analysis system in a manner that allows you to access the VSCs within the image; perhaps the easiest way to do so is via the VHD method.  Once you have the image mounted (let's call it V:\), you'll want to determine which VSCs are available using the vssadmin command:


You'll see a bunch of stuff go by, and you'll want to look for lines that look like this:

Shadow Copy Volume: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy8

A really easy way to cut through all of that stuff is to use the following command line:


Okay, so now you should have a list of VSCs from the image; for the sake of this example, let's say that you have VSCs numbered 23 through 30.  How can we use this information to compare the values in, say, the Run key from the Software hive?  We know that the 'soft_run.pl' plugin lets us output the contents of this key, but how can we easily retrieve information from the previous versions of the Software hive within the VSCs?

Let's create a batch file to automate this for us.  A simple 'for' loop in a batch file looks like this:


If you put the above command in a batch file ('test.bat') and then run the batch file, you'll see the numbers 23 through 30 echo'd to the console.  We can use variables in our batch file by substituting the first and last numbers with '%1' and '%2', respectively:


Okay, that's easy enough.  Now, all we need to do is get RegRipper to parse this information for us.  We can do that using the latest version (2.5) of RegRipper, and specifically rip.exe.


We would save this command into a batch file (name it "vsc_run.bat") in the same directory where we have rip.exe, and then run it using the following command line:


That's it.  That's all it takes.  And the cool thing is that we can save this batch file and use it again and again, or modify it in some way for future use.  One way to modify it would be to output everything to a file, rather than just allowing everything to fly by at the console.  To do that, simply add " >> output.txt" to the end of the command within the batch file.  You can also add comments to the batch file, via normal batch file scripting techniques.

This is just another example of how we can use already-available tools and techniques to build better and more efficient analysis methodologies.  Why sit around staring at your monitor when there are easy and efficient ways to extract the data that you need for analysis?

Here's another use for this technique; at the request of a member of LE, I recently modified the currently available 'ares.pl' plugin (for parsing Registry keys for the Ares P2P application) to parse out just specific information, which includes decoding the search terms typed in by the user.  If a Windows 7 (or Vista) system was being examined, you could use this technique to see the change of of several of the values, including the user typing in search terms, over time.  The key that maintains the search terms does not include an MRU value, so you can use this technique to easily parse out exactly what you're looking for, and rather than seeing "between these two dates, the user typed in 30 search terms", you could see the progression of the terms typed in over time, across the available VSCs.

Following that same technique, I've seen instances where administrators have "taken remediation actions" and "cleaned up" prior to systems being reported as compromised and acquired.  Using the contents of the MUICache key (located in the USRCLASS.DAT hive on a Win7 system), I found that this little bundle of joy had been run on the system, but "cleaned up".  Using this technique, I could narrow down when the application had been run, and then go into my timeline to see what else was going on around that time.

Note that this technique can be used to approximate the time of program execution on systems where application Prefetch files are not available, either because they were deleted, or because the system is a server (Win2003, Win2008) and doesn't have application prefetching enabled by default.

With that kind of pin-point, surgical accuracy, this kind of sounds like Sniper Forensics to me!

I've posted before regarding how to mount and access Volume Shadow Copies (VSCs), but I thought it might be useful to revisit this topic, as there's a great deal that you can do once you've mounted a VSC.

If you received/have an image acquired from a Vista or Win7 system, you'll likely want to mount the image and access data within the available VSCs at some point.  Commercial tools such as ProDiscover provide access to the VSCs within an image (PDF here), but how can you access this source of data in a more economical fashion?

Well, there are a couple of ways to go about this, both of which require that you're using a version of Windows that supports VSCs, such as Windows 2008 or Windows 7.

VMDK Method
Starting with your image, download a copy of either raw2vmdk or LiveView and create a VMWare virtual disk (.vmdk) file for the image (I say "for" because the .vmdk file will most likely contain a reference to the image file).  Once you've done this, you can add this .vmdk file as an additional hard drive to a VMWare virtual machine (VM), and then boot that VM.  You can add a .vmdk file as an additional hard drive via VMPlayer, but if you have VMWare Workstation, you can add the .vmdk file as an independent, non-persistent disk, which means that no changes are made to the .vmdk file.

Note: You should always work on a copy of an image, not the original image file itself.

As a test, I opened VMPlayer running on a Windows 7 64-bit host system and selected a 32-bit Windows 2008 guest VM.  I added a .vmdk file from a 32-bit Windows 7 guest VM to the Win2008 VM as an additional hard drive, and booted the Win2008 VM.  Once I logged in, I was able to list the available VSCs from the Windows 7 .vmdk file (mounted as the E:\ volume) using the command vssadmin list shadows /for=e:.  From that point, it was simply a matter of using the mklink command to mount a VSC.

VHD Method
To use this method, download a copy of vhdtool, and use it to convert the image to a VHD file (i.e., vhdtool /convert).  The tool adds a VHD footer to the image file, so the extension of the image file won't change automatically, although that's not needed in order to mount the VHD file (you can change the extension manually, if you like).  You can then use the Disk Management tool to add the VHD file to a Windows 2008 or Windows 7 system as a read-only disk.

What now?
Once you've mounted the image file, you can list the available VSCs using the vssadmin command, and even create a batch file that will mount each VSC using the mklink command, run various tools on the mounted VSC (i.e., rip.pl/.exe, LogParser, etc.), and then unmount each VSC using the rmdir or rd command.

I've used this method to cycle through the VSCs within an image from a Vista system to extract information from a user's UserAssist key using the userassist_tln.pl RegRipper plugin (via rip.pl), in order to determine not only the last time that the user launched an application, but previous times, as well.

Resources
This section provides links to blog posts from other analysts to demonstrate what they've done while having access to VSCs...

- Stacey Edwards' SANS Forensic Blog post on using LogParser against VSCs
- Corey's "A Little Help with VSCs" post
- SANS Forensics Blog post (using TSK tools)

 Book Update
 I've received the counter-signed contract from Syngress for Windows Forensic Analysis 3/e, and I'm finishing up a couple of the chapters to get in for review.  This book is NOT the same as 2/e, in that I did not start with the manuscript from that edition (the way I did when I started 2/e).  Instead, 3/e is a companion edition...if you already have 2/e, you will want to have 3/e, as well.  This is because the information in 2/e is still valid, and in many instances (in particular information such as the PE file format, etc.) hasn't changed.  Also, 2/e focused primarily on XP, and those systems are still around...there hasn't been a huge corporate shift to Windows 7 yet.  As such, 3/e will shift focus to Windows 7...it will also focus more on solving problems, rather than simply depositing technical information in your lap and leaving you to figure out what to do with it.

Another new aspect of WFA 3/e is that rather than providing an accompanying DVD, the tools (as with WRF) will be provided online.  Providing the tools in this manner is just so much easier for everyone, particularly when someone purchases the ebook/Kindle version of the book, or leaves their DVD at home.  As with my previous books, I will do my best to provide functioning, tested code along with book, and provide links to other tools mentioned, described, or discussed in the book.

Accessing VSCs
I've posted before on accessing Volume Shadow Copies, but thanks to a recent blog post from Corey Harrell, I thought that it might be a good idea to revive the topic.  In his post, A Little Help with Volume Shadow Copies, Corey walks through a means for automating access to several VSCs, as well as automating the collection of information from each.  Corey does this through the use of a batch file.

Accessing VSCs in this manner is nothing new...it's been around for a while.  This post appeared on the Forensics from the sausage factory blog over a year ago.  In this post, copying of specific files via robocopy is demonstrated, showing how to use batch files to mount VSCs, copy files and then unmount the VSCs.  Corey's script takes a different approach, in that rather than copying files, he rips Registry hives using RegRipper (more accurately, rip.exe).  Corey was kind enough to provide a commented copy of one iteration of his batch file for inclusion in the materials associated with WFA 3/e (see above).

More than anything else, this is just the beginning.  Corey's had a need and used already-available information as a stepping stone to meeting his needs.  Whether you use the VHD method for mounting images, or the VMWare method (described by Rob Lee and Jimmy Weg), or some other method, the fact is that once you mount the VSC, it's simply a matter of getting the job done.  You can either copy out the Registry hives, or do as Corey's done, and run RegRipper (you'll still have the image and VSCs to access if you need the original data) on the hives.  You can copy or query for other files, as well, or use other tools (some I'll mention later).  In fact, with the right tools and a little bit of thought, you can do pretty much anything...compare files by hash, look for specific files, etc.  You may need to build some tools (or reach to someone for assistance), or download some tools, but you can piece some pretty decent automated (and self-documenting) functionality together and achieve a great deal.

Open Source Tools Book
Speaking of books, the book that Cory Altheide wrote (I was a minor co-author), Digital Forensics with Open Source Tools (aka, "DFwOST"), has been published and should be available to those who pre-ordered it soon.  Also, a really good idea is to follow @syngress on Twitter...I've been asked a couple of times if I will be providing a discount; I didn't provide the discount, Syngress did via Twitter.  I simply "RT'd" it.  You should really check this book out.  Cory's goal was to provide a means for folks with a basic understanding of digital forensics (and limited means) with an understanding of some of the open source tools available to them, and how to get them installed and configured.  And he did a great job of it!

My books have focused on the analysis of Windows systems, and have discussed/described free and open source tools that can assist an analyst.  Cory's book focuses on the open source tools, and covers several that you can use to analyze Linux, MacOSX and Windows systems.

SANS Forensic Summit
I don't know if you've seen it, but Rob's posted the agenda for this year's SANS Forensic Summit, to be held on 7 and 8 June, in Austin, TX.  Check it out...there are a number of great speakers, and several panels, which have proven to be an excellent format for conferences, as opposed to just having speaker after speaker.

It looks like Chris is gonna kick right off with his "Sniper Forensics" presentation, which has been getting him a LOT of mileage.  Richard Bejtlich is also presenting, in addition to being on a panel on the second day.  All in all, it looks like this will be another great opportunity to hear some good presentations, as well as to mingle with some of the folks in the business who are right there in the trenches.

OSDFC
I wanted to give another plug for Brian Carrier's OSDFC, the open source conference coming up on 14 June in McLean, VA.  Cory Altheide and I will both be presenting; I'm presenting in the morning, and Cory's got clean-up in the afternoon; that's Brian's tactic to get everyone to stay, by saving the best for last!  ;-)  I hope that this will be another great opportunity to mingle with others in the community...I had several interesting conversations with attendees at last year's conference.  Also, don't forget...DFwOST is out!  Bring your copy and get both of us to sign it...although you may have to wait for the cocktail reception at the end for that! 

Scalpel
There's an announcement over at the DFS Forensics blog that scalpel 2.0 is available.  There are some interesting enhancements, and the download contains pre-compiled Windows binaries and the source code.

USBStor
I received another question today that I see time and again, via email and in the lists/forums, having to do with LastWrite times on the USBStor subkeys and how they apply to the time that a USB device was last connected to the system.

In this particular case, the person who emailed me had confiscated and secured the thumb drive, and then found that the LastWrite time (apparently, the system itself was still active) for the USBStor subkey had been updated recently.

Folks, I really don't understand how this can be written and talked about so much, published in books (WFA 2/e, WRF, etc.) and STILL be so misunderstood.  Rob Lee's even made PDFs available that describe very clearly how to perform USB device analysis (XP, Vista/Win7).

If you want to know more about what may have caused the USBStor subkey LastWrite time to be updated when the device hadn't been connected, or more about why all of the USBStor subkeys have the same LastWrite time, put together a timeline.  Seriously.  I've seen both of these questions (some even include, "...I need to explain this in court..."), and a great way to answer it is to create a timeline of activity on the system and see what occurred around that time.