Journey Into Incident Response

This is a quick post to pass along that I updated my auto_rip script. For those who may not know, auto_rip is a wrapper script for Harlan Carvey's RegRipper program and it executes RegRipper’s plug-ins based on categories and in a specific order. To learn more about my script please see my previous post Unleashing auto_rip. The auto_rip updates are pretty minor. I separated out the changes to a change log instead of documenting changes in the script itself, added a device category (due to a new plug-in), and I added most of the new RegRipper plug-ins Harlan created (as of 7/30/15). The download location can be found on the right of my blog or using this link to its Google drive location.


****** 08/11/2015  Update *******

At this time I removed the compiled executable from auto_rip. The compiled executable is having issues and I'm working to resolve it. However, the perl script is present and works fine. As soon as I'm able to compile the script into an exe then I'll add it back to the auto_rip archive

This post is a quick update about a few things I've been working on over the years.

auto_rip updates

auto_rip is a wrapper script for Harlan Carvey's RegRipper and the script has a few updates. For those unfamiliar with the program please refer to my post Unleashing auto_rip. The script's home has always been on the RegRipper Google Code site but Google dropped support for adding new downloads. As a result, I thought it might be helpful to make newer versions available at different places since Google Code can no longer be used. One of the download locations where the script will be available is Google Drive. The link to the download folder is located here. In addition, along the right side of this blog is a link to the script's download location.

Harlan has put in a ton of work on Regripper and in the spring he released some updates to the program. Inside the downloadable archive he made available a file named updates.txt that outlines all of the work he did. New plug-ins, combined plug-ins, retiring plug-ins, etc.. Needless to say, an outstanding tool is now even better. After Harlan released the updates others asked if I was going to update auto_rip to match. Things have been busy so it took longer than I wanted. However, I finally updated auto_rip to account for the new RegRipper updates.

The latest auto_rip download works with the RegRipper rr_20140414.zip download. All changes are noted at the top of the code. The changes include: adding plug-ins to parse, removing plug-ins no longer supported, adding the malware category (not all malware plug-ins run), and parsing the AMcache.hve registry hive with a new switch (Harlan, awesome job making this plug-in). I also renamed the executed to reflect it is 64bit and won't work on 32bit systems. Harlan, again thanks for all the work you put into maintaining the project.

tr3secure_collection_script

Another script I released is the tr3secure_collection_script. This script automates the collection of volatile and non-volatile data from systems to support incident response activities. For more information about the script refer to my posts: Dual Purpose Volatile Data Collection Script and Tr3Secure Data Collection Script Reloaded. This script was another Google Code causality and had to find a new home (Google Drive again.) The link to the download folder is located here. In addition, along the right side of this blog is a link to the script's download location.

Besides getting a new home there is only one small change in this version. I dropped support for pv.exe since it is no longer downloadable. At some point in the future there may be another update on this front.

Digital Forensic Search Update

I have been keeping track of the various blogs and websites to add to the Digital Forensic Search over the past six months. I finally added the new sites to the index. To access the custom Google you can use this link directly. To see the full list of what is included in the index refer to the post: Introducing the Digital Forensics Search.

The most common question someone asks me after they find out the work I do for a living is “what tools do you use”. This occurs regardless if the person only knows about digital forensics from TV shows or if they are a fellow practitioner. At meetings, conferences, or passing conversations the question is always one of the initial things someone asks. The question that has yet to be asked and in my opinion is the most important is “what process do you use”. The process is what determines the steps one takes to achieve an end goal; the tools only help complete those steps. Talking about tools outside the context of a process doesn’t provide an accurate picture. A carpenter can talk about his hammer all day long. It won’t mean much until he explains how he uses the hammer to accomplish something. In this post I’m unleashing auto_rip which is a wrapper script for RegRipper. Not only do I talk about what auto_rip is and how to use it but I also explain the process behind it as well.

System Examination Process

When I started this blog my main focus was to discuss the “process for investigating security incidents”. My first few posts were about the “initial examination steps I put together to investigate systems”. Ever since those early posts I’ve been honing and improving upon my process. I outlined my methodology on the jIIr methodology webpage and below are some of the steps listed for system examinations.

     * Profile the System
          - General Operating System Information
          - User Account Information
          - Software Information
          - Networking Information
          - Storage Locations Information
     * Examine the Programs Ran on the System
     * Examine the Auto-start Locations
     * Examine Host Based Logs for Activity of Interest
     * Examine Web Browsing
     * Examine User Profiles of Interest
          - User Account Configuration Information
          - User Account General Activity
          - User Account Network Activity
          - User Account File/Folder Access Activity
          - User Account Virtualization Access Activity
     * Examine Communications

Examination Steps + Artifacts = Categories

Taking a closer look at the above examination steps it’s easier to see how artifacts can be organized beneath them. Take for example the step “Examine the programs ran on the system”. Beneath this step you can organize different artifacts such as: application compatibility cache, userassist, and muicache. The same concept applies to every step and artifact.

The biggest benefit to approaching examinations in this manner is the increased efficiency and speed. You no longer find yourself jumping around looking at different items on a system. You remain focus on what you need to do and the data you need to examine to accomplish your end goal. When you start looking at all the artifacts within a category you get a more accurate picture and avoid overlooking artifacts when processing a case. The end result is your examinations are more focused, efficient, and timely. This is the concept behind why auto_rip was needed; this is the examination process auto_rip follows.

