# Your MFA Is Not Protecting Your Google Workspace — And Attackers Know It
When a company's Google Workspace gets compromised, the post-mortem almost always blames phishing. An executive clicked a link. Someone's password got reused. The MFA prompt got approved at 2 a.m. These stories are true, and they are also incomplete — because a growing share of Workspace intrusions never touch a password or a push notification at all.
OAuth tokens are the skeleton key that most security teams aren't watching closely enough.
## The Attack Your Controls Weren't Built For
Here's how the access works in practice: a user's browser gets compromised — through an infostealer malware infection, a malicious extension, or a session hijacking tool — and the attacker walks away with a live OAuth access token. That token doesn't represent a credential. It represents an already-authenticated session. Google sees it as legitimate. Your identity provider sees nothing. Your MFA controls never fire.
With a valid OAuth token, an attacker can read Gmail, access Drive files, enumerate shared calendars, and — critically — pivot to every third-party application that the user's Google account is connected to. That list is typically long and poorly audited. Project management tools. HR systems. Code repositories. Customer data platforms. The blast radius expands well beyond the Workspace itself.
This isn't theoretical. Infostealer malware — Redline, Raccoon, Lumma — has been explicitly engineered to harvest browser session tokens at scale, and underground markets sell access to fresh Workspace sessions the same way they sell stolen credit card numbers: in bulk, with pricing tiers based on account privileges.
## Why "Phishing-First" Thinking Leaves You Exposed
The security industry spent a decade optimizing for the credential-theft model. Train employees to spot phishing. Add MFA. Block known-malicious domains. These controls have real value — but they address the front door while the back window sits open.
The problem with framing Workspace security around the initial access vector is that it doesn't account for what happens after. Assume breach. An attacker who has a live OAuth token doesn't need to pivot through your network in a way that looks like lateral movement. They're operating inside a legitimate cloud application, as a legitimate user, doing things that legitimate users do. Exfiltrating files from Drive looks like downloading for a business trip. Forwarding emails looks like someone setting up a vacation rule.
Detection has to work differently here — not around "what did the attacker do to get in" but "what is this authenticated session doing that a real user wouldn't."
## Where AI Enters the Picture
Generative AI has tilted the attack economics in three uncomfortable ways.
First, phishing — when attackers do use it — is now nearly indistinguishable from legitimate communication. The grammatical tells that security awareness training taught employees to spot are gone. Spear phishing emails written against a target's email history, tone, and relationships don't read like phishing. They read like colleagues.
Second, AI-assisted tools are making OAuth app abuse more accessible. Writing a malicious Google Workspace OAuth app that requests plausible-looking permissions — "access to your files to enable productivity features" — used to require meaningful development effort. That barrier is collapsing.
Third, and less discussed: AI is accelerating the infostealer pipeline. Operators are using LLMs to generate convincing lure sites, automate the deployment of stealers, and sort harvested credentials at a pace that wasn't previously possible. The time between infection and active session abuse is compressing.
## What the Full Attack Chain Actually Looks Like
Reframe the threat model as a chain, not a single event:
Initial access — infostealer, phishing, malicious OAuth app, or compromised device
Token harvest — live session tokens extracted from browser storage
Reconnaissance — enumerate Drive contents, shared folders, connected apps, calendar access
Data exfiltration — download sensitive documents, forward email to external address, scrape contacts
Persistence — install a malicious OAuth application that maintains access even after password change
Lateral movement — abuse connected third-party applications to reach systems outside Workspace
The persistence step is where organizations get hurt the worst. A password reset feels like an incident response action — it revokes the path the attacker used to get in. But an OAuth application that the attacker registered during their access window survives the password reset. The attacker retains access. The security team thinks the incident is closed.
## What Defenders Should Actually Do
Audit your OAuth application landscape. Most organizations have dozens of third-party applications connected to Google Workspace and no ongoing review process. Pull the list. Revoke anything that isn't actively used or recognized. Set policies that require admin approval for new OAuth app connections.
Monitor for anomalous session behavior, not just failed logins. Successful authentications from unexpected geolocations, unusual data access volume, or new mail forwarding rules deserve the same scrutiny as failed MFA attempts. Your SIEM or CASB should be generating signals here.
Treat endpoint hygiene as a Workspace security control. An infostealer on an employee's personal device can harvest tokens for corporate Workspace sessions if that device is used for work. The perimeter isn't just your managed fleet anymore.
Revoke, don't just reset. When an account is compromised, token revocation and OAuth app audit should be part of incident response procedure — not an afterthought after the password change.
---
## HackWire Analysis
The framing of "AI-era Workspace security" is accurate but undersells what's actually new here. The OAuth token problem isn't new — security researchers were warning about session token theft and OAuth app abuse years before generative AI existed. What's changed is the scale and accessibility of the attack ecosystem that enables it.
Infostealer-as-a-service has matured into a functioning criminal market. Lumma Stealer, to pick one recent example, has been used in campaigns targeting hundreds of organizations, harvesting session tokens and selling access with turnaround times measured in hours. The AI acceleration layer is real, but it's compressing a pipeline that already worked.
What concerns me more than the AI angle is the persistent gap between where enterprise security investment concentrates and where actual intrusions begin. Google Workspace holds the crown jewels for most modern organizations — email, documents, calendars, and the authentication backbone for dozens of connected SaaS tools. But Workspace security still gets treated as an email security problem, solvable by anti-phishing tooling at the perimeter.
The OAuth attack surface is largely invisible to traditional controls. It doesn't generate failed authentication events. It doesn't look like scanning or exploitation. Defenders need to shift from perimeter-centric thinking to behavioral monitoring of authenticated sessions — asking not "did this login succeed?" but "is this authenticated session behaving like a human?"
Healthcare, legal, and financial services organizations carry the most exposure here, because their Workspace accounts are connected to the highest-value downstream systems and often have the least mature SaaS security programs. If you're in those sectors and you haven't audited your OAuth landscape this year, that's the first item to put on next week's agenda.
— HackWire Editorial
---
## Related Coverage