Salesloft / Drift, OAuth at supply-chain scale.

Summary

The Salesloft/Drift incident is the clearest large-scale demonstration to date of OAuth supply-chain risk: when an upstream SaaS vendor holds OAuth refresh tokens granting broad access to downstream customers' other SaaS environments, compromise of that vendor cascades into every customer that authorised the integration. The population of impact was determined not by the attacker's choices but by who had ever installed the Drift→Salesforce integration.

The event was significant not because the primitive (OAuth token theft) was new, but because of its reach. Seven hundred downstream organisations, each independently breached, from a single upstream compromise is a new scale for the category. The industry response, including Salesforce's subsequent tightening of OAuth-app governance and vendor-side improvements to token-theft detection, has already produced policy changes that outlast the incident itself.

Timeline (reconstructed from public reporting)

Precise dates and sequence vary across public reporting; the above is our editorial reconstruction and not a definitive timeline.

Attack chain

1. Initial access to Drift. Details not fully public. Credible reporting suggests identity-based compromise via a third-party identity or SaaS path, the specifics matter less to the downstream story than the outcome: the attacker obtained access to Drift's production environment containing customer OAuth refresh tokens.
2. Token extraction. The attacker located and extracted the OAuth refresh tokens Drift held on behalf of its customers for Salesforce and similar SaaS integrations. These are the NHI credentials at the heart of the incident.
3. Downstream authentication. Using each extracted refresh token, the attacker obtained fresh Salesforce access tokens and authenticated to each downstream customer's Salesforce tenant.
4. Reconnaissance and extraction. Automated querying across tenants, looking for high-value records, case data, account records, customer credentials stored in CRM notes, and (in several reported cases) data suggesting further identity credentials available for harvesting.
5. Persistence attempts. In some victim environments, the attacker created additional OAuth apps or followed credentials discovered in the CRM data into other SaaS systems.

NHI root cause analysis

Three OWASP NHI Top 10 risks converge in this incident:

• NHI3, Vulnerable third-party NHI. The primary failure mode. Each downstream customer had authorised Drift to hold an OAuth refresh token with broad Salesforce access. When Drift was compromised, those tokens became attacker assets. None of the downstream customers had compromised their own environments.
• NHI5, Overprivileged NHI. In many customer environments, the Drift OAuth scope granted was broader than the Drift use case required, for example, read access to account records and case data that Drift did not operationally need. This amplified the data-exposure radius.
• NHI7, Long-lived secrets. OAuth refresh tokens typically have long lifetimes (months to years by default). A rotation discipline enforced by either Salesforce's OAuth implementation or customer-side OAuth-app governance would have limited attacker dwell.

Below these three, a governance failure: most customer organisations had no periodic review of their OAuth-connected applications and no inventory of the scopes those applications held. The integrations were installed once, approved, and forgotten. Some had been live for years.

Confirmed victim organisations (selected)

Companies that publicly acknowledged impact in their own disclosures or through media reports:

• Cloudflare
• Google
• Tanium
• Zscaler
• Palo Alto Networks
• Qualys
• Cato Networks
• Multiple additional large enterprises across finance, tech, and manufacturing

The list is non-exhaustive. Total organisations impacted has been reported in the range of 700+, with Mandiant's UNC6395 attribution tracking engagement across a broader population.

Detection story

Detection was primarily customer-side. Cloudflare's public post-mortem, one of the clearer and faster disclosures, described the detection originating with SOC analysts noticing anomalous Salesforce query patterns: specifically, large volumes of record-enumeration queries from an OAuth app that historically issued only modest, targeted read operations.

The pattern that repeated across multiple victim SOCs:

• Behavioural baselines on SaaS API usage per OAuth app
• Alert on substantial deviation from baseline
• Rapid cross-reference with Salesforce's OAuth-app authentication logs
• Token revocation as immediate containment

Impact assessment

