Salesloft/Drift OAuth Breach: SaaS as Attack Vectors

Executive Summary

The Salesloft Drift OAuth breach (August 2025) compromised 700+ organizations through weaponized OAuth tokens, demonstrating why product security teams must threat model SaaS integrations as untrusted attack surfaces. This analysis examines the technical mechanics, architectural anti-patterns, and secure-by-design lessons for teams building or evaluating third-party integrations.

The Attack: Six Months of Silent Credential Harvesting

UNC6395 (tracked by Google’s GTIG, also called GRUB1 by Cloudflare) executed a sophisticated supply chain attack that revealed fundamental weaknesses in how SaaS platforms handle OAuth integrations. The threat actor obtained compromised OAuth tokens associated with the Salesloft Drift third-party application and weaponized them to conduct a widespread data theft campaign beginning as early as August 8, 2025 through at least August 18, 2025. These tokens enabled systematic SOQL queries and bulk exports across hundreds of victim organizations, demonstrating how a single compromised integration can cascade across an entire SaaS ecosystem.

Attack Timeline

Prior to Aug 2025: UNC6395 obtains compromised OAuth tokens associated with Salesloft Drift application (exact method and timing not publicly disclosed)
August 8-18, 2025: Active exploitation phase: systematic SOQL queries via Salesforce Bulk API 2.0 to enumerate and exfiltrate data from 700+ victim organizations
August 18, 2025: Cloudflare detects anomalous activity; begins incident response
August 20, 2025: Salesloft/Drift revoke compromised OAuth tokens; public disclosure begins

Technical Mechanics: Why OAuth Tokens Are Persistent Attack Primitives

The attack demonstrates a common architectural blind spot: OAuth integrations are often treated as “set and forget” convenience features rather than privileged access channels. This same pattern of unmanaged machine identities and SaaS credential governance gaps has become a systemic risk across enterprise environments. Once a user authorizes an integration, the resulting tokens provide continuous access to production data without the same scrutiny applied to interactive user sessions.

Attack Vector: UNC6395 executed SOQL queries via Salesforce’s Bulk API 2.0 to enumerate record counts, then selectively exfiltrated support case text containing plaintext credentials including AWS AKIA keys, Snowflake tokens, VPN credentials, and passwords.

The attackers demonstrated operational discipline by targeting high-value data sources first: support cases, incident reports, and internal communications where organizations often (incorrectly) paste sensitive credentials for troubleshooting. This pattern reveals a secondary security failure: the normalization of credential sharing through unstructured SaaS fields.

What Made This Attack Successful

This incident succeeded not because of novel exploitation techniques, but because it exploited predictable enterprise behaviors and integration architecture patterns:

Integration trust assumptions: Organizations implicitly trusted Drift as a secure custodian of OAuth tokens, without modeling Drift as a potential breach victim.
Over-broad access: OAuth scopes granted read access across multiple Salesforce object types, enabling wide reconnaissance and data harvesting. This is a textbook case of ambient credential escalation, where broad default scopes expand effective privilege far beyond the integration’s intended purpose.
Secrets sprawl: Credentials stored in unstructured case fields became accessible through any integration with read permissions.
Limited behavioral monitoring: Bulk exports and record enumeration by service accounts did not trigger immediate alarms in many environments.

Three Architectural Risk Patterns Exposed by This Attack

Broad OAuth Scopes: When tokens provide access to multiple object types without clear business justification, a single compromised credential enables wide-ranging data exfiltration.

Long-Lived Tokens Without Monitoring: OAuth tokens that don’t expire or rotate create persistent attack surface. Without behavioral anomaly detection, malicious usage appears identical to legitimate integration activity.

Unstructured Sensitive Data: Storing credentials and API keys in text fields (support cases, notes) makes them accessible to any integration with read permissions on those objects.

Cloudflare’s Response: A Blueprint for Incident Handling

Cloudflare’s public disclosure provides a rare, detailed look at how a mature security organization handles third-party OAuth compromise. Their response combined rapid containment with systematic investigation and forward-looking architectural improvements.

Detection Method: Anomalous API activity patterns triggered automated alerts, leading to discovery of unauthorized bulk export operations from the Drift OAuth integration account during off-hours.

The response demonstrates defense-in-depth principles applied to SaaS ecosystems: even when a trusted partner is breached, internal monitoring and rapid response can limit blast radius.

Secure-by-Design Lessons for Product Security Teams

When evaluating or building SaaS integrations, product security teams must assume that integration partners will eventually be compromised. This requires designing OAuth architectures that minimize damage when — not if — tokens are stolen.

Architectural Requirements for OAuth Integration Security

