From Workspace to GCP: how an attacker escalates in the Google ecosystem

By Kike Gandia · Co-Founder & CEO, OSCP

Google Workspace is rarely isolated: it shares identities with Google Cloud (GCP) and with dozens of SaaS apps through SSO. That integration is convenient, but it creates escalation paths an attacker uses to move from email to infrastructure. This guide explains that boundary and how to audit it.

Shared identity: the connection point

Google Workspace accounts are also identities in Google Cloud. If a user has permissions in GCP, compromising their Workspace account can open the door to cloud resources: machines, databases, buckets or secrets. Identity is the glue that ties both worlds together and, therefore, the attacker's target.

Domain-wide delegation and service accounts

Domain-wide delegation allows a GCP service account to impersonate any Workspace user. The DeleFriend research demonstrated how to abuse this from GCP with limited permissions. It's the most dangerous bridge between the two environments and one of the least audited.

SSO and federated apps

When Workspace acts as the identity provider (SSO) for other applications, compromising it propagates access to everything federated. The blast radius of a single compromise stops being one mailbox and becomes the company's entire application ecosystem.

How to audit the Workspace-GCP boundary

You have to look at both sides: review GCP IAM and service accounts, inventory domain-wide delegations, restrict who can create service account keys and correlate Workspace and GCP logs. Auditing one without the other leaves a critical gap the attacker knows well.

One concrete escalation path, step by step

The route we see in audits usually looks like this. First, the attacker compromises the Workspace account of a technical profile —a developer, someone from platform— through real-time phishing. That account is not a Workspace admin, so at first glance the damage looks contained.

Second, they enumerate the IAM of the Google Cloud projects that identity can reach and look for service accounts they can act upon: the service account token creator and service account user roles allow obtaining credentials for that account without stealing any key. Third, they check whether any of those service accounts has domain-wide delegation configured. If one does, they can request a token on behalf of any user in the domain within the delegated scopes, including the super admin.

The important thing about this chain is what does not appear in it: at no point is the final victim’s password or second factor needed. The super admin’s 2SV never comes into play, because access arrives through the API, not through sign-in.

What to check on each side of the boundary

The questions that need answering do not all live in the same console, and that is exactly why this vector goes unaudited.

Question	Where Workspace answers it	Where Google Cloud answers it
Which service accounts can impersonate users?	API access controls, domain-wide delegation	IAM and service accounts in each project
With which scopes can they do it?	List of client IDs and authorized scopes	—
Who can create service account keys?	—	Organization policies and IAM roles
Who can mint tokens for a service account?	—	Token creator and service account user roles
Is delegation use traceable?	Admin and token audit logs	Cloud Audit Logs

Auditing one column only leaves the gap intact, and it is a gap attackers know well.

FAQ

Is auditing only the Workspace enough?

No, if you also use Google Cloud. The escalation leverages precisely the integration between the two: you must audit GCP IAM, service accounts and domain-wide delegations in addition to the Workspace configuration.

Who should worry about this?

Any company using Google Workspace and Google Cloud together, especially if it has service accounts with domain-wide delegation or automated integrations between the two environments.

What is the scope of an audit covering both environments?

At minimum: the inventory of domain-wide delegations with their scopes, the IAM of the Google Cloud projects, who can mint credentials for each service account, the organization policies restricting key creation, and the correlation of logs across both sides. The real size of the work is driven by the number of projects and service accounts, not the number of users.

Can it be done in production?

The review part, yes: enumerating delegations, roles and policies is done with read-only permissions and changes nothing. Demonstrating a specific escalation path is agreed in writing and executed in a scheduled window, or reproduced against a test account created for the purpose, so no real data is touched.

What deliverables come out of this work?

A map of the escalation paths that exist today between Workspace and Google Cloud, the list of domain-wide delegations with their scopes and who can use them, the recommended organization policies to shut down unnecessary key creation and impersonation, and the specific events to monitor in order to detect delegation being used.

If we do not use Google Cloud, does this still affect us?

Probably yes. Domain-wide delegation is configured on a Google Cloud service account, even if you use Google Cloud for nothing: if some third-party integration once asked for it, there is a project with a service account able to impersonate your users. That is precisely the case nobody reviews, because the organization believes it has nothing in Google Cloud.

Related service

Google Workspace security audit

Sources

Request a Google Workspace audit