Salesloft Drift Breach: Stolen OAuth Tokens Hit Hundreds of Firms

Ask a security team to name its third-party risks and you will hear about the CRM, the cloud provider, the payroll system. You are less likely to hear about the marketing chatbot that was bolted onto the website two years ago. The Salesloft Drift campaign of August 2025 is the story of how exactly that kind of overlooked integration became the path into hundreds of companies' most sensitive customer data, and why the OAuth token quietly linking two of your SaaS apps may be the riskiest thing in your portfolio.

No password was phished. No firewall was breached. The attackers simply stole the digital keys that one trusted application had been issued to talk to another, and walked in through the front door of every connection those keys unlocked.

What Happened

Drift is an AI-powered chat and conversational marketing platform owned by Salesloft. Many companies connect Drift to their Salesforce environment so that chatbot conversations flow into the CRM. That connection is authorized with OAuth tokens, long-lived credentials that let Drift access Salesforce data on the customer's behalf without a human logging in each time.

Google Threat Intelligence Group, part of Mandiant, reported that a threat actor it tracks as UNC6395 obtained the OAuth and refresh tokens tied to the Salesloft Drift application and used them to access the Salesforce instances of Drift's customers. With valid tokens in hand, the attacker ran automated queries against Salesforce APIs and bulk-exported data, using custom user-agent strings to blend in with normal traffic. Because the access used legitimate tokens, it did not trigger a password prompt or a multi-factor challenge. It looked like Drift doing its job.

The origin of the tokens, disclosed as the investigation matured, is the part that should worry any TPRM practitioner. The chain did not begin at Salesforce. Investigators traced it to a compromise of Salesloft's GitHub account, with attacker access running from roughly March through June 2025, from which the actor pivoted into Drift's cloud environment and stole the OAuth tokens issued for customers' integrations. In other words, a source-code account at one vendor led to stolen keys at its subsidiary, which led to data theft at the vendor's customers. That is a supply chain three links deep, and the victims had a direct relationship with none of the failure points.

The Real Prize Was Secrets, Not Sales Records

Google's analysts assessed that the primary goal was credential harvesting. After exporting Salesforce data, the actor combed through it for secrets: AWS access keys, Snowflake-related tokens, passwords, and other credentials. The richest hunting ground was support-case text, the free-form fields where customers and support agents routinely paste API keys, connection strings, and other secrets to troubleshoot a problem.

Cloudflare, one of the companies that publicly disclosed impact, offered a concrete example. It found 104 of its own API tokens in the exfiltrated support-case data, rotated all of them, and told customers to treat any token, password, or log shared in a support ticket as compromised. The lesson is uncomfortable and universal: your CRM and support systems are full of other systems' keys, and a breach of the CRM becomes a breach of everything those keys unlock.

A number of well-known security and technology firms confirmed they were affected, including Cloudflare, Palo Alto Networks, Zscaler, Proofpoint, Tenable, PagerDuty, SpyCloud, Tanium, and Bugcrowd. Reporting placed the number of affected organizations in the hundreds, with some coverage citing more than 700, though Google's own advisory described the scope as numerous instances rather than publishing a precise count. The total number of organizations and records was never authoritatively disclosed.

The Blind Spot: SaaS Talking to SaaS

Traditional vendor risk management assesses vendors one at a time. You review Salesforce. You review Salesloft. You may never review the OAuth grant that connects Drift to your Salesforce, because it is not a vendor, it is a setting, often enabled by a marketing team without a security review. That connection is a fourth-party relationship in disguise, the same hidden concentration risk that catches teams who assess only the vendors directly in front of them.

OAuth tokens make the problem worse in three specific ways. They are long-lived, often persisting for months or years until someone revokes them. They carry broad scopes, frequently far more access than the integration actually needs. And they are invisible in most monitoring, because the resulting API traffic looks like the legitimate application doing legitimate work. A single stolen token set enabled bulk export with no password and no MFA, from an account nobody was watching.

This is identity-layer supply chain risk, and it rhymes with earlier lessons. When an identity or authentication vendor is compromised, the blast radius is every downstream system that trusts it, a pattern we traced through the Okta and Lapsus$ incident. Here the trusted party was not a login provider but a marketing chatbot, which is precisely why it slipped past so many review processes.

What TPRM Teams Should Do

The Drift campaign converts a vague worry about integrations into a concrete checklist. Several actions follow directly from how the attack worked.

• Inventory every SaaS-to-SaaS OAuth grant. You cannot govern connections you have not enumerated. Pull the list of authorized third-party apps in your critical platforms, Salesforce included, and assign each an owner and a justification.
• Minimize scopes and set expiry. Grant integrations only the access they need, prefer short-lived tokens, and rotate refresh tokens on a schedule. A token that expires is a token that cannot be replayed months later.
• Monitor for anomalous API activity. Watch for unusual bulk exports, unfamiliar user-agent strings, and access patterns that do not match the integration's normal behavior. Legitimate credentials used illegitimately are still detectable at the behavior layer.
• Keep secrets out of CRM and support text. Scan support cases and CRM notes for keys and credentials, and treat that content as sensitive. The multiplier in this breach was secrets sitting in free-text fields.
• Extend diligence to sub-processors and their integrations. Ask vendors which of their own systems and acquisitions touch your data, and how those connections are secured. The failure here started in a source-code account most customers never knew existed.