Short-Lived Tokens: Enforce expiration and rotation. Refresh tokens should rotate on use and expire after reasonable periods (hours to days, not months).
Least-Privilege Scopes: Deny by default. Grant minimal read access only to required objects. Avoid wildcard permissions or “convenience” scopes like “read all cases.”
Behavioral Monitoring: Alert on bulk exports, unusual query patterns, off-hours API activity, or geographic anomalies from integration service accounts.
Secrets Hygiene: Treat unstructured text fields as untrusted. Implement DLP controls, scan for credentials with entropy detection, educate users not to paste secrets into support tickets or notes.
Network Segmentation: Integration tokens should not have access to internal infrastructure, administrative APIs, or cross-tenant data without explicit business justification.
Audit Trail Integrity: Ensure OAuth query logs cannot be deleted by the token holder. Implement tamper-evident logging with external backup.

The Supply Chain Attack Surface Has Expanded

This incident proves that the supply chain attack surface extends beyond open-source dependencies and vendor software. Every OAuth integration represents a privileged supply chain relationship with persistent access to production data. The same principle applies to autonomous AI agents that chain tools without trust boundaries — any component granted ambient credentials can become an exfiltration vector.

The threat model must evolve: OAuth integrations are not just application features — they are long-lived credentials stored in third-party environments, with blast radius equivalent to compromised admin accounts.

Actionable Recommendations

For product security teams building platforms that support OAuth integrations:

Implement token-specific rate limiting and behavioral analysis. A support tool shouldn’t be executing bulk exports during weekends.
Require periodic reauthorization for high-privilege scopes. Force users to reaffirm consent quarterly, not indefinitely.
Build revocation workflows that operators can execute in seconds, not hours. When a breach is suspected, time-to-revoke determines blast radius.
Treat OAuth Connected Apps like privileged service accounts. Apply the same monitoring, alerting, and access review processes you use for production database credentials — as explored in our analysis of why privileged access management tools must meet a higher security standard.

For security teams evaluating third-party SaaS integrations:

Audit which OAuth scopes your critical SaaS integrations possess. Remove access to objects that are not strictly required.
Implement compensating controls: weekly token rotation, API monitoring, and DLP scanning for credential patterns in unstructured fields.
Include OAuth integration breach scenarios in tabletop exercises. Know how to revoke tokens and assess exfiltration quickly.

Conclusion: Rethinking Trust Boundaries in SaaS Ecosystems

The Salesloft/Drift breach is a forcing function for modern product security: OAuth integrations must be treated as untrusted, compromise-prone attack surfaces with persistent access to core business data. When trust boundaries fail at the integration layer, the consequences mirror what happens when trust boundary enforcement relies on the wrong architectural layer — the control never holds under adversarial conditions.

Secure-by-design means architecting as if your partners will be breached. Because they will be.

Frequently Asked Questions

What was the Salesloft Drift OAuth breach?

The Salesloft Drift OAuth breach was an August 2025 supply chain attack where threat actor UNC6395 weaponized compromised OAuth tokens from the Salesloft Drift third-party application. The attackers used these tokens to execute systematic SOQL queries via Salesforce Bulk API 2.0, exfiltrating data from over 700 victim organizations before detection and token revocation on August 20, 2025.

How did attackers exploit OAuth tokens in the Salesloft breach?

UNC6395 used compromised OAuth tokens to query Salesforce instances through the Bulk API 2.0. They first enumerated record counts, then selectively exfiltrated high-value data from support cases and internal communications. These unstructured fields often contained plaintext credentials — including AWS AKIA keys, Snowflake tokens, and VPN passwords — enabling potential secondary compromise.

What data was exposed in the Salesloft Drift incident?

The attackers targeted support case text, incident reports, and internal communications across 700+ organizations. These fields contained plaintext credentials including AWS access keys, Snowflake tokens, VPN credentials, and passwords that users had pasted into unstructured SaaS fields for troubleshooting. This secrets sprawl created a secondary exposure beyond the initial breach scope.

How did Cloudflare detect the Drift OAuth compromise?

Cloudflare detected the compromise through automated alerts triggered by anomalous API activity patterns. Specifically, they identified unauthorized bulk export operations originating from the Drift OAuth integration account during off-hours. Their response combined rapid token revocation with systematic investigation, demonstrating how behavioral monitoring and defense-in-depth principles can limit blast radius.

How can organizations protect against OAuth integration breaches?

Organizations should enforce short-lived token expiration with rotation, apply least-privilege OAuth scopes, and implement behavioral monitoring for bulk exports and off-hours API activity. Additionally, teams must treat unstructured text fields as untrusted by deploying DLP controls and credential scanning. Regular scope audits and rapid revocation workflows are essential compensating controls.

References

About this analysis:

This article examines the August 2025 Salesloft/Drift OAuth breach from a product security architecture perspective. All technical details are sourced from public disclosures by Google Threat Intelligence Group, Cloudflare, and AppOmni. The goal is to provide actionable threat modeling lessons for teams building and evaluating SaaS integrations.