OAuth Gone Rogue: Lessons from the Salesforce Drift Breach

Most breach post-mortems eventually arrive at a vulnerability, a misconfiguration, or a phished credential. The Salesloft Drift incident arrived at something more uncomfortable: nothing was broken. The attacker used a legitimate integration, authenticating with a legitimate token, running legitimate API queries against a platform that behaved exactly as designed.

No core vulnerability was identified in the Salesforce platform itself. The trust relationship between two SaaS applications was the attack surface, and that trust had been granted deliberately by hundreds of organizations who had every reason to think they were doing something routine.

Between 9 and 17 August 2025, an intrusion cluster tracked as UNC6395 used stolen OAuth tokens from Salesloft's Drift chatbot integration to reach hundreds of Salesforce environments, systematically exporting records from more than 700 organizations including Cloudflare, Palo Alto Networks, Proofpoint, Tanium, and Zscaler.

This post breaks down how the attack worked, why the standard identity controls provided no protection, and what a defensible approach to third-party SaaS integration actually looks like.

What Happened in the Drift Breach

The mechanics matter, because they generalize well beyond this specific integration.

The Integration Was the Path

Drift is a conversational marketing platform that connects to Salesforce to sync chat conversations, leads, and cases into the CRM. Making that work requires the integration to hold persistent, broad access to Salesforce objects.

UNC6395 compromised Salesloft through the Salesloft and Drift integration, then pivoted through that trusted connection to reach Salesforce data. The customer organizations were not individually targeted or individually compromised. They were reached through an integration each had authorized.

Tokens Bypassed Authentication Entirely

This is the detail that should reshape how organizations think about identity controls. Using the stolen OAuth credentials, the threat actor bypassed normal authentication including MFA, and exfiltrated large volumes of Salesforce data from hundreds of organizations.

Multi-factor authentication protects the moment a user logs in. An OAuth token represents access that was already granted, so there is no login to protect. Every organization affected could have had phishing-resistant authentication perfectly deployed across every human account and the outcome would have been identical.

Unlike user sessions, OAuth tokens frequently do not expire, which creates long-term exposure once one is compromised. A token issued two years ago and never rotated is a permanent credential nobody is tracking.

The Activity Looked Like Normal API Use

The intrusion ran through Salesforce APIs, with the adversary using automated SOQL queries, bulk exports, and custom user-agent strings to appear legitimate.

There is no malicious binary here, no unusual network path, and no endpoint involvement of any kind. An integration that routinely queries Salesforce objects at volume queried Salesforce objects at volume. Distinguishing that from an attack requires knowing what normal looks like for that specific integration, which almost nobody had baselined.

The Objective Was Credentials, Not the CRM Data

Stolen records were searched for plaintext AWS keys, VPN credentials, Snowflake tokens, and other secrets that could enable follow-on compromise.

Support cases turn out to be an excellent place to find secrets. Customers paste access keys into tickets when troubleshooting. Engineers include connection strings in case notes. Screenshots contain tokens. None of this is intentional, and all of it accumulates in a system most organizations classify as low sensitivity.

Anti-Forensics Slowed Detection

The attackers deleted Salesforce query job records after exporting data to obscure their activity. Organizations relying solely on the platform's own visibility to reconstruct events found that visibility had been degraded from inside.

Containment and Scope

Salesforce and Salesloft responded on 20 August 2025 by revoking all Drift tokens, and Google Threat Intelligence Group subsequently published a detailed report identifying the actor and indicators of compromise.

Later investigation established that the exposure extended beyond Salesforce, with stolen tokens permitting access to other platforms integrated through Salesloft. The blast radius of a compromised integration provider is every connection that provider holds.

Why This Class of Attack Keeps Working

The Drift incident is a specific case of a structural problem.

OAuth Grants Are Approved Once and Never Reviewed

