The defensive playbook most organizations run against Google Workspace compromise is built around a single assumption: the attack starts with a phish. Credentials get harvested, MFA gets fatigued or bypassed, and the SOC responds with a password reset and a session revocation. Material Security's latest analysis of the modern Workspace attack chain dismantles that assumption. Attackers are increasingly entering Workspace tenants through stolen OAuth tokens — no social engineering, no password prompt, no MFA challenge. A token lifted from an endpoint, a malicious third-party integration, or an over-permissive consent grant walks straight into Gmail, Drive, and every downstream SaaS application federated through Google identity.
This matters now because AI-driven tooling has industrialized both halves of the operation: token theft at scale on the endpoint side, and rapid, automated enumeration and exfiltration once inside the mailbox. If your detection strategy begins and ends at the login event, you are blind to the majority of this attack chain. Defenders need visibility from endpoint token access, through OAuth grant creation, to mailbox behavior — and containment that revokes tokens, not just passwords.
Technical Analysis
The Attack Chain, End to End
The modern Workspace intrusion, as characterized by Material Security, unfolds across four phases that defenders must instrument independently:
- Token acquisition without phishing. OAuth tokens are harvested from compromised endpoints (browser cookie stores and token caches are prime targets for commodity infostealers), captured through adversary-in-the-middle tooling, or obtained directly when a user is tricked into granting consent to a malicious third-party application. A refresh token, once held, mints new access tokens indefinitely — surviving password changes entirely.
- Token replay and session establishment. The attacker replays the token from infrastructure that does not match the victim's geography, ASN, or device fingerprint. Google's own session telemetry will often show a new IP and user agent operating under an otherwise legitimate session.
- Workspace entrenchment. Once inside Gmail, attackers create inbox rules to hide security alerts and vendor notifications, configure forwarding, register additional OAuth applications or service accounts for persistence, and enumerate Drive for sensitive data.
- AI-accelerated exploitation. LLM-driven tooling is being used to parse years of mailbox content in minutes — identifying invoices for payment fraud, mapping internal relationships for follow-on business email compromise (BEC), and drafting convincing lures in the victim's own voice. What used to take an operator days now happens before your first alert fires.
Affected Scope
- Products: Google Workspace (Gmail, Google Drive, Calendar, Admin SDK), plus any SaaS application accepting Google OAuth for authentication.
- Platforms: All Workspace editions; endpoint side affects Windows and macOS hosts where browser token stores are targeted by infostealers.
- Exploitation status: These techniques are actively used in the wild by financially motivated actors and initial access brokers. This is not theoretical — token theft and consent phishing are standard tradecraft in 2025-2026 intrusions, and Workspace tenants without phishing-resistant MFA and token controls are the softest targets.
Why Traditional Defenses Miss It
A password reset does not revoke OAuth refresh tokens or third-party app grants. MFA is not re-evaluated when an existing valid token is presented. Conditional access and session-length policies (Google's session control and context-aware access) are the only levers that constrain token replay — and most mid-market tenants have never configured them.
Detection & Response
Detection must span two telemetry planes: Google Workspace audit logs (admin, OAuth authorize, token, Gmail log events) and endpoint telemetry (infostealer access to browser credential stores).
Sigma Rules
---
title: Suspicious OAuth Application Grant in Google Workspace
id: 3b8f2e71-6c4a-4d9b-a512-9e7c5f1a8d02
status: experimental
description: Detects OAuth authorization grants to unverified or rarely seen third-party applications in Google Workspace, a common entry point for token-based compromise and consent phishing.
references:
- https://www.bleepingcomputer.com/news/security/the-modern-attack-chain-rethinking-google-workspace-security-in-the-age-of-ai/
- https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.persistence
- attack.t1550.001
- attack.t1528
logsource:
product: google_workspace
service: token
detection:
selection:
eventName: authorize
filter_known_apps:
applicationName|contains:
- 'Google'
- 'Microsoft'
- 'Zoom'
- 'Slack'
- 'Salesforce'
condition: selection and not filter_known_apps
falsepositives:
- Legitimate new SaaS onboarding; maintain an allowlist of approved application names and client IDs
level: medium
---
title: Gmail Delegation or Forwarding Configuration Added
id: 91c4d6a2-2f58-4b1e-9c37-4a6b8d0e5f13
status: experimental
description: Detects creation of Gmail forwarding addresses, mail delegation, or send-as configuration changes, frequently used by attackers for persistence and silent exfiltration after token-based mailbox access.
references:
- https://www.bleepingcomputer.com/news/security/the-modern-attack-chain-rethinking-google-workspace-security-in-the-age-of-ai/
- https://attack.mitre.org/techniques/T1114/003/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.exfiltration
- attack.t1114.003
logsource:
product: google_workspace
service: admin
detection:
selection:
eventName|contains:
- 'EMAIL_FORWARDING'
- 'DELEGATE'
- 'SEND_AS'
- 'CHANGE_GMAIL_SETTING'
condition: selection
falsepositives:
- Executive assistant delegation and legitimate user-configured forwarding; correlate with change tickets
level: high
---
title: Infostealer-Style Access to Browser Credential Stores
id: 5f2a9c84-1d37-4e6b-b208-7c3e9a4f6b51
status: experimental
description: Detects non-browser processes reading Chrome or Edge cookie and login-data stores, a hallmark of infostealers harvesting session tokens later replayed against Google Workspace.
references:
- https://www.bleepingcomputer.com/news/security/the-modern-attack-chain-rethinking-google-workspace-security-in-the-age-of-ai/
- https://attack.mitre.org/techniques/T1539/
- https://attack.mitre.org/techniques/T1555.003/
author: Security Arsenal
date: 2026/04/06
tags:
- attack.credential_access
- attack.t1539
- attack.t1555.003
logsource:
category: file_access
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\AppData\Local\Google\Chrome\User Data\'
- '\AppData\Local\Microsoft\Edge\User Data\'
selection_file:
TargetFilename|endswith:
- '\Cookies'
- '\Login Data'
- '\Web Data'
- '\Local State'
filter_browsers:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
- '\MsMpEng.exe'
condition: selection_path and selection_file and not filter_browsers
falsepositives:
- EDR/AV scanners and backup agents; exclude by known process hash or path after tuning
level: high
KQL — Microsoft Sentinel
Assumes Workspace audit logs are ingested via the Google Workspace connector (or a custom pipeline landing in a custom table) and that Defender for Endpoint process telemetry is available for the endpoint side.
// Hunt 1: OAuth grants to unverified/new apps followed by anomalous token use
GWorkspaceActivityReports
| where TimeGenerated > ago(14d)
| where EventName =~ "authorize"
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Users=make_set(ActorEmail, 50)
by ClientId = tostring(ExtendedProperties.client_id), AppName = tostring(ExtendedProperties.app_name), Scope = tostring(ExtendedProperties.scope)
| where Scope has_any ("mail.google.com", "gmail.readonly", "drive", "admin.directory")
| order by FirstSeen asc;
// Hunt 2: Gmail session activity from an IP/ASN never seen for that user (token replay)
GWorkspaceActivityReports
| where TimeGenerated > ago(30d)
| where isnotempty(IpAddress)
| summarize IPs=make_set(IpAddress) by ActorEmail;
// Correlate the output against a 90-day baseline table of known user IPs;
// flag sessions whose IP appears in the 30-day set but not the 90-day baseline.
// Hunt 3: Endpoint side - non-browser process touching browser cookie stores
DeviceFileEvents
| where TimeGenerated > ago(7d)
| where FolderPath has_any ("\\Google\\Chrome\\User Data\\", "\\Microsoft\\Edge\\User Data\\")
| where FileName in~ ("Cookies", "Login Data", "Local State", "Web Data")
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "MsMpEng.exe", "MsSense.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FolderPath, FileName
| order by TimeGenerated desc;
Velociraptor VQL
-- Hunt for non-browser processes with open handles to browser token stores
-- Deploy as a hunt across Windows fleets where infostealer activity is suspected
SELECT Pid,
Name,
Exe,
CommandLine,
Username,
CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(cookies|login data|local state)'
OR Exe =~ '(?i)(appdata|temp|programdata)\\\\[^\\\\]+\.exe$'
-- Companion artifact: enumerate recent modifications to Chrome token stores
SELECT FullPath,
Size,
Mtime,
Ctime
FROM glob(globs='C:/Users/*/AppData/Local/Google/Chrome/User Data/*/Network/Cookies')
WHERE Mtime > now() - 86400
ORDER BY Mtime DESC
Remediation & Audit Script
The script below uses GAM (GAMADV-XTD3), the standard Workspace admin CLI, to inventory third-party OAuth grants, flag grants with high-risk scopes (full Gmail/Drive access), and revoke tokens for a specified compromised user.
#!/usr/bin/env bash
# Workspace OAuth grant audit + emergency token revocation
# Requires: GAMADV-XTD3 (https://github.com/taers232c/GAMADV-XTD3) with admin credentials
set -euo pipefail
GAM="$HOME/bin/gam/gam"
HIGH_RISK_SCOPES="mail.google.com|gmail.readonly|gmail.modify|drive|admin.directory"
REPORT="oauth_grant_audit_$(date +%Y%m%d).csv"
echo "[*] Exporting all user OAuth token grants..."
$GAM print users all fields primaryemail > /tmp/ws_users.csv
tail -n +2 /tmp/ws_users.csv | cut -d, -f1 | while read -r user; do
$GAM user "$user" print tokens >> "$REPORT" 2>/dev/null || true
done
echo "[*] Flagging grants with high-risk scopes..."
grep -Ei "$HIGH_RISK_SCOPES" "$REPORT" | sort -u > high_risk_grants.txt || true
cat high_risk_grants.txt
echo "[*] Emergency revocation (run manually for a confirmed-compromised user):"
echo " # Revoke ALL third-party tokens for the user"
echo " $GAM user victim@example.com deprovision"
echo " # Or surgically: revoke a specific client ID"
echo " $GAM user victim@example.com delete token client <CLIENT_ID>"
echo " # Force global session invalidation (kills refresh-token replay)"
echo " $GAM user victim@example.com signout"
echo " # Suspend while investigating"
echo " $GAM update user victim@example.com suspended on"
echo "[*] Checking for users with forwarding enabled (exfil indicator)..."
tail -n +2 /tmp/ws_users.csv | cut -d, -f1 | while read -r user; do
fwd=$($GAM user "$user" show forwarding 2>/dev/null | grep -i "enabled" || true)
[ -n "$fwd" ] && echo "FORWARDING ENABLED: $user"
done
echo "[+] Done. Review high_risk_grants.txt and forwarding output before revoking en masse."
Remediation
Immediate (24 hours):
- Revoke sessions and third-party tokens for any user with anomalous token or OAuth grant events:
gam user <user> signoutandgam user <user> delete token client <id>. Remember: password resets alone do not kill refresh tokens. - Audit all OAuth grants with Gmail/Drive scopes (
mail.google.com,gmail.modify,drive). Any app not on your approved list gets revoked and its client ID blocked. - Review Gmail forwarding, delegation, and send-as settings across the tenant — these are the quietest persistence mechanisms in a Workspace intrusion.
Short term (this week):
- In Admin console (Security → API Controls → App Access Control), move third-party API access from "unrestricted" to trusted/limited/blocked classification, and require admin approval for new grants. This single control stops most consent-phishing entry points.
- Reduce session length for high-risk OU members (Admin console → Security → Google Session Control) and enable Context-Aware Access to bind sessions to IP, device, and geography — this is the control that actually defeats token replay.
- Deploy phishing-resistant MFA (FIDO2 security keys or passkeys) for admins and finance/executive users; enforce 2SV tenant-wide if not already done.
Structural:
- Ingest Workspace audit logs (token, admin, Gmail log events, Drive) into your SIEM and build a per-user IP/ASN baseline so token replay stands out.
- Add endpoint detections for infostealer access to browser credential stores — that is where these tokens come from before they ever touch Google.
- Establish a Workspace compromise runbook that treats token revocation, app grant review, and mail-setting audit as the first response actions, parallel to (not after) credential reset.
- Reference: Google Admin Help — Control which third-party apps access Workspace data and the Material Security analysis via BleepingComputer.
The strategic lesson: identity is the perimeter in Workspace, and tokens — not passwords — are the credential that matters. Defend the whole chain: endpoint token stores, consent and grant governance, session context, and mailbox behavior. Anything less leaves the door open.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.