Salesforce Drift Supply Chain Breach: OAuth Attack Explained

A threat actor spent months inside Salesloft's development environment before raiding Salesforce data across hundreds of enterprises in ten days. Here is what happened and what defenders should still be doing about it.

Cloudflare, Palo Alto Networks, Zscaler, Proofpoint, PagerDuty — a remarkable slice of the cybersecurity industry found out in September 2025 that their Salesforce data had been quietly extracted weeks earlier. Not through a Salesforce vulnerability. Not through phishing their employees. Through a chatbot integration they had largely forgotten about.

The attack on Salesloft's Drift platform is one of the cleaner case studies in SaaS supply chain risk that we have seen. The mechanics were not especially novel, but the scale was striking, and the sequence — months of patient access before a ten-day exfiltration campaign — is worth understanding carefully if you have OAuth integrations sitting quietly connected to your CRM.

What Drift Was and Why It Had Such Broad Access

Drift was a conversational marketing and sales platform, acquired by Salesloft in 2024. It provided the chat widget on company websites and connected to Salesforce to pull contact data, log interactions, and sync case information. That integration required broad OAuth access to Salesforce — specifically, it was granted permissions that included reading Accounts, Contacts, Opportunities, Cases, and User data.

This is how most SaaS-to-SaaS integrations work. The third-party tool requests a scope, the administrator approves it during setup, and OAuth tokens are issued that allow the tool to authenticate on behalf of the organization. The tokens are typically long-lived. They are often stored in the vendor's own infrastructure. Most security teams do not revisit them after initial provisioning, and few monitor which user agent strings or IP addresses are actually using them day-to-day.

That is the attack surface UNC6395 — also tracked as GRUB1 by Cloudflare's threat intelligence team — chose to target.

The Attack in Three Phases

According to Google Threat Intelligence Group (GTIG), which published a detailed advisory on August 26, 2025, and Mandiant, which conducted the post-incident investigation for Salesloft, the attack unfolded across three distinct phases [1].

The first phase involved Salesloft's GitHub repository. Between March and June 2025, the threat actor gained persistent access to Salesloft's development infrastructure. For roughly three months, UNC6395 maintained this access without detection — studying the codebase, understanding how Drift's integrations were architected, and building the knowledge needed to proceed [2].

The second phase moved from source code access to production infrastructure. In August 2025, the actor pivoted into Drift's AWS cloud environment and located the OAuth tokens that Drift used to authenticate against customer Salesforce instances. Because these tokens represented legitimate Drift service accounts, they bypassed Salesforce's MFA protections entirely — the request looked, from Salesforce's perspective, like an ordinary API call from an authorized integration.

The third phase was execution. Between August 8 and 18, 2025, UNC6395 used Salesforce's Bulk API 2.0 to systematically extract data from over 700 customer Salesforce organizations [3]. The GTIG advisory published the specific SOQL queries the actor ran — simple but effective sweeps of User, Account, Contact, Opportunity, and Case objects. After exfiltrating a given organization's data, they deleted the Bulk API job records to cover the activity. As Cloudflare documented in its post-mortem, logs were not impacted by the deletion, which is why forensic reconstruction was still possible.

Cloudflare's own investigation showed the actor spent days on reconnaissance before pulling data — enumerating objects, checking record counts, confirming they were in a production environment, querying API limits. They returned for a final count on August 16 and ran the actual exfiltration on August 17, completing the job in roughly four minutes using a fresh IP address before attempting to clean up [2].

What Was Taken

GTIG's assessment is that UNC6395's primary goal was credential harvesting, not just data collection. After pulling contact records and case histories, the actor searched the exfiltrated material specifically for secrets — AWS access keys (identifiable by the AKIA prefix), Snowflake credentials, passwords, and API tokens that customers had pasted into support tickets [1].