Connecting an application involves a consent screen listing requested permissions, approved in seconds by someone trying to complete a task. That grant then persists indefinitely. Nobody revisits it, nobody notices when the application's ownership changes, and nobody removes it when the team that requested it stops using the tool.

Most organizations cannot produce a list of which applications hold access to their SaaS tenants, what scopes each was granted, and who approved them.

Permissions Are Almost Always Broader Than Needed

Integrations request the scopes that make every feature work, not the minimum for the features you use. An application needing to write chat transcripts into leads may request read access across accounts, contacts, cases, and users, because that is what the vendor's broadest configuration requires.

The customer approves the whole set because the alternative is the integration not working, and there is often no mechanism to grant a subset.

Tokens Are Machine Identities With No Governance

An OAuth token is a machine credential. It holds broad permissions, it does not rotate, it has no second factor, and its behavior is rarely baselined. It sits in exactly the governance gap that non-human identities occupy in most programs, which is to say almost entirely outside it.

The Vendor's Security Becomes Your Security

Your Salesforce tenant was as exposed as your integration provider's token storage. That is a genuine transfer of risk to a third party whose controls you cannot inspect and whose incident detection you cannot influence.

Organizations that want to know which third-party applications currently hold access to their SaaS environments, and what those applications could reach, can establish that inventory with FoxRadar360 before assuming the answer is a short list.

Consent Phishing Is the Same Attack Without the Vendor Breach

Worth noting alongside this incident: a separate cluster tracked as UNC6040 ran a voice phishing campaign that tricked Salesforce users into approving a malicious connected app, often disguised as a data loading tool, to obtain direct access to their environments.

Same outcome, different starting point. Whether the malicious grant arrives through a compromised vendor or a socially engineered administrator, the resulting access looks identical and evades the same controls.

What Would Have Detected It

Nothing in this attack is invisible. It is only invisible to monitoring that was never pointed at SaaS.

Baselines for Integration Behavior

Integrations have narrow, predictable behavior, which makes them excellent candidates for anomaly detection once baselined. Meaningful deviations include query volume far outside the established range, access to object types the integration has never touched, bulk export operations from an application that normally performs incremental syncs, and activity from source infrastructure the integration has not used before.

Mass SOQL queries, excessive OAuth token use, and unusual data exports are precisely the anomalies that behavioral analysis over normalized SaaS logs is meant to surface.

SaaS Audit Logs Treated as Security Telemetry

Most organizations collect endpoint, network, and increasingly cloud control plane telemetry, and stop there. The Salesforce, Google Workspace, and collaboration platform audit logs holding the record of this activity are frequently uncollected.

Nothing in a SIEM means nothing detected. The events existed; they simply were not being read.

Alerting on Authorization Events

New third-party application authorizations, scope expansions on existing grants, and connected app installations are all high-signal events with few benign explanations outside a known change. These deserve alerting rather than periodic review, because the window between a malicious grant and bulk extraction can be short.

Correlating SaaS Activity With Identity

A bulk export becomes far more meaningful alongside the authentication that preceded it, the geography it originated from, and whether a human session was involved at all. In the Drift case, the answer to that last question would have been telling: substantial data movement attributed to an application with no corresponding user activity.

Cross-domain correlation is where SaaS detection becomes genuinely effective, and it is a core part of how FoxRadar360 approaches SaaS coverage rather than treating platform-native alerting as sufficient.

Detection on Secrets in Support Data

Scanning support cases, ticket bodies, and chat transcripts for credential patterns serves two purposes: it removes secrets that make a data exposure far worse, and it identifies the process problems that put them there.

Controls That Reduce Third-Party Integration Risk

Practical measures, roughly in order of value.

Inventory Every OAuth Grant

Start with what exists. For each SaaS platform holding meaningful data, enumerate every connected application, the scopes it holds, who approved it, when, and whether it is still in use.

Expect the list to be longer than anticipated and to include applications nobody recognizes. Grants belonging to tools the organization stopped using years ago are common, and they retain full access.

