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

Archive for usb tracking

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 
· 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 
· January 3, 2014 
· 28 Comments

The Windows 7 Event Log and USB Device Tracking

Recently, there have been a few blog posts discussing evidence found on a system when USB devices are connected and removed (Yogesh Khatri’s blog series and Nicole Ibrahim’s blog).  I’ve been meaning to release this post for a while and Yogesh and Nicole’s posts have motivated me to do so.  Much of the conversation regarding USB device activity on a Windows system often surrounds the registry, but the Windows 7 Event Log can provide a wealth of information in addition to the registry. Utilizing the Event Log during USB device investigations has been mentioned in various other locations, including chapter 5 of Harlan Carvey’s Windows Forensics Analysis 3/E (and recently in Yogesh Khatri’s blog).  This post discusses both USB device connection and disconnection artifacts found in the Windows 7 Event Log, specifically the Microsoft-Windows-DriverFrameworks-UserMode/Operational log, and explores an interesting value that can be used to pair a device’s connection event with its associated disconnection event.

Connection Event IDs

When a USB removable storage device is connected to a Windows 7 system, a number of event records should be generated in the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log.  The records include those with Event ID 2003, 2004, 2005, 2010, 2100, 2105, and more.  Some of the generated event records contain identifying information about the USB device that was connected.  For example, when viewing an event record with Event ID 2003 using the Windows Event Viewer, the event information below is displayed.

Connection Event Record

A portion of the text formatting in the screenshot above above should look familiar to most, as it contains some of the same information about a USB device that can be found in the SYSTEM hive. Importantly, the device serial number (“000ECC0100087054”) is stored in last portion of the event record’s strings section. Combined with the record’s TimeGenerated field, an examiner can derive the date and time that a USB device was connected to the machine.

Disconnection Event IDs

When a USB thumb drive is disconnected from a Windows 7 system, a few event records should be generated in the same event log as the connection events.  Records with Event ID 2100, 2102, and potentially more may be generated when a USB device is disconnected.  Variables such as whether there is another USB removable storage device still connected to the system at the time a USB device is disconnected can dictate which event records are generated and which are not.  Some records, however, appear to be more consistent.  For example, it appears that an event record with Event ID 2100 and the text “Received a Pnp or Power operation (27, 23) for device <deviceInfo>” is consistently generated when a USB removable storage device is disconnected from a system.  In addition, the same event record should contain the device’s serial number/Windows unique identifier that can be mapped to a device.  An example of some of the information available from a disconnection event record with Event ID 2100 can be seen in the screenshot below.

Disconnection Event Record

LifetimeID Value

The LifetimeID value associated with a USB device’s connection session is an interesting piece of information.  This GUID value is assigned to a UMDF (User Mode Driver Framework) host when a USB device is connected and should remain the same throughout the connection “lifetime” of the device.  In other words, an examiner should be able to match the LifetimeID written to a device’s connection event records with the LifetimeID written to the device’s disconnection event records in order to tie a particular disconnection event with its associated connection event.

This is simple enough when a single USB device is used, however, when multiple USB devices are used at once, they appear to all use the same UMDF host and are all assigned the same LifetimeID.  This means that a LifetimeID value cannot be tied to a single USB device, but it appears that it can be used to correlate device connections and disconnections on a per-session basis.

LifetimeID from Disconnection Event Record

Utilizing the LifetimeID associated with a device connection session can help in developing a timeline that, among other things, indicates the length of time a particular device was connected to the system.  In addition, the LifetimeID is useful in pairing a device’s connection event with its corresponding disconnection event.  Since there may not be the same number of connection and disconnection events (e.g. a device is removed after the system has been powered down so no disconnection events are generated), the LifetimeID can help to make sense of various connections and disconnections and correctly pair the two together for a particular device.

In addition to being used to determine the length of a USB device’s connection session via the Windows Event Log, the LifetimeID value may play an interesting and useful role in determining the time a USB device was last disconnected from the system, based on the LastWrite time of a registry subkey.  I’ll forego this discussion for now since this post is focused on event records, but will revisit this topic later.

Automation

Automating the process of identifying connection and disconnection event records can really allow the power of utilizing the Windows Event Log in USB analysis to shine. While entirely possible, it would be a tedious process to manually analyze the Windows Event Log for USB connection/disconnection events.  Microsoft Log Parser is a great tool for processing the Event Log in this manner.  Given that event records associated with a device’s connection and disconnection will contain identifying information as well as a timestamp, it’s just a matter of isolating the event records associated with connection and disconnection and parsing portions of the strings section of the record.  For example, the Log Parser query below returns all event records with Event ID 2003 (connect) or 2100 (disconnect) as long as the device serial number/Windows unique identifier (“1372995DDDCB6185180CDB&0” in this case) is contained in the Strings portion of the event record and, in the case of a disconnection event, the text “27|23” is also in the Strings portion.

logparser -i EVT -o datagrid “SELECT EventID, TimeGenerated FROM Microsoft-Windows-DriverFrameworks-UserMode-Operational.evtx WHERE (EventID=2003 AND STRINGS Like ‘%1372995DDDCB6185180CDB&0%’) OR (EventID=2100 AND STRINGS LIKE ‘%1372995DDDCB6185180CDB&0%27|23%’)”

Output of Log Parser query above

If you want to clean up the output and add a bit more information, you can use the Log Parser query below (replacing “1372995DDDCB6185180CDB&0” with the USB serial number/Windows unique identifier you’re interested in).

logparser -i EVT -o datagrid “SELECT CASE EventID WHEN 2003 THEN ‘Connect’ WHEN 2100 THEN ‘Disconnect’ END As Event, TimeGenerated as Time, ‘1372995DDDCB6185180CDB&0′ as DeviceIdentifier, EXTRACT_TOKEN(Strings,0,’|’) as LifetimeID FROM Microsoft-Windows-DriverFrameworks-UserMode-Operational.evtx WHERE (EventID=2003 AND STRINGS Like ‘%1372995DDDCB6185180CDB&0%’) OR (EventID=2100 AND STRINGS LIKE ‘%1372995DDDCB6185180CDB&0%27|23%’)”

Output of Log Parser query above

As you can see, Log Parser dramatically reduces the leg work involved in analyzing event records for USB connection and disconnection events.  Moreover, Log Parser queries can easily be incorporated into a batch script that allows the examiner to input the device serial number he or she is interested in to quickly identify the connection and disconnection events associated with the device.  The LifetimeID value can then be used match associated connection and disconnection events.

As with other event logs, event records in the Microsoft-Windows-DriverFrameworks-UserMode/Operational event log eventually roll over, leaving the examiner with a limit on how far back in time he or she can go.  However, utilizing VSCs can allow an examiner to squeeze a bit more out of this approach and ultimately build a very telling history of USB device connection and disconnection events.

28 Comments
Categories : Event Logs, USB Device Forensics
Tags : , ,

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.