Archive for forensics

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.

Amazon Cloud Drive Forensics: Part 1

Amazon Cloud Drive is yet another way that users can upload and store information in the cloud.  Much like other cloud storage options, an Amazon Could Drive can be used for a variety of purposes, including those a bit more nefarious such as intellectual property theft.  It’s important that an examiner know what artifacts are left behind when an Amazon Cloud Drive is utilized in order to better explain what actions may have taken place surrounding a user and his or her Cloud Drive.  At the time of this writing, I’m unaware of any commercial forensic tool that interprets/parses Amazon Cloud Drive artifacts.  This post (as well as the next) sets out to highlight some of the forensic artifacts available to an examiner after a user transfers files to and from an Amazon Cloud Drive.

A user may currently interact with an Amazon Cloud Drive in one of three ways:

  1. Via the desktop application
  2. Via the online interface (i.e. using a web browser)
  3. Via the mobile application (iPhone and Android)

Depending on the method used to interact with the Cloud Drive, artifacts will be left in different locations of the associated file system.  At the time of my research, the Amazon Cloud Drive mobile app had not been released so I currently do not have details of the artifacts found on mobile devices.  This post will cover the the artifacts left as a result of the Windows desktop application being utilized for Amazon Cloud Drive file transfers.  In Part Two of this series, I will cover the artifacts available to an examiner as a result of the user accessing his or her Cloud Drive using only a web browser.

Desktop Application Usage

The Amazon Cloud Drive desktop application is a small app that can be installed on a Windows or Macintosh system that helps streamline operations carried out on an Amazon Cloud Drive.  Once installed, the user will be prompted to enter his or her credentials to access their Cloud Drive.  After the credentials have been verified and the desktop app is running, the user may drag and drop files either to a small window associated with the app (see screenshot below) or the app’s icon in the taskbar to initiate an upload.

Uploading files via ACD desktop application

One aspect of an Amazon Cloud Drive that sets it apart from some of the other cloud storage solutions is that there is no “magic folder” or directory within the file system that is set to automatically sync with the Cloud Drive.  Instead, a user must selectively choose which files and folders he or she would like to upload or download from their Cloud Drive. Because of this, an examiner is not able to focus in on a single directory as the source of uploads/downloads on the local system.  Luckily, the app has left us with a log file that is very helpful during forensic examinations.

Desktop Application Forensic Artifacts

ADriveNativeClientService.log
The ADriveNativeClientService.log file is a simple ASCII text file that holds, among other things, a log of completed file transfers made between the Cloud Drive and local machine.  This file is located in the user’s Application Data directory under “Users<user>AppDataLocalAmazonCloudDrive” on a Windows 7 system.  By analyzing the records within this file, an examiner can determine details regarding completed file transfers such as: file name, local path, cloud path, file size, and whether the transfer was an upload or download. Here’s an example of a record you might find within an ADriveNativeClientService.log file (with some potentially more relevant portions bolded for emphasis):

DEBUG [pool-1-thread-2] c.a.a.c.l.PostTransferHandler.handleRequest (PostTransferHandler.java:24) – Task has been retried FileUploadTask:taskId=C:UsersPublicPicturesSample PicturesHydrangeas.jpg,parentTaskId=upload,status=FINISHED,taskInfo={“fileCounts”:{“PAUSED”:0,”CANCELLED”:0,”RUNNING”:0,”PENDING”:0,”FINISHED”:1,”ERRORED”:0},”byteCounts”:{“PAUSED”:0,”CANCELLED”:0,”RUNNING”:0,”PENDING”:0,”FINISHED”:595284,”ERRORED”:0},”taskId”:”C:UsersPublicPicturesSample PicturesHydrangeas.jpg”,”timeRemaining”:””},children=[],localpath=C:UsersPublicPicturesSample PicturesHydrangeas.jpg,cloudpath=/Uploads,conflictResolution=RENAME,filesize=595284
Since this file is in plain text, it’s possible to simply open the file in a text editor and analyze each record line by line or perhaps search for file names of interest within the file.  However, if there was much activity with the Cloud Drive and this log expanded to hundreds or thousands of records, manual analysis would become quite cumbersome.  After manually analyzing a few records from an ADriveNativeClientService.log file, the benefit of a script to parse this file is obvious.  To carry out such automation, I’ve written a Perl script that parses the records within an ADriveNativeClientService.log file and outputs the result in CSV format for easy viewing within a spreadsheet application.

The Perl script for parsing this log file simply accepts the path to the log file (or a directory of log files specified with the “-d” flag) and outputs the result in CSV format.  By using this script, you can translate records similar to the one above into a much more readable format as in the screenshot below. The script is freely available for download here.

Sample output from acdLogParse.pl

1319b5c6-2672-49b4-b623-bf5a33fd4c40.db
This is a SQLite database stored in the same directory as ADriveNativeClientService.log that holds the queue of files to be transferred to or from a Cloud Drive. When many files are requested to be uploaded or downloaded at once, a queue will be formed and tasks (one task per file) will be assigned a status of “PENDING”.  When a transfer tasks’s status is “PENDING”, information about the transfer (local path, cloud path, file size) is written to a record within this database. Additionally, if a transfer is paused while there are still files in the queue, the transfer tasks in the queue will be assigned a status of “PAUSED” and will remain in this database. If network connectivity is lost while a large transfer is taking place, this database allows the transfer to continue when connectivity is regained by supplying the list of files waiting to be transferred to either the local machine or the Amazon Cloud Drive.  When the file transfer is complete, the associated database record is removed and information about the individual transfer is logged to ADriveNativeClientService.log.

As I have not found this database to contain any active records relating to completed file transfers (i.e. where the transfer status is “COMPLETE”), the ADriveNativeClientService.log file appears to contain more useful information regarding completed file transfers.  The information within this SQLite database may be relevant, however, to aid in demonstrating a user’s intent to transfer the files described in the database records to his or her Cloud Drive.

The Amazon Cloud Drive desktop application is easy to use and streamlines the process of file transfers to and from an Amazon Cloud Drive.  This method of transfer may be desirable for many users, but for those that do not want to install an application on their workstation, the online interface provides a means of transferring files that requires nothing more than a web browser (and network connectivity of course). The forensic artifacts left behind as a result of file transfers to and from an Amazon Cloud Drive using only a web browser will be discussed in Part Two of this series.

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