Support cases are a particularly dangerous category of data to lose. When customers open support tickets, they often paste configuration files, error outputs, API responses, and logs — content that frequently contains active credentials. Cloudflare's post-mortem confirmed exactly this: their investigation found 104 Cloudflare-issued API tokens embedded in case text, all of which were rotated as a precaution. No suspicious activity was observed against those tokens, but the risk was real [2].

Aside from credentials, the typical data package from each organization included business contact records — names, titles, email addresses, phone numbers — along with Salesforce Account, Contact, Opportunity, and Case objects. None of the confirmed disclosures mentioned file attachments being taken; the Bulk API queries were limited to text fields.

Who Was Affected

FINRA confirmed the breach affected more than 700 organizations [3]. Among the publicly confirmed victims — security companies prominent enough to be uncomfortable to name in this context:

Table of publicly confirmed affected organizations based on Cloudflare, GTIG, and SecureWorld reporting. Not exhaustive.

The irony is hard to miss. Some of the most security-conscious organizations in the industry got caught here — not because their own defenses failed, but because a chatbot integration they approved had a token stored in someone else's AWS environment.

The Vulnerability Was Not in Salesforce

This is worth stating clearly because it shaped how organizations responded. Salesforce itself was not compromised. The attack did not exploit a Salesforce vulnerability. GTIG's advisory explicitly noted this: the issue stemmed from compromised connections between the Drift application and Salesforce, not from the Salesforce platform [1].

This is an important distinction for organizations trying to understand their risk surface. If you are monitoring Salesforce login anomalies, blocking unusual IP ranges at the Salesforce perimeter, or reviewing Salesforce security settings — those controls would not have caught this. The activity looked legitimate to Salesforce because it was using legitimate, issued tokens.

The actual attack surface was the OAuth integration layer itself: a vendor stored long-lived tokens in their own infrastructure with insufficient protection, and that vendor's development environment was itself breached months before the tokens were used.

Organizations with zero trust architecture in mind for their internal environments often have very little zero trust applied to their vendor integration stack. This incident is a concrete demonstration of why that gap matters.

The Follow-On: Gainsight, November 2025

The Drift incident did not trigger an industry-wide review of SaaS integration risk that actually stuck. Two months later, FINRA issued a second cybersecurity alert describing a related incident involving Gainsight, a customer success platform with similar Salesforce connectivity.

ShinyHunters — a financially motivated threat group with ties to Scattered Spider — claimed to have used compromised Gainsight tokens to access data from hundreds of organizations. Salesforce confirmed unauthorized access to sensitive customer data occurred between October 23 and November 19, 2025 [4].

FINRA's Gainsight alert explicitly referenced the Drift campaign and noted that the same user agent strings — python-requests, python/3.11 aiohttp, Salesforce-Multi-Org-Fetcher/1.0 — appeared in both incidents. The exfiltration methodology was nearly identical. The pattern was consistent enough that defenders who had implemented controls after Drift had detection opportunities they might have missed in August.

Two large-scale SaaS supply chain attacks against Salesforce-connected applications within roughly three months of each other — through different vendors, possibly different threat actors — makes a strong argument that the attack surface was well understood by adversaries well before defenders began paying serious attention to it.

What Defenders Should Do

The GTIG advisory, Cloudflare's post-mortem, and FINRA's alerts converge on similar recommendations. Most are straightforward but require deliberate process changes to implement [1] [2].

The most immediate action for any organization that used Drift before August 20, 2025 is token rotation — not just for Drift, but for any credential that may have appeared in Salesforce support case text. GTIG specifically called out AWS access keys (look for the AKIA prefix pattern), Snowflake credentials, and any string matching password, secret, or key within case objects [1].

Beyond the immediate Drift response, the structural changes that would have reduced exposure are well-established: enforce least-privilege OAuth scopes rather than granting full access during integration setup; configure Salesforce Session Settings to enforce shorter token lifetimes; apply IP restrictions to connected app profiles so Salesforce API access is limited to known vendor IP ranges; enable Event Monitoring and alert on unusual user agent strings or bulk data export activity.

