OAuth Tokens Left Unmonitored Represent Active Attack Vector, Material Security Research Shows

TL;DR — Most organizations lack visibility into OAuth tokens issued to third-party and AI applications connected to Google Workspace and Microsoft environments. Research indicates 80% of security leaders view unmanaged OAuth grants as critical risk, yet 45% perform no monitoring at all. The Drift incident, in which threat actor UNC6395 weaponized legitimate OAuth credentials to breach 700+ Salesforce environments, demonstrates that tokens grant persistent access independent of passwords and MFA.

What happened

A threat actor tracked by Palo Alto Unit 42 as UNC6395 obtained valid OAuth refresh tokens—likely through prior phishing campaigns—and used them to access Salesforce environments belonging to more than 700 organizations. The attacker leveraged credentials from Drift, a sales engagement platform acquired by Salesloft that maintained OAuth integrations across hundreds of customer Salesforce instances.

Once inside, UNC6395 systematically exported data including AWS access keys, Snowflake tokens, and passwords. Cloudflare, PagerDuty, and dozens of other organizations were affected. The full scope of the Drift compromise is still being assessed.

The attack bypassed standard perimeter controls and multi-factor authentication entirely. From the perspective of access logs, nothing appeared wrong: the tokens were legitimate, the integration was legitimate, and the API calls were authorized. The attacker never logged in with compromised credentials—they presented OAuth tokens that Drift had already been granted permission to use.

Why it matters

OAuth grants function as a persistent backdoor that security teams cannot see through traditional access controls. Unlike password-based authentication, OAuth tokens:

Do not expire automatically
Do not reset when employee passwords change
Do not trigger MFA validation when used
Persist in most environments with no centralized visibility
Remain valid even after employees depart

For development and infrastructure teams, this means unauthorized API access to critical systems is possible without detection by standard logging. For SOC analysts, OAuth tokens represent a blind spot: legitimate-appearing API activity from known applications may mask credential theft and lateral movement. For sysadmins managing cloud environments, a single compromised token connected to a high-privilege account can grant attackers access to AWS keys, database credentials, and configuration data across the organization.

Research from Material Security quantifies the capability gap: 80% of security leaders consider unmanaged OAuth grants a critical or significant risk. However, 45% of organizations are doing nothing to monitor OAuth grants at scale. An additional 33% rely on manual processes—spreadsheets, ad hoc reviews, and employee reporting—which do not constitute threat response capability.

Affected systems and CVEs

Products mentioned in source:

Google Workspace
Microsoft environments (unspecified products)
Salesforce
Drift (Salesloft)
AWS
Snowflake
Cloudflare
PagerDuty

No CVE assigned at the time of publication. The source does not reference assigned CVEs. The vulnerability is an architectural property of OAuth token persistence rather than a discrete software flaw in a versioned product.

What to do

The source identifies these mitigation approaches:

Implement continuous behavioral monitoring of OAuth-connected applications, not point-in-time risk assessment at the moment of installation.
Monitor actual API calls made by OAuth-connected apps over time to detect anomalies—sudden spikes in data access, unusual data types, access at unexpected hours.
Conduct blast radius assessment for each OAuth grant: determine the access levels and data exposure of the accounts to which each app is connected, since a malicious token connected to a high-privilege account poses categorically different risk than the same token on a restricted account.
Implement graduated response capabilities matched to organizational risk tolerance: obviously malicious grants (unknown vendor, broad permissions, anomalous behavior) should trigger automated revocation; mission-critical integrations showing mild anomalies should surface to the security team with full context before action.
Establish automated remediation thresholds while maintaining human review gates for applications deemed mission-critical.

Open questions

What is the full scope of organizations affected by the Drift compromise? The source states assessment is ongoing.
How many organizations currently have automated OAuth monitoring deployed? The source does not specify adoption rates.
What specific indicators or API call patterns define anomalous OAuth behavior? The source provides examples but does not establish thresholds.
When did the Drift incident occur? The source provides no date.
What attack vector was used in the initial phishing campaigns that compromised the OAuth credentials UNC6395 leveraged? The source indicates phishing but provides no detail.