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
Under the Hill Forensics
A blog about my capstone and my life as a forensicator. And no, I do not live in the Shire with Bilbo Baggins.
Thursday, May 1, 2014
Wednesday, April 16, 2014
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.
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.
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.
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.
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 |
Sunday, April 13, 2014
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.
Moved to Original
(MTO) Files
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.
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.
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 |
Friday, March 21, 2014
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.
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.
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.
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.
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.
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.
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 |
Subscribe to:
Posts (Atom)