Not a Cloud in the Sky

Hello fellow examiners! This is my last blog post for my Capstone and will detail my conclusion for my findings.

Conclusion

After conducting this forensic analysis of the IDrive Windows application, the investigator found that the data is stored in two default locations, which are: “C:\Program Files (x86)\IDriveWindows\” and “C:\Users\username\AppData\Local\IDrive\”.  Within this second location most of the important forensic artifacts are stored, including logs, which provide details about every action performed within IDrive and every file that was ever backed up, restored, deleted, cleaned up, and moved from the IDrive trash to the original location within the IDrive backup set.

Also, when a file is deleted within the IDrive backup set, it is moved to the IDrive trash, which is recorded in a log.  These files still remain on the computer however.  Once the files are deleted from the IDrive trash, the files still remain on the computer, but they don’t remain in the IDrive backup set until they are backed up again.  This data is again, recorded in a log.  Once a backed up file is deleted from the computer itself, the user can run Archive Cleanup, which removes it completely from the IDrive backup, which is logged as well.

It was also found that an investigator can find the computer name and the IDrive username from the artifacts generated by IDrive.  The investigator was able to prove that it is possible to recover the username and password of the IDrive account by acquiring and analyzing a RAM dump of the computer.

An investigator will additionally be able to tell if another computer was backed up to IDrive using the same IDrive account, as the computer name for each connected computer is used as the parent folder in the backup set to store the data.  An investigator will be able to tell if another drive was connected to a computer, if the contents of this drive were backed up to IDrive, as there is a drive letter associated with the drive and shown in the IDrive backup set.

Furthermore, if a user shares files from IDrive via Twitter or Facebook, the investigator will have the ability to find the files that were shared.  He or she will be able to have access to the URL that is generated from IDrive, which is used to share the files.

Moreover, the investigator found 4 files are generated on the computer during install of IDrive, which connect to the Internet to send data and reach out to the IDrive website, as well as IDrive’s host company.  These files used various protocols and ports to connect out to the Internet.

Once IDrive is unistalled, an investigator will still have access to all of the important artifacts, as the AppData Local IDrive folder is not deleted after uninstall.  This will allow an investigator to conduct a thorough investigation even after a user attempts to remove evidence of the IDrive Windows application. Everything that a user does within IDrive, can be found out by an investigator because everything is documented by logs and session files.

The Cloud Continues to Dissipate

This will be my second to last blog post for my Capstone and will cover Internet activity after sharing files from IDrive via Twitter and Facebook.  After sharing files within IDrive, I conducted analysis of the acdquisition image of the VM to collect Internet activity, using Internet Evidence Finder v6.  I found that IEF was able to capture Internet activity for Facebook and Twitter.

Facebook Artifacts

During analysis of the Internet activity, the investigator was able to find evidence that Facebook was linked to IDrive.  There was a URL entry that shows there was a signed request from IDrive to connect to Facebook.  When an investigator enters this URL into a web browser, a Facebook login page is brought up which says, “Login to use your Facebook Account with IDrive”.

IDrive Facebook Request

Facebook IDrive Login Request

Also found within the results from IEF is another URL string that shows the URL of the files that were shared to Facebook.  When this URL is entered into a web browser, a Facebook login webpage can be seen that asks the user to login first to view the files.  Once logged into Facebook, a webpage allowing one to re-share the files to Facebook timeline is shown.

Facebook IDrive Shared Files URL

Shared Files to Facebook Timeline