Restrict Who Can Authorize Applications

Most SaaS platforms allow administrators to require approval before users can grant application access. Enabling that single setting converts an uncontrolled surface into a governed one.

The trade-off is friction, which needs a fast approval path to avoid people seeking workarounds. But an unrestricted consent model means any user with a plausible business reason can hand a third party access to organizational data.

Review Scopes Against Actual Need

Where a platform permits scope limitation, grant the minimum the integration genuinely requires. Where it does not, treat that as a risk factor in the vendor decision itself, and document what the integration could reach if compromised.

Rotate and Expire Tokens

Tokens that never expire are permanent credentials. Where the platform supports token lifetimes, configure them. Where it does not, establish a periodic revocation and reauthorization cycle for high-privilege integrations, accepting the operational cost as the price of bounding exposure.

Tier Vendors by Access, Not by Spend

A small vendor holding a persistent read grant across your CRM presents more risk than a large vendor providing an isolated service. Assess by what the integration can reach: which objects, which data types, whether it can write as well as read, and whether it can create further access.

Concentrate real diligence on the small number at the top rather than distributing questionnaires evenly.

Remove Secrets From Support Channels

The credential harvesting objective in this campaign only worked because plaintext secrets sat in support cases. Establish a process for handling credentials shared during support interactions, scan for them proactively, and rotate anything found.

This is one of the few controls that reduces impact rather than probability, and it is entirely within your control regardless of vendor security.

Prepare a Token Revocation Runbook

When a provider discloses a compromise, the response is time-sensitive: revoke the tokens, disable the integration, review audit logs for the exposure window, identify what data was accessible, and rotate any credentials that may have appeared in it.

Organizations that had this documented moved within hours. Organizations that did not spent the first day working out who owned the integration.

Questions to Ask Before Approving Any Integration

What scopes does it require, and which of those does our use case actually need? If the answer is that everything is required for anything to work, that is a risk to record explicitly.

Does the token expire, and can we control the lifetime? Persistent access with no expiry is a permanent credential.

What visibility do we have into its activity? If the platform does not log integration API calls in a form you can collect, you cannot detect misuse.

Who owns this integration internally? A named person accountable for its continued existence and eventual removal, without which it will outlive its purpose indefinitely.

How does the vendor secure the tokens they hold on our behalf? This is a legitimate diligence question for any integration with broad access.

What is the notification commitment if the vendor is compromised? Speed of disclosure directly determines your exposure window.

What would we do if this integration were compromised tomorrow? If the answer requires improvisation, write the runbook now.

Key Takeaways

The Drift breach is instructive precisely because it did not involve a failure most organizations would recognize as one. No platform vulnerability was exploited, no employee was phished, and no endpoint was compromised. An integration that had been legitimately authorized was used by someone who should not have had it, and the resulting activity looked exactly like the activity everyone expected that integration to perform.

Three lessons follow directly. Multi-factor authentication protects logins, and OAuth tokens are not logins, which means the identity control most organizations rely on most heavily provided nothing here. Third-party integrations are machine identities with broad, non-expiring, ungoverned access, and they belong in the same governance program as service accounts and API keys rather than in a category nobody owns. And SaaS audit logs are security telemetry, because the record of this entire campaign existed in platform logs that most affected organizations were not collecting.

The practical response is unglamorous: inventory every OAuth grant and remove what is unused, restrict who can authorize applications, tier vendors by what they can reach rather than what they cost, baseline integration behavior so bulk extraction stands out, and stop letting plaintext credentials accumulate in support cases where a single data exposure turns into a cascade of compromised cloud accounts.

The organizations that came through this well were not the ones with the strongest authentication. They were the ones who knew which applications held access to their data and would have noticed one of them behaving differently. To review which third-party integrations currently hold access to your SaaS environments and whether unusual activity from one would be detected, start a conversation with the team at FoxRadar360.