OAuth integrations make their vendors custodians of your credentials
The Salesloft Drift data theft started in a vendor’s environment, not in any customer’s Salesforce org. Approving an integration hands a vendor a standing credential, and most third-party reviews never asked how that credential was kept.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On August 26, 2025, Google’s threat intelligence team published an advisory on a data theft campaign by a group it tracked as UNC6395. Between about August 8 and August 18, the group used OAuth tokens belonging to Salesloft’s Drift chat application to query and export data from many customers’ Salesforce instances. It then searched the stolen records for secrets such as AWS access keys, passwords and Snowflake-related tokens. Salesloft and Salesforce had revoked the Drift tokens on August 20, and Salesforce removed Drift from its AppExchange. On August 28, Google updated the advisory: tokens for the separate Drift Email integration had been used on August 9 to read mail in a very small number of Google Workspace accounts. Google advised customers to treat every token connected to Drift as compromised.
Earlier in this series we argued that application permissions are identities and belong in access reviews. The Drift campaign adds a harder point about where those identities live. No customer’s Salesforce login was phished and no customer’s multifactor control failed. The tokens were taken from the vendor that held them. When a Salesforce administrator approves an integration, the platform issues a refresh token that the vendor stores and uses for as long as the grant stands. The customer keeps the data. The vendor keeps the key. We break the resulting exposure into four parts: where the token is held, what it can reach, what the reachable data is worth to an attacker, and how fast the grant can be cut.
Where the token is held
Third-party risk programs usually assess a SaaS vendor as a data processor. The questionnaire asks where customer data is stored, whether it is encrypted, and which certifications the vendor holds. An integration vendor like Drift may store little customer CRM data at all. What it stores is thousands of standing credentials into its customers’ systems, which is a more valuable asset.
Concentration makes that asset attractive. One vendor holds grants into hundreds of customers, so a single intrusion at the vendor pays out many times. Attackers who once had to phish each target separately can now breach one supplier and inherit its trust relationships wholesale.
Due diligence should therefore establish where OAuth refresh tokens are stored and whether they are encrypted with keys the application tier cannot read in bulk. It should identify which vendor staff and services can retrieve them. It should also cover how the vendor protects its source code repositories and cloud administrator accounts, since either can lead to the token store. A vendor with a SOC 2 report may still answer these poorly, because the report’s scope rarely singles out customer credentials.
The answers should change contract terms. A vendor holding tokens into a bank’s CRM or a health system’s patient engagement platform should commit to notify the customer of suspected token exposure within hours, not the days typical of data breach clauses.
What the token can reach
An OAuth grant carries the permissions of the integration user it is tied to, bounded by the scopes approved at installation. Chat and marketing tools often run under an integration user with broad read access, because a narrowly scoped user breaks features and the vendor’s setup guide asks for more. In this campaign, that breadth let the attackers run export queries against objects the chat tool had no business need to read.
Two controls reduce reach without waiting on the vendor. The first is a dedicated integration user per vendor, with a permission set limited to the objects the integration needs. The second is restricting where the token can be used from. Salesforce and other platforms let administrators limit connected apps or integration users to known IP ranges. A token stolen from a vendor and replayed from attacker infrastructure would then fail. Some vendors cannot support fixed egress addresses, which is itself useful information at procurement.
What the reachable data is worth
The attackers’ main target was not customer lists. Google assessed that the group was primarily harvesting credentials. Support cases, notes and free-text fields in a CRM collect secrets because troubleshooting invites them: a customer pastes an API key, an engineer records a temporary password, a partner shares a connection string. Each one is a door into another system.
For regulated organizations the same fields hold other exposure. A bank’s service cases can contain account numbers and nonpublic personal information covered by the Gramm-Leach-Bliley Act. A health system using a CRM for patient outreach may hold protected health information there, which brings HIPAA breach analysis into scope. Scanning these fields for secrets and regulated data, rotating any credentials found, and adding validation rules that block common key formats shrink the prize. They also shorten breach analysis if a token is stolen later.
How fast the grant can be cut
Salesloft and Salesforce revoked the Drift tokens on August 20, two days after the last activity Google observed. Customers did not make that decision themselves. Many learned the details only from the advisory a week later, and then had to work out whether their own instance had been queried and what the queries returned.
Organizations need their own kill switch. That means knowing, for each platform, how to revoke every grant issued to a given vendor in one action, and who has authority to do it out of hours. It also means having the logs to answer the next question. Salesforce event monitoring that records API queries and report exports is often a paid add-on, and retention can be short. An organization without those logs cannot show regulators or customers what left, so notification decisions default to the worst case.
The trade-off is operational. Revoking an integration breaks a sales or service workflow, and business owners will resist doing it on a vendor’s rumor. Agreeing the trigger in advance, such as any vendor notice of suspected credential exposure, removes that negotiation from the incident.
With hindsight
In early September 2025, Salesloft said its investigation with Mandiant traced the campaign to unauthorized access to its GitHub account between March and June 2025. From there the attackers reached Drift’s AWS environment and obtained customers’ OAuth tokens. Drift was taken offline while the vendor rebuilt. In October 2025 an extortion group calling itself Scattered Lapsus$ Hunters launched a leak site naming dozens of companies whose Salesforce data it claimed to hold. Salesforce said it would not negotiate or pay, and that its platform had not been compromised. In November 2025, Salesforce revoked tokens tied to Gainsight-published apps after detecting suspicious activity, and Google linked that campaign to actors associated with ShinyHunters. Twice in four months, the path into customer CRM data ran through an integration vendor. That pattern supports treating integration vendors as credential custodians in third-party risk reviews.