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

Archive for Event Logs

Posted by Jason Hale 
· July 17, 2018 
· No Comments

USB Device Tracking using the Partition/Diagnostic Event Log – Part 2

In my last post, I discussed using the Partition/Diagnostic Event Log in Windows 10 for USB device tracking.  Specifically, we looked at the volume boot record (VBR) available in this event log and what it means to a forensic investigation.  In this post, I’ll continue by examining the device master boot record (MBR) that is available in this event log and discuss how it can be leveraged in a forensic examination.

Event ID 1006 of the Partition/Diagnostic event log contains a field for the MBR of a device that was connected to the system. This field is used to store a hexadecimal string of the entire MBR of the device at the time the event record was created.  The MBR often contains boot code, the disk signature, and the disk partition table.  In addition to the partition table embedded in the MBR, the raw partition table bytes are included as a separate field in Event ID 1006.  It’s also worth noting that GPT disks are handled differently than MBR disks when it comes to this event log.  I’ll save the partition table and differences in GPT handling for a later discussion and will focus on the disk signature from an MBR drive in this post.

The \MountedDevices subkey has historically been used to determine the last drive letter and/or the volume GUID associated with a removable device by correlating the serial number or ParentIdPrefix stored in the \DosDevices\X: or \??\Volume{GUID} value data with its corresponding device.  This is well documented (here, here, here, and many other places).  However, the  value data available in the \MountedDevices subkey for a fixed device (such as an external hard drive) stores the disk signature of the device instead of the serial number or ParentIdPrefix.  This means that determining the previous drive letter of a fixed device using the \MountedDevices subkey requires that you know the disk signature of the fixed device.

The disk signature is a 4-byte value located at decimal offset 440 of the MBR and is easily obtained from the external device itself, but it’s difficult to come by without access to the device.  This is why obtaining the MBR from Event ID 1006 is so valuable – it provides the examiner with a means to determine a device’s disk signature without access to the device itself.

Disk Signature Embedded in Event ID 1006

By saving the value of the MBR field (pictured above) to a new file, you can use any hex editor or tool capable of parsing raw MBRs to obtain the disk signature from the MBR.  After determining the disk signature, you can then try to match the disk signature up with the value data in the \MountedDevices subkey to find a drive letter with which the disk was associated.  Another option would be to use a tool such as USB Detective that handles the extraction, parsing, and correlation of all of this information for you.  Regardless of your approach, the Partition/Diagnostic Event Log should be included in your USB device investigations.

No Comments
Categories : Event Logs, USB Device Forensics, Windows 10
Tags : , , , , , ,
Posted by Jason Hale 
· May 1, 2018 
· No Comments

USB Device Tracking using the Partition/Diagnostic Event Log – Part 1

One of the new event logs that was introduced in Windows 10 is the Microsoft-Windows-Partition/Diagnostic event log.  Matt Graeber pointed out some of the data this log contains in October of 2017 and Harlan followed up shortly thereafter, but there doesn’t appear to be a great deal of information available outside of that, particularly with regard to how this event log can be leveraged in USB device investigations.  This is the first of a multi-part series that will break down pieces of this event log that are useful as it relates to USB device tracking.

Background

Introduced in Windows 10, the Partition/Diagnostic event log creates a new event record with ID 1006 when a device is connected to or disconnected from the system.  When viewed in the Windows event viewer, the default “General” view of these records is not exactly helpful, but the “Details” view includes many useful bits of information about the connected device.  Unfortunately, this event log appears to be cleared when a major Windows update (such as the Fall Creators Update) occurs so you will likely not have records in the current log dating back prior to the most recent major update.  However, the records that are present can provide you with a substantial amount of information about a particular device including device identifiers, connection times, disconnection times, the device volume boot record (VBR), device master boot record (MBR), and more.

Device Info from Event ID 1006

Device Volume Boot Record

Event ID 1006 of the Partition/Diagnostic event log contains a field for the volume boot record of a device that was connected to the system.  This field contains a hexadecimal string of the entire VBR of the device.  This is significant in USB device investigations because the VBR contains, among many other things, the volume serial number.  Additionally, if the USB device has a FAT-formatted file system, the volume name is available from the VBR.

As you know, the volume serial number is a critical link in correlating activity reflected in LNK files and jump lists with a particular device since the device VSN is embedded in both LNK files and jump lists.  The EMDMgmt subkey of the SOFTWARE registry hive may contain the volume serial number of connected devices, however, this subkey is not populated in some instances – including when Windows detects that it’s installed on a solid state drive.  Given the proliferation of SSDs, the overall usefulness of the EMDMgmt subkey is declining.  The good news is that despite a device’s VSN becoming less available from the EMDMgmt subkey, the VSN may still be available from the Partition/Diagnostic event log.

