OAuth consent phishing in Google Workspace

By the QuantumSec team

Consent phishing is an attack that doesn't steal passwords: it steals permissions. Instead of tricking you into revealing your credential, it tricks you into authorizing a malicious application that gains access to your Gmail and Drive. It's one of the most effective vectors against Google Workspace because it bypasses MFA and persists over time.

What consent phishing is

The attacker registers an OAuth application and directs the victim to Google's real consent screen, where they're asked to authorize permissions over their account. If the victim clicks Allow, the app receives an access token with the requested permissions (scopes). From there the attacker can read and send email or access files without knowing the user's password.

Why MFA doesn't stop it

In a classic phishing attack, MFA can stop the use of the stolen credential. In consent phishing there's no stolen credential: the user authenticates legitimately with Google —passing their own MFA— and then grants the permission. MFA doesn't intervene again, and the granted token stays valid even if the user later changes the password.

Anatomy of the attack

The usual pattern is: a lure email (a supposed productivity tool, a document viewer or an integration) with a link; Google's legitimate consent screen showing the app and its permissions; the click on Allow; and obtaining a token with scopes over Gmail or Drive. Because the screen is the real Google one, many users don't detect the deception: the trick is in the app, not in a fake website.

Signals and detection

The clues we look for in an audit or incident response: apps not verified by Google with broad permissions, scopes disproportionate to the declared function, spikes of authorizations of the same app in a short time and access to Gmail or Drive from unknown applications in the logs. The Workspace investigation tool lets you trace which accounts authorized which apps.

How to protect your Workspace

The most effective defense is moving API access to a restricted access model (allowlist): block third-party apps by default and authorize only trusted ones, and block apps not verified by Google. Complement this with user training, alerts for authorizations of apps with sensitive scopes and a periodic review of the apps connected to your environment.

FAQ

If I change the password, is it solved?

No. The attacker's access depends on the granted OAuth token, not on the password. To cut it you must revoke the app's authorization (its token) from the admin console, in addition to reviewing forwarding rules and active sessions.

How do I block this attack at the organization level?

By configuring API access control in restricted mode: third-party apps are blocked except those you approve in an allowlist, and unverified apps are blocked. This way, even if an employee clicks Allow, the organization policy prevents access.