Unleash the auto_rip

There is one data source that provides a wealth of artifacts throughout the examination process. This data source is the Windows registry and it contains information for every single examination step I listed above. To parse the information from the registry my tool of choice has been RegRipper. However, I found myself doing one of two things. I was either running all the RegRipper plug-ins according to their registry hives then jumping around the reports depending on the step I was doing. The other method was running select plug-ins with rip (RegRipper command-line tool) based on the step I was performing. Both methods worked but they weren’t as fast as I wanted it to be when doing my examination process. Enter auto_rip.

Auto_rip automates the execution of the RegRipper plug-ins according to my examination process. I reviewed every RegRipper plug-in and organized them beneath the categories. I then looked over my extensive reference sheet to see what plug-ins were needed or had to be updated. Lastly, I wrote auto_rip to execute the majority of the plug-ins based on the categories. As it stands right now, auto_rip is a command-line script and its help menu is listed below:

auto_rip v2013.05.16

auto_rip [-s path] [-n path] [-u path] [-c categories]

-h, --help lists all of the available options
-s, --system path to the folder containing the SAM, Security, Software, and System hives
-n, --ntuser path to the folder containing the NTUSER.DAT hive
-u, --usrclass path to the folder containing the UsrClass.dat hive
-c, --cat specifies the plug-in categories to run. Separate multiple categories with a comma

Supported Categories:
     all                  gets information from all categories
     os                  gets General Operating System Information
     users              gets User Account Information
     software         gets Installed Software Information
     network          gets Networking Configuration Information
     storage           gets Storage Information
     execution        gets Program Execution Information
     autoruns          gets Autostart Locations Information
     log                 gets Logging Information
     web                gets Web Browsing Information
     user_config      gets User Account Configuration Information
     user_act          gets User Account General Activity
     user_network    gets User Account Network Activity
     user_file          gets User Account File/Folder Access Activity
     user_virtual      gets User Account Virtualization Access Activity
     comm              gets Communication Software Information

Usage:

Extract all information from the SAM, Security, Software, and System hives.
C:\>auto_rip -s H:\Windows\System32\config -c all

Extract file and network access information from NTUSER.DAT hive (Windows XP user profile)
C:\>auto_rip -n "H:\Documents and Settings\Corey" -c user_network,user_file

Extract file access information from NTUSER.DAT and UsrClass.dat hive (Windows 7 profile)
C:\>auto_rip -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows -c user_file

The auto_rip archive contains two files: auto_rip.pl and auto_rip.exe. Auto_rip.pl works with rip.pl while auto_rip.exe works with rip.exe. The script has been successfully tested on Windows and Linux. The auto_rip script needs to be placed in the same directory as rip.pl (or rip.exe). The output reports are placed in a sub-directory named auto_rip-reports as shown below.


Side note: sometimes files named with numbers appear inside the RegRipper folder during execution. These files can be ignored and deleted when the script finishes

Different Ways to Use Auto_rip

Automating RegRipper is not a new concept for me. I first discussed it almost two years ago in the post Obtaining Information about the Operating System. Auto_rip is just taking it to the next level and automating extracting information from the registry according to categories. I’ve been using auto_rip for some time now (initially it was a batch script). It has made my examinations faster; allowing me to produce results faster. How auto_rip is used depends on what you are trying to accomplish but here are a few ways I use it.

One of my initial steps in any examination is to profile the system. To determine basic operating system information such as version, timezone, and installation dates, installed software information, local user accounts, networking configuration, and storage locations. It’s fairly easy to extract all this information with the command below.

C:\>auto_rip -s H:\Windows\System32\config -c os,users,software,network,storage

I tend to look what programs executed on the system and what programs are set to launch automatically when confronted with a system infected with malware. Again it’s fairly easy to do with auto_rip even when a user profile is included.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c execution,autoruns

Maybe I’m not interested in the programs that executed and only want to extract the Auto-Start Extensibility Points (ASEPs) from the registry hives. It’s breeze with auto_rip.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c autoruns

Another item I’m always interested in is what a user account has been doing on a system. What did they access on the network and what files and folders were opened. Extracting this information may be time consuming with other methods but not with auto_rip.

C:\>auto_rip -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows –c user_act,user_network,user_file

To make things even easier and typically what I end up doing. Just run auto_rip with all the categories selected and review the output reports as needed. It only takes about a minute or two to finish.

C:\>auto_rip -s H:\Windows\System32\config -n H:\Users\Corey -u H:\Users\Corey\AppData\Local\Microsoft\Windows

What’s Next

Auto_rip is an evolving tool. It started out as a batch script (that I didn’t release) and was moved over to Perl to it more versatile. Development is ongoing. My future plans are to extend its functionality and provide a GUI version to go along with the command-line version.

auto_rip download location is here

The next two RegRipper plugins I wanted to highlight are: soft_run and user_run. Some may have been familiar with what these plugins did and the registry keys they checked. I’m referencing the past tense since Harlan has been busy working and he updated these plugins in the process. Not only were new run keys added to the plugins but Wow6432Node keys were added as well. The registry run keys are locations on a system which automatically start programs. Run keys are present in the Software registry hives which start programs when the operating system starts. Run keys are also present in the NTUSER.DAT hives and these execute programs when the user logs onto the system. These plugins are demonstrated against registry hives from a system infected with Symantec detection W32.SillyFDC (MD5 78c9d2949c81984414e6e1f5974905e1).

