Thursday, February 27, 2014

Understanding a Hyper-V server when doing Forensics

Hyper-V is Microsoft's visualization server software. It is very similar to VMware in that it provides a host allowing you to run several 'guest' machines on a single piece of hardware.

When doing incident response/forensics, you may run into one of these servers and need to understand a bit more about how to deal with them.

Hyper-V comes in two flavors (modes):
  • A stand-alone Hyper-V server based on Windows 2012 core OS (current version)
  • A role-based Hyper-V add-in available in Windows server 2008 & 2012
The stand-alone version of Hyper-V server is a complete operating system based on Windows 2012 core (current version) and can can be downloaded for FREE here.

For the Hyper-V Server version (Windows Core), once downloaded, it is installed just like a typical version of Windows, except there is no GUI interface for the user. There will be an initial GUI screen displayed for the login, but once logged in as the administrator, you will typically be presented with two command prompt windows:



From this initial console, you can change some of the options the server uses, such as the hostname, networking options and if remote management is enabled, but there is not much more to see from this console. The Hyper-V server is likely administered via the Hyper-V management console from another Windows based computer. The management console allows you to connect to the Hyper-V server and manage all the virtual guest devices. This management console is part of the administrative tools set that needs to be installed separately on workstations (Windows 7 & 8), but is included on server-class operating systems (2008 & 2012):


However the Hyper-V serer is typically managed, you as a forensic analyst are going to be concerned with two major things:

  • The path to where the virtual disk(s) that are configured for each virtual machine are stored
  • If the virtual machine has any 'snapshots'
If the administrator is cooperative and not part of the investigation, you will want to leverage their knowledge about where the virtual hosts are stored and getting access to the server. The following information could be used to help verify what they are giving you is what you are expecting. If the administrator is not available, then you will have to do the steps below on your own.
 
The first item is needed so you know what virtual disk files are associated with a specific virtual machine. The easiest way to determine this is to identify the virtual machine of interest in the hyper-V manager and look at its settings by right-clicking and viewing the properties of the hard drive configured for the virtual machine.




The important items to note is the path to where the disk file is stored AND if it notes that there is a snapshot in use. Pressing the "INSPECT" button gives a little more details and view to the path where the disk file for this virtual machine is stored.


A "differencing virtual hard drive" is the terminology used for a disk that uses snapshot technology, allowing the administrator to save the state of the guest host at specific time and then revert back to that snapshot at some point. The reason this is important to know is the same reason when dealing VMware virtual machines. The snapshot data is actually stored in a different file and if you do not get a copy of that file, you will end up with a copy of the base system, but not with the data that represent the current state.

Hyper-V uses *.VHD as the extension for virtual hard drives. Snapshots are stored in a similar file with the extension of *.AVHD. Many Forensic tools can natively read VHD files, which is good. The complication comes in when there are snapshots (differencing files), which most forensic tools DO NOT know how to deal with them.

The Hyper-V manager has a feature named "merge" which allows you to merge snapshots into the base disk file.This feature can be used to apply the various snapshots to the base disk file (VHD) and you will end up with a VHD with all the snapshots applied. If there are multiple snapshots, its important to apply them sequentially one at a time.

In the example below, you can see multiple snapshots exist in the lower "Snapshots" windows. To apply the merge feature, you select the "Edit Disk" option on the right side:



Once you select the "Edit Disk" option a wizard will open up asking you for which VHD or AVHD file to merge. You want to select the OLDEST AVHD file and merge that into the VHD file. Then repeat with the next oldest AVHD file, etc, etc, until you have merged all the AVHD files. This can be done as a non-destructive process, meaning when you merge you can tell the wizard to merge a AVHD file and create a NEW VHD file from that process. My recommendation would be to create a new VHD, leaving the original one intact and allowing you to have various versions with the snapshots applied along the way, which can be loaded into your favorite forensic tools.






Note: You will only get the "MERGE" option if you selected a AVHD file in the step above. If you select the VHD from the file picker dialog, you will not be presented with a MERGE option.

