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.
Very interesting. Nice Post. Thank You.