soft_run plugin

The soft_run plugin parses the run keys located in the Software hive. The following are the keys checked:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

Windows performs Win32 emulation on 64-bit operating systems to make 32-bit applications work. Part of the emulation is registry redirection. 32-bit applications are redirected to HKLM\Software\Wow6432Node when they try to access HKLM\Software. The additional Wow6432Node run keys parsed by the soft_run plugin are:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

Running the soft_run plugin against the Software hive from the infected system produced the output below. In the output you will notice an entry for C:\Users\lab\Templates\cache\SFCsrvc.pif listed beneath a Wow6432Node. This malware entry provides us with a few different clues. First the malware obtained administrative privileges since a system-wide modification was made. The second was the malware was 32-bit executed on a 64-bit system.

soft_run v.20130329
(Software) [Autostart] Get autostart key contents from Software hive

Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 17:36:00 2013 (UTC)
VMware User Process - "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

Microsoft\Windows\CurrentVersion\Run has no subkeys.

Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:34:33 2013 (UTC)
Microsoft\Windows\CurrentVersion\RunOnce has no values.
Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\RunServices not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey - C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent - C:\Windows\SysWOW64\fdisk.com

Wow6432Node\Microsoft\Windows\CurrentVersion\Run has no subkeys.

Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Tue Jul 14 04:53:25 2009 (UTC)
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no values.
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

user_run plugin

The user_run plugin parses the run keys located in the NTUSER.DAT hive. The following are the keys checked:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
Run value listed in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

Similar to the soft_run plugin, user_run also takes into account Win32 emulation on 64-bit operating systems. The additional Wow6432Node run keys parsed are:

HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Running the user_run plugin against the Software hive from the infected system produced the output below. In the output notice the entries for C:\Users\lab\Templates\cache\SFCsrvc.pif and C:\Users\lab\AppData\Local\Temp\svchost.com. The biggest clue provided by the output is the lab user account should be focused on to determine the initial infecton vector.

user_run v.20130329
(NTUSER.DAT) [Autostart] Get autostart key contents from NTUSER.DAT hive

Software\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey: C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent: C:\Users\lab\AppData\Local\Temp\svchost.com

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:35:09 2013 (UTC)

Software\Microsoft\Windows\CurrentVersion\RunOnce has no values.

Software\Microsoft\Windows\CurrentVersion\RunServices not found.

Software\Microsoft\Windows\CurrentVersion\RunServicesOnce not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Windows
LastWrite Time Thu Apr 4 18:48:46 2013 (UTC)
Run value = C:\Users\lab\AppData\Local\Temp\svchost.com
run value = C:\Users\lab\AppData\Local\Temp\svchost.com
load value = C:\Users\lab\AppData\Local\Temp\svchost.com

A new RegRipper plugin archive was released during the RegRipper Consolidation. The archive contains some new plug-ins; one of them is the MenuOrder.pl plug-in. Before discussing the plug-in I thought it would be helpful to first explain the importance of the registry key it parses. I was working a malware case when actions were taken in an attempt to remove the malware. Not only was malware deleted from the system but artifacts associated with the malware were deleted as well. Despite these actions taken, there was still evidence present in the MenuOrder registry key. This plug-in’s importance is not limited to malware cases; it’s important for any case where it’s important to know what programs or favorites were deleted from a system.

The MenuOrder registry key contains Start Menu and IE Favorites artifacts. The article Start Menu and IE Favorites Artifacts in the MenuOrder Registry Key explains in-depth how these artifacts get populated in this key. The article states:

“In most versions of Windows, a user can manually organize the order in which applications and application groups are displayed in the Start Menu. A user might, for example, drag a frequently-used application group to the top of the Start Menu and leave the remainder of the items in alphabetical order.”

“Similarly, a user can manually rearrange items in the Favorites menu”

In essence, when a user changes the display for either the Start Menu or IE Favorites these settings are stored in the registry. The information that gets stored includes the directory structure and file names for the program shortcuts in the Start Menu and favorites in IE. This means we are able to see how the Start Menu or IE favorites looked at a certain point in time even if actions were taken to delete the program shortcuts or favorites. The registry keys storing the information are:

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Favorites

This by itself makes the MenuOrder key a useful artifact to examine. However, Harlan discovered something even cooler. In his post DOSDate Time Stamps in Shell Items he mentions how the MenuOrder key contains shell items. This means there are timestamps accompanying the file and directory names stored in the registry key. It’s another source to get the creation dates for items.

I ran the plug-in against a Windows XP NTUSER.DAT hive I had laying around and here are a few snippets from its output (command was rip.pl –p menuorder –r ntuser.dat)


menuorder v.20121005

\Start Menu2
LastWrite: Wed Apr 9 13:15:39 2008 Z