If an investigator copies the shared URL found in the link shown above (https://www.idrive.com/idrive/sh/sh?k=g2j8k7b3s7), he/she will be brought to the IDrive home page where he/she can download the shared files directly from the IDrive website.  On this homepage, an investigator can see the first name of the Facebook user who shared the files.

Shared Files on IDrive Home

IEF was also able to pull the user’s profile picture from Facebook after sharing IDrive files.  This could help an investigator possibly see who the person was that shared the files and where they should start looking during an investigation into a suspect.

Facebook User Profile Picture

IEF also produces similar results for Twitter.  Within the “Social Media URLs” results, an investigator can find a URL entry containing the message that was Tweeted.  This URL contained the actual tweet that was sent, “check this out”, followed by the URL for the shared files from IDrive.  When searching the full URL in a web browser, the investigator is brought to the Twitter website with a Tweet box containing the message text and the URL for the shared files from IDrive.

Twitter IDrive URL

Twitter IDrive Retweet

Again, the results from IEF do not provide the username of the account that shared the files from IDrive via Twitter, however; when an investigator retrieves the shared URL for IDrive, he or she will be brought to the IDrive homepage and view the first name of the user/account that shared the files, as seen above.

Also, when analyzing the Internet Activity with IEF v6, an investigator can additionally find the user ID and password for IDrive, in plaintext, within the “Cloud Service URLs” results.  It appears that when a person shares files from IDrive, the IDrive website receives a token from the IDrive desktop application, which contains this data.

IDrive User ID and Password Token

The Cloud Begins to Dissipate

In this blog post I will be talking about the local database file and the Session files.

Local Database File

After a backup has completed within IDrive, a local SQLite 3 database file is create.  This file is located: C:\Users\Username\AppData\Local\IDrive\IBCOMMON\idriveusername\LDBNEW\.

The file naming convention for the database file is: “idriveusername.idbs”.  This file contains details about every file that was backed up to IDrive, from the very first backup, including files that were deleted or cleaned up from the IDrive backup set.  Within this database are two important tables called “ibfile” and “ibfolder”.

ibfile

This table contains a table with a list of all of the files backed up to IDrive.  This file provides the name of the file, the last modified date of the file, the file size, the directory identification number (DIRID), the file identification number (FILEID), and the name of the backup set that the file was located in.

ibfile

ibfolder

This table contains a list of the folders that were backed up to IDrive.  This table details the directory identification number (DIRID), the file path of the folders, and the last modified date of the folder.  When cross-referencing the two database tables, an investigator will be able to tell what files were stored in which folders by comparing the DIRID numbers for the folders and the files.  For instance, the highlighted file in the image above has a DIRID of 36, which is the same DIRID as the "Documents" folder, meaning that the "HTC Fuze Report.pdf" file was stored in this directory.

ibfolder

Session Folder

The “Session” folder is a very important folder for an investigator as it contains specific details about all actions performed in IDrive.  The location of this folder is: C:\Users\Username\AppData\Local\IDrive\IBCOMMON\Session\.  There are 7 folders that can be potentially added to the "Session" folder, which are created after different actions performed in IDrive.

Session Folder

The “Backup”, “Delete”, “Archive Cleanup”, “PutBack”, and “Restore” folders all contain similar files.  The naming convention for the files in each folder is the same, “MM-DD-YYYY HH-MM-SS”.  A file is created for every time that a backup, delete, restore, putback (moving files from IDrive trash to their original location) or archive cleanup operation is performed.  Within the contents of each file found in these action folders, an investigation can expect to find the username of the user that performed the action, the backup set name, the start date/time and/or end date/time of the operation, the type of operation, the date/time of the specific files being backed up or deleted, and the file names and file paths of the entire backed up, restored, or deleted content.

Example of a Session File

Hidden Behind the Cumulonimbus Part 2A

This is part two of "Hidden Behind the Cumulonimbus Part 2" blog post.  This blog continues to cover the IDTEMP folder.

Delete and Archive Cleanup Files

After deleting files within IDrive there is one additional file created in the IDTEMP folder.  This files is called “Delete.txt”.  This file contains the filename and file path of the file(s)/folder(s) deleted from the IDrive backup set.  Moreover, after a user performs an archive cleanup, the files; “Delete.txt”, “Delete_Args.txt”, and “OutputFile_Delete.txt” all change to reflect the files that were cleaned up.  These files will contain details about the files that were deleted during an archive cleanup.  Since these files contain the same data as the data added after deleting a file from the IDrive backup set, an investigator will not be able to tell if a file was deleted during an archive cleanup or a deletion within the IDrive backup set.

There is also an additional file added to the IDTEMP folder, called “DFTDelete.txt”, which is added after a user deletes a file from the IDrive trash.  This file is similar to the “Delete.txt”, as it contains the filename and file path of the file that was deleted from the trash.

 

Delete.txt

Moved to Original (MTO) Files

After file(s)/folder(s) have been deleted and sent to the IDrive trash, a user has the ability to restore these files to their original location within the IDrive backup set.  After a user moves the files, there is an additional file added to the IDTEMP folder called “MTOFile.txt”.  Within this file an investigator will contain a list of the file(s)/folder(s) found moved from the IDrive trash, which includes the filename and path of the file(s)/folder(s). 

MTOFile.txt

Hidden Behind the Cumulonimbus Part 2

Hello all!  I have been very busy over the past few weeks trying to finish analyzing my data and finalizing my capstone paper.  This blog post is a continuation of the previous and will consist of 2 parts because there is a lot of data that I would like to present to my fellow investigators.

In my last post I talked a little bit about the IDTEMP folder, which appears only when a user is logged into IDrive.  After conducting further tests, I have found that there are more files generated in this folder based on certain actions performed in IDrive, which you can see in the image below.

IDTEMP Folder Artifacts

Outfile_Authlist.txt

I talked a little bit about the “Outfile_Authlist.txt” file in my last post, but I have found more information about this file in my update. This file is generated after viewing the restore tab in IDrive.  This file is updated every time a user opens the contents of a folder in the restore tab.  For instance, if the user is navigating through to the Pictures folder (PC_NAME\C\Users\username\Pictures\), the last folder that the user selected, will show up in this file as fname.   Within this file, an investigator will find a list of file(s)/folder(s) that are currently selected in the backup window to be restored.  The investigator will also find specific details about these file(s)/folder(s) such as: the item type, directory (D) or file (F), size, file version, modification time, whether or not there is a thumbnail associated with the file, and the full name (fname) of the files/folders that are currently active in the restore window.  For files, an investigator can also view the file size and the file version of the file.

 Outfile_Authlist.txt

OutputFile_Delete.txt

The “OutputFile_Delete.txt” file is generated after deleting files from the IDrive backup set.  Within this file, an investigator will find a detailed list about the files that were deleted from the IDrive backup set.  These files will contain details about the type of operation performed (item op=”deleted”), the file name and path of the file(s)/folder(s) deleted (fname), and the total number of items that were deleted. 

OutputFile_Delete.txt

OutputFile_Search.txt

The “OutputFile_Search.txt” file is generated after a user views the contents of the IDrive trash.  Within this file, an investigator will find a detailed list about the files that are currently in the trash.  The contents of this file include: the last modification time, the size, the file version, whether or not the file(s)/folder(s) are in the trash, the reference ID number, the filename and path, and the total number of items located within the trash.

OutputFile_Search.txt

OutputFile_MTO.txt

The “OutputFile_MTO.txt” file is generated after a user moves delete files from the IDrive trash to their original location in the backup set.  This file contains similar data to the “OutputFile_Delete.txt” file.  An investigator will see that the files were moved successfully (item op=”moved successfully”), the filename and path of the file(s)/folder(s) being moved (fname), and the total number of items moved.

OutputFile_MTO.txt