VSC Archives | Forensic Blogs

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 ImagerDuring 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 contentsThe 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)