The Salesloft Drift breach: how stolen OAuth tokens exposed Salesforce data.

In August 2025, attackers used stolen Salesloft Drift OAuth tokens to access Salesforce customer data. The incident shows how a compromised SaaS integration can expose data through existing permissions, and why credentials embedded in exported records can extend the risk.

Google Threat Intelligence Group tracks the actor as UNC6395. Its investigation describes stolen tokens used for bulk data theft and searches of exported records for credentials, including AWS keys and Snowflake tokens.

What happened

Drift connects to Salesforce through OAuth. Each grant authorises access within its assigned permissions and token lifecycle. Google’s investigation describes bulk SOQL exports using stolen tokens and searches for high-value secrets in the resulting data.

There was no exotic exploit. The token did exactly what it was authorized to do. The failure was that nobody had asked the second question: if this one token is compromised, what does it reach?

Trust you never granted

OAuth creates delegated access: a SaaS integration can act within the permissions granted to it. A stolen usable token can let an attacker exercise those permissions without repeating an interactive login. Inventory integrations, examine their scopes and understand which records each grant exposes.

A password is something you can rotate. A forgotten OAuth grant is a door you don’t remember installing.

This is the same failure mode as the Railway agent incident, an over-privileged non-human identity reaching a target no one reviewed, just expressed through SaaS instead of infrastructure.

Anatomy of the path

drift-oauth-token     # stolen; scoped to read/query Salesforce
  → salesforce-org     # access depends on each stolen token’s scope
  → SOQL bulk export   # pull everything the token can see
  → embedded-secrets     # AWS keys, Snowflake tokens in the data
  → downstream-systems   # the next environment entirely

From exported records to further credentials

The investigation supports an escalation pattern: steal integration tokens, export accessible records, then search those records for more credentials. Each additional credential needs its own scope and activity review. A shared OAuth technique does not by itself prove that separate incidents form one causal chain.

The first 48 hours after an integration breach

When a SaaS integration is named in an incident, the instinct is to revoke its tokens and move on. Revocation closes the door that was used. It does nothing about the records that already left, and it is those records that carry the next set of credentials.

1. Revoke and re-issue the named integration first. In Salesforce that means the connected app, not the person who installed it. Check whether a second grant exists under a different admin account.
2. Pull the API access log for the token window. The question is not whether the token was used, but which objects it queried and how many rows came back. A bulk export looks nothing like normal integration traffic.
3. Search the exported objects for secrets, not just the export itself. Free-text fields, case notes and attachment bodies are where cloud keys and warehouse tokens sit. Run the same secret patterns a scanner would run against a repository.
4. Rotate every credential found in those fields, in reach order. Anything that can write to production first, anything that can read customer data second.
5. Review the other integrations holding the same scope. If one marketing tool could export the entire CRM, check which of the remaining grants could do the same thing tomorrow.

Steps three and four are the ones that get skipped, and they are the reason this incident reached past Salesforce at all. A CRM is a credential store that nobody labels as one.

What good looks like

You can’t remove OAuth integrations, they run your business. You can make sure you know what each one reaches, and revoke the ones that reach too far:

1. Discover every OAuth grant and service account. Including the ones an offboarded contractor connected two years ago.
2. Trace where each token reaches, across SaaS, cloud and warehouse, not just its label.
3. Flag transitive trust to sensitive data. A marketing tool that can export your entire CRM is a path, not a feature.
4. Cut and rotate the edge that matters, and offboard NHIs the moment they go idle.

#FAQ

Review the OAuth grants connected to your customer data and the credentials stored inside those records. Elmoz helps teams investigate identity access paths and identify permissions to review.