Digital Forensics Stream
Findings, tips, and tools developed while trekking through the world of digital forensics

Archive for Tool Release/Update

Posted by Jason Hale 
· March 13, 2018 
· No Comments

Introducing USB Detective

USB device forensics can be difficult.  It is fraught with a number of caveats.  The data points that can be relied upon vary based on the specific version of Windows, the type of USB device, the type of drive on which the operating system is installed, and more.  Compounding these, Windows 10 further complicated things with the device cleanup process, which removes USB device-related records from locations that have long been relied upon by tools and examiners.  To help combat these issues and more, I developed USB Detective.

For those that want to skip the details below, USB Detective can be downloaded from usbdetective.com.  There are two versions of USB Detective: community and professional.  The community version can be freely downloaded and the professional version can be purchased from the site.  Note that you must have .NET version 4.6 or higher installed to run USB Detective!

USB Detective aims to ease the burden on the examiner by visually distinguishing attributes with inconsistent timestamps from those with multiple corroborating sources.  This is accomplished by leveraging numerous data points for the identification of USB device attributes such as the first connected and last connected time.  USB Detective organizes its findings in a way that allows for easy reporting to non-technical individuals or in-depth analysis and reporting for examiners.  The source of every value reported by USB Detective is also maintained to allow the examiner to verify and document the results.

Timestamp (In)Consistency

Associating a single data point with a specific event, such as a device connection or disconnection, can be problematic if the examiner ignores the context of the data point.  For example, the Enum\USB subkey hierarchy in the SYSTEM hive is a well-known location for, in some cases, identifying the last time a USB device was connected to a system.  However, this subkey hierarchy can be updated through events that result in the Last Write time of all subkeys in the hierarchy being updated to the same date and time.  This is a well-known behavior, but one that an examiner must be cognizant of during analysis.  In many cases, there are other data points available that accurately reflect the targeted event.

Investigating multiple data points known to be tied to the target event allows the examiner to identify corroborating timestamps and determine the overall consistency across the data points.  For example, an examiner taking this approach may determine that four out of five of the data points (subkeys, values, log entries, etc.) known to be associated with the target event are the same or within a couple of seconds of one another.  This would likely increase the examiner’s confidence in his or her findings and help to identify unreliable data points on the system under investigation.

USB Detective takes into account multiple data points that are available for some of the key USB device attributes such as first connected, last connected, volume name, and more.  After compiling all queried timestamps associated with a specific event, the gathered timestamps are compared and the consistency of the reported timestamp is displayed to the user via USB Detective’s consistency level color-coding.  This allows the examiner to quickly identify the specific attributes that have inconsistent timestamps and those that have multiple sources of corroborating data.

USB Detective Results Grid

Windows 10 Woes

Windows 10 (and some earlier versions) removes some of the most well-known USB device artifacts through its “device cleanup” procedure for devices that have not been recently used by the system.  David Cowen reported this in April last year and described a scheduled task that will remove many common USB device registry subkeys during the process, including those in USBSTOR, USB, WPDBUSENUM, and STORAGE.  In other words, USB device entries in these locations are removed during the device cleanup procedure.  I have observed that a similar action occurs during Windows upgrades, such as upgrading to the Fall Creator’s edition of Windows.  During the upgrade, USB storage device-related entries will be removed from many of the well-known locations, including the four subkeys mentioned earlier.  This is obviously problematic when it comes to USB device analysis.  If a tool or examiner is relying only on the common USB device locations, information about many devices could be missed.

Before Windows Upgrade After Windows Upgrade

In addition to the common areas such as USBSTOR, USB Detective probes many other locations – including some that are not currently covered by the device cleanup procedure performed by Windows.  In many cases, the last disconnect time of devices that have been cleared by the device cleanup procedure will still be available (in addition to device serial, description, volume name, and more).  The date/time that a device was removed via the device cleanup procedure is also identified and reported by USB Detective.  Knowing when a device was removed by the device cleanup procedure can help to provide clarity to the examiner with regard to why certain information about some devices is unavailable.  If multiple versions of the registry hives (including amcache hives) are available from volume shadow copies or other means, they can all be fed into USB Detective in order to build a more complete picture of USB device activity on a system.

USB Detective aims to simplify the USB device analysis process by identifying USB device data from dozens of locations, reporting key USB device attributes, and highlighting conflicting and corroborating data points.  There are many additional features not mentioned here that are currently available in USB Detective as well as many others on the road map for later release.  To learn more about USB Detective or to try it out, visit usbdetective.com.

