Salesloft Drift OAuth abuse shows how SaaS trust can collapse

At a glance

What this is: This is an analysis of the Salesloft Drift OAuth abuse campaign and its impact on Salesforce, email, and connected cloud access across hundreds of organisations.

Why it matters: It matters because IAM, NHI, and SaaS governance teams have to treat third-party OAuth grants as standing access paths, not benign integrations.

By the numbers:

• Over 700 companies were impacted, including some of the world’s most prominent cybersecurity vendors.
• Cloudflare later disclosed that 104 API tokens were stolen from their Salesforce Case system.

👉 Read Abnormal AI's analysis of the Salesloft Drift OAuth abuse campaign

Context

Salesloft Drift OAuth abuse exposed a basic governance problem in cloud identity: a trusted integration can behave like a standing credential path when it is not continuously governed. In practice, the issue is not whether the connection was originally authorised, but whether the permission outlived the operational need that justified it.

For IAM and NHI teams, this is a reminder that SaaS integrations now sit inside the identity perimeter. Once an OAuth token can read support cases, query mailboxes, and touch downstream cloud services, the attack surface expands from one application to an entire delegated access chain.

Key questions

Q: What breaks when OAuth tokens are not governed like credentials?

A: When OAuth tokens are treated as convenience links instead of governed credentials, they become persistent access paths that bypass phishing controls, password resets, and inbox inspection. The result is inherited trust with no clear expiry, which lets attackers query SaaS data and move into connected systems through legitimate API traffic.

Q: Why do third-party SaaS integrations increase breach impact?

A: Third-party integrations expand breach impact because one stolen token can reach multiple tenants, objects, and downstream services. In this campaign, access to Salesforce led to secret harvesting from Cases, email exposure through Drift Email tokens, and attempts to reach cloud storage, which turned one integration into a multi-system incident.

Q: How do security teams know if SaaS integrations are overprivileged?

A: The clearest signal is an integration that still has access but no active business justification, especially when its scopes are broad, its owner is unclear, or its last use is stale. Unusual bulk queries, case exports, and mailbox activity also indicate that delegated access has moved outside its intended boundary.

Q: Who is accountable when a trusted integration is abused?

A: Accountability sits with the team that approved, owned, and failed to retire the grant, not just the vendor whose token was stolen. For SaaS and NHI governance, delegated access needs an explicit owner, a lifecycle record, and a revocation path, or the organisation has no defensible control boundary.

Technical breakdown

How OAuth tokens became persistent access paths

OAuth access is designed to let a third-party app act on behalf of a user or tenant without sharing a password. That delegation is convenient, but in SaaS environments it often becomes durable access because tokens can remain valid for long periods and inherit broad scopes. In this case, the Drift integration provided a trusted channel into Salesforce, then into Google Workspace, and attempts were made to use stolen credentials against S3. The key technical issue is that the token is treated as legitimate traffic until revoked, so normal gateway controls and phishing filters never see an inbound attack.

Practical implication: Treat OAuth grants as governed credentials and review their scopes, age, and business purpose on a fixed schedule.

Why support cases are high-value secrets reservoirs

Support systems often accumulate sensitive operational data because users paste logs, keys, and recovery details into tickets to speed troubleshooting. That makes Salesforce Cases a lucrative target, especially when attackers already have application-level access and can query records at scale. The article shows the attackers searched accounts, users, opportunities, and cases, but focused on cases because they often contain reusable secrets and high-trust context. This is not accidental data exposure in a single record. It is a structured search for credentials embedded in operational workflows.

Practical implication: Reduce secret storage in case data and build detection around high-volume case queries and bulk exports.

Why traditional email security missed the compromise

This campaign did not begin with phishing, malicious attachments, or user deception. It began with inherited integration trust, which means email security tools that inspect inbound messages had no interception point. Once attackers gained Drift Email tokens, they could access a limited set of Google Workspace accounts and exfiltrate mail data using legitimate API paths. That makes identity telemetry, application permission review, and SaaS posture monitoring more important than mail gateway inspection alone. The breach shows how cloud email compromise can be identity-led even when no email is ever sent.

Practical implication: Correlate email, OAuth, and SaaS admin logs so abnormal delegated access can be revoked before it spreads.

Threat narrative

Attacker objective: The objective was to turn trusted SaaS integrations into reusable access and secret-harvesting channels across multiple customer environments.

