Webinar: How malicious OAuth apps can lead to Google Workspace breaches

A new security webinar examines how attackers gain access to Google Workspace environments without ever stealing a password — by tricking users into granting permissions to malicious OAuth applications.

The session walks through two specific attack scenarios and the security controls that stop them.

The Shift the Session Is Built Around

The core argument is that the attack model has moved from stealing credentials to manipulating authorisation.

Instead of phishing a password, an attacker presents a legitimate-looking OAuth consent screen. The user approves it. The attacker receives a token carrying exactly the permissions that were granted.

What makes this dangerous is what the token survives. It persists after a password change. It persists after an MFA reset. It generates no login alert, because no login occurred. Every control most organisations rely on to contain a compromised account simply does not apply.

CISA and multiple threat intelligence teams have flagged OAuth consent phishing as a significant and growing pattern against enterprise cloud environments. In one documented campaign, attackers created thousands of malicious applications to harvest persistent access tokens at scale.

A Real Case Worth Knowing

Red Canary documented an attack earlier this year that illustrates the mechanics well.

Targets were directed to a legitimate Google login page, which then requested authorisation for a malicious OAuth application named "Privacy Policy Extension." The critical detail was the scope it requested: Chrome Web Store access.

Once a developer granted that permission, the attacker could modify and publish altered versions of that developer's Chrome extensions. The compromised extension then collected and exfiltrated session cookies and authentication tokens, targeting Facebook Ads accounts.

Everything the victim saw was genuine. Real Google domain, real consent flow, real login page. The only fraudulent element was the application requesting access — and there is no visual cue that distinguishes a malicious app's consent screen from a legitimate one.

That is why user training alone does not solve this.

The Bigger Problem Is Forgotten Access

The webinar's framing around active attacks is only half the risk surface. Most OAuth exposure in a typical Workspace domain comes from access that was legitimately granted and then forgotten.

Consider a marketing integration authorised two years ago. It may have requested read, compose, send and delete permissions across Gmail plus full Drive access. The campaign ended. Someone disconnected it in the vendor's dashboard. The OAuth token remained valid in your environment, carrying every permission originally approved.

Research has found privileged dormant service accounts in more than 70 percent of enterprise environments. The risk is not that attackers must work hard to exploit them — it is that they barely need to work at all.

There is a third-party dimension too. When the app developer's own infrastructure is breached, every token they hold for your environment is exposed, through no failure on your side. Third-party involvement in breaches doubled year over year, rising from 15 to 30 percent.

The Controls That Matter

Several practical measures come up consistently across the coverage.

OAuth app allowlisting is the foundational one. In the Admin Console, under Security then API Controls, administrators can restrict which third-party applications are permitted to request access. This converts the model from permissive-by-default to explicit approval.

Grant inventory is the second. You cannot revoke what you cannot see. A full inventory maps every active token, links it to a human or service account owner, and scores it by the sensitivity of the scopes it holds.

Threat hunting on rare consents is a useful detection approach. Querying for external apps consented to by fewer than some minimum number of users surfaces unusual installations — a legitimate productivity tool tends to have many users, while an attacker's app typically has one or two.

Scope review deserves particular attention. The question is not whether an app is trustworthy but whether it needs the access it asked for. An integration that only needs to read calendar availability should not hold Gmail send permissions.

Two-step verification remains worth enforcing, though with an important caveat in this context: it protects against stolen passwords and does nothing against a token the user willingly authorised. Microsoft has found MFA prevents 99.9 percent of automated attacks on cloud accounts, which is exactly why attackers moved to this technique.

Why Fast-Growing Companies Are Most Exposed

The accumulation problem scales with growth. Every new tool, every trial, every departmental integration adds grants. Few organisations run periodic access reviews on OAuth tokens the way they do on user accounts.

The result is a permission surface that expands continuously and contracts almost never.

None of this has a patch. It is a security practice issue rather than a software vulnerability, which means it gets fixed through process — regular review, revocation of unnecessary grants, and least privilege applied to applications rather than only to people.

The webinar is one of a series on the topic; a companion session covers forgotten third-party access specifically.