OAuth integrations make their vendors custodians of your credentials

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.

Most companies expect a data breach to look like someone breaking into their own systems: a phished password, a hacked server. This campaign worked differently. The attackers never had to break into the victims at all. They walked in through a door the victims had opened, on purpose, for a trusted vendor.

Salesforce is a widely used customer relationship management system, or CRM: the database where a company keeps its customer accounts, sales opportunities, support cases and notes. An “instance” is one company’s own copy of it. Drift is a chat tool that companies put on their websites to talk with prospective customers, and it connects to Salesforce so that conversations flow into the sales records automatically.

That connection runs on OAuth, a widely used standard that lets one application act inside another without being given the user’s password. When a Salesforce administrator approves an app like Drift, Salesforce issues a token, a digital pass the app can present again and again to read or write data. It works like a building access card handed to a contractor: no one has to share the master key, but whoever holds the card can come and go.

The attackers had those cards. After exporting records, they searched the stolen data for secrets such as AWS access keys (credentials for Amazon’s cloud services), passwords and Snowflake-related tokens (credentials for a popular data warehouse). They were using one breach to find the keys to the next.

Salesloft and Salesforce had revoked the Drift tokens on August 20, and Salesforce removed Drift from its AppExchange, its marketplace for add-on apps. 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.

The Drift campaign raised a hard point about where application credentials live.

No customer’s Salesforce login was phished and no customer’s multifactor control failed. Multifactor authentication, the extra step of a code or a phone prompt on top of a password, is one of the strongest everyday defenses, and it was simply not in the path. 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.

How OAuth integrations actually work

The mechanics explain why this kind of breach slips past so many controls.

Modern businesses run on software-as-a-service, or SaaS: applications rented over the internet rather than installed on company servers. Salesforce, Google Workspace, Microsoft 365, and countless smaller tools for chat, marketing, scheduling and analytics all fall into this category. These tools are far more useful when they talk to each other, so a chat tool feeds the CRM, a marketing tool reads the CRM, and an analytics tool reads everything.

OAuth is the standard way they connect. The flow goes roughly like this:

1. An administrator at the customer clicks “connect” in the vendor’s app and is sent to Salesforce to approve it.
2. Salesforce shows what the app is asking to do, its “scopes,” such as read and write access to certain data.
3. The administrator approves, and Salesforce gives the vendor two things: a short-lived access token for immediate use, and a long-lived refresh token the vendor can use to get new access tokens whenever it needs them.
4. From then on, the vendor’s systems talk to Salesforce directly, day and night, without any person logging in.

The refresh token is the important one. It does not expire overnight or when an employee leaves. It stands until someone revokes it. It is stored not at the customer but in the vendor’s own systems. The customer’s standing key, in effect, never expires and is kept in the vendor’s office.

This design is sensible. It keeps passwords out of vendors’ hands and lets integrations run unattended. But it moves the security of the customer’s data partly into the vendor’s environment, and most organizations never examine that environment with this in mind.

How integrations pile up inside an organization

Few executives could say how many outside applications hold standing access to their company’s CRM. The honest answer in many organizations is “more than anyone remembers,” and the reason is how these connections get approved.

A marketing manager wants a new tool for scoring leads. A free trial needs a Salesforce connection to be useful, so a Salesforce administrator, often a business analyst inside the sales operations team rather than a security professional, clicks “allow.” The trial becomes a subscription. A year later the marketing manager leaves, the tool falls out of use, and nobody revokes the connection. The vendor still holds a valid refresh token. Multiply that by every team, every trial and every year, and a mid-sized company can easily accumulate dozens of standing grants.

Three features of this pattern matter.

• Approval happens outside security. Connecting an app often requires only an administrator’s click inside the platform. It may never pass through procurement or third-party risk review at all, especially if the tool was free.
• Access is rarely reviewed. Organizations review which people have access to systems. Far fewer review which applications do, how broad that access is, or whether the app is still in use.
• Ownership fades. The person who approved the connection moves on, and with them goes the knowledge of why it exists and what would break if it were cut.

Good practice begins with an inventory: a list of every connected app on each major platform, its owner, its scopes, its integration user and the last time it was used. Most platforms can produce the raw data. The harder work is assigning an accountable owner to each entry and removing the ones nobody claims. In our view, that inventory is the single most useful artifact an organization can produce after reading about Drift, because every other control depends on knowing what is connected.

Where the token is held

Third-party risk programs, the processes organizations use to vet suppliers, 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. The test is whether someone who breaks into the vendor’s main software could pull out every customer’s token at once, or whether the tokens are locked away so that each must be unlocked individually. Diligence should identify which vendor staff and services can retrieve them. It should also cover how the vendor protects its source code repositories (where its software is written and stored) 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. SOC 2 is a widely used independent audit of a service provider’s security controls. It is valuable, but it tests whatever the vendor and auditor agree to test, and that agreement rarely includes “how do you protect the keys your customers have given you?”

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. An integration user is a Salesforce account created for software rather than for a person. 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.

