DriveFS Sleuth — Your Ultimate Google Drive File Stream Investigator!
File syncing applications, while providing convenient solutions for seamless collaboration and data access within organizations, also pose inherent risks that demand careful consideration. As files are synchronized across multiple devices and platforms, the likelihood of data breaches increases, exposing organizations to the threat of confidential information falling into the wrong hands. Furthermore, organizations must grapple with the challenge of ensuring compliance with data protection regulations, as the use of file-syncing applications may inadvertently result in non-compliance.
While engaged in a threat-hunting service for a client whose objective was to identify potential misuse of file syncing applications for exfiltration, I came across the usage of Google Drive File Stream while it was not allowed in that environment. Notably, there was a lack of automation open source tools for parsing and investigating the disk forensic artifacts associated with this application, and no published research was available to provide insights into its artifacts at that time. Consequently, I undertook independent research on Google Drive File Stream so analysts could investigate its artifacts to determine the impact of its unauthorized usage, and I have decided to share my findings thus far along with the automation tool I developed.
Google Drive File Stream — What is it?
Google Drive File Stream works as a file-syncing application, facilitating the synchronization of files and photos with Google Drive and Google Photos services. The nomenclature “file stream” is attributed to its capability to stream files on demand, thereby avoiding the need to occupy disk space by downloading all files preemptively. Upon installation and login, users can promptly access all previously synced files through Windows Explorer, without the necessity of storing an offline version.
What happens upon installation?
Similar to other applications, Google Drive File Stream, as part of its installation process, configures the system for operational functionalities, these system modifications can serve as indicators to detect the installation of the application. Below we’ll discuss the most notable indicators to detect the installation of this application.
In this Medium story, we’ll not discuss the forensic artifacts mentioned in the SANS Poster, as it’s not the purpose of this research.
Registry Modifications
During installation, Google Drive File Stream adds some registry keys and values in order to configure its functionalities. The main registry creations are:
Installation, Update, and Uninstallation information:
HKLM\SOFTWARE\Google\DriveFS
HKLM\SOFTWARE\WOW6432Node\Google\Update\Clients\{6BBAE539–2232–434A-A4E5–9A33560C6283}
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{6BBAE539–2232–434A-A4E5–9A33560C6283}
Registering COM objects via CLSIDs
HKLM\Software\Classes\CLSID\{CFE8B367–77A7–41D7–9C90–75D16D7DC6B6}HKLM\Software\Classes\CLSID\{A8E52322–8734–481D-A7E2–27B309EF8D56}HKLM\Software\Classes\CLSID\{C973DA94-CBDF-4E77–81D1-E5B794FBD146}HKLM\Software\Classes\CLSID\{51EF1569–67EE-4AD6–9646-E726C3FFC8A2}HKLM\Software\Classes\CLSID\{EE15C2BD-CECB-49F8-A113-CA1BFC528F5B}HKLM\Software\Classes\CLSID\{8AD5CECD-DF0D-41C3-BA21–1E22114CC73C}HKLM\Software\Classes\CLSID\{F1196F08-BAFE-4C9C-AEE7–71C69DA5B818}HKLM\Software\Classes\CLSID\{03E6C474–8D95–4C1B-9268–4AA3FA16DE4F}
Registering Shell Icon Overlays
For displaying icons. Mind the space in the key name.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ GoogleDrivePinnedOverlayIconHandlerHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ GoogleDriveCloudOverlayIconHandlerHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ GoogleDriveProgressOverlayIconHandlerHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ GoogleDriveMirrorBlacklistedOverlayIconHandler
Registering Shell Extensions
To be added in the context menu when a user right-clicks on a shell item. Mind the space in the key name.
HKLM\Software\Classes\*\shellex\ContextMenuHandlers\DriveFS 28 or laterHKLM\Software\Classes\lnkfile\shellex\ContextMenuHandlers\DriveFS 28 or laterHKLM\Software\Classes\Directory\shellex\ContextMenuHandlers\DriveFS 28 or laterHKLM\SOFTWARE\Classes\Directory\background\shellex\ContextMenuHandlers\DriveFS 28 or later
Registering Outlook Add-ons
HKLM\SOFTWARE\Classes\DriveFSExtensionLib.ConnectHKLM\SOFTWARE\Classes\DriveFSExtensionLib.Connect\CurVerHKLM\SOFTWARE\Classes\DriveFSExtensionLib.Connect.1HKLM\SOFTWARE\Classes\DriveFSExtensionLib.Connect.1\CLSIDHKLM\SOFTWARE\Classes\DriveFSExtensionLib.Connect.1\CurVerHKLM\SOFTWARE\Classes\DriveFSExtensionLib.Meet.1HKLM\SOFTWARE\Classes\DriveFSExtensionLib.Meet.1\CLSIDHKLM\SOFTWARE\Classes\DriveFSExtensionLib.Meet.1\CurVer
Registering Type Libraries
HKLM\Software\Classes\TypeLib\{E27EC053–3263–4908–8ECD-5AFDFB754728}\1.0\HKLM\Software\Classes\TypeLib\{E27EC053–3263–4908–8ECD-5AFDFB754728}\1.0\FLAGSHKLM\Software\Classes\TypeLib\{E27EC053–3263–4908–8ECD-5AFDFB754728}\1.0\HELPDIRSoftware\Classes\TypeLib\{E27EC053–3263–4908–8ECD-5AFDFB754728}\1.0\0\win64\
Persistence in the Run Registry
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\GoogleDriveFS
File System Artifacts
During installation, Google Drive File Stream creates some files and folders on disk for the application functionality. The main disk modifications are:
Installation files, icons, DLLs, etc.
C:\Program Files\Google\Drive File Stream
Start Menu lnk
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Google Drive.lnk
What happens upon launching the application for the first time?
Many files and folders are written to disk upon launching the application for the first time after installation.
Almost all of them are under the %LocalAppData%\Google directory and this is the most important disk artifact as it will contain the user-specific artifacts that reveal the synced files.
PS: this is the default location, it could be configured though.
What happens upon logging in?
Upon user login, Google Drive File Stream creates a folder named with the user’s account ID for each account as Google Drive File Stream supports multiple accounts login. This folder contains substantial information, providing valuable insights into the files and folders that the user has synchronized with his account, these artifacts can also reveal some of the shared items with the user.
The DriveFS Sleuth Tool
DriveFS Sleuth is a Python tool that automates investigating Google Drive File Stream disk artifacts, the tool has been developed based on research that has been performed by mounting different scenarios and noting down the changes in the Google Drive File Stream disk artifacts.
DriveFS Sleuth is capable of parsing the disk artifacts and building a filesystem tree-like structure enumerating the synchronized files along with their respective properties. DriveFS Sleuth detects some deleted synchronized items and items that have been shared with the user, compiles information on mirroring folders, and provides insights into connected device configurations along with searching functionality to facilitate the investigations. Additionally, DriveFS Sleuth offers the functionality to generate reports in HTML or CSV formats.
DriveFS Sleuth is available at: https://github.com/AmgdGocha/DriveFS-Sleuth
Google Drive File Stream Artifacts Collection
For those who are fans of Velociraptor, like myself, here is a Velociraptor offline collector ready to be used for triaging Google Drive File Stream artifacts to investigate them. The collector can be found here https://github.com/AmgdGocha/DriveFS-Sleuth/tree/main/collectors
You can also use this Kape target to gather the same artifacts: https://github.com/EricZimmerman/KapeFiles/blob/master/Targets/Apps/GoogleDrive_Metadata.tkape
DriveFS Sleuth — The Theory Behind
In the following sections, we’ll discuss the most important disk artifacts that exist in %LocalAppData%\Google\DriveFS and how we can parse them to have meaningful insights about the user’s synced items.
It is worth mentioning that these artifacts are mostly for functional purposes of the application itself on the host machine so most of these artifacts are only stored offline and not being synced. Consequently, when conducting investigations on the same account through two different triages from two different machines, variations in results may arise.
experiments.db
Location: %LocalAppData%\Google\DriveFS\experiments.db
Type: SQLite DB
The experiments.db database contains important information about the logged-in accounts in the PhenotypeValues table where it stores a list of the logged-in account IDs even if the account has logged out, this information is stored in the value of the account_ids key. It’s a good artifact from which you can gather all the logged-in account IDs at any time since the account profile gets deleted when it logs out. In the below screenshot, I was able to prove the login of the account that has an account ID starting with 1153 even though it was logged out at that time and the profile was deleted.
The value of the last_sync key contains an epoch timestamp that represents the last syncing date between all the currently logged-in accounts.
pid.txt
Location: %LocalAppData%\Google\DriveFS\pid.txt
Type: TXT File
The pid.txt is the process ID of the last execution of GoogleDriveFS.exe which is the main process of the Google Drive File Stream application.
root_preference_sqlite.db
Location: %LocalAppData%\Google\DriveFS\root_preference_sqlite.db
Type: SQLite DB
The root_preference_sqlite.db contains useful information about the synced media storages and mirroring roots, these information is scattered in different tables. Let’s discover them one by one.
For each connected storage device like a USB or an HDD, the Google Drive File Stream application shows a popup window, like the one below, to ask the user whether he wants to sync from this media or ignore it.
If the user chooses to sync from this device, a second screen will be shown to the user to select the account where the sync should happen and whether the user wants to sync to Drive or Photos.
The same configuration can be configured from the Preferences menu and by clicking “Add Folder”.
According to the user’s selected options, an entry will be added to the media table to mainly track whether or not that specific media storage should be synced, Google Drive File Stream will ignore the storage media if the ignored=1, otherwise, it will sync from it.
It also stores some other useful information like the name of the storage media in the name column, the last mounting drive letter in the last_mount_point column, and the size in bytes in the capacity column. The capacity equals -1 for the storage media if the user for example connected to a mobile device and doesn’t allow access to the phone data.
A unique GUID for the storage media will be added to the media_id column where it’s the same as that is being stored in the registry, so this is good news if the analyst would like to proceed with USB forensics regarding the connected device.
That GUID can be correlated based on the media_id column with the info in the roots table where an entry for each configured device to be synced or any mirrored folder is stored.
The roots table assigns an incremental root_id for each entry, it also tracks the name of the configured item in the title column, the root path in the root_path and the last_seen_absolute_path columns, and the account ID to which the item will be synced in the account_token column. It also tracks to which service the files are going to be synced in the destination column where it equals 1 to sync the root to Drive or 2 to sync to Photos, if the root is configured to be synced to both Drive and Photos, two entries with the same information will be stored for the same root with two different destinations 1 and 2 like root IDs 4 and 7 in the previous screenshot. The one_shot column stores 1 if the user didn’t select the “Remember my choice for this device.” option and 0 if it’s a permanent configuration, once the user unplugs the device that is not remembered (with one_shot = 1), the entire row will be deleted from the database.
The max_ids table tracks the number of the roots that have been added to be synced. If the max_root_id > the number of roots in the roots table, then some roots have been removed or their configuration has been modified.
drive_fs[_num].txt
Location: %LocalAppData%\Google\DriveFS\Logs\drive_fs[_num].txt
Type: TXT File
Google Drive File Stream maintains several log files, the most important log files are the ones with the name drive_fs[_num].txt (the _num may or may not exist) as we can use it to resolve the account IDs to emails. DriveFS Sleuth uses the regex ([\w\.-]+@[\w\.-]+\.\w+) \(<account_id>\) to look up the <account_id> from the drive_fs.txt log file.
Account Profile
Following the authentication of each user account, a folder named after the account’s ID is generated with account-specific information. Subsequent sections will delve into a detailed exploration of these contents, addressing each aspect individually.
AccountProfile — metadata_sqlite_db
Location: %LocalAppData%\Google\DriveFS\<account ID>\metadata_sqlite_db
Type: SQLite DB
The metadata_sqlite_db stands out as the pivotal database, containing crucial data regarding synchronized, deleted, and shared items with the user, it consists of 18 tables, however, we’ll only discuss the most important ones to our quest.
The metadata_sqlite_db assigns an internal ID to each item and calls it stable_id which works as a PK for multiple tables for relationships, for example, the items table which serves as the central repository listing all the items. It also tracks the URL ID of the item in the id column, like what is shown in the below screenshot.
Within the items database, the trashed column is designated to store a value of 1 if the item is deleted and resides in the Trash; otherwise, it is set to 0. Similarly, the is_owner column distinguishes items owned by the user with a value of 1, while items shared with the user are marked with 0. In the case of folders, the is_folder attribute is set to 1, and 0 otherwise. The shared_with_me_date field contains an epoch timestamp of the sharing date, and 0 otherwise. If the is_owner is set to 0 and the shared_with_me_date is set to 0 then the corresponding item was shared with the user then the share was stopped.
In addition to the known mime types, Google maintains its own list of mime types, utilizing them to distinguish various item types. Google Drive File Stream records the item’s mime type in the mime_type column within the items database.
The items database tracks the items’ names in the local_title and it stores the name tokenized in the local_title_tokenized, I didn’t practically prove it, however, this is usually done for searching capabilities.
the items table stores two epoch timestamps for the last modification date and the last date when the user viewed the item in the modified_date and the viewed_by_me_date respectively.
The metadata_sqlite_db stores additional properties for each file within the item_properties table where it stores the stable ID of the item in the item_stable_id column and assigns the property name and its value in the key and value columns.
The list of the properties will be different from one account to another since the synced items are different, below is a list of the unique item properties that I was able to compile throughout my research on different accounts, this list will be updated whenever I come across additional properties.
folder_queriedlocal-content-modified-datelocal-titlemodified-dateversion-counterchurn-countcontent-entrylocal-cache-reasonexplicitly-pinned-folderpinnedinactive-content-entriesofflineStatusstale-revision-idthumbnail-cache-id-listdrivefs.Zone.Identifierdrivefs.Zone.Identifier:$DATAcrtimelocal-content-sizeatimeattr-maskdo-not-uploaddrivefs.OECustomPropertydirty-handlelast-resubscribe-timetrashed-locallytrashed-locally-metadatatrashed-locally-namedelete-item-on-startupswap-stable-id
One of the important item properties is the drivefs.Zone.Identifier:$DATA where it reveals the Zone Identified ADS data which is very helpful, if exists, revealing the source from which the file has been downloaded.
Within the metadata_sqlite_db database, Google Drive File Stream tracks the parent-child relationships between the items in the stable_parents where it stores the corresponding stable ID of the items in the item_stable_id and parent_stable_id columns. The stable_parent may reveal some deleted items where its stable ID exists as a parent or a child and the same Stable ID can’t be found in the items table, however, for such cases we may not able to get the deleted item information.
Google Drive allows users to create shortcuts for the shared items so they can add a link to them in the desired path to be accessed easily. The metadata_sqlite_db database tracks the information of those shortcuts in the shortcut_details table where it stores the ID of the shortcut file itself in the shortcut_stable_id column and the ID of the target file in the target_stable_id, it also stores a copy of the mime type of the target in the target_mime_type column.
A list of all shortcut files can be obtained by querying the items table where the mime_type is set to application/vnd.google-apps.shortcut. It is noteworthy that even if the target file is shared (with is_owner set to 0), the corresponding shortcut referencing this shared file will have the is_owner attribute set to 1. This is because the user owns the shortcut file itself, and the shared_with_me_date will be set to 0. Additionally, it is observed that the file_size will always equal to 0 since the shortcut file solely serves as a reference to another file.
When an item is deleted, it undergoes a 30-day retention period in the Trash, allowing for potential restoration. Subsequently, the item is permanently deleted. During its tenure in the Trash, its record in the items table will persist with the trashed attribute set to 1. Upon permanent deletion, this record is removed from the items table and a new record is stored in the deleted_items table. In the deleted_items table, the stable_id column retains the item’s stable ID. While the specific duration of a record’s stay in the deleted_items table and the corresponding trigger for deletion are not definitively known, the record is eventually deleted.
For some reason, the Google Drive File Stream application maintains a copy of the items’ stable IDs and their URL IDs in the stable_ids database in the stable_id and the cloud_id columns, the same information exists in the items table in the stable_id and the id columns.
AccountProfile — mirror_metadata_sqlite.db
Location: %LocalAppData%\Google\DriveFS\<account ID>\mirror_metadata_sqlite.db
Type: SQLite DB
Given that the primary purpose of the Google Drive File Stream application is to facilitate access to synchronized files on Google Drive without maintaining offline versions, the items table holds pivotal information. Consequently, a copy of this database is preserved in the mirror_metadata_sqlite.db database for reference, it doesn’t contain all of the items though, and sometimes the items will have different stable IDs for them. It has the same structure as the metadata_sqlite_db database.
AccountProfile — mirror_sqlite.db
Location: %LocalAppData%\Google\DriveFS\<account ID>\mirror_sqlite.db
Type: SQLite DB
Due to the sensitivity and critical nature of the mirroring function, Google Drive File Stream allocates a dedicated database named mirror_sqlite for monitoring mirrored items. Within this database, these items are listed in the mirror_item table, where two distinct IDs are stored for each item: a locally generated ID in the local_stable_id column and a stable ID in the stable_id column. It is noteworthy that the mirror_sqlite database maintains a distinct set of stable IDs, separate from those maintained by the metadata_sqlite database for the same items. The mirror_item table also tracks the local and the cloud names of the mirrored item in the local_filename and the cloud_filename respectively. Two epoch timestamps are stored for each item that represents the local and the cloud modification timestamps in the local_mtime_ms and the cloud_mtime_ms columns. Also the local and the cloud sizes are stored in the local_size and the cloud_size columns
Like version controllers, Google Drive stores the older versions of the synced files for 30 days or till 100 versions, the mirror_item tracks the version number of the mirrored items in the local_version and the cloud_version columns. It also sets the shared attribute to 1 if the mirrored item is shared.
The volume column represents the root for mirrored items, containing a GUID that aligns with the media_id GUID defined in the roots column of the root_preferences_sqlite database for the same root.
The root can also be directly identified by querying the mirror_item table for records with is_root=1.
The parent-child relationship of the mirrored items can be determined by following the parent_local_stable_id in the mirror_item table. As you can see in the next screenshot, the parent-child relationship is aligned with the hierarchy structure shown in the previous screenshot.
One of the cool artifacts for the mirrored items is the MD5 hash, the mirror_item table tracks the hash of the mirrored item which is an incredible piece of information, isn’t it?
The same information of the root_id, and the local_stable_id of the roots can be found in the root_config table.
The cloud_relations table maps the local ID to the cloud IDs for the mirrored items in the columns child_local_stable_id and child_stable_id, it also stores the cloud-stable ID of the parent in the parent_stable_id column.
The mirror_sqlite database tracks the root folder of the current machine in the machine_root table, in this case, it’s the My Laptop folder.
In the event of a pending upload, a temporary file is generated, named after the cloud stable ID of the item to be uploaded. This file contains the updated content and is created within a designated temporary folder named .temp.driveupload This temporary folder is established in the root directory containing the item to be uploaded. Also, a corresponding record in the pending_uploads table is being saved, and that record and the temp files are being deleted after a successful upload. In the context of this scenario, I have made modifications to a mirrored text file titled text file.txt with a cloud-stable ID of 62122 and appended additional text, as shown below:
Accordingly, a temp file named after the cloud-stable ID of the modified file has been created with the modification content inside a newly created temp folder called .temp.driveupload in the root that contains the pending upload.
Also an entry has been added into the pending_uploads table as follows.
Similarly, a .temp.drivedownload file will be created for the files that are being downloaded.
The shorcut_relations table tracks the mirrored shortcuts where it lists the stable ID of the shortcut file along with the local stable ID of the shortcut file in the target_stable_id, the shortcut_stable_id, and the shortcut_local_stable_id columns.
AccountProfile — Content Cache
Location: %LocalAppData%\Google\DriveFS\<account ID>\content_cache
So far, all the artifacts are only tracking some metadata about the synced items, we only have visibility over the synced items themselves if you have triaged them which is not always possible. The good news is Google Drive File Stream caches the contents in content_cache folder where it contains subdirectories of subdirectories that contain cached contents of synced files, for example, in the below screenshot I had a cached-content with a header %PNG which is the header of PNG files so I added the .png extension to the file and open it to see the content of the file.
Of course, any recovery tool can be used to automate this process.
The DriveFS Sleuth Tool — Usage and Output
The tool can be found here: https://github.com/AmgdGocha/DriveFS-Sleuth
usage: DriveFS Sleuth [-h] [--accounts ACCOUNTS [ACCOUNTS ...]] [--regex REGEX [REGEX ...]] [-q QUERY_BY_NAME [QUERY_BY_NAME ...]] [--search-csv SEARCH_CSV] [--exact]
[--dont-list-sub-items] [--csv CSV] [--html HTML]
path
██████╗ ██████╗ ██╗██╗ ██╗███████╗███████╗███████╗ ███████╗██╗ ███████╗██╗ ██╗████████╗██╗ ██╗
██╔══██╗██╔══██╗██║██║ ██║██╔════╝██╔════╝██╔════╝ ██╔════╝██║ ██╔════╝██║ ██║╚══██╔══╝██║ ██║
██║ ██║██████╔╝██║██║ ██║█████╗ █████╗ ███████╗ ███████╗██║ █████╗ ██║ ██║ ██║ ███████║
██║ ██║██╔══██╗██║╚██╗ ██╔╝██╔══╝ ██╔══╝ ╚════██║ ╚════██║██║ ██╔══╝ ██║ ██║ ██║ ██╔══██║
██████╔╝██║ ██║██║ ╚████╔╝ ███████╗██║ ███████║ ███████║███████╗███████╗╚██████╔╝ ██║ ██║ ██║
╚═════╝ ╚═╝ ╚═╝╚═╝ ╚═══╝ ╚══════╝╚═╝ ╚══════╝ ╚══════╝╚══════╝╚══════╝ ╚═════╝ ╚═╝ ╚═╝ ╚═╝
A tool for investigating Google Drive File Stream's disk forensic artifacts.
By: Amged Wageh
Twitter: @amgdgocha
GitHub: https://github.com/AmgdGocha
Medium: https://medium.com/@amgedwageh
Linked In: https://www.linkedin.com/in/amgedwageh
positional arguments:
path A path to the DriveFS folder. By default on a live system, it should exist in %LocalAppData%\Google\DriveFS.
optional arguments:
-h, --help show this help message and exit
--accounts ACCOUNTS [ACCOUNTS ...]
Specifies account id/s or emails separated by space to be processed, defaults to all the accounts.
--regex REGEX [REGEX ...]
Searches for files or folders by regular expressions. Multiple regex can be passed separated by spaces.
-q QUERY_BY_NAME [QUERY_BY_NAME ...], --query-by-name QUERY_BY_NAME [QUERY_BY_NAME ...]
Searches for files or folders by name. The search will be case insensitive. Multiple file names can be passed separated by spaces.
--search-csv SEARCH_CSV
Searches for files or folders that satisfies the searching conditions in the provided CSV file.
--exact If selected, only files or folders with exact file names will be returned. The --query_by_name argument has to be passed. Defaults to False.
--dont-list-sub-items
By default, if a folder matches the search criteria, the results will contain all of it's sub-items. This argument suppresses this feature to only return the folder without listing it's sub-items.
--csv CSV Generates an HTML report. The CSV report will only contain information regarding the queried files.
--html HTML Generates an HTML report. The HTML report contains comprehensive information about the analyzed artifacts.DriveFS Sleuth has been developed following research results, aiming to automate the investigation of disk forensic artifacts associated with the Google Drive File Stream Application. The tool’s usage is straightforward: the analyst provides a path to the DriveFS triaged folder. Additionally, by utilizing the --accounts argument, the analyst can specify the email or account ID of the targeted account, allowing the tool to process the interesting accounts. Multiple accounts can be specified, separated by spaces.
DriveFS Sleuth supports searching functionalities, allowing the analyst to employ regular expressions by passing a regex to the --regex parameter. Multiple expressions can be specified, separated by spaces. Furthermore, a simple text search is facilitated through the -q| — query-by-name optional parameter, where the analyst can input single or multiple texts separated by spaces. By default, the tool searches for files or folders with names containing the provided simple text. The --exact parameter can be toggled to enforce an exact name search.
While the default behavior involves listing all sub-items of a folder meeting the search criteria, the analyst can use the --dont-list-sub-items parameter to suppress this feature and only list the matching folder.
DriveFS Sleuth facilitates a more complex combination of search criteria by enabling the analyst to pass a CSV file containing the search conditions through the--search-csv parameter. The CSV file utilized for searching includes case-sensitive headers: TARGET, TYPE, CONTAINS, and LIST_SUB_ITEMS. The TARGET field holds the searching regex or simple text, while the TYPE field classifies the search type as either FILENAME or REGEX. The CONTAINS field employs FALSE for an exact search or TRUE to search for any filename containing the specified TARGET. Additionally, LIST_SUB_ITEMS is utilized to enable or disable the listing of sub-items for matching folders, indicated by TRUE or FALSE, respectively.
DriveFS Sleuth supports two types of outputs:
1- A CSV File/s.
2- An HTML Report.
A path can be passed to the --csv arguments so DriveFS Sleuth outputs 2 CSV files, the first file contains a list of all the processed files while the second CSV file lists the files and folders that match the search if the analyst provided any. Similarly, a path can be provided to the --html argument to generate an HTML report with the analysis results.
The report starts by providing information about the path of the processed artifacts, the last Sync Date, the Max Root IDs along with the modification state, and the Last PID, and then it lists the connected devices.
Then for each account, the report will list the account information, the Mirroring Roots, and the Mirrored Items with their details.
Then, a list of search results will be presented, accompanied by hierarchical structures for synchronized files, shared items, and deleted items. Items meeting the search criteria will be distinctly highlighted in dark red within the tree for easy identification. The tree is collapsable and expandable allowing easy navigation, the analyst can click any of the items in the tree to quickly access its details in the items details table.
Future work
While the current research findings offer more than enough knowledge for conducting a forensic investigation of one of the most widely used file-syncing applications, certain areas may need further exploration. I’ll work on filling those gaps and I encourage community participation to delve deeper into aspects such as, but not limited to:
- Enhancing the look of the generated HTML report.
- Investigating the
photos_catalog_sqlite.dbto have insights about how it maintains the syncing with Google Photos. - Have a deeper look into the logs written in the
%LocalAppData%\Google\DriveFS\Logsdirectory. - Check whether the
mirror_metadata_sqlite.dbcan be used to recover some deleted artifacts, what is the trigger for a record to be written in this database, and what causes the record to be deleted. - Integrating with a recovery tool to automate the recovery of the cached contents.
- Parsing the
protoBLOB of the deleted items in thedeleted_itemstable in themetadata_sqlite_dbdatabase. - Enhancing the mirrored items representation in the tool.
