How attackers hack a Google Workspace

By the QuantumSec team

Understanding how a Google Workspace is attacked is the first step to defending it. Most compromises don't exploit a Google flaw, but the organization's configuration and behavior. These are the vectors we see again and again in audits and incident response, explained from the attacker's point of view.

Phishing and credential theft

It's still the number one entry point. The attacker sends a phishing email impersonating Google or a known service to steal credentials. Modern adversary-in-the-middle (AitM) campaigns can even capture the 2-step verification code and the session cookie, bypassing SMS- or code-based MFA. Once inside, the next step is usually CEO fraud (BEC) or data exfiltration.

Consent phishing: malicious OAuth apps

Instead of stealing the password, the attacker tricks the user into authorizing a malicious OAuth application with permissions over Gmail and Drive. The user clicks Allow and the app obtains a persistent access token. The dangerous part is that this access survives a password change and even MFA: as long as the token is valid, the attacker keeps reading email and files. That's why OAuth app control is one of the most important and most ignored defenses.

Gmail persistence: forwarding rules and filters

After gaining access to an account, one of the attacker's first actions is to create automatic forwarding rules or filters that send copies of the email to an external address and, at the same time, hide or delete security alerts. These rules are discreet and persist even if the victim changes the password, so they're used to keep access to the mailbox for weeks without being detected.

Domain-wide delegation abuse (DeleFriend / DWD)

Domain-wide delegation allows a service account to act on behalf of any user in the domain. Security researchers demonstrated with DeleFriend that, with access to a Google Cloud project, an attacker can abuse a service account with delegation to impersonate any user —including super admins— without their password and without triggering MFA. It's one of the most severe and least audited vectors in Google environments.

From Workspace to GCP and SaaS apps

Google Workspace is rarely isolated. It usually acts as the identity provider (SSO) for dozens of SaaS applications and is tightly integrated with Google Cloud (GCP). Compromising the Workspace can mean compromising everything federated through it, and an attacker with access can pivot toward GCP to reach infrastructure, databases or secrets. The blast radius of a single compromise is enormous.

How this is stopped

Defense combines several layers: phishing-resistant MFA (security keys or passkeys), strict OAuth app control with an allowlist, monitoring of Gmail forwarding rules, inventory and least privilege for domain-wide delegations, and logging with alerts to detect suspicious activity in time. A periodic audit with an offensive approach verifies that these defenses actually work, not just on paper.

FAQ

If I change the password, do I lock the attacker out?

Not necessarily. OAuth tokens, Gmail forwarding rules, app passwords and domain-wide delegations can keep access even if you change the password. After an incident you must revoke sessions and tokens, review rules and filters, and audit connected apps.

Does MFA protect me from all these attacks?

Phishing-resistant MFA is essential, but it doesn't cover everything: it doesn't stop consent phishing (where the user authorizes a malicious app) or domain-wide delegation abuse, which doesn't require the user's credentials. That's why you need to harden the configuration and audit the environment.