ARTIFACTS OF GOOGLE DRIVE USAGE IN WINDOWS

Google drive is an online file storage and sharing service from Google that supports sharing of different types of files such as pictures, videos, documents, spreadsheets,presentations, etc. The service supports various devices including desktops, mobiles, etc. through different modes such as desktop client, web portal, mobile applications etc.

The users can also invite others to view, download, and collaborate on the files. The storage works in collaboration with Google docs, sheets, and slides, an office suite that allows users to edit the documents, spreadsheets, presentations, and so on, online.

Google Drive Forensic Artifatcs

Google Drive's native app name is Backup and Sync from Google. After installing the application, the following entries will be created on the root drive.

Directories created when Google Drive is installed
<SYSTEMROOT>\Program Files\Google\Drive	In this folder you will find the executable file of the application
<SYSTEMROOT>\Program Files (x86)\Google\Drive	Here you will find information about the updates of the application
<SYSTEMROOT>\Users\<username>\GoogleDrive	This is the default folder used for synchronizing the user’s files with Google Drive cloud service
<SYSTEMROOT>\Users\<username>\AppData\Local\Google\Drive	Here you will find all the native app’s files that store information about the app and the user’s data

Registry

The installation of Google drive creates various keys and values inside the Registry. View the registry hives listed below in the forensic image of the suspect's hard disk.

SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders
SOFTWARE\Google\Drive
NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run\GoogleDriveSync
NTUSER.DAT\Software\Classes

From the Registry we can obtain the installed version and the user folder.

Let’s check the Registry to see if the sync process starts automatically with the user’s login. The right key to view here is NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run

The version and installation of Google Drive in Window’s Registry can be found at NTUSER.DAT\Software\Google\Drive.

Event Log

We can also determine the installation of Google drive on the hard disk of the suspect by viewing the details of the following event log.

Path	<SYSTEMROOT>\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 the execution of the Google drive application by the suspect, there are plethora of artifacts to look out for.

Prefetch

Windows stores Prefetch files at <SYSTEMROOT>\Windows\Prefetch. Prefetch files are all named using common naming criteria. The name of the running application comes first, then comes an eight-character hash of the location where the application was run, and finally it ends with the .PF extension.

You can parse the prefetch file with Eric Zimmerman's PECmd to obtained a more detailed information. A truncated output is shown below.

LNK (Shortcut) Files

LNK files hold a wealth of useful information about the computer at which the file was first created time in addition to the computer where it resides currently. For Google drive, the files to look out for are:

<SYSTEMROOT>\Users\<username>\Desktop\Google Drive.lnk
<SYSTEMROOT>\Users\<username>\Links\Google Drive.lnk
<SYSTEMROOT>\ProgramData\Microsoft\Windows\Start Menu\Programs\Google \Drive\Google Drive.lnk

You can parse each of these lnk files with Eric Zimmerman's LECmd for detailed information. A truncated output is shown below.

Database Artifacts

To find evidence of usage of the application, the examiner will have to examine valuable information that can be stored in the following databases of the application.

<SYSTEMROOT>\Users\<username>\AppData\Local\ Google\Drive\user_default\snapshot.db
<SYSTEMROOT>\Users\<username>\AppData\Local\Google\Drive\user_default\sync_config.db
<SYSTEMROOT>\Users\<username>\AppData\Local\Google\Drive\cloud_graph\cloud_graph.db
<SYSTEMROOT>Users\<username>\AppData\Local\Google\Drive\global.db

You should definitely check the above databases as they are full of valuable information.

Sync_config.db

The sync_config.db is a SQlite3 dB which contain profile configuration like:

Client version installed
Local sync root path
User email

Snapshot.db

The snapshot.db is a SQlite3 dB that contains information about local and cloud entries

Cloud_entry table

File name
Created (UNIX timestamp)
Modified (UNIX timestamp)
URL
Checksum (MD5 hash)
Size
Shared

Local_entry

File name
Modified (UNIX timestamp)
Checksum (Md5 hash)
Size

From the above, 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)

By selecting cloud_entry from the table, we obtained information such as file name, date of files created, removed, and modified size, checksum, shared, resource_type, etc. We can also select local_entry for more information.

From the local_entry, investigators can pull out values like inode number, file name, modified, checksum, size, and is_folder, where 1 = true (it's folder) and 0 = false (it's file).

The Log File

You can obtain information about the client sync session from the sync_log.log file located at <SYSTEMROOT>\Users\<username>\AppData\Local\Google\Drive\user_default. The logfile logs EVERYTHING that a user does with the application and it is what I consider the gold mine in Google drive forensic investigation. Information available includes: sync sessions, file created, file modified, and file deleted.

Note: Because log files are easy to modify (even by novice computer users) and are usually subject to integrity debate at the court of law as a result, the investigator is adviced to take a hash of the log file in order to prove its integrity in the court.

Let us open it in notepad to see what it looks like.

Above is the entries that were created when the user logged in the native application. Search using the strings below:

Action.CREATE
Action.DELETE
Action.MODIFY

Modifying 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 matches most of the data that are inside the databases. However, this log also stores user actions, which are not stored in the databases.

Memory Artifacts

Investigators can find out information about the sessions of a Google Drive client from RAM analysis. This, of course, can only be achieved if, on arriving at the crime scene, the incident responder finds the system powered on. For this, the investigator can run a RAM capture tool to dump the RAM contents, and then use a hex editor tool to analyze the captured RAM contents. The tool of choice here will be Belkasoft RAM capturer. To use this tool, follow these steps:

Download the tool from here (you will need to fill out a simple registration form first in order to proceed to the download section).
Transfer the tool onto a USB drive—the USB should have more storage than target computer RAM memory. As an incident responder, you ought to have had a USB drive prepared with the RAM capturer tool in it already.\
Execute the program on the PC where you want to capture its RAM and click the “Capture” button.
Open your .mem file (here 20210305.mem) captured using the RAM Capturer tool from the previous step in your HxD hex editor for analysis.

To find the email ID of the user, enter the string user_emailvalue in the hex editor (use Ctrl F).

To check the version of Google Drive client, enter the string highest_app_versionvalue in the hex editor.

To find the display path for the default sync folder, enter the string local_sync_root_pathvalue in the hex editor.

Well, that is all for now. I hope this article will help you in your investigations. Bye!

Facebook SDK