No Comments
Categories : Tool Release/Update, USB Device Forensics
Tags : , , ,
Posted by Jason Hale 
· April 18, 2016 
· 6 Comments

Fun with Recycle Bin $I Files & Windows 10

A few weeks back, I found myself in need of a free tool to parse $I files from Windows Vista+ recycle bins.  For anyone needing a refresher, $I files store metadata regarding the act of sending a file to the recycle bin in Windows Vista and later.  These $I files essentially replace the functionality of the INFO2 file used in Windows XP and store information such as the name and original path of a file before it was sent to the recycle bin as well as the time the file was sent to the recycle bin.  The file format itself is trivial to manually parse in a hex editor, but I wanted to be able to demonstrate the value of the $I files to students in a class I was teaching without the need for a hex editor.  I also wanted the students to be able to easily parse these files on their own.  I was aware of a couple of free tools that parse $I files, but couldn’t find one that was exactly what I was looking for – so I decided to write one and provide it to my students. I doubt that I’m the only one to encounter this, so I’ve released this simple $I file parser in case someone else finds that they have a need for it.  The link is at the bottom of this post for those interested.

One of the intriguing things I came across in writing this tool is that $I files from Windows 10 recycle bins vary slightly from those in Vista through 8.1.  The change is not significant, but it is enough to potentially throw off some $I file parsers.  The slight change also provides us with the ability to distinguish between $I files originating from a Windows 10 system and those originating from a Vista/7/8/8.1 system.  This piece of information could be important in some instances.  For example, if you encounter an $I file in the unallocated space of a Windows 10 system, you could determine if that file was an artifact from a previous non-Windows 10 installation.  Given the ability to distinguish Windows 10 $I files from previous versions, I’ve included a version field in the output of my $I file parser so that this information is reported.The difference I’ve noted between the Windows 10 $I file structure and that from previous versions of Windows is detailed below.

$I structure prior to Win 10

Windows 10 $I structure

 

 

 

 

As you can see, the only structural change in the Windows 10 version appears to be the addition of the file name length field at offset 24.  This will typically result in $I files from Windows 10 systems being smaller than in prior versions since the $I file is only as large as it needs to be.  In prior versions, each $I file was a static 544 bytes.  While not structural, another change can be found in the header/version field.  The header field for Vista, 7, 8, and 8.1 is 0x01, while this field is 0x02 for Windows 10.  This makes it very easy to distinguish between the two versions when parsing.

For those interested, the link to download my $I file parser can be found on the download page here.

6 Comments
Categories : Tool Release/Update, Windows Artifacts
Tags : , ,
Posted by Jason Hale 
· February 14, 2014 
· No Comments

VSC Toolset Update

I’ve made various updates to VSC Toolset since its last public release in September 2012 and wanted to write a quick post about some of the updates for those interested. The most significant additions to the tool have been two new batch scripts: one for comparing the contents of a directory between two VSCs and one for extracting the USB device connection and disconnection events from one or more VSCs (based on the event log and Event IDs detailed here).  There have also been numerous user interface and general usability enhancements made to the tool.  Read on for more details, or you can skip to the VSC Toolset page to download the latest version.

CompareDirectory Batch Script

It can be helpful to see how the contents of a directory have changed over time.  For example, identifying how an employment contract has been updated, not updated, or even created and deleted over a period of time can be critical in accomplishing the goals of your examination.  VSC Toolset previously supported (and still supports) running a batch script utilizing diff.exe to compare two VSCs, but that may be overkill in many cases.  Being able to specify a particular directory for comparison is much quicker and helps to eliminate the noise found in the output of running diff.exe against the entire VSC.

The “CompareDirectory” batch script addition to VSC Toolset works by first creating a file listing of each directory to be compared using the “dir” command.  It then compares the two directory listings using diff.exe, generating output similar to the screenshot below.

CompareDirectory Batch Script Sample Output

EventLogUSB-Win7 Batch Script

In my last post, I introduced a batch script that can be executed against a Microsoft-Windows-DriverFrameworks-UserMode/Operational event log originating from a Windows 7 system to identify USB device connection and disconnection events.  In order to port over a version of the batch script compatible with VSC Toolset, I made a couple of slight modifications (primarily to the input variables).  Simply select the linked VSCs against which you want to execute the batch script and click “Run Command”; VSC Toolset takes care of the rest (with some help from Log Parser).  A separate CSV file containing the USB connection and disconnection events is created for each VSC the batch script is executed against.  Note that you’ll need the LogParser.exe and LogParser.dll file in the same directory as the VSC Toolset executable for this batch script to work.  Log Parser can be downloaded here.