1. Entry occurred through compromised OAuth tokens tied to the Salesloft Drift app, which gave the attackers trusted access to Salesforce without a phishing email or password theft. The token itself functioned as the initial access mechanism.
2. Credential access and abuse followed when the attackers queried Salesforce objects, especially Cases, to collect AWS keys, Snowflake tokens, VPN credentials, passwords, and other reusable secrets. They also used Drift Email tokens to reach Google Workspace accounts.
3. Impact included data exfiltration from more than 700 organisations, theft of 104 Cloudflare API tokens, and attempts to use stolen Salesforce credentials against Amazon S3. The campaign created downstream risk for impersonation, lateral movement, and further cloud compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth trust is a credential problem, not just an integration problem: The Drift campaign worked because delegated access was treated as a convenience feature instead of a governed credential path. Once a third-party token can query Salesforce and email data, the organisation has created standing access that outlives the user action that authorised it. For NHI governance, the lesson is that application tokens must be managed as live identities with explicit lifecycle and revocation ownership.

Support-case data is a secret sprawl amplifier: Case systems are now credential reservoirs because users paste operational secrets into them under pressure. The attackers’ focus on Cases shows that the breach path was not only OAuth abuse but also secret concentration inside service workflows. The implication is that support tooling has become part of the secret-management control plane, not a passive repository.

Third-party access without lifecycle offboarding is the failure mode this breach exposes: The trust relationship with Drift was allowed to persist even after it became operationally unsafe. That is a lifecycle governance failure, not a visibility failure, because the access existed longer than the business justification. Practitioners should treat offboarding and entitlement review for SaaS integrations as mandatory identity controls, not vendor hygiene.

Identity blast radius now extends across SaaS, email, and downstream cloud services: The breach did not stop at Salesforce because the stolen tokens and harvested secrets created chained access opportunities. This is why zero trust for SaaS has to include delegated application review, secret containment, and downstream misuse detection. The practical conclusion is that one compromised integration can now behave like a multi-system identity incident.

Cloud email compromise has moved beyond phishing-era assumptions: The attack bypassed inbox inspection entirely, which means legacy control logic no longer matches the threat model. When email access is inherited through an API token, the deciding factor is not whether a message was opened but whether the delegated identity should have existed at all. Security teams need to reframe email compromise as an identity and integration governance problem.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to Guide to the Secret Sprawl Challenge.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the 2026 Infrastructure Identity Survey.
• For lifecycle control patterns and revocation design, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for how persistent secrets turn delegation into standing access.

What this signals

Secret sprawl is now an integration-layer problem: The practical boundary has moved from endpoints to SaaS permissions, which means revocation discipline matters as much as discovery. When a support system can hold passwords, API keys, and cloud tokens, the organisation needs secret hygiene across workflows, not only in code repositories.

Delegated access needs lifecycle ownership, not just initial approval: OAuth grants should be retired with the same seriousness as service accounts and privileged users. If the owner cannot explain why an integration still exists, the grant has already outlived its purpose and should be removed before it becomes a hidden persistence mechanism.

Security teams should treat support data as identity-relevant telemetry: Case objects, mailbox metadata, and admin events now reveal whether an attacker is harvesting secrets or merely moving through normal SaaS activity. The governance gap is not lack of logs, but lack of joined-up identity context across the cloud stack.

For practitioners

• Inventory all third-party OAuth grants Map every SaaS integration to its scopes, business owner, and last-used date, then remove anything that cannot justify ongoing access to Salesforce, email, or downstream cloud services.
• Review support-case handling for secret leakage Block or redact AWS keys, Snowflake tokens, VPN credentials, and passwords from support workflows, and alert on bulk searches or exports from case objects.
• Correlate SaaS, email, and identity logs Detect suspicious delegated access by joining OAuth activity, mailbox access, and admin events so revoked tokens and anomalous API use can be identified together.
• Offboard inactive integrations on a fixed cadence Apply lifecycle controls to every integration that no longer has a clear business need, with owner sign-off and explicit revocation before the next review cycle.

Key takeaways

• This campaign shows that trusted SaaS integrations can function like standing credentials when their lifecycle is not governed.
• The scale was broad, with more than 700 companies affected and secret harvesting focused on support data that often contains reusable cloud access.
• The control that mattered was not gateway inspection but timely revocation, scoped delegation, and lifecycle ownership for every OAuth grant.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission that lets one application act on behalf of a user or tenant without sharing a password. In identity governance, it must be treated as a live credential path with scope, owner, and expiry, not as a one-time setup step.
• SaaS Posture Management: SaaS posture management is the practice of discovering, evaluating, and controlling the security state of connected cloud applications and their permissions. It matters because integrations often hold broad access to email, files, and support data long after the original business need has passed.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of passwords, API keys, tokens, and certificates across code, tickets, chat, and cloud platforms. It increases breach impact because attackers can often recover multiple reusable credentials from a single compromised workflow or repository.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems exposed when one identity or integration is compromised. In SaaS environments, it is shaped by token scope, connected applications, and how quickly revoked access is actually removed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI covering the Salesloft Drift OAuth abuse campaign: Key Insights UNC6395 abused OAuth tokens tied to Salesloft's Drift app to query Salesforce data across 700+ organizations. Read the original.