\Start Menu2\Programs
LastWrite: Wed Oct 13 14:32:52 2010 Z
Microsoft Office 2003
Set Program Access and Defaults.lnk
Accessories
WinZip
Adobe Reader 9.lnk
Internet Explorer.lnk (@xpsp1res.dll,-11001)
Microsoft Access 2003.lnk
Microsoft Excel 2003.lnk
Microsoft PowerPoint 2003.lnk
Microsoft Word 2003.lnk

\Start Menu2\Programs\Accessories
LastWrite: Wed Jun 9 19:26:37 2010 Z
Accessibility (@shell32.dll,-21760)
Communications (@shell32.dll,-21768)
Entertainment (@shell32.dll,-21772)
System Tools
Address Book.lnk (@shell32.dll,-22017)
Calculator.lnk (@shell32.dll,-22019)
Command Prompt.lnk (@shell32.dll,-22022)
Notepad.lnk (@shell32.dll,-22051)
Paint.lnk (@shell32.dll,-22054)
Program Compatibility Wizard.lnk (@C:\WINDOWS\system32\compatUI.dll,-115)
Remote Desktop Connection.lnk
Synchronize.lnk (@shell32.dll,-22062)
Tour Windows XP.lnk (@C:\WINDOWS\system32\tourstart.exe,-1)
Windows Explorer.lnk (@shell32.dll,-22067)
WordPad.lnk (@shell32.dll,-22069)

.......

\Favorites\Links
LastWrite: Mon Oct 4 18:31:22 2010 Z
Customize Links.url
Free Hotmail.url
Windows.url
Windows Marketplace.url
Windows Media.url

\Favorites\Microsoft Websites
LastWrite: Tue Sep 7 15:34:21 2010 Z
IE Add-on site.url
IE site on Microsoft.com.url
Marketplace.url
Microsoft At Home.url
Microsoft At Work.url
Welcome to IE7.url

On my to-do list for quite some time has been tracking down the various locations in the registry that malware and attackers use to remain persistent on a system. Typically, one of my initial examination steps when confronted with malware is to review the various auto-run locations. The way I approached this step works but it isn’t as efficient as I want it to be. I do most of my registry analysis with RegRipper and it even extracts numerous auto-run locations. However, when I’m looking at persistence mechanisms I go with the Microsoft Autoruns utility since it is the best tool out there for extracting auto-runs from a system. This is where the inefficiently comes into play. I’m using two tools to extract registry auto-run locations. With the Autoruns utility, I’m forced to do additional work since it only works against mounted drives (or images). What I want is to solely use RegRipper to perform this task since it can extract this information in seconds. To do so, I had to track down the various persistence mechanisms to see what, if anything had to be added to RegRipper. This post shows what and how I went about this.

What Locations are Checked By Autoruns

To track down the registry persistence mechanisms I first needed an authoritative resource on the various locations. The Autoruns utility is the best tool for reviewing auto-runs locations since it is constantly updated. The locations checked by the tool would be one of the most authoritative resources on the subject. I reached out to the Win4n6 group to see if anyone knew of a site that outlines the different places the tool checks. Both Troy Larson and Adam said the tool itself can be used to determine this. I picked my platform – Windows 7 64-bit – to get the best coverage of artifacts and followed their guidance. I ran Autoruns (v11.4) against my system. After it completed I selected Options from the menu then Filter Options on the drop down. In the Autoruns Filter Options window: checked the box next to Include empty locations and deselected Hide Windows entries followed by clicking OK.


The end result is the most comprehensive listing of auto-start locations. More extensive then I have ever seen in books, presentations, trainings, and other tools. You may have read Harlan’s post Wow6432Node: Registry Redirection or my post Houston We’ve Had a Problem – Wow64 about the impact Wow64 has on where to look for persistence mechanisms. Well, there are numerous auto-run locations redirected due to Wow64 and this is a topic that is discussed very little in Digital Forensics and Incident Response. To see what I mean run Autoruns against a 64-bit system and you will see all the different Wow64 entries that are being missed by our processes, tools, and literature.

What To Do with these Autorun Locations

Obtaining a comprehensive list of the various persistence mechanisms was only the first step. My idea wasn’t to see every auto-run location added to RegRipper. This would require a lot of work; work done by myself or someone else volunteering their time. The more effective approach is to determine which persistence mechanisms are actually being used by malware. This is what Elizabeth Schweinsberg did when she scraped an antivirus website to determine the most common persistence mechanisms. Similar concept but different approach. I started with the most comprehensive listing of auto-run locations (Autoruns output from my 64-bit system). Then I researched every registry key and values to determine which ones were actually used by malware. I leveraged the Malware Analysis Search since it indexes numerous sites related to malware such as antivirus sites and online sandboxes. Basically, I went through hundreds of auto-start locations and selected the locations based on how many hits I got. Only a few hits wasn’t worth the effort to create test data and write a RegRipper plug-in. It took numerous hits (at least two pages worth) to make it worth the while; for it to be considered as Harlan says low hanging fruit.

Side note: I didn’t apply the search hit count to the Wow64 folder redirection locations. I barely got any hits for these locations. This shows how antivirus sites and online sandboxes are not accounting for all the artifacts created by malware.

Extending RegRipper

For the past few months I have been focused on RegRipper; specifically on the plug-ins. As a result, I know fairly well what every plug-in in the RegRipper archive does, what it checks, and which ones fall into the auto-runs category. I proceeded to review every RegRipper auto-run plug-in against my list of persistence mechanisms. What I found out was pretty cool? Excluding the Wow64 folder redirection keys/values, RegRipper already accounted for the majority of the persistence mechanisms I noted. However, I did identify what new plug-ins was needed and which ones needed to be updated.