The real benefit in running the EventLogUSB-Win7 batch script against multiple VSCs is that it allows you to recover USB connection and disconnection events that have since rolled off the current DriverFrameworks-UserMode/Operational event log.  This can be invaluable in cases where the length of time a certain device was connected to the system is important and the time frame of interest is prior to the earliest event in the current DriverFrameworks-UserMode/Operational event log.

Other Updates

In addition to the CompareDirectory and EventLogUSB-Win7 batch scripts, various user interface and general usability enhancements to VSC Toolset were made.  These include tips in the output of some commands (e.g. CompareDirectory) to help make the output easier to understand and a few help buttons added to the interface in some situations (depending on which command is specified in the Command drop-down box) to clarify exactly what a specific parameter is requesting.  The file system view, visible after clicking “Browse Shadow Copy”, has also been improved to allow for sorting by file name or date by clicking the appropriate column header.

To ease the burden of finding all of the supporting tools you’ll need to take full advantage of VSC Toolset, I’ve added the download links and any special requirements for each on the VSC Toolset page.  This information was previously scattered across multiple blog posts.

I’m always open to and appreciate feedback, including suggestions for improvement and bug reports.  You can download the latest version of VSC Toolset here.

**Update 02-19-14**
Corey Harrell’s auto_rip has been integrated into VSC Toolset.  Version 20140216 includes this update.
No Comments
Categories : Tool Release/Update
Tags :
Posted by Jason Hale 
· February 7, 2014 
· 4 Comments

USB Device Tracking Batch Script

Last month, I wrote about utilizing the Windows 7 Event Log in USB device tracking.  In my previous post, I mentioned automating the process using Microsoft’s Log Parser, but didn’t go into much detail regarding how to do so other than a couple of Log Parser queries.  This post introduces a batch script that can be used to quickly identify USB storage devices that have been connected to and disconnected from a Windows 7 system based on information available from the Windows Event Log, specifically the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log.

The Log Parser query described in my previous post identifies the connection and disconnection events associated with a given device identifier, but is limited in that it requires the user to have knowledge of the USB device identifier and must be executed for each device identifier of interest.  In many cases, an examiner will not have knowledge of the device identifier(s) that should be targeted or may be interested in a listing of connection and disconnection events within a particular time period (regardless of the device connected).  This batch script accepts a Microsoft-Windows-DriverFrameworks-UserMode/Operational event log as input and parses the connection and disconnection events associated with each unique USB device identifier, based on the connection and disconnection Event IDs described in my previous post (i.e. 2003 for connect, 2100 for disconnect).

The batch script performs three main steps:

  1. Scans the event log and generates a list of device identifiers
  2. Removes duplicate device identifiers from the list compiled in Step 1
  3. Queries the event log for connection and disconnection events associated with each unique device identifier

It may seem odd at first to remove duplicate device identifiers in Step 2, but this important step eliminates the duplicate entries that would otherwise be found in the script output and allows for quicker execution of the script (as each device identifier will be queried only once within the event log).

Example usage of evtx-usb.bat

The script output is in CSV format and may look something similar to the screenshot below.  The output includes the type of event (connect or disconnect), the device identifier, the time of the event, and the LifetimeID associated with the USB device connection session.

Sample output of evtx-usb batch script

As you can see, the screenshot above details three separate connection sessions for two different USB devices.  We know there are two separate devices because of the different device identifiers and we know there are three separate connection sessions by comparing the LifetimeID values.  For a refresher on the LifetimeID value, see my previous post.

The output of the batch script allows an examiner to easily pair connection and disconnection events using the LifetimeID value as well as quickly determine which devices may have been connected to the system at the same time by identifying different devices with the same LifetimeID.  Since the script output is in CSV format, filtering and sorting is easily accomplished using a spreadsheet editor.

Since the batch script relies on Microsoft Log Parser, you will need to download Log Parser here and ensure LogParser.exe and LogParser.dll are both in the same directory as the batch file.

The script is available for download here.

4 Comments
Categories : Tool Release/Update, USB Device Forensics
Tags : ,
Posted by Jason Hale 
· June 26, 2013 
· 1 Comment

Amazon Cloud Drive Forensics: Part 2

