Skip to content

Beginner-friendly red team icon   GCP

Leverage Google Workspace for GCP Access

In this hands-on red team lab, you'll pivot from a compromised Windows jumpbox into a cloud-based Google Workspace and GCP environment. 

Scenario

The ability to expose and leverage even the smallest oversights is a coveted skill. A global Logistics Company has reached out to our cybersecurity company for assistance and have provided the IP address of their website. Your objective? Start the engagement and use this IP address to identify their AWS account ID via a public S3 bucket so we can commence the process of enumeration.

Lab prerequisites
  • Basic Linux command line knowledge
Learning outcomes
  • Knowledge of a technique that can be used to find AWS Account IDs
  • Understanding what a tool does by performing a code review
Real-world context

If threat actors get their hands on an AWS Account ID, they can try to identify the IAM roles and users tied to that account. They can do this by taking advantage of detailed error messages that AWS services return when inputting an incorrect username or role name. These messages can verify if an IAM user or role exists, which can help threat actors compile a list of possible targets in the AWS account. It's also possible to filter public EBS and RDS snapshots by the AWS Account ID that owns it.

Attackers leverage SNS's deep integration into automated workflows and its broad permissions to silently deliver confidential information outside the organization. The service's legitimate business purpose provides perfect cover for malicious activity, as data exfiltration disguised as routine notifications rarely raises suspicions among security teams focused on traditional attack vectors like direct database access or file transfers. This technique has proven particularly effective because most organizations implement robust monitoring for their databases and storage systems while neglecting to scrutinize the content and recipients of their notification streams, creating a blind spot that experienced adversaries are quick to exploit.

KEY TAKEAWAY

Google Workspace and Google Cloud share an identity plane. A compromised Workspace account is not only an email and documents problem, it is a potential cloud problem, because the same identity may carry bindings into projects and the documents themselves frequently contain what is needed to use them.

What this lab covers

You start from a compromised endpoint, move into the Workspace environment behind it, and mine the productivity suite for the information that leads into Google Cloud.

The lab reflects how real intrusions progress. Attackers do not go straight for infrastructure, they read what people wrote down, and productivity tools are where organizations record credentials, architecture and process.

It is rated intermediate and suits defenders responsible for either Workspace or GCP, because the connection between them is usually owned by neither team.

How Workspace compromise reaches cloud infrastructure

Workspace and Google Cloud use the same identity directory. A user who signs into Gmail can hold IAM bindings on projects, so the boundary people imagine between productivity tooling and infrastructure does not exist at the identity layer.

The documents are the first prize. Docs, Sheets, Keep notes and Gmail routinely contain credentials shared during onboarding, architecture descriptions, environment names, support ticket contents and links to internal systems. Search across a mailbox and drive is fast and yields more than infrastructure enumeration would.

From there the path is ordinary Google Cloud escalation. The compromised identity's bindings are enumerated, and any token creation rights over service accounts allow movement to identities with broader access than the human ever had.

How to detect this in your own environment

Watch for unusual search and download activity in Workspace. Bulk drive downloads and broad mailbox searches are distinctive, and Workspace audit logs record them, though many organizations do not route those logs anywhere useful.

Correlate Workspace and Google Cloud activity for the same identity. A user who signs into Workspace from an unusual location and then makes their first ever Cloud API calls is a much stronger signal than either event considered alone.

Alert on new OAuth application grants by users. Consent to a third-party application is a common persistence mechanism, since it survives password changes and is rarely reviewed.

How to prevent it

Separate human identities from infrastructure access. Cloud permissions should be held by groups with just-in-time elevation rather than standing bindings on the accounts people read email with.

Enforce phishing-resistant authentication on Workspace, because it is the front door to both environments. Standard multi-factor authentication does not prevent token theft through relay proxies.

Restrict third-party application access and review OAuth grants, and give people somewhere better than a Doc to put credentials so the productivity suite stops being a secret store by default.

Real-world context

Productivity suites are a consistent early target in intrusions precisely because they contain the organization's written knowledge. Attackers have historically found credentials, network diagrams and process documentation faster than they could enumerate the infrastructure directly.

The identity linkage is what makes this specifically a cloud issue rather than a data loss one. Where the same account holds cloud bindings, the compromise of a mailbox becomes a compromise of infrastructure without any further exploitation.

The pattern maps to MITRE ATT&CK T1114 Email Collection, T1213 Data from Information Repositories and T1078.004 Cloud Accounts.

Applying this at work

  • Check which of your Workspace users hold direct IAM bindings in Google Cloud, and move that access to groups with elevation instead.
  • Confirm Workspace audit logs are collected and searchable, including drive and mail activity.
  • Review OAuth application grants across your tenant and remove those nobody can account for.
  • Enforce phishing-resistant authentication for anyone with cloud access.
  • Search your own Drive and Keep for credential-shaped content. The result is usually a useful shock.

Frequently asked questions

Are Google Workspace and Google Cloud separate environments?

They share an identity directory. The same user account can access Gmail and hold IAM bindings on cloud projects, so a Workspace compromise can become a cloud compromise without any additional exploitation.

Why do attackers search documents before infrastructure?

Because it is faster and more informative. Docs, Sheets, Keep and Gmail commonly contain credentials, architecture notes and environment details that would otherwise take extensive enumeration to discover.

How do I break the link between Workspace and cloud access?

Hold cloud permissions through groups with just-in-time elevation rather than standing bindings on individual user accounts, and enforce phishing-resistant authentication on the identities that can elevate.

Do I need my own Google account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own organization.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.