We're an RSA Conference 2024 Innovation Sandbox Finalist!



After gaining initial access to any platform, data theft (exfiltration) is one of the most common attack vectors used by threat actors. These days, one of the most common targets for such attacks is Google Drive, a cloud-based repository that enables users to store and access files online. With more than 6 million paying businesses using the Google Workspace platform (formerly G-Suite), there is a tremendous opportunity for bad actors to exploit it.

Given the prominence of this attack method and platform, Mitiga’s research team recently focused on examining potential data exfiltration techniques in Google Workspace as part of our ongoing research into cloud and SaaS (Software as a Service) attacks and forensics. During our examination, we discovered a significant forensic security deficiency in Google Workspace that enables a threat actor to exfiltrate data in Google Drive without any trace. Once a malicious user inside has accessed the organization’s Google Drive, they can take action without being recorded at all.

The Forensics Deficiency Problem

Google Workspace provides visibility into a company’s Google Drive resources using “Drive log events,” for actions such as copying, deleting, downloading, and viewing files. Events that involve external domains also get recorded, like sharing an object with an external user. However, this practice only applies to actions completed by users with a paid license (For example "Google Workspace Enterprise Plus”). For a full list of licenses which support google drive logs: https://support.google.com/a/answer/4579696

This limitation is the crux of the problem. By default, every Google Drive user starts by possessing a “Cloud Identity Free” license. To get more features, an admin must assign a paid license, in our research this license is "Google Workspace Enterprise Plus” to their users. When a "Google Workspace Enterprise Plus” license is not assigned, there are no log records of actions in the users’ private drive.

All users can access the Workspace and complete actions with the files inside their private company drive. They simply do so without generating any logs, making organizations blind to potential data manipulation and exfiltration attacks. When incidents occur, this standard prevents organizations from efficiently responding, as they have no chance to correctly assess what data has been stolen or whether it has been stolen at all.


This lack of visibility presents a significant problem in two main use cases:  

1. A user's account is compromised by a threat actor

  1. A threat actor who gains access to an admin user can revoke the user’s license, download all their private files, and reassign the license. The only log records that are generated in this case are of revoke and assign license (under “Admin Log Events”).
  2. A threat actor who gains access to a user without a paid license, but still uses the organization's private drive. An attacker who gains access to this user can download all the drive’s files without leaving any trace.

2. Employee offboarding

  1. Occurs in cases when an employee is leaving the company (worker offboarding) and their license gets removed before actually disabling/removing the employee as a Google user. The employee can potentially download internal files from its private drive without any notice.
  2. When the organization’s user isn’t assigned with a paid license for some reason, but still uses its private drive. Before departing they can still download the drive’s files without any log record.

Either way, without a paid license, users can still have access to shared drive as viewers. In combination with any cases mentioned in this advisory, a user or a threat actor can copy all the files from the shared drive to their private drive and download them.

In general, for copying a file to and from the google drive there are two log records – “source_copy” and “copy”, and then for downloading a file there is a “download” log record.

In the case of a user without a "Google Workspace Enterprise Plus” license, there are only “source_copy” events but not “copy” events. In addition, there are no logs of the download actions from the user private drive at all. So, if the company checks only for “copy” events and not also “source_copy” for data theft, if the copying is done by a user with unpaid license, they will miss the exfiltration detection.

Vendor Response

We have contacted Google’s security team but have not yet received an official response to include it in this Advisory. Based on earlier advisories, Google’s security team typically does not recognize forensics deficiencies as a security problem.

Recommendations to Identify Emerging Threats

1. Although there are no log records on file actions in this situation, there are events about license assignment and revoke. These events appear under “Admin Log Events”.

Event names:


If these events are happening in quick succession, it could suggest that a threat actor is revoking and reassigning licenses in your environment.

As a result, we suggest conducting regular threat hunts in Google Workspace that include searching for this activity.

2. Although in most cases it is unnecessary, we recommend monitoring “source_copy” events in your hunts to catch the case that an employee or a threat actor copies files from the shared drive to a private drive and downloads them from there.

It is crucial for organizations to follow the common effective techniques for identifying and mitigating security threats and to update their techniques to address emerging threats. Focusing solely on significant downloads may not be enough to detect all potential security breaches. Monitoring events such as license revoke and assign are critical for finding potential threats. In addition, organizations must recognize the growing importance of monitoring "source_copy" events in their threat hunting efforts. By implementing these best practices, organizations can better protect their data and infrastructure from sophisticated cyber threats.

Learn More

To read about how to make your Google Workspace logs more readable, and how to perform data exfiltration threat hunts in this environment, check out this resource from our research team: Google Workspace - Log Insights to Your Threat Hunt.


April 17, 2024

Don't miss these stories:

Mitiga Security Advisory: Abusing the SSM Agent as a Remote Access Trojan

Mitiga's research discovered a significant new post-exploitation security concept: involving the use of Systems Manager (SSM) agent as a Remote Access Trojan (RAT) on Linux and Windows machines, controlling them using another AWS account. We shared our research with the AWS security team and included some of their feedback to this advisory.

Ransomware Strikes Azure Storage: Are You Ready?

There’s been a recent surge in cloud ransomware attacks. Examples of such attacks were observed by Sophos X-Ops, which detected the ransomware group BlackCat/ALPHV using a new Sphinx encryptor variant to encrypt Azure storage accounts by employing stolen Azure Storage account keys. The BlackCat/ALPHV ransomware group is the same entity that claimed responsibility for infiltrating MGM’s infrastructure and encrypting more than 100 ESXi hypervisors.

How AWS EKS Pod Identity Feature Enhances Credential Management

This past week at re:Invent, AWS announced a very cool new product feature: EKS Pod Identity. As an AWS user, and specifically an EKS (Elastic Kubernetes Service) user, I spend a great deal of time connecting my pods and workloads to other AWS services and clusters in other regions and accounts, so for me, this feature arrives just in time.