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.

“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.

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 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.

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):

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.