• Data exposure: customer CRM data, account details, contact information, case history, custom fields. In some cases, credentials embedded in case notes were further weaponised.
• Operational disruption: emergency token revocations and integration outages across hundreds of organisations.
• Secondary exposures: in cases where CRM records contained references to other credentials (API keys in support cases, passwords in customer communications), the initial Salesforce breach cascaded further.
• Regulatory: multiple jurisdictions' data-protection authorities have initiated inquiries. GDPR notifications were made by EU-based victim organisations. US state-level disclosures (including to attorneys general) have occurred.
• Market: Drift usage declined significantly post-incident; Salesloft's commercial position was impacted; Salesforce tightened its OAuth-app review and revocation processes.

Mitigation playbook, what to do if you were impacted

1. Revoke all Drift OAuth tokens, Salesforce will have done this; verify in the Salesforce Connected Apps console.
2. Pull Salesforce login and API-call history for the Drift OAuth app for the full attack window. Look for enumeration patterns, queries outside operational hours, IP addresses unusual for Drift.
3. Identify data that was accessible. Map the Drift OAuth scope to specific Salesforce objects and fields. Any field reachable via those scopes is candidate-exposed.
4. Audit CRM content for secondary credentials. Search case notes, custom text fields, and attachments for password/token/key patterns. Rotate any credentials found.
5. Notify appropriately. GDPR Article 33/34, state AG notifications, customer notifications as applicable. Qualified counsel decisions.
6. Review all other OAuth integrations. This is the opportunity to establish the governance cycle you should have had all along, inventory, scope review, rotation cadence, revocation of unused apps.

Lessons that transfer to every organisation

• OAuth apps are NHIs. Treat them with the same rigour as service accounts. Inventory. Owner. Scope review. Rotation.
• OAuth scopes should be minimum-viable. Do not grant "read all" when "read a specific object" would suffice. Most SaaS platforms support granular scopes; few organisations use them.
• Supplier OAuth-token hygiene is your problem. You cannot assume your SaaS suppliers rotate their stored refresh tokens. Contractually, you can push for improvements; operationally, you can rotate on your schedule.
• SSPM tooling helps. SaaS security posture management (Astrix, AppOmni, Obsidian, Adaptive Shield) provides the cross-SaaS OAuth inventory and anomaly baseline that makes detection faster.
• Behavioural baselines work. The SOC teams that detected this fastest had app-level baselines on SaaS API usage. Those that did not, detected later.
• Regulator expectations are tightening. NIS2 and DORA both create explicit third-party ICT risk expectations that cover this incident shape. Your OAuth-integration governance is now compliance-relevant, not just good practice.

Primary sources

• Mandiant / Google Threat Intelligence UNC6395 tracking and TTPs
• Cloudflare public post-mortem
• Google, Tanium, Zscaler, Palo Alto Networks individual disclosures
• Salesloft / Drift customer communications
• Salesforce security advisories related to Drift OAuth app revocation
• CISA alerts and advisories published during and after the incident window

Frequently asked questions

What was the Salesloft Drift OAuth breach?

OAuth tokens associated with the Drift integration were compromised and used to access data in connected systems belonging to downstream organisations. The integration itself was legitimate and had been authorised by each customer; the compromise occurred at the integration provider. It is the clearest recent example of third-party non-human identity risk, where the customer's own controls were not the failure point.

Why do OAuth integrations create non-human identity risk?

Because they create a durable, broadly scoped credential held outside your organisation, usually granted once by a business user and never reviewed. The grant has no expiry by default, no named owner in your inventory, and permissions that reflect what the vendor asked for rather than what the integration needs. When the vendor is compromised, that grant is the attacker's access path and you have no visibility into its use.

How do you find third-party OAuth grants in your environment?

Through the admin consoles of the SaaS platforms themselves rather than through your identity provider. Each major platform exposes a list of authorised applications with their granted scopes. This is rarely in a security team's inventory because the grants are created by business users through consent screens rather than by IT through provisioning.

What is the right control for third-party integrations?

Restrict who can authorise them, review granted scopes against actual need rather than vendor request, register each as a non-human identity with an owner and review date, and rehearse revocation so that removing an integration under pressure is a known procedure rather than an improvisation. Scope reduction is the highest-value control, because it bounds the blast radius of a compromise you cannot prevent.