• A dedicated integration user per vendor, with a permission set limited to the objects the integration needs. A chat tool that only needs to create leads should not be able to read every support case.
• Restricting where the token can be used from. Salesforce and other platforms let administrators limit connected apps or integration users to known IP ranges, the internet addresses a vendor’s systems use. A token stolen from a vendor and replayed from attacker infrastructure would then fail.

Some vendors cannot support fixed egress addresses, meaning they cannot promise their traffic will come from a known set of internet addresses. That 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 (the details a program uses to log into a database). Each one is a door into another system.

The most valuable thing in a CRM may not be customer data at all. It may be the passwords and keys that busy people typed into a comment box because it was the quickest way to fix a problem.

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, the federal law governing how financial institutions protect customer information. 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 (replacing them with new ones so the old ones stop working), 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.

A regional bank’s Friday evening

Suppose a regional bank uses Salesforce for commercial customer relationships and has connected a website chat tool and two marketing tools to it.

On a Friday evening, the chat vendor emails customers: it is investigating suspected unauthorized access to its environment. Consider two versions of what happens next.

In the first version, the bank’s CISO finds that nobody is sure how to revoke the chat tool’s access, or whether doing so would break the sales team’s lead routing. The head of sales, reached by phone, asks to wait until Monday for more details. The integration user turns out to have read access to every object, including commercial service cases where relationship managers sometimes paste account details. The bank never bought the logging add-on. By Monday, it cannot say whether anything was read, and counsel advises treating every record as potentially exposed.

In the second version, the bank has a one-page runbook. Any vendor notice of suspected credential exposure triggers revocation, a rule the head of sales agreed to months earlier. An on-call administrator revokes all of the vendor’s grants in minutes. The integration user could only create leads and read a handful of fields. Access was restricted to the vendor’s published IP ranges. Free-text fields were scanned last quarter, and the few passwords found were rotated. Query logs show what the integration did over the past weeks. By Monday, the bank can tell its board and regulators, with evidence, what was and was not reachable.

Both banks faced the same vendor and the same incident. What separated them was preparation, and almost none of it required the vendor’s cooperation.

What sits behind a standing key

Risk concentration. Every integration is a standing key held by someone else. The more integrations, the more key-holders, and each is a possible route in that bypasses the customer’s own defenses.

Regulatory exposure. Banks and health systems must analyze and often report breaches of regulated data. Without logs, they must assume the worst, which can mean broader notifications, higher costs and harder conversations with examiners.

Business disruption. Cutting an integration hurts. Deciding in advance turns a painful debate into a routine step.

Reputation and customer trust. Customers rarely distinguish between “our systems were breached” and “a vendor connected to our systems was breached.” If their information leaves, it left from the company they trusted with it. The explanation that a third party held the key may be accurate, but it is not reassuring, and it invites the obvious follow-up question of why that third party held so much access in the first place.

Downstream breaches. Because the attackers were hunting for credentials, a CRM breach can become the first step in a cloud or data warehouse breach elsewhere. The cost of a single exposed access key in a support note can far exceed the cost of the CRM data around it.

The organizations caught out by campaigns like this tend to have made the same choices. They vetted integration vendors only as data processors and never asked about token custody. They accepted the vendor setup guide’s request for broad access without question. They let secrets accumulate in CRM notes and support cases, did not license or retain the logs needed to show what an integration read, and left the revocation decision to be negotiated in the middle of an incident.

Inventory, scope, revocation and logs before the next vendor notice

• How many third-party apps hold standing access to our CRM, email and file systems, and who approved each one?
• For our most connected vendors, where are our tokens stored, and could one intrusion at the vendor expose all of them at once?
• Does each integration have its own account, limited to the data it actually needs and, where possible, to the vendor’s known internet addresses?
• If a vendor told us tonight that its environment was breached, who would revoke its access, how quickly, and have business owners agreed the trigger in advance?
• Do we have, and retain, logs showing what each integration queried and exported?

With hindsight

In September 2025, Salesloft said its investigation with Mandiant, an incident response firm, traced the campaign to access to its GitHub account, with reconnaissance between March and June 2025. GitHub is where many software companies store their source code. From there the attackers reached Drift’s AWS environment and obtained customers’ OAuth tokens. Drift was taken offline while the vendor rebuilt.

The attackers spent months inside the vendor before stealing data from its customers, and the path ran from a code repository to a cloud account to the token store, exactly the chain that typical vendor questionnaires do not cover. No customer could have seen it from its own systems.

In early October 2025, responding to extortion attempts against its customers, Salesforce said the attempts related to past or unsubstantiated incidents and that there was no indication its platform had been compromised. That distinction matters: the platform held, and the exposure came through connected apps that customers had approved.

In November 2025, Salesforce revoked active access for Gainsight’s connected apps while it investigated, and Gainsight’s own status page tracked the restoration into early 2026. Within four months, a second integration vendor’s standing access into customers’ Salesforce data had to be cut.

That pattern supports treating integration vendors as credential custodians in third-party risk reviews. Every app connected to a core business system is a standing key held outside your walls. Knowing who holds those keys, limiting what each one opens, keeping the evidence of what was opened, and being able to change the locks quickly are now basic disciplines, not advanced ones. The cost of each is modest compared with a weekend spent unable to say what left.