Artifacts of Google Drive Usage on Windows 10 (Part 1)

Published Date : August 28, 2020 , atropos4n6

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:

  • I installed Windows 10 Pro 16299 on a brand new VM.
  • I full-cloned this base VM.
  • I used the clone to install the native app of Google Drive (version 3.43.2448.9071).
  • Then I made an army of full-clones of the full-clone of Step 3 (recursion?!).
  • I performed a series of actions.
  • I acquired both the virtual machine’s hard drive and memory.
  • I examined the images.

And with that said, lets see our scenario.


The scenario was pretty basic. I performed each and every of the following actions (wherever applicable):

  • Install/Uninstall native Google Drive app.
  • Execute the application and synced it with my Google Drive’s account.
  • Upload a file.
  • Download a file.
  • Delete a file.

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.

Findings Installation

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\DriveIn this folder you can find the executable file of the application.
C:\Program Files (x86)\Google\DriveIn this folder, you can find information about the updates of the application.
C:\Users\<username>\GoogleDriveThis 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\DriveIn this directory you will find all the native app’s files that store information about both the app and the user’s data.
Folders and directories that are created when the application is installed

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>”

Findings – Execution

To determine execution of the application, there is a plethora of artifacts, such as Prefetch and LNK files.



File Path:C:\Windows\Prefetch\

LNK Files

Linked Path:C:\Program Files\Google\Drive\googledrivesync.exe

Findings – Usage

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.dbThis 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.dbThis 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.dbThis database stores information such as user’s Google Drive account email.
C:\Users\<username>\AppData\Local\ Google\Drive\global.dbThis database also stores information such as user’s Google Drive account email.
Google Drive’s native app data files

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:

Table:global_preferences Path:C:\Users\<username>\AppData\Local\Google\Drive\global.db
Table: data Path: C:\Users\<username>\AppData\Local\ Google\Drive\user_default\sync_config.db

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:

You can find important information about the synced files’ metadata, such as hash value and last modified timestamp
You can tell if a synced file is shared with others and determine possible distribution of this file. (As always 1=True and 0=False for shared attribute)

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:

Here you can see the entries that were created when the user logged in the native application.
Deleting a synced file with the app, created the above entry. This helps to document actions taken on the synced files.

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 ActionInterpretation
Direction.UPLOAD Action.CREATE A local file is being uploaded to the user’s cloud.
Direction.DOWNLOAD Action.CREATEA file is being downloaded from the user’s cloud to the local system.
Direction.UPLOAD Action.DELETEA 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.

Findings – Uninstall

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!

One Reply to “Artifacts of Google Drive Usage on Windows 10 (Part 1)”



Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.