Final Research Paper

Hello All! Here is a link to my final Capstone paper, which includes all of my methods, tools, research, and findings.  I hope you all find it beneficial to your studies and can help you improve and/or further my research.

https://www.dropbox.com/s/ohxxln3gwho6tst/Lahaie_IDrive_Forensics_Final_Draft_CCC-410-14.docx

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

Hidden Behind the Cumulonimbus

After conducting some additional analyses, I have found a very important folder.  I found this folder located at: C:\Users\Capstone_PC\AppData\Local\IDrive\.  This folder is called IDTEMP.

IDTEMP Folder

When first conducting my analysis on my first few acquisition images, I found this file in only a few of the images.  At first, I did not know why this folder showed up in some images, but not others.  But, after conducting some more tests with IDrive, I was able to find out what this folder is and why it only shows up at certain times.

When I first took my snapshot of my VM, after installing IDrive, I closed IDrive before creating the snapshot.  When I acquired the snapshot and opened it in FTK Imager for an initial analysis, I did not see this IDTEMP folder.

However, after searching through the RAM image, with WinHex, which I dumped with DumpIt, I found an entry pointing to this folder.

Why did the IDTEMP folder disappear?  It wasn't until after I finished conducting all of my tests with IDrive that I was able to figure out why this folder disappeared and what data it contains.  After analyzing the datas, I found that this folder disappears when IDrive is exited by the user.  Once the user logs back in his or her account in the IDrive application, this folder reappears.

Within this folder are some very key files.

One of these files is a text file, "Outputfile_stringencode_stringencodepswd.txt", containing an encrypted string of the password.

Outputfile_stringencode_stringencodepswd.txt

There is another file called "OutputFile_GetQuota.txt", which contains the total quota in the users IDrive account (stored in bytes), the used quota (stored in bytes), which is the size of the data that is currently backed up to IDrive, the file count, and whether or not the backup was a success or not.

OutputFile_GetQuoata.txt

There are also two files called "Authlist_Args.txt", and "Quota_Args.txt".  These two files have almost very similar data stored in them.  They contain the port number used (443), the temp folder, the locations of the output files and error files, the username of the IDrive account, and the IP Address used to reach out to the Pro Softnet servers.

Authlist_Args.txt

Quota_Args.txt

Another important file is the "Outfile_Authlist.txt".  This file contains the folder names of the computers that were connected to IDrive and used to backup data, the modified time of these folders, and the amount of data sent and received.

Outfile_Authlist.txt

I also found that there was one file, which was missing from the above screenshots, which ONLY appears after the very first log in to the IDrive Windows application.  This file is called "Outfile_stringencode_stringencodekey.txt".  This file appears to be an encoded string of the private or public encryption key.  I cannot say for certain which key this is as I have tried to use it to decrypt the encoded password, and I do not know the specific type of 256-bit AES encryption method that IDrive uses.

Outfile_stringencode_stringencodekey.txt

What's Life Like in the Clouds?

It has been a long couple of months and I have been busy working on my capstone, among other classwork. I have made substantial progress on my project.  This post will outline my methods and initial findings up until this point.

Methods:
In order to conduct my research, I had to start off with a clean Windows system that had no prior data generated on it.  In order to do this, I created a Virtual Machine (VM) installed with a fresh copy of Windows 7 Professional Edition (x64 bit ).  When setting up the VM, I created a user called "Capstone_PC".  See the below table for more specs. on my VM:

Once I setup my VM, and installed all of the Windows updates, I copied DumpIt, Process Monitor, and RegShot to my VM desktop from my host machine.  I then created a snapshot of the VM, to have a clean image before conducting my research, in case I needed to start over again.  Once I did this, I went to www.idrive.com and created an account using the name "Capp Stone" with my college email address.

I then downloaded the IDrive Windows Executable to my VM's desktop.

Before conducting any of my research with IDrive, I took a snapshot of the registry using RegShot and I ran Process Monitor to monitor any of the running processes generated by IDrive.  After finishing each of my steps, I took a second snapshot of the registry with RegShot, to compare any registry changes, and I captured the VM's RAM using DumpIt.

Then, I took a snapshot of the VM after each step, and I imaged each snapshot, which are stored as .vmdk (Virtual Machine Disk) files, with FTK Imager.  These images were used to conduct most of my analysis.  In total, I have 12 acquisition images to sift through.

Initial Analysis:
After briefly analyzing my first few images with FTK Imager, I found that IDrive stores its data in two locations.  These locations are C:\Program Files (x86)\IDriveWindows

and C:\Users\Capstone_PC\AppData\Local\IDrive.  The most important data, from a forensics standpoint, is located in this second location.

In the colby.lahaie@mymail.champlain.edu subdirectory, located: C:\Users\Capstone_PC\AppData\Local\IDrive\IBCOMMON\, I found a file called "20140125222358363.txt".  This file contains the directories that were automatically synced to IDrive after install.  This file is also contained with in the AutoSync subdirectory located within the colby.lahaie@mymail.champlain.edu subdirectory.

Also found within this subdirectory is a .ini file labeled "idriveserver.ini".  .ini files are text files containing configuration information.  This file shows the IP Address for Pro Softnet, which is the company that makes IDrive, the total quota given to me in IDrive, the type of account I have, and the size of the data currently backed up to IDrive.

In the WIN-UTORKF6HPTE subdirectory, located: C:\Users\Capstone_PC\AppData\Local\IDrive\IBCOMMON\logs\colby.lahaie@mymail.champlain.edu\, I found a file called "01-25-2014_01252014222407.xml".  This file contains data showing the date and time that a backup to IDrive was started, how many files were added to the backup set, the IDrive username, the computer name, and what type of backup it was.

There is also another file located in the same directory called "WIN-UTORKF6HPTE.xml".  This file contains the current size of the data in the current backup, the file count of files in the backup, and the last backup time.

After analyzing the logfile.pml generated by Process Monitor, I found 4 services/executables that were added to the VM after installing IDrive.  These services/executables were reaching out to idrive.com, 1uweb.com, and deploy.static.akamaltechnologies.com, when IDrive was running.  These four files were:

idwutil_600.exe,

id_win.exe,

id_service.exe,

and id_bglaunch.exe.

Stay tuned for my next blog.