Archive for forensics

ShellBags & Windows 10 Feature Updates

Windows 10 feature updates have far reaching impacts on a digital forensic investigation. Released twice a year in Windows 10, these updates essentially install a new version of the Windows operating system when they’re applied. From clearing event logs to removing common USB storage registry subkeys and more, feature updates touch many artifacts often relied upon in digital investigations.

ShellBags are a popular artifact in Windows forensics often used to identify the existence of directories on local, network, and removable storage devices. ShellBags are stored as a highly nested and hierarchal set of subkeys in the UsrClass.dat registry hive of Windows 10 systems (although they’ve been around since much earlier versions of Windows). The structure and layout of shellbags has been covered in numerous locations (such as here and here), so I won’t be detailing that.  Instead, the focus of this post is to highlight the impact of Windows 10 feature updates as it relates to the interpretation of shellbags in a forensic investigation.

One of the data points that can be leveraged during shellbag analysis is the LastWrite time of various subkeys within the BagMRU hierarchy in an attempt to identify the first and last interacted times of a directory referenced by shellbags. The methodology used to identify these times, which leverages the MRUListEx values in conjunction with subkey LastWrite times, was detailed by Dan Pullega back in 2013 and later described in an episode of David Cowen’s forensic lunch. It was also incorporated into some shellbag forensic tools. While the interaction times of a directory referenced in shellbags can be extremely valuable, they come with some caveats for later versions of Windows 10.

During the process of installing a Windows 10 feature update, testing has shown that the LastWrite time of all subkeys in the BagMRU hierarchy are updated.  This looks to be the case with versions dating back to at least 1709 and up through the latest feature update (1903 at the time of this writing).  Since the LastWrite time of these subkeys is used to illustrate an interaction time with a directory, this eliminates the examiner’s ability to use the active UsrClass.dat hive to reliably determine interaction times that occurred prior to the most recent feature update.  As an example, the below screenshot illustrates the view of a couple of shellbag entries just prior to the 1803 feature update being applied to a system.

View of ShellBags Prior to Feature Update

The next screenshot below is from the same shellbag entries on the system after the 1803 feature update was applied on May 9, 2018.  As you can see, the first and last interacted timestamps have been updated to May 9, 2018.  The interaction times here are simply pulled from the LastWrite time registry subkeys.  The LastWrite time of the subkeys was changed during the feature update.

View of ShellBags After a Feature Update

This change wouldn’t necessarily stand out if you were focusing on a single location within the system shellbags. However, when the first/last interacted times (or the LastWrite times of UsrClass.dat subkeys) are viewed in aggregate, it becomes clear that they have been updated en masse.

Interaction Times After a Feature Update

One thing to note in this example is that the directory file system timestamps (such as the Created On timestamp included in the screenshots above) that are included in the shellbag extension blocks remain unchanged across feature updates.  However, the first and last interaction methodology that relies upon the LastWrite time of registry subkeys is limited by Windows 10 feature updates.  If a directory referenced in the shellbags is interacted with after a feature update, the associated LastWrite time should be as reliable as it has been for identifying an interaction time.  Directories that have not been interacted with since the most recent feature update will not have a reliable interaction time available in the active UsrClass.dat since any interaction time previously available for the directory was updated during the feature update.

This issue is reminiscent of the problems caused when various USB-related subkey LastWrite times were updated en masse.  As with the USB-related subkeys though, understanding the limitations of the data points that are being relied upon – registry subkey LastWrite times in this example – will allow an examiner to more effectively and accurately leverage the artifact.

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.

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.

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.

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.