Hello there. Today I will write down the artifacts of a research I have made about a year ago. I know what you may think. A year ago is old enough for these artifacts to be accurate today. Well, apparently this is not the case for most of the artifacts you will find below. This research was about Cloud Forensics. More particularly, I used Google Drive (this post is about the native app- upcoming post for using Google Drive with web browsers) on a Windows 10 machine and performed a series of actions with it. Then, I acquired both the hard drive and memory and searched for artifacts of the Google Drive’s usage, which could prove my actions. Lets see how that went. Firstly, we are gonna see the setup and then jump into the scenario and the findings.
The idea was to keep everything as clean as possible. What I mean is that I didn’t want to perform all the actions from the same machine, as this could have gotten me puzzled, as for which artifact matched which action. So, I used a different machine for each action in order to (stay calm) make my findings more solid. Of course I couldn’t have done this without using virtual machines (using VMware Workstation 14). The setup was this:
And with that said, lets see our scenario.
The scenario was pretty basic. I performed each and every of the following actions (wherever applicable):
The scope of this research was to locate those artifacts that could prove that the above actions were made from the user. Lets see how that went.
Google Drive’s native app name is “Backup and Sync from Google”. After installing the app, I found these entries in my C drive:
C:\Program Files\Google\Drive | In this folder you can find the executable file of the application. |
C:\Program Files (x86)\Google\Drive | In this folder, you can find information about the updates of the application. |
C:\Users\<username>\GoogleDrive | This folder is being used (by default) by the app for synchronizing user’s files with Google Drive cloud service. You can choose from the native app’s settings, which directories you wish to be automatically synced with the cloud, but you can also drop any file to this folder and it will automatically be uploaded to the user’s cloud. |
C:\Users\<username>\AppData\ Local\Google\Drive | In this directory you will find all the native app’s files that store information about both the app and the user’s data. |
If you are trying to determine installation of the application, apart from the registry keys and the above folders, here are the details of a specific event log you should look for:
Path: C:\Windows\System32\winevt\Logs\Application.evtx
Event ID: 1033
Event Description Summary: Windows Installer installed the product.
Provider Name: MsInstaller
Event Data: Among others “<EventData> <Data> Backup and Sync From Google3.43.2448.907110330Google,Inc.(NULL)</Data>”
To determine execution of the application, there is a plethora of artifacts, such as Prefetch and LNK files.
Prefetch
Application Name: GOOGLEDRIVESYNC.EXE
File Path:C:\Windows\Prefetch\GOOGLEDRIVESYNC.EXE-XXXXXXXX.pf
LNK Files
Linked Path:C:\Program Files\Google\Drive\googledrivesync.exe
Databases that store valuable information
Lets see some of the valuable information that can be stored inside the applications’ databases.
C:\Users\<username>\AppData\Local\ Google\Drive\user_default\snapshot.db | This database stores information about the files that have been synced with the user’s Google Drive account. |
C:\Users\<username>\AppData\Local\G oogle\Drive\cloud_graph\cloud_graph.db | This database also stores information about the files that have been synced with the user’s Google Drive account. |
C:\Users\<username>\AppData\Local\ Google\Drive\user_default\sync_config.db | This database stores information such as user’s Google Drive account email. |
C:\Users\<username>\AppData\Local\ Google\Drive\global.db | This database also stores information such as user’s Google Drive account email. |
You should definitely check the above databases as they are full of valuable information. We will take a glimpse here and will refer to some of their fields, but be advised that there is more information there. If you are interesting in determining the user logged in Google Drive, check these fields:
If you are interesting in the files that are synced with the app and for their information (e.g. you are looking if a particular file is shared with the user), then table cloud_entry inside snapshot.db is your place. Lets see a couple of screenshots:
The databases’ fields (removed-deleted) were not accurate as for the deleted files. I find more files marked as deleted than the files that were actually deleted (has something to do with editing a file but was not sure). So I wouldn’t rely only on that. If you are searching for deleted synced files, typical Windows Forensics are always applicable. For example:
The files that were synced from the user Google Drive’s account are placed inside C:\Users\<username>\GoogleDrive. So, if you suspect that a local synced file was deleted, you can look inside the Recycle Bin and check for files that have this directory as their “Original Path”. What is more, you can search inside the $Logfile for “Delete File” operations which have the above directory’s MFT number as their “Original Parent MFT Record Number”.
The gold is in the log
Although the above-mentioned artifacts are enough to determine many of the actions I have made during my research, there is one particular artifact, which I personally consider the “goldmine” of Google Drive’s native app examination. But of course, this file could not be anything else than a logfile. The logfile that logs EVERYTHING that a user do with the application. Its name is “sync_log.log” and you can find under “C:\Users\<username>\AppData\Local\Google\Drive” directory. Firstly, lets see how this log looks like and afterwards we will see some of its entries:
The entries stored in this log, match most of the data that are inside the databases. However, this log also stores user actions, which are not stored in the databases. Here are some combination of user action (direction of the action and actual action) that I matched up against my actions during this research.
Direction and Action | Interpretation |
---|---|
Direction.UPLOAD Action.CREATE | A local file is being uploaded to the user’s cloud. |
Direction.DOWNLOAD Action.CREATE | A file is being downloaded from the user’s cloud to the local system. |
Direction.UPLOAD Action.DELETE | A locally synced file is being deleted. |
That’s pretty much all the types of artifacts that I managed to pull from the images. The only interesting artifact that was found in memory was the user’s account password. If you are interesting in performing cloud extraction for the user account then I suggest collecting RAM memory. I used the string “&Passwd=“, in order to find the password. Now, lets see what remains after uninstalling this software.
Unfortunately, I did not find any of the above-mentioned important artifacts, after uninstalling the app. I used 2 ways to uninstall it (Windows remove app function and CCleaner) and the results were the same. None of the databases or the logfile were there. I managed to carve the log, but not the databases. Of course, not everything is bad. When uninstalling the application, it prompts the user to select whether or not he wants to keep the synced files (default option is to keep them). So, the chances are that you may find the synced files at the path mentioned above. What is more, you can prove that the software was uninstalled using the below Event Log:
Path: C:\Windows\System32\winevt\Logs\Application.evtx
Event ID: 1034
Event Description Summary: Windows Installer removed a product.
Provider Name: MsInstaller
Event Data: Among others “<EventData> <Data> Backup and Sync From Google3.43.2448.907110330Google,Inc.(NULL)</Data>”
Well, that is all for now. I hope this artifacts’ reference will help you in your investigations. I am going to write another post about the artifacts of Google Drive’s usage, but this time using Google Chrome and Mozilla Firefox browsers. Be safe and keep DFIRing!
Interesting…