Archive for Tool Release/Update

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.

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.

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.

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.