OAuth token abuse turned Salesloft Drift into a Salesforce breach

At a glance

What this is: This is an analysis of how stolen OAuth tokens from a trusted connected app were used to access Salesforce tenants at scale and hide the exfiltration trail.

Why it matters: It matters because IAM, PAM, and NHI programmes have to govern connected apps and tokens as first-class identities, not as peripheral integrations.

By the numbers:

• Cloudflare rotated 104 internal API tokens found in the exfiltrated case text and notified customers.
• 17 minutes and as quickly as 9 minutes

👉 Read CYATA’s analysis of the Salesloft Drift OAuth token breach

Context

OAuth tokens extend an application’s privileges into the systems it connects to, which means compromise of the token can be more damaging than compromise of the interface itself. In this case, the trusted Drift connected app became the access path into Salesforce tenants, and that is a governance problem for NHI and IAM programmes as much as a detection problem.

The primary failure was not malware or a broken Salesforce control. It was the assumption that a connected app can be trusted because it is known, while its bearer tokens and refresh tokens can be reused elsewhere with the same authority. That assumption breaks the moment the token becomes the identity.

Cloud monitoring often sees this activity as normal API traffic until data volume, query patterns, or token geography become extreme. That makes lifecycle control, scope reduction, and cross-platform telemetry the practical centre of gravity for teams managing SaaS-connected identities.

Key questions

Q: What breaks when a connected app token is stolen and reused?

A: A stolen connected app token turns delegated trust into direct access. MFA and password controls do not help because the attacker is already presenting valid bearer credentials. The real failure is that the token often inherits the app’s full scopes, so one compromise can expose multiple tenants, large data sets, and downstream systems before revocation happens.

Q: Why do OAuth-connected integrations increase NHI risk?

A: OAuth-connected integrations increase NHI risk because they behave like machine identities with persistent authority and long-lived credentials. If teams do not govern scope, rotation, and offboarding, a single token can outlive the business need that created it. That creates a standing access path that is easy to forget and hard to detect.

Q: How can security teams detect token abuse in SaaS platforms?

A: Look for abnormal API sequences rather than login failures. Sudden object enumeration, repeated count queries, bulk export jobs, geographic drift, and cleanup actions such as job deletion are strong indicators. Detection improves when token issuance, validation, and data-access logs are joined into one investigation view.

Q: Who is accountable when a third-party integration exposes customer data?

A: Accountability is shared, but operational ownership must be explicit. The SaaS owner is responsible for governing the connected app inside its tenant, while the integration owner must manage scopes, tokens, and offboarding across every platform touched. If neither side owns lifecycle controls, the integration becomes a persistent identity gap.

Technical breakdown

How stolen OAuth tokens become a reusable identity path

OAuth bearer tokens act as proof of authorization, so anyone holding the token can act as the connected app until expiry or revocation. If a refresh token is also stolen, the attacker can mint new access tokens and keep the session alive. In SaaS integrations, the token often inherits the app’s broad scopes, which means the attacker does not need to defeat MFA or steal a user password. The identity boundary has already been crossed through delegated trust.

Practical implication: treat connected app tokens as high-value secrets and monitor their issuance, use, and revocation as one lifecycle.

Why Salesforce data exfiltration blended into normal API activity

The activity described in the article used describe calls, SELECT COUNT() queries, and Bulk API 2.0 exports, which are all legitimate platform behaviours. The problem is scale and sequence. Repeated object enumeration, sudden query bursts, and job deletion after export create a pattern that is easy to miss if monitoring focuses only on authentication events. Without correlation across Event Monitoring, UniqueQuery logs, and API telemetry, the attack looks like routine integration traffic.

Practical implication: baseline per-app API behaviour and alert on query volume, object fan-out, and post-export job deletion.

Why connected-app trust must include offboarding and scope reduction

A connected app is not just an integration. It is a non-human identity with its own access path, own secrets, and own ownership model. If the app keeps broad scopes, long-lived tokens, and weak session controls, it behaves like standing privilege in machine form. That creates an identity blast radius across every tenant the app can reach, especially when free-text fields and support cases also contain secrets that can be exfiltrated.

Practical implication: inventory each connected app, narrow its scopes, and revoke access everywhere the app touches when the relationship changes.

Threat narrative

Attacker objective: The attacker’s objective was to quietly harvest high-volume customer data from trusted SaaS tenants while hiding activity inside normal integration traffic.

1. Entry occurred when stolen OAuth bearer and refresh tokens from the Drift connected app were reused from attacker infrastructure against customer Salesforce tenants.
2. Escalation followed as the actor enumerated tenant objects, measured scope with SELECT COUNT() calls, and used the Bulk API to export large datasets at scale.
3. Impact came from Salesforce case and contact data exposure, token discovery in exfiltrated text, and deliberate job deletion that reduced visibility into the theft.

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

Connected apps are non-human identities, not background plumbing: This incident shows that a trusted integration can become the primary identity path into customer data when tokens are stolen. Once the app’s bearer tokens were reused, Salesforce controls were acting on a valid identity, not an obvious intrusion. The implication is that IAM teams must govern connected apps with the same seriousness they apply to service accounts and privileged human accounts.