Once you have merged all the snapshots into a VHD, you can then load that VHD into forensic tool  that supports parsing VHD files and it will be displayed with the snapshots applied, in a state as it was when you encountered the machine (assuming the file system used by the virtual host is supported by the forensic tool).

Alternatively, if you are comfortable with PowerShell, you can either locally or remotely use Hyper-V cmdlets to get all the information you need and even do the merging without using the Hyper-V manager GUI.

You may also want to grab copies of the other files present in the same root directory as the VHD & AVHD files, specifically the *.BIN files, which is a saved version of the virtual host's memory. The XML file contains information about the virtual host's configuration, including how much memory it was allocated, etc.

Thursday, February 20, 2014

EnCase EnScript to parse out the VS_VERSION_INFO resource in executables

I wrote this EnScript awhile ago in order to quickly parse out the string resources inside an executable to assist in determining if it was suspicious.

Most executables contain a resource known as "VS_VERSION_INFO". This structure contains metadata about the specific executable, including the manufacturer name, original filename, version info and other useful information. This EnScript specifically targets this resource instead of just running a "strings" search across the entire executable, which often leads to lots of noise.

The information in this resource is what is displayed if/when you right-click on an executable in Windows and  choose the "details" tab.


Looking at this information, while not authoritative or definitive, can commonly give you some initial hints about the legitimacy of a file and/or if it has been renamed from when it was originally compiled. 

The EnScript is designed to be able to check any executable(s) and then run the EnScript. It will then print out the information from this resource to the console tab (and make a bookmark). For example, if I came across an executable in EnCase with the name of "cmd.exe", I can run the EnScript, which will output the following:
 




This technique goes way back when I wrote the EnScript to extract the embedded icons in an executable. Since EnCase does not show you a graphical representation of the embedded icon, which could be quickly identified or recognized regardless of the filename, I wrote that EnScript in 2005.

This EnScript follows the same line of thinking since there is no easy/quick way to see the VS_VERSION_INFO resource in a file from within EnCase. The raw VS_VERSION_INFO data looks like this in EnCase when looking at the specific data inside a file:


To use, simply check the executable you want to parse and run the EnScript. Each file will get its own bookmark and the formatted text will be displayed in the console tab.

Download EnCase v6 EnScript here

Saturday, February 1, 2014

EnScript to create EnCase v7 hash set from text file


It has been nearly seven years since I posted an EnScript to import hash values from a text file and create a EnCase v6 hash set. That EnScript still remains popular to this day.

The EnScript linked below was written to basically do the same thing for EnCase v7. The hash values in EnCase v7 are stored completely different than in v6 and while I had to create the hash sets in EnCase v6 from scratch, EnCase v7 includes an EnScript API to create the new hash set using the new format.

It still surprises me to this day though that EnCase does not have a feature to import a list of hash values into a hash set from a simple text file. So many examiners and incident responders obtain plain text files that contain hash values from 3rd party tools and commonly don't have the original file, especially with malware databases like Virus Total and Virus Share that provide hash values but you don't necessarily have the file itself to obtain the hash value on your own.

This EnScript was written to read a text file with up to three fields per line:

MD5SHA1logicalsize

The order of the fields are not important, they can be in any order. The delimiter can be a space, tab or comma and there should not be a header row with field labels. The EnScript was designed to read/parse an ANSI text file.

Here is a sample input file from http://virusshare.com/hashes/VirusShare_00001.md5:

 
The lines above with the '#' are automatically ignored.
 

Here is another example file that contains three fields (MD5, SHA1, logical size)  that were extracted from here: http://a4lg.com/downloads/vxshare/ using awk:
 

 
 
The above example is a text file that contains the MD5SHA1 that was extracted using AWK.
 
Once you have a text file with the hash values you want to use (second hash value and logical size are optional), run the EnScript and select the text file:
 

 
Specify a name (it will be the name of the directory created that contains all the hash indexes as well as the name displayed inside the EnCase Hash library Manager), Category and a Hash Set Tag.
 
Once run, a directory containing the EnCase v7 hash set indexes will be created in the default export folder for your case:
 
 
You can now add the hash set using the EnCase Manage Hash Library option:
 
 
 

 
 
 

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles