Archive for forensics – Page 2

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.

FoxTab: Firefox’s Hidden Camera

The FoxTab add-on to Mozilla Firefox presents some interesting artifacts in respect to forensic analysis.  According to FoxTab’s webpage, the add-on “brings innovative 3D functionality to your Firefox.”  Among the features offered by FoxTab are the “Tab Flipper” and “Recently Closed Tabs”, which allow a user to view their currently opened tabs and recently closed tabs in an animated fashion.  While these features may be appealing to some users, they are interesting from a digital forensic standpoint in that the artifacts they leave behind provide a unique insight into a user’s browsing history.  Each screenshot taken by FoxTab is either a JPG or PNG file (depending on the version of FoxTab) that is stored on the disk and in many cases readily available to a forensic examiner.  And unlike the page thumbnails stored by newer versions of Firefox, Foxtab’s thumbnails are undisturbed after clearing the browsing history.

Screenshot stored by FoxTab

Foxtabthumbs Directory
The images displayed using the Tab Flipper feature (depicting the currently opened tabs) are stored in a folder titled “thumbs” within a user’s AppDataLocalTempfoxtab directory (or Local SettingsTempfoxtab on XP).  For each tab that is opened in Firefox, a screenshot of the webpage depicted in the tab is stored for use in navigating between currently opened tabs using the Foxtab interface. While newer versions of FoxTab appear to delete the screenshots in the foxtabthumbs folder when Firefox is closed, older versions (1.4.2 and earlier) of FoxTab aren’t quite as efficient in cleaning up their mess. When testing this feature, I observed on several occasions files remaining in the foxtabthumbs directory after closing Firefox.  The remaining files could simply be given a .jpg or .png extension (they are stored without an extension) and viewed using the native Windows photo viewer.

Based on my testing thus far, the $STANDARD_INFORMATION creation date of the files within the foxtabthumbs folder correspond with the time in which the webpage depicted in the screenshot was first visited. The $STANDARD_INFORMATION last modified time appears to be a close approximation of the time the webpage was first visited, although it’s a few seconds after the creation date.  I haven’t pinned down exactly what the variance can be attributed to, but in all tests, the last modified time of each file was within 40 seconds of the creation time (although some were as close as four seconds apart).

FoxtabthumbsRCT Directory 
The images displayed using the Recently Closed Tabs feature are stored in a folder titled “thumbsRCT” within a user’s AppDataLocalTempfoxtab folder (or Local SettingsTempfoxtab on XP).  Similar to the foxtabthumbs folder, this directory stores images of tabs that were opened in Firefox at some point.  Within the FoxTab interface, a user may view a graphical depiction of the recently closed tabs.  My testing has indicated that only those tabs that were closed since Firefox was last opened are available, despite the fact that screenshots from previous browsing sessions may very well still be stored in the foxtabthumbsRCT folder.

Recently Closed Tab Feature of FoxTab

As with the foxtabthumbs folder, newer versions of FoxTab appear to remove screenshots from previous browsing sessions stored in the foxtabthumbsRCT directory more frequently.  When FoxTab is installed and a tab is closed within Firefox, the image file depicting the screenshot appears to be copied from the foxtabthumbs directory to the foxtabthumbsRCT folder and renamed using the computed MD5 hash of the URL of the webpage from which the screenshot was taken.  I’ve been unable to find a location in which the URL is stored for the purposes of FoxTab, so an examiner may only have the screenshot of the webpage and the MD5 of the URL at their disposal.

Based on my testing thus far, it appears that the $STANDARD_INFORMATION last modified date of each file in the foxtabthumbsRCT folder corresponds to the approximate time in which the webpage depicted in the screenshot was opened (this is the same last modified time of the file when stored in the foxtabthumbs directory).  The $STANDARD_INFORMATION creation date of each file appears to correspond with the time in which the Firefox tab containing the depicted webpage was closed (and hence the screenshot was added to the “thumbsRCT” folder).  If the $STANDARD_INFORMATION timestamps can be trusted in a particular case, the creation and last modified time of files in the foxtabthumbsRCT folder may provide a time frame in which the webpage depicted in the screenshot was open in the user’s browser.

Forensic Implications of FoxTab
Although the artifacts left behind by FoxTab do not seem to store the URL of the webpage depicted in each screenshot, an examiner is provided with a visual depiction of the webpage as the user would have viewed it.  This can be very telling in cases involving access to illicit websites where the relevant browsing history of the computer is no longer available.

It seems that clearing the Firefox browsing history does not have an effect on the files saved by FoxTab, as they are stored independently of the browsing history and cache files.  Additionally, uninstalling the FoxTab add-on does not seem to remove either the foxtabthumbs or foxtabthumbsRCT directory.  Further, utilizing Firefox’s InPrivate browsing mode does not seem to have an effect on the functionality of FoxTab.  It appears that unless the foxtab directories themselves are deleted, many screenshots from previous browsing sessions, both standard and InPrivate, may remain on disk.

Overall, if FoxTab is functioning correctly, it will save screenshots of currently opened tabs and tabs that were closed since Firefox was last opened.  Older versions of FoxTab (1.4.2 and earlier) remove screenshots less frequently (if at all) than newer versions, however, even the most current version (1.4.5) does not seem to remove all screenshots.  This means that a visual depiction of many webpages visited by the user may potentially be available in the foxtab directories previously described, regardless of whether a user deleted their browsing history or utilized the InPrivate browsing mode of Firefox.  While the absence of the page URL is certainly a drawback, the artifacts left behind by FoxTab may provide insight into a user’s browsing history where it would otherwise be unavailable.