My last step in journey to track down persistence mechanisms was to reach out to Harlan for a few reasons. First if I have any questions about Windows forensics especially with the registry then he is at the top of my list. The other reason is because he is the author of RegRipper and I felt letting him know what I was trying to do was the right thing to do. His reaction caught me by surprise after I sent him all my documentation and notes. He was willing to start writing the new plug-ins and updating the existing ones. Really cool and to me this showed his passion for our field. His willingness to help me out with about 20 different plug-ins. As he mentioned, RegRipper is being updated. Actually, he is doing all the updating and I’m just trying to give him any support I can.

In Closing

Out of my desire to work more effectively I set out to track down the various persistence mechanisms to see what needed to be added to RegRipper. I found out about the most comprehensive reference available for auto-run locations with the help of others. I saw firsthand the impact Wow64 has on our processes and tools as well as antivirus websites and online sandboxes since it’s not accounted for. I learned about the various persistence mechanisms, what they do, and more importantly if malware is actually using them. I created a nice reference for myself so I’m more aware about what to take into consideration on future casework. As a result of Harlan’s effort, RegRipper is getting updated and there will be a better tool available. The end result, going forward I will work faster and smarter since I took the time to track down the most common persistence mechanisms. Another item knocked off my to-do list and now my focus moves to the next issue...


*** Update ***

The locations identified in this post has been documented on the ASEPs RegRipper Wiki page. The page outlines all the auto-run plug-ins and the locations they check.

*** Update ***

This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry Redirection goes into detail about what Wow64 is, it’s impact on registry analysis, and contains links to great resources. After giving some thought to this issue I’m in full agreement with Harlan when he said “this is huge”. Computing is moving on from 32-bit to 64-bit platforms. I am already witnessing the transition since the majority of the systems I see running Windows 7 are 64-bit. We are entering a 64-bit world and as this transition occurs systems will run both 64-bit and 32-bit applications. This is where Wow64 comes into play and I wanted to follow up Harlan’s post with a few more examples about why we should be aware about this issue. I’m not only expanding on what Wow64 is but I’m highlighting issues with our processes and tools to demonstrate why this is an important issue.

What Is Wow64

In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.

Windows Internals states the following about file system redirection:

“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."

The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:

“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."

The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said

“In the worst case this can lead to an entirely wrong interpretation of a case/situation”

Wow64 Impact on Our Processes and Tools

Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.

Wow64 Impact on Live Analysis

Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.

There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:

Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run

If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.

Wow64 Impact on Malware Analysis

Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.

Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.

SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).

Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.

Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.

Wow64 Impact on Post-mortem Analysis

Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.

One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.

Summary

Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”

In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.

In this Linkz edition I’m mentioning write-ups discussing tools. A range of items are covered from the registry to malware to jump lists to timelines to processes.

RegRipper Updates

Harlan has been pretty busy updating RegRipper. First RegRipper version 2.5 was released then there were some changes to where Regripper is hosted along with some nice new plugins. Check out Harlan’s posts for all the information. I wanted to touch on a few of the updates though. The updates to Regripper included the ability to run directly against volume shadow copies and parse big data. The significance to parsing big data is apparent in his new plugin that parses the shim cache which is an awesome artifact (link up next). Another excellent addition to RegRipper is the shellbags plugin since it parses Windows 7 shell bags. Harlan’s latest post Shellbags Analysis highlights the forensic significance to shell bags and why one may want to look at the information they contain. I think these are awesome updates; now one tool can be used to parse registry data when it used to take three separate tools. Not to be left out the community has been submitting some plugins as well. To only mention a few Hal Pomeranz provided some plugins to extract Putty and WinSCP information and Elizabeth Schweinsberg added plugins to parse different Run keys. The latest RR plugin download has the plugins submitted by the community. Seriously, if you use RegRipper and haven’t checked out any of these updates then what are you waiting for?

Shim Cache

Mandiant’s post Leveraging the Application Compatibility Cache in Forensic Investigations explained the forensic significance of the Windows Application Compatibility Database. Furthermore, Mandiant released the Shim Cache Parser script to parse the appcompatcache registry key in the System hive. The post, script, and information Mandiant released speaks for itself. Plain and simple, it rocks. So far the shim cache has been valuable for me on fraud and malware cases. Case in point, at times when working malware cases programs execute on a system but the usual program execution artifacts (such as prefetch files) doesn’t show it. I see this pretty frequently with downloaders which are programs whose sole purpose is to download and execute additional malware. The usual program execution artifacts may not show the program running but the shim cache was a gold mine. Not only did it reflect the downloaders executing but the information provided more context to the activity I saw in my timelines. What’s even cooler than the shim cache? Well there are now two different programs that can extract the information from the registry.

Searching Virus Total