Token replay creates identity blast radius, not just access risk: Long-lived OAuth credentials inherit the scopes of the integration that minted them, so compromise of one token can expose many tenants and data sets. That is why this was a governance failure as much as a security event. Practitioners should think in terms of where the token can move, what data it can enumerate, and how quickly it can be revoked.

Identity blast radius: The article exposes a useful term for this class of event. The blast radius is not defined by the breached app alone, but by every platform and tenant that accepts its token as proof of trust. That matters for NHI governance because offboarding, rotation, and scope review all have to work across systems, not only within one SaaS console.

Known app identity can mask hostile behaviour: Monitoring that trusts the client identity too much will miss the sequence of enumeration, extraction, and cleanup that follows token theft. Cloudflare’s timeline shows the attacker using normal platform functions in abnormal sequence and volume. The lesson for identity security programmes is to correlate token lifecycle signals with data-access behaviour, not to rely on authentication events alone.

Lifecycle ownership for connected apps is the control gap this breach exposes: The Drift connection acted like a standing third-party identity with too much persistence and too little visibility. That is a classic NHI governance gap, but one that now affects SaaS, CRM, and collaboration estates at once. Security teams need ownership, scope, and revocation paths that follow the identity wherever it is used.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• The 52 NHI breaches Report shows how recurring credential exposure patterns continue to drive real-world incidents.

What this signals

Connected-app governance is now a core IAM problem, not a niche integration issue: The next phase of SaaS security will be measured by how well organisations can see, own, and revoke machine identities that sit outside traditional user lifecycle tooling. That means treating OAuth clients, refresh tokens, and service integrations as part of the identity plane, not a side effect of application onboarding.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the broader lesson from this incident is that hidden credentials remain the easiest route into trusted systems. The operational response is to connect secret hygiene, token lifecycle, and API telemetry in one control model.

Identity blast radius: As connected apps spread across CRM, collaboration, and cloud services, the practical question becomes how far a token can travel before it is revoked. Teams that can map token authority across platforms will detect abuse earlier and limit downstream exposure faster than those that only watch sign-in events.

For practitioners

• Inventory every connected app as an identity Create a register of connected apps, OAuth clients, and refresh-token holders across CRM, collaboration, and cloud platforms. Include business owner, technical owner, scopes, token lifetime, and where the app can act on behalf of a tenant.
• Correlate token issuance with data-access behaviour Join OAuth server logs, API access logs, and SaaS event logs so you can see first use, geo drift, burst queries, and job deletion in one timeline. Alert when a token’s behaviour diverges from its normal integration pattern.
• Reduce scopes before you need revocation Replace broad connected-app permissions with narrow platform-specific scopes, enforce IP restrictions where possible, and shorten token lifetime so compromise does not inherit standing privilege across tenants.
• Treat case text and support notes as secret-bearing Search exfiltrated support content, ticket bodies, and case fields for embedded API keys, passwords, and tokens. Rotate anything found and assume attackers will target free text as readily as structured secret stores.
• Offboard integrations across every platform they touch Disconnect the app, revoke tokens in each SaaS, and verify that downstream mailboxes, case systems, and cloud services no longer accept the integration’s credentials. Offboarding is incomplete until every accepting system has been checked.

Key takeaways

• This breach shows that a trusted connected app can become the shortest route to large-scale SaaS data exposure when OAuth tokens are stolen.
• The scale matters because API-driven enumeration and bulk export can look like routine integration traffic unless teams correlate token activity with data movement.
• The limiting control is lifecycle governance for connected apps, including scope reduction, token revocation, and offboarding across every platform the integration touches.

Key terms

• OAuth Bearer Token: A bearer token is a credential that grants access to a resource without needing a password at the point of use. In practice, whoever holds it can act as the connected identity until the token expires or is revoked, which makes theft of the token itself the security failure.
• Connected App: A connected app is a third-party integration that authenticates to a platform and acts with delegated permissions. For identity governance, it should be treated as a non-human identity with an owner, scope, lifecycle, and revocation process, not as a simple technical link between systems.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems exposed when one identity is compromised. For non-human identities, the blast radius is often defined by token scope, platform reach, and how quickly the identity can be revoked across every system it touches.
• Bulk API Exfiltration: Bulk API exfiltration is the use of legitimate high-volume export interfaces to remove data at scale. It is hard to detect when monitoring only watches for failed logins, because the activity often looks like ordinary integration traffic until query volume, job timing, or cleanup behaviour becomes abnormal.

What's in the full article

CYATA's full analysis covers the operational detail this post intentionally leaves for the source:

• Cloudflare’s incident timeline and the sequence of SOQL, Bulk API, and cleanup actions used by the actor.
• Google Threat Intelligence guidance on token abuse patterns, affected integrations, and connected-app indicators of compromise.
• Salesforce and Google response actions, including token revocation and integration disablement details.
• Per-tenant exposure context and the customer disclosure pattern seen across the affected organisations.

👉 CYATA’s full post covers the Salesforce attack chain, exposed data, and response actions in detail

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 building or maturing an IAM programme, it is worth exploring.