In my last post, I covered artifacts that an examiner might find when analyzing a system that has accessed an Amazon Cloud Drive using the desktop application.  While the desktop application makes it easier to transfer files to and from an Amazon Cloud Drive, it also requires the installation of an app.  Some users may opt to avoid installing another application on their system in an effort to reduce the footprint they leave behind or for a number of other reasons.  To service this category of users, Amazon allows anyone with a Cloud Drive to upload and download files using only a web browser.  This post will cover some of the artifacts that will be helpful when examining systems that have accessed an Amazon Cloud Drive using only a web browser.

Browsing History Databases
When examining the browsing history databases (e.g. index.dat) of a system, references to “https://www.amazon.com/clouddrive/api” followed by a specific query to the Cloud Drive are good indications that the system has interacted with an Amazon Cloud Drive.  The query issued will vary based on the operation carried out (upload, download, deletion, etc.).  For example, the following is a URL that an examiner may find in a system’s browsing history after a file has been uploaded to an Amazon Cloud Drive using only a web browser:

“https://www.amazon.com/clouddrive/api/?_=1345403115054&
Operation=createById&customerId=VENTYD0L9U99P&ContentType=
JSON&type=FILE&parentId=ac857013-ac6a-41da-95a3-989fa0566ed0
&name=495.txt&conflictResolution=RENAME&overwrite=false”

As you can see, there is potentially useful information available from this URL, such as the file name, customer ID, and type of operation. However, based on my research, a more complete source of information regarding file uploads and other Cloud Drive activity is available from the browser cache files stored on a system.  Nevertheless, analysis of a system’s browsing history database will at least give the examiner an idea as to whether an Amazon Cloud Drive was accessed from the system.

Browser Cache
The most significant evidence that I’ve found of a user’s interaction with a Cloud Drive when using only a web browser is found in the browser cache files.  There are specific cache files related to different operations carried out on the Cloud Drive, such as uploads and deletions.  Further, there are two types of deletions within an Amazon Cloud Drive: recycling and “permanent” deletion.  Deleting a file within the Amazon Cloud Drive web interface sends the file to the “Deleted Items” folder/area of the Cloud Drive, which functions very much like the Recycle Bin on a Windows system.  If the file is then deleted from the “Deleted Items” area, it is no longer accessible to the user within the Cloud Drive interface.  The type of deletion that takes place via web browser can be distinguished through analysis of the browser cache.

Although the relevant cache files that I’ve found have been in plain text, analysis of these individual files can get messy and time consuming.  To illustrate, the screenshot below is one particular type of cache file that is helpful when examining a system used to interact with an Amazon Cloud Drive.

Example ACD browser cache file

To ease the burden of an examiner having to manually extract this information, I’ve written a Perl script called acdCacheParse.pl that accepts the path to a directory containing cache files and parses information from each relevant cache file identified by the script.  The type of information that can be harvested from browser cache files includes: file name, object ID, amazon customer ID, file creation date, file last updated date, cloud path, file size, the file’s MD5, and the type of operation (upload, recycle, or permanent deletion).

When running acdCacheParse.pl against a directory containing browser cache files from a system and redirecting the output to a CSV file, you will be presented with a table of information associated with Amazon Cloud Drive activity.  For example, you may see something similar to the screenshot below.

Example output from acdCacheParse.pl

One of the most significant distinguishing factors between the information available from browser cache files and that which is available from the ADriveNativeClientService.log file (as seen with the Amazon Cloud Drive desktop app) is the inclusion of timestamps.  As the above screenshot indicates, browser cache files associated with Amazon Cloud Drive activity should contain a “File Creation” and “File Last Updated” time stamp.  These timestamps are stored in Unix Numeric format within the browser cache files, but can easily be decoded (and are with acdCacheParse.pl).  Based on my research, the File Creation time stored in a cache file in consistent with the “Date Added” column within the Cloud Drive web interface (and thus the time the file was uploaded to the Cloud Drive).  This timestamp, along with the other information available from browser cache files, can play a critical role in building a timeline of activity associated with an Amazon Cloud Drive and a more complete picture of how a user interacted the with Cloud Drive.

AcdCacheParse.pl is available for download here.

For more detailed coverage of Amazon Cloud Drive forensics, please see my Digital Investigation article on the topic.

1 Comment
Categories : Cloud Storage Forensics, Tool Release/Update
Tags : ,
Next Page »

Twitter

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

DISCLAIMER

The contents of this blog reflect my opinion and may not represent the views of my employer or anyone else.  Any material on this blog, especially related to technology and/or forensic methodology should not be assumed to be true in all possible scenarios.  As always, test any theories, ideas, or tools from this blog in your own environment before stating them or the results therefrom as factual.