Continuing on with the malware topic, Didier Stevens released a virustotal-search program. The program will search for VirusTotal reports using a file’s hash (MD5, SHA1, SHA256) and produces a csv file showing the results. One cool thing about the program is it only performs hash searches against Virustotal so a file never gets uploaded. I see numerous uses for this program since it accepts a file containing a list of hashes as input. One way I’m going to start using virustotal-search is for malware detection. One area I tend to look at for malware and exploits are temporary folders in user profiles. It wouldn’t take too much to search those folders looking for any files with an executable, Java archive, or PDF file signatures. Then for each file found perform a search on the file’s hash to determine if VirusTotal detects it as malicious. Best of all, this entire process could be automated and run in the background as you perform your examination.

Malware Strings

Rounding out my linkz about malware related tools comes from the Hexacorn blog. Adam released Hexdrive version 0.3. In Adam’s own words the concept behind Hexdrive is to “extract a subset of all strings from a given file/sample in order to reduce time needed for finding ‘juicy’ stuff – meaning: any string that can be associated with a) malware b) any other category”. Using Hexdrive makes reviewing strings so much easier. You can think of it as applying a filter across the strings to initially see only the relevant ones typically associated with malware. Then afterwards all of the strings can be viewed using something like Bintext or Strings. It’s a nice data reduction technique and is now my first go to tool when looking at strings in a suspected malicious file.

Log2timeline Updates

Log2timeline has been updated a few times since I last spoke about it on the blog. The latest release is version 0.64. There have been quite a few updates ranging from small bug fixes to new input modules to changing the output of some modules. To see all the updates check out the changelog.

Most of the time when I see people reference log2timeline they are creating timelines using either the default module lists (such as winxp) or log2timeline-sift. Everyone does things differently and there is nothing wrong with these approaches. Personally, both approaches doesn’t exactly meet my needs. The majority of the systems I encounter have numerous user profiles stored on them which mean these profiles contain files with timestamps log2timeline extracts. Running a default module list (such as winxp) or log2timeline-sift against the all the user profiles is an issue for me. Why should I include timeline data for all user accounts instead of the one or two user profiles of interest? Why include the internet history for 10 accounts when I only care about one user? Not only does it take additional time for timeline creation but it results in a lot more data then what I need thus slowing down my analysis. I take a different approach; an approach that better meets my needs for all types of cases.

I narrow my focus down to specific user accounts. I either confirm who the person of interest is which tells me what user profiles to examine. Or I check the user profile timestamps to determine which ones to focus on. What exactly does this have to do with log2timeline? The answer lies in the –e switch since it can exclude files or folders. The –e switch can be used to exclude all user profiles I don’t care about. There’s 10 user profiles and I only care about 2 profiles but I only want to run one log2timeline command. No problem if you use the –e switch. To illustrate let’s say I’m looking at the Internet Explorer history on a Windows 7 system with five user profiles: corey, sam, mike, sally b, and alice. I only need to see the browser history for the corey user account but I don’t want to run multiple log2timeline commands. This is where the –e switch comes into play as shown below:

log2timeline.pl -z local -f iehistory -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The exclusion switch eliminates anything containing the text used in the switch. I could have used sam instead of Users\\sam but then I might miss some important files such as anything containing the text “sam”. Using a file path limits the amount of data that is skipped but will still eliminate any file or folder that falls within those user profiles (actually anything falling under the C root directory containing the text Users\username). Notice the use of the double back slashes (\\) and the quotes; for the command to work properly this is needed. What’s the command’s end result? The Internet history from every profile stored in the Users folder except for the sam, mike, sally b, alice, and all user profiles is parsed. I know most people don’t run multiple log2timeline commands when generating timelines since they only pick one of the default modules list. Taking the same scenario where I’m only interested in the corey user account on a Windows 7 box check out the command below. This will parse every Windows 7 artifact except for the excluded user profiles (note the command will impact the filesystem metadata for those accounts if the MFT is parsed as well).

log2timeline.pl -z local -f win7 -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The end result is a timeline focused only on the user accounts of interest. Personally, I don't use the default module lists in log2timeline but I wanted to show different ways to use the -e switch.

Time and Date Website

Daylight savings time does not occur on the same day each year. One day I was looking around the Internet for a website showing the exact dates when previous daylight savings time changes occurred. I came across the timeanddate.com website. The site has some cool things. There’s a converter to change the date and time from one timezone to another. There’s a timezone map showing where the various timezones are located. A portion of the site even explains what Daylight Savings Time is. The icing on the cake is the world clock where you can select any timezone to get additional information including the historical dates of when Daylight Savings Time occurred. Here is the historical information for the Eastern Timezone for the time period from the year 2000 to 2009. This will be a useful site when you need to make sure that your timestamps are properly taken into consideration Daylight Savings Time.

Jump Lists

The day has finally arrived; over the past few months I’ve been seeing more Windows 7 systems than Windows XP. This means the artifacts available in the Windows 7 operating system are playing a greater role in my cases. One of those artifacts is jump lists and Woanware released a new version of Jumplister which parses them. This new version has the ability to parse out the DestList data and performs a lookup on the AppID.

Process, Process, Process

Despite all the awesome tools people release they won’t be much use if there isn’t a process in place to use them. I could buy the best saws and hammers but they would be worthless to me building a house since I don’t know the process one uses to build a house. I see digital forensics tools in the same light and in hindsight maybe I should have put these links first. Lance is back blogging over at ForensicKB and he posted a draft to the Forensic Process Lifecycle. The lifecycle covers the entire digital forensic process from the Preparation steps to triage to imaging to analysis to report writing. I think this one is a gem and it’s great to see others outlining a digital forensic process to follow. If you live under a rock then this next link may be a surprise but a few months back SANS released their Digital Forensics and Incident Response poster. The poster has two sides; one outlines various Windows artifacts while the other outlines the SANs process to find malware. The artifact side is great and makes a good reference hanging on the wall. However, I really liked seeing and reading about the SANs malware detection process since I’ve never had the opportunity to attend their courses or read their training materials. I highly recommend for anyone to get a copy of the poster (paper and/or electronic versions). I’ve been slacking updating my methodology page but over the weekend I updated a few things. The most obvious is adding links to my relevant blog posts. The other change and maybe less obvious is I moved around some examination steps so they are more efficient for malware cases. The steps reflect the fastest process I’ve found yet to not only find malware on a system but to determine how malware got there. Just an FYI, the methodology is not only limited to malware cases since I use the same process for fraud and acceptable use policy violations.

CyberSpeak Podcast About Volume Shadow Copies

I recently had the opportunity to talk with Ovie about Volume Shadow Copies (VSCs) on his CyberSpeak podcast. It was a great experience to meet Ovie and see what it’s like behind the scenes. (I’ve never been on a podcast before and I found out quickly how tough it is to explain something technical without visuals). The CyberSpeak episode May 7 Volume Shadow Copies is online and in it we talk about examining VSCs. In the interview I mentioned a few different things about VSCs and I wanted to elaborate on a few of them. Specifically, I wanted to discuss running the Regripper plugins to identify volumes with VSCs, using the Sift to access VSCs, comparing a user profile across VSCs, and narrowing down the VSC comparison reports with Grep.

Determining Volumes with VSCs and What Files Are Excluded from VSCs

One of my initial steps on an examination is to profile a system so I can get a better idea about what I’m facing. I information I look at includes: basic operating system info, user accounts, installed software, networking information, and data storage locations. I do this by running Regripper in a batch script to generate a custom report containing the information I want. I blogged about this previously in the post Obtaining Information about the Operating System and I even released my Regripper batch script (general-info.bat). I made some changes to the batch script; specifically I added the VSCs plugins spp_clients.pl and filesnottosnapshot.pl. The spp_clients.pl plugin obtains the volumes monitored by the Volume Shadow Copy service and this is an indication about what volumes may have VSCs available. The filesnottosnapshot.pl plugin gets a list of files/folders that are not included in the VSCs (snapshots). The information the VSCs plugins provide is extremely valuable to know early in an examination since it impacts how I may do things.

While I’m talking about RegRipper, Harlan released RegRipper version 2.5 his post RegRipper: Update, Road Map and further explained how to use the new RegRipper to extract info from VSCs in the excellent post Approximating Program Execution via VSC Analysis with RegRipper. RegRipper is an awesome tool and is one of the few tools I use on every single case. The new update lets RR run directly against VSCs making it even better. That’s like putting bacon on top of bacon.

Using the Sift to Access VSCs

There are different ways to access VSCs stored within an image. Two potential ways are using Encase with the PDE module or the VHD method. Sometime ago Gerald Parsons contacted me about another way to access VSCs; he refers to it as the iSCSI Initiator Method. The method uses a combination of Windows 7 iSCSI Initiator and the Sift workstation. I encouraged Gerald to do a write-up about the method but he was unable to due to time constraints. However, he said I could share the approach and his work with others. In this section of my post I’m only a ghost writer for Gerald Parsons and I’m only conveying the detailed information he provided me including his screenshots. I only made one minor tweak which is to provide additional information about how to access a raw image besides the e01 format.

To use the iSCSI Initiator Method requires a virtual machine running an iSCSI service (I used the Sift workstation inside VMware) and the host operating system running Windows 7. The method involves the following steps:

Sift Workstation Steps

1. Provide access to image in raw format
2. Enable the SIFT iSCSI service
3. Edit the iSCSI configuration file
4. Restart the iscsitarget service

Windows 7 Host Steps

5. Search for iSCSI to locate the iSCSI Initiator program
6. Launch the iSCSI Initiator
7. Enter the Sift IP Address and connect to image
8. Examine VSCs

Sift Workstation Steps

1. Provide access to image in raw format

A raw image needs to be available within the Sift workstation. If the forensic image is already in the raw format and is not split then nothing else needs to be done. However, if the image is a split raw image or is in the e01 format then one of the next commands needs to be used so a single raw image is available.

Split raw image:

sudo affuse path-to-image mount_point

E01 Format use:

sudo mount_ewf.py path-to-image mount_point

2. Enable the SIFT iSCSI service

By default, in Sift 2.1 the iSCSI is turned off so it needs to be turned on. The false value in the /etc/default/iscsitarget configuration file needs to be change to true. The commands below uses the Gedit text editor to accomplish this.

sudo gedit /etc/default/iscsitarget

(Change “false” to “true”)


3. Edit the iSCSI configuration file

The iSCSI configuration file needs to be edited so it points to your raw image. Edit the /etc/ietd.conf configuration file by performing the following (the first command opens the config file in the text editor Gedit):

sudo gedit /etc/ietd.conf

Comment out the following line by adding the # symbol in front of it:

Target iqn.2001-04.com.example:storage.disk2.sys1.xyz

Add the following two lines (the date can be whatever you want (2011-04) but make sure the image path points to your raw image):

Target iqn.2011-04.sift:storage.disk
Lun 0 Path=/media/path-to-raw-image,Type=fileio,IOMode=ro


4. Restart the iscsitarget service

Restart the iSCSI service with the following command:

sudo service iscsitarget restart

Windows 7 Host Steps

5. Search for iSCSI to locate the iSCSI Initiator program

Search for the Windows 7 built-in iSCSI Initiator program


6. Launch the iSCSI Initiator

Run the iSCSI Initiator program

7. Enter the Sift IP Address and connect to image

The Sift workstation will need a valid IP address and the Windows 7 host must be able to connect to the Sift using it. Enter the Sift’s IP address then select the Quick Connect.


A status window should appear showing a successful connection.


8. Examine VSCs

Windows automatically mounts the forensic image’s volumes to the host after a successful iSCSI connection to the Sift. In my testing it took about 30 seconds for the volumes to appear once the connection was established. The picture below shows Gerald’s host system with two volumes from the forensic image mounted.


If there are any VSCs on the mounted volumes then they can be examined with your method of choice (cough cough Ripping VSCs). Gerald provided additional information about how he leverages Dave Hull’s Plotting photo location data with Bing and Cheeky4n6Monkey Diving in to Perl with GeoTags and GoogleMaps to extract metadata from all the VSCs images to create maps. He extracts the metadata by running the programs from the Sift against the VSCs.

Another cool thing about the iSCSI Initiator Method (besides being another free solution to access VSCs) is the ability to access the Sift iSCSI service from multiple computers. In my test I connected a second system on my network to the Sift iSCSI service while my Windows 7 host system was connected to it. I was able to browse the image’s volumes and access the VSCs at the same time from my host and the other system on the network. Really cool…. When finished examining the volumes and VSCs then you can disconnect the iSCSI connection (in my testing it took about a minute to completely disconnect).

Comparing User Profile Across VSCs

I won’t repeat everything I said in the CyberSpeak podcast about my process to examine VSCs and how I focus on the user profile of interest. Focusing on the user profile of interest within VSCs is very powerful because it can quickly identify interesting files and highlight a user’s activity about what files/folders they accessed. Comparing a user profile or any folder across VSCs is pretty simple to do with my vsc-parser script and I wanted to explain how to do this.

The vsc-parser is written to compare the differences between entire VSCs. In some instances this may be needed. However, if I’m interested in what specific users were doing on a computer then the better option is to only compare the user profiles across VSCs since it’s faster and provides me with everything I need to know. You can do this by making two edits to the batch script that does the comparison. Locate the batch file named file-info-vsc.bat inside the vsc-parser folder as shown below.


Open the file with a text editor and find the function named :files-diff. The function executes diff.exe to identify the differences between VSCs. There are two lines (lines 122 and 129) that need to be modified so the file path reflects the user profile. As can be seen in the picture below the script is written to use the root of the mounted image (%mount-point%:\) and VSCs (c:\vsc%%f and c:\vsc!f!).


These paths need to be changed so they reflect the user profile location. For example, let's say we are interested in the user profile named harrell. Both lines just need to be changed to point to the harrell user profile. The screenshot below now shows the updated script.


When the script executes diff.exe there the comparison reports are placed into the Output folder. The picture below shows the reports for comparing the harrell user profile across 25 VSCs.

Reducing the VSCs Comparison Reports

When comparing a folder such as a user profile across VSCs there will be numerous differences that are not relevant to your case. One example could be the activity associated with Internet browsing. The picture below illustrates this by showing the report comparing VSC 12 to VSC11.


The report showing the differences between VSC12 and VSC11 had 720 lines. Looking at the report you can see there are a lot of lines that are not important. A quick way to remove them is to use grep.exe with the –v switch to only display non-matching lines. I wanted to remove the lines in my report involving the Internet activity. The folders I wanted to get rid of were: Temporary Internet Files, Cookies, Internet Explorer, and History.IE5. I also wanted to get rid of the activity involving the AppData\LocalLow\ CryptnetUrlCache folder. The command below shows how I stacked my grep commands to remove these lines and I saved the output into a text file named reduced_files-diff_vsc12-2-vsc11.txt .

grep.exe -v "Temporary Internet Files" files-diff_vsc12-2-vsc11.txt | grep.exe -v Cookies | grep.exe -v "Internet Explorer" | grep.exe -v History.IE5 | grep.exe -v CryptnetUrlCache > reduced_files-diff_vsc12-2-vsc11.txt

I reduced the report from 720 lines to 35. It’s good practice to look at the report again to make sure no obvious lines were missed before running the same command against the other VSC comparison reports. Staking grep commands to reduce the amount of data to look at makes it easier to spot items of potential interest such as documents or Windows link files. It’s pretty easy to see that the harrell user account was accessing a Word document template, an image named staples, and a document named Invoice-#233-Staples-Office-Supplies in the reduced_files-diff_vsc12-2-vsc11.txt report shown below.


I compare user profiles across VSCs because it’s a quick way to identify data of interest inside VSCs. Regardless, if the data is images, documents, user activity artifacts, email files, or anything else that may stored inside a user profile or that a user account accessed.