VSN Embedded in Event ID 1006

By saving the value of the VBR0 field (pictured above) to a new file, you can use any hex editor or tool capable of parsing raw VBRs to harvest the VSN, volume name, and other useful information from the volume boot record.  Another option would be to use a USB device forensics tool that handles all of the extraction, parsing, and correlation of all of this information for you (such as USB Detective).

The information found in the Partition/Diagnostic event log is useful in and of itself, but it can become even more powerful when correlated and combined with other sources of USB-related data, such as other event logs, registry hives, and setupapi logs.  In addition to the device volume boot record, there are other pieces of useful information that can harvested from the Partition/Diagnostic event log.  I plan to cover some of the other parts in follow-up posts – stay tuned for a breakdown of those bits.

No Comments
Categories : Event Logs, USB Device Forensics, Windows 10
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 : , ,
Posted by Jason Hale 
· June 18, 2012 
· 1 Comment

Quickly Find the Date Range of EVTX Event Logs

It’s helpful to know the date range that an event log spans, as that information lets you know whether or not you should expect the events from a particular time to be included in the event log, assuming the events you’re interested in are being audited.  I’ve often used Harlan’s evtrpt.pl script (available on the WFA 2e DVD) to find, among other things, the date range that is covered by an EVT file.  This has proven to be very helpful in identifying whether a particular event log covers the time frame of interest in an examination.  However, to my knowledge, no such script exists for EVTX files.

I originally wrote a batch script for pulling the date range from EVTX files as an add-on to VSC Toolset, but I figured it would be helpful to have the ability to run it against the most current version of event logs (i.e. those not in volume shadow copies) as well.  A couple of modifications to the VSC Toolset batch script made it ready for use on its own.

In writing the batch script, I decided to harness the power of Log Parser to get the job done.  If you’re unfamiliar with Log Parser, it’s a great tool from Microsoft that allows you to interpret data files (event logs, for example) as SQL records and execute SQL queries against them to quickly pull out specific information.  The command that I used to find the oldest event record (by TimeGenerated) in an event log is “logparser -i: EVT “SELECT TOP 1 TimeGenerated FROM %1 ORDER BY TimeGenerated ASC”.  Walking through the command, I simply notify Log Parser that the input file is an event log and then specify the query that I want to execute against the file.  The “%1” indicates the value passed into the batch file (G:filesSecurity.evtx, for example). The query instructs Log Parser to return the top value existing in the TimeGenerated field when that field is listed in ascending order.  You should actually get the same results without “ORDER BY TimeGenerated ASC” since we’re only interested in the first entry of the event log.To find the newest event record by TimeGenerated, I simply had to sort the event log in reverse order by TimeGenerated.  This can be done by changing the “ASC” in the previous command to “DESC”.  I also gathered the oldest and newest records by TimeWritten to report in addition to the TimeGenerated values.  The bulk of the code and work on my part in writing the batch file came from formatting the output for a very easy-to-read display.  I won’t break down the code I used for that here, but it turned out to be a nice exercise in batch programming for me.

To use the script, download it here and copy the Log Parser executable and DLL into the same folder as the script (or vice versa).  Note that you’ll have to install Log Parser from the MSI before the executable and DLL are available in the Program Files directory.  Then execute the evtxdaterange.bat script from the command line, passing in the path to the extracted event log.  For example, issuing “evtxdaterange k:filesSecurity.evtx” should give you output similar to that in the screenshot below.

If you’re interested in learning more about Log Parser, I would recommend taking a look at the Log Parser Toolkit book (however there are also many resources available online, such as this article by Chad Tilbury).  If you’re interested in batch scripting, there are countless online references, including this one by Corey Harrell that goes over getting started with batch scripting.

VSC Toolset Update

I thought it would be helpful to quickly be able to determine the date range covered by an event log within a shadow copy, particularly if the most current version doesn’t go back far enough.  So if you’re interested in finding which shadow copy contains the event log covering the date range of interest, you can simply run the EventLogDateRange command against all shadow copies to pinpoint which event logs you’ll want to parse.  Event log parsing has also been incorporated in the latest update, via Log Parser.  You can read about the other updates and download the latest version of VSC Toolset here.

1 Comment
Categories : Event Logs, Tool Release/Update
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.