{
	"id": "13a81820-8a43-488f-a405-665e4fd72456",
	"created_at": "2026-04-06T00:08:53.744505Z",
	"updated_at": "2026-04-10T13:12:27.054148Z",
	"deleted_at": null,
	"sha1_hash": "287933eeb4bddb2ec86faa7b6a073171acc6936d",
	"title": "Exploring a Critical Risk in Google Workspace's Domain-Wide Delegation Feature",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 411823,
	"plain_text": "Exploring a Critical Risk in Google Workspace's Domain-Wide\r\nDelegation Feature\r\nBy Zohar Zigdon\r\nPublished: 2023-11-30 · Archived: 2026-04-05 15:00:18 UTC\r\nExecutive Summary\r\nUnit 42 researchers discovered a security risk in the Google Workspace (formerly known as G Suite) domain-wide\r\ndelegation feature. We exposed an unexpected way to gain access to the Google Workspace domain data from\r\nGoogle Cloud Platform (GCP).\r\nWe found that a GCP identity with the necessary permission can generate an access token to a delegated user. A\r\nmalicious insider or an external attacker with stolen credentials can use this access token to impersonate Google\r\nWorkspace users, granting unauthorized access to their data or to perform operations on their behalf.\r\nIn this article, we will highlight the risk of the Google Workspace domain-wide delegation feature. In doing so, we\r\nwill explore its potential misuse by malicious actors and examine the implications for the security of Google\r\nWorkspace data.\r\nAs organizations increasingly rely on the power of cloud-based services like Google Workspace and Google\r\nCloud Platform GCP, it becomes crucial to delve into the intricacies of their security features and vulnerabilities.\r\nWe will discuss the link between GCP and Google Workspace and examine how the GCP permission model can\r\nimpact the security of Google Workspace.\r\nPalo Alto Networks customers receive protection from the issue discussed in this article through Cortex XDR and\r\nPrisma Cloud.\r\nDomain-Wide Delegation Misuse Overview\r\nSimulation\r\nA possible attack path shown in Figure 1 could be a malicious insider (e.g., a developer with editor permissions in\r\na GCP project) exploiting their access. They could do so by abusing a service account that is granted domain-wide\r\ndelegation permissions in Google Workspace. The insider has permission to generate access tokens to service\r\naccounts within the same GCP project.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 1 of 9\n\nFigure 1. Second attack scenario.\r\nWith the domain-wide delegation permissions enabled, a malicious insider can impersonate users in the Google\r\nWorkspace domain and use the access tokens to authenticate API requests. By leveraging the appropriate scopes\r\nand API access, the insider can access and retrieve sensitive Google Workspace data, potentially compromising\r\nemails, documents and other confidential information stored within the domain. Such actions highlight the threats\r\nof the domain-wide delegation feature.\r\nA worst case scenario would come about if an attacker has obtained a GCP service account token attached to a\r\ncompute engine instance (e.g., the compute engine default service account, which has editor permissions by\r\ndefault). From there, the attacker may be able to exploit the domain-wide delegation feature for larger impact. If in\r\nthe same project, a service account with domain-wide delegation exists, this can lead the attacker to impersonate\r\nthe delegated service account and move laterally from GCP to gain access to the Google Workspace environment.\r\nGoogle Workspace\r\nBefore we delve into the intricacies of a recent security risk that surfaced within Google Workspace and GCP, it is\r\ncrucial to establish a solid foundation of understanding about these powerful cloud-based services.\r\nGoogle Workspace apps are a collection of cloud-based collaboration tools. Organizations use Google Workspace\r\nto enhance their productivity and communication through various tools such as the following:\r\nEmail\r\nCalendar\r\nFile storage and sharing\r\nTeam communication\r\nWorkflow automation\r\nSecurity\r\nAdministration\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 2 of 9\n\nGoogle Workspace provides role-based access control (RBAC) capabilities and allows administrators to assign\r\nspecific roles to users, granting them predefined sets of permissions based on their responsibilities and needs.\r\nThese roles include the following:\r\nSuper admin\r\nGroups admin\r\nUser management admin\r\nEach role has specific privileges and controls over different aspects of the organization's Google Workspace\r\nenvironment. The Google Workspace super admin holds elevated permissions and broader domain management\r\nresponsibilities, including the ability to grant domain-wide delegation permission to service accounts, which we\r\nwill explore in more detail later.\r\nGoogle Workspace administrators can also define application-specific permissions and restrict sharing and\r\nvisibility settings. For example, an administrator can enforce policies that prevent users from publicly sharing files\r\nand limit sharing options to ensure files remain within authorized boundaries.\r\nA common use case for a link between GCP and Google Workspace is when an application hosted on GCP needs\r\nto interact with one of the Google Workspace services. These services include the following:\r\nGmail\r\nCalendar\r\nDrive\r\nDocs\r\nThis integration allows the application to access and manipulate user-specific data, perform actions on behalf of\r\nusers, or leverage the collaboration and productivity features of Google Workspace.\r\nA delegated GCP service account is required to create an application that interacts with Google services, accesses\r\nGoogle APIs, handles users' data or performs actions on their behalf.\r\nWhat Is a Service Account?\r\nA service account is a special type of account in GCP that represents nonhuman entities, such as applications or\r\nvirtual machines. It allows them to authenticate and interact with Google APIs. A service account is associated\r\nwith the application itself rather than an individual end user.\r\nService accounts are not members of your Google Workspace domain, unlike user accounts. They aren't subject to\r\ndomain policies set by Google Workspace administrators and can only access users' data if they are granted\r\ndomain-wide delegation.\r\nWhat Is Domain-Wide Delegation?\r\nDomain-wide delegation is a feature in Google Workspace that allows GCP service accounts to access Google\r\nWorkspace users' data and to act on their behalf within a specific domain.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 3 of 9\n\nWhen using the domain-wide delegation feature, applications can act on behalf of users in a Google Workspace\r\ndomain without requiring individual users to authenticate and authorize the application.\r\nOnly a Google Workspace super admin can authorize an application, acting as the service account, to access data\r\non behalf of users in a domain. This authorization is called “delegating domain-wide authority\" to a service\r\naccount.\r\nHow Does Domain-Wide Delegation Work?\r\nTo use the domain-wide delegation feature, the following steps (shown in Figure 2) are required:\r\n1. Enabling Domain-Wide Delegation: The Google Workspace super admin grants domain-wide delegation\r\nfor a service account, along with a set of OAuth scopes allowed for that access. These scopes detail which\r\nspecific services and specific actions the service account will have access to. For example, if just the scope\r\n/auth/gmail.readonly is granted, the service account will have access to read a user’s Gmail messages when\r\nacting on behalf of that user, but not their other Workspace data such as access to files in Drive.\r\n2. Requesting Google Workspace Access Token: The application sends a request to the Google Workspace\r\ntoken endpoint with the appropriate credentials. This includes the service account's client ID and client\r\nsecret, as well as the desired scopes for accessing the user data. If the request is valid and the service\r\naccount has been granted the necessary domain-wide delegation privileges, the token endpoint responds\r\nwith an access token. The application can use this access token to access user data across the domain\r\nwithin the limits of the scopes requested.\r\n3. API Access: The application includes the access token in API requests as an authorization header, and it\r\nacts as proof of authentication and authorization on behalf of the service account.\r\nFigure 2. Domain-wide delegation flow.\r\nWhen granted domain-wide delegation, a service account in Google Workspace can access user data, act on their\r\nbehalf and authenticate requests to Google APIs. The specific capabilities and data accessible depend on the\r\ndefined scopes.\r\nUnderstanding the Risks and Implications of the Domain-Wide Delegation Feature\r\nOnce the domain-wide delegation is granted to a GCP service account, a GCP identity with the necessary\r\npermission can generate an access token to a delegated service account in the same project. A malicious insider\r\ncan then use this access token to impersonate Google Workspace users, granting unauthorized access to the users'\r\ndata or performing operations on their behalf.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 4 of 9\n\nThis scenario creates a mismatch between the sensitivity of the domain-wide delegation permission and the\r\npermission model managed on the GCP platform.\r\nGoogle documentation includes a cautionary notice concerning the domain-wide delegation feature, which\r\noutlines the significant capabilities of this feature. Google mentions that, “For this reason, only super admins can\r\nmanage domain-wide delegation, and they must specify each API scope that the app can access.”\r\nGoogle has an article suggesting not using automatic role grants for Service Accounts, which in the described case\r\nwould have prevented the creation of a default Google Compute Engine Service Account. To help reduce excess\r\npermissions, Google has documentation on GCP role recommendations best practices, which also mentions their\r\n\"Recommender API\" tool.\r\nUsing Audit Logs From Both Ends to Identify Potential Misuse\r\nIt is impossible to understand the complete picture of the activity and identify any potential misuse of the domain-wide delegation feature without analyzing the audit logs from both platforms, GCP and Google Workspace. The\r\ngeneration of a service account key log will appear in GCP logs while Google key generation and API call\r\nexecution logs will appear in Google Workspace logs.\r\nIn Figure 3, there is an XQL query from the Cortex web interface that is searching for service account key creation\r\nin GCP audit logs.\r\nFigure 3. Searching for service account key creation.\r\nFigure 4. Equivalent query in Prisma Cloud RQL syntax.\r\nFigure 5 shows an XQL query that searches for the service account authorization log.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 5 of 9\n\nFigure 5. Searching for the Google Workspace access token request.\r\nFigure 6. Equivalent query in Prisma Cloud RQL syntax.\r\nFigure 7 shows we checked who gave this service account domain-wide delegation permission and when that\r\nhappened.\r\nFigure 7. Searching for the log that indicates that domain-wide delegation permissions were granted\r\nto a service account.\r\nFigure 8. Equivalent query in Prisma Cloud RQL syntax.\r\nFigure 9 shows the alert “A Google Workspace admin has enabled domain-wide delegation to a GCP service\r\naccount and granted him access to a sensitive scope” was triggered in the Cortex web interface.\r\nFigure 9. Domain-wide delegation alert in the Cortex web interface.\r\nMitigation\r\nThe security risk we have identified lies in the mismatch between the initial permissions necessary for a malicious\r\ninsider to misuse the domain-wide delegation feature and the potential impact.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 6 of 9\n\nOptimal security practices for service accounts with domain delegation permissions are to position them within a\r\nhigher-level folder in the GCP hierarchy. In the GCP hierarchy model, access control is hierarchical.\r\nPermissions and policies set at a higher level (e.g., organization or folder) do not automatically grant access to\r\nlower-level folders or projects. Access control is not inherited downward in the hierarchy, meaning that lower-level folders or projects do not have automatic access to higher-level ones.\r\nFigure 10. GCP resource hierarchy tree\r\nThis strategy reduces the surface area for security breaches by potential malicious insiders who would normally\r\nonly have permissions within lower-level folders or projects within the GCP hierarchy shown in Figure 10. You\r\ncan stop entities in lower-level areas from getting the service account's access tokens by making sure that only\r\nentities in the same or higher-level folders or projects can generate access tokens to the delegated service account.\r\nThis helps prevent the misuse of domain-wide delegation permissions and prevents access to Google Workspace\r\ndata.\r\nConclusion\r\nWe’ve been discussing this issue with Google through a variety of contact points since June 2023. This issue was\r\nalso identified by Team Axon, which they have also reported to Google.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 7 of 9\n\nThere are risks and implications associated with the domain-wide delegation feature that security defenders need\r\nto consider when configuring this permission. Depending on the scope that was granted with the domain-wide\r\ndelegation, an attacker can use the feature to impersonate Google Workspace users, perform actions on their\r\nbehalf and gain unauthorized access to their data.\r\nIt’s important to highlight the mismatch between the initial permissions required for the attacker to misuse this\r\nfeature, and the possible impact. In worst cases, an attacker or a malicious insider can leak sensitive Google\r\nWorkspace data, such as emails, documents, and other confidential information stored within the domain.\r\nPalo Alto Networks customers receive protection from the issue discussed in this article through both Cortex XDR\r\nand Prisma Cloud.\r\nCortex XDR capabilities can identify and alert on various abnormal activities such as the granting of domain wide\r\ndelegation permissions or the creation of GCP service account keys. Cortex XDR is able to learn the behavior of\r\nGCP and Google Workspace entities and detect unusual behavior.\r\nPrisma Cloud CIEM can help mitigate risky and over-privileged access by providing:\r\nVisibility, alerting, and automated remediation on risky permissions\r\nAutomatic findings of unused permissions with Least-privilege access remediations\r\nPrisma Cloud Threat Detection capabilities can alert on various identity-related anomalous activities such as\r\nunusual usage of credentials from inside or outside of the cloud.\r\nPrisma Cloud can also perform runtime operation monitoring and provide governance, risk and compliance (GRC)\r\nrequirements for any component associated with their cloud environment.\r\nIf you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident\r\nResponse team or call:\r\nNorth America Toll-Free: 866.486.4842 (866.4.UNIT42)\r\nEMEA: +31.20.299.3130\r\nAPAC: +65.6983.8730\r\nJapan: +81.50.1790.0200\r\nPalo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA\r\nmembers use this intelligence to rapidly deploy protections to their customers and to systematically disrupt\r\nmalicious cyber actors. Learn more about the Cyber Threat Alliance.\r\nDisclosure Timeline\r\nJune 27, 2023: Palo Alto Networks submitted a report about the domain-wide delegation security risk to\r\nthe Google Workspace product team.\r\nJuly 10, 2023: Security discussion between Google Workspace product team and Palo Alto Networks\r\ncloud research group.\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 8 of 9\n\nJuly 18, 2023: Palo Alto Networks submitted a report to the Google Vulnerability Reward Program\r\nregarding this issue.\r\nAug. 2, 2023: Palo Alto Networks filed a bug with the Google Workspace product team and they replied\r\nthat they would implement a fix if required.\r\nAugust 2023: Palo Alto Networks notified Google of the intention to publish on the security risk and\r\noffered the opportunity for fixes or input.\r\nNov. 8, 2023: Palo Alto Networks invited Google’s input on our article on the domain-wide delegation\r\nsecurity risk.\r\nSource: https://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nhttps://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/critical-risk-in-google-workspace-delegation-feature/"
	],
	"report_names": [
		"critical-risk-in-google-workspace-delegation-feature"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434133,
	"ts_updated_at": 1775826747,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/287933eeb4bddb2ec86faa7b6a073171acc6936d.pdf",
		"text": "https://archive.orkl.eu/287933eeb4bddb2ec86faa7b6a073171acc6936d.txt",
		"img": "https://archive.orkl.eu/287933eeb4bddb2ec86faa7b6a073171acc6936d.jpg"
	}
}