Detection-side: the specific user agents UNC6395 used — Salesforce-Multi-Org-Fetcher/1.0, Salesforce-CLI/1.0, and Python-based agents — appeared in both the Drift and Gainsight campaigns. Organizations that built detection for those strings after August would have had visibility into the November incident. A good vulnerability management process includes monitoring these IOC updates from regulatory bodies and threat intelligence teams when initial incidents are disclosed.

The vendor side is harder to fix quickly but more important in the long run. Organizations need to ask the questions that most procurement processes skip: how does this vendor store the OAuth tokens we issue them? Are those tokens encrypted at rest? Who within their organization can access them? Is their development infrastructure isolated from production credential storage? The Drift breach began with GitHub access — a development-side compromise that eventually reached production OAuth tokens. That is a control failure on Salesloft's side, but it is the kind of failure that a thorough vendor security review can surface as a risk before it becomes an incident.

If you are thinking about broader identity and access posture in this context, the relationship between phishing-resistant MFA and conditional access is relevant here too — not because MFA would have stopped this specific attack, but because the OAuth token pattern used here is similar to the AiTM and device code flow attacks that have targeted cloud identity environments. The trust boundaries are analogous.

What This Incident Actually Demonstrated

There is a tendency, after large supply chain incidents, to describe them as fundamentally new. This one was not. OAuth token abuse as a supply chain vector was already a known pattern. Third-party integrations with broad CRM access were already a known risk category. None of the technical mechanisms were novel.

What the Drift breach demonstrated, more precisely, was how far that known risk had gone unaddressed in practice. Organizations with mature security programs — including some of the companies that make security products — had approved a third-party chatbot integration with Bulk API access to their entire Salesforce estate and then effectively forgotten about it. The token sat there, in Salesloft's AWS environment, for months after the actor had access to the GitHub repository that explained what it could do.

The Gainsight follow-on two months later reinforced the point. Different vendor, different actor, same attack pattern. The security industry's response to the Drift breach — while thorough at the individual organization level — did not result in industry-wide remediation of the broader SaaS integration risk surface quickly enough to prevent a nearly identical incident at scale.

That is the defender takeaway here. Not that Salesforce or Drift specifically are the problem. The problem is the accumulated stack of third-party integrations, each with OAuth tokens issued by vendors whose own security posture you cannot control, sitting in your CRM, your email environment, your HR system, and your data warehouse. Most organizations have not inventoried them. Most have not reviewed their scopes. Most do not monitor for anomalous API usage patterns that would indicate misuse.

The software supply chain attack pattern that has been well-documented in the open-source ecosystem is now playing out in the SaaS integration layer. The organizations that treat third-party SaaS access as a first-class security concern — with the same rigor they apply to code dependencies or vendor hardware — will be better positioned when the next variant arrives.

What Remains Uncertain

The full scope of affected organizations is not public. FINRA's figure of 700-plus is the most authoritative number available, but the complete victim list was not disclosed. It is also not fully clear how much of the exfiltrated credential material was successfully used in follow-on attacks. GTIG assessed that credential harvesting was the primary intent, but confirmed secondary exploitation at scale has not been publicly documented as of the time of writing.

The Gainsight incident attributed to ShinyHunters and the Drift incident attributed to UNC6395/GRUB1 are treated as separate campaigns by FINRA and available reporting. Whether there is any relationship between the two actors or whether either operated with shared tooling remains an open intelligence question.

Sources & References

1. Google Threat Intelligence Group / Mandiant — "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift," August 26, 2025
2. Cloudflare Blog — "The impact of the Salesloft Drift breach on Cloudflare and our customers," September 2, 2025
3. FINRA — "Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack," September 2025
4. FINRA — "Cybersecurity Alert – Salesforce Gainsight Security Incident," late 2025
5. Today's General Counsel — "Supply Chain Attacks Hit Cloudflare, Proofpoint, and Other Major Firms," September 10, 2025