Between 8 and 18 August 2025, someone ran database queries against the Salesforce accounts of hundreds of companies, exported their support cases and customer contacts, and left. Security vendors were among them: Cloudflare, Zscaler, Palo Alto Networks, Elastic and Bugcrowd all said so in public. None of them had a password stolen. None of their staff clicked anything. Their Salesforce sign-in pages, with single sign-on and MFA, were never touched.
The intruder came in as Drift, a website chat widget those companies had connected to Salesforce years earlier so that chat leads would land in the CRM. Drift, owned by Salesloft, held an OAuth token for each customer. Whoever holds the token is the integration.
Step 1: the vendor, months earlier
Salesloft hired Mandiant and published what it found:
• From March to June 2025 the intruder had access to Salesloft's GitHub account. They downloaded content from several repositories, added a guest user and set up workflows. Salesloft has not said how the account was first entered.
• In the same months they did reconnaissance in the Salesloft and Drift application environments.
• They then got into Drift's AWS environment and took the OAuth tokens for Drift customers' integrations.
Google's threat intelligence group, which tracks the intruder as UNC6395, later added that tokens for the Drift Email integration were taken too, and used on 9 August to read mail in a very small number of Google Workspace accounts that had been connected to Drift.
Step 2: what an OAuth token is, in one paragraph
When you click "Connect to Salesforce" in a third-party tool, sign in and press Allow, Salesforce gives that tool two strings: an access token and a refresh token. From then on the tool calls the Salesforce API with the token and gets whatever the granted scope allows. It doesn't know your password and never sees an MFA prompt, because you already passed both on the day you clicked Allow. The refresh token lets it keep going for months or years.
That design is right. It is far better than handing a vendor a password. It also means:
• the token is a bearer credential: any program that presents it is treated as the integration;
• it works from any IP address unless you restricted it;
• it sits in the vendor's infrastructure, protected by the vendor's security and not yours;
• your identity provider's sign-in logs show nothing, because nobody signed in.
You approved the integration once, with MFA. Every use of its token after that is a sign-in with no second factor.
Step 3: ten days of queries
With the tokens the intruder called each customer's Salesforce API directly. Google published some of the queries. They began by sizing up the account:
Then they pulled the data, with support cases the main target. Cloudflare reconstructed the visit to its own account from logs:
• 9 August: a first probe.
• 12 to 14 August: sign-in with the Drift credential, a listing of objects, a look at the Case schema, counts of accounts, contacts and users, and a check of the API limits.
• 16 August: one more count of cases.
• 17 August, 11:11 UTC: a Salesforce Bulk API job exports the Case object. It runs for just over three minutes. Twenty-four seconds after it finishes the intruder deletes the job record.
Deleting the job hid it from the list an administrator would look at, but not from the event logs. Requests came from cloud servers and Tor exit nodes, with user-agent strings such as Salesforce-Multi-Org-Fetcher/1.0: a script working down a list of customers.
Step 4: reading support tickets for keys
The CRM data was not the prize. Google's assessment is that the aim was credential harvesting: the exported text was searched for strings like AKIA (the start of an AWS access key), snowflakecomputing.com, password, secret and key.
Why support cases? Because that is where customers paste things. "Here is the config that fails." "This is the API token I'm using." A support queue is years of other companies' secrets in free text. Cloudflare searched its own exported cases the same way and found 104 Cloudflare API tokens that customers had pasted into tickets. It rotated all of them.
So the chain has a third link: vendor (Drift) to customer (the Salesforce account) to the customer's customers (whoever pasted a key into a ticket).
Timeline
• March to June 2025: access to Salesloft's GitHub account; reconnaissance.
• Before August: Drift's AWS environment entered; customers' OAuth tokens taken.
• 8 to 18 August: Salesforce data exported from hundreds of organisations.
• 20 August: Salesloft and Salesforce revoke every Drift access and refresh token; Salesforce removes Drift from its app marketplace.
• 23 August: Cloudflare is notified. 27 August: Google publishes its advisory.
• 28 August: Google reports the Drift Email tokens and revokes them.
• September: victims publish their own accounts; Salesloft reports Mandiant's findings and says the incident is contained.
What to do about integrations you already have
1. List them. All of them
Every platform that lets third-party apps connect has a page for it. Open each one and write down what's there:
For each app: who connected it, when, what scope it has, when it last made a call. Expect to find tools nobody has used since the trial ended, still holding a refresh token.
2. Remove what isn't used, then cut the scope of the rest
• No calls in 90 days: revoke. Reconnecting takes two minutes if someone needs it.
• Look at the scope. A chat widget that creates leads needs to create leads. Many connected apps hold full or api access to everything the connecting user can see, because that was the default the day someone clicked Allow.
• Connect integrations through a dedicated integration user with a small permission set, never through an administrator's own account. The token inherits the rights of the user who approved it.
3. Tie the token to where the vendor really is
Bearer tokens work from anywhere unless told otherwise. In Salesforce, set the connected app's IP relaxation policy to Enforce IP restrictions and give the integration user's profile the vendor's published IP ranges. Other platforms have the same idea under other names (conditional access for workload identities in Entra, IP allow-lists for GitHub organisations). A token replayed from Tor then fails.
4. Make sure you would see the next one
• Turn on API and export logging where it is an add-on (Salesforce Event Monitoring; audit logs in Workspace and Microsoft 365), and keep the logs for months.
• Alert on bulk exports, on API calls from a connected app at an unusual volume, and on new user agents for an existing integration.
• In this case the customers learned of it from the vendor, days after their data was gone. Those with logs could at least say exactly what was taken.
5. Keep secrets out of tickets, on both sides
• If you run a support desk: say on the form not to paste keys or passwords, scan incoming text for key patterns and mask them, and delete old attachments on a schedule.
• If you are the customer: a key pasted into any vendor's ticket is a key to rotate once the ticket is closed.
6. Know how to pull the plug
For each important integration, write down where the revoke button is (step 1 lists the pages) and who may press it. On 20 August the vendors revoked the tokens for everyone. A customer who had noticed odd API calls on the 12th could have done it themselves in a minute.
If you run a product that holds other people's tokens
Drift's side has its own list: encrypt stored tokens with a key that the application's database credentials can't read, keep refresh tokens short-lived and rotating where the provider supports it, ask for the narrowest scope the feature needs, and treat the source code host as production, since that is where this started. The Okta support-system case and Cloudflare's four unrotated credentials are the same story from the customer side: someone else's breach becomes yours through a credential you forgot you had issued.
The lesson
Companies spend real effort on how people sign in, and that work held here: no password, no phish, no MFA bypass. The way in was a permission granted years ago by someone who clicked Allow. Sign-in for integrations deserves the same list, the same least privilege and the same off switch as sign-in for people.
osec.one makes small security tools for sites without a security team: passwordless sign-in, login rules, scans and CSP reports, each added with a pasted snippet and no DNS move.
See the toolsSources: Google Threat Intelligence Group: Widespread data theft targets Salesforce instances via Salesloft Drift (27 August 2025, updated 28 August); Cloudflare: The impact of the Salesloft Drift breach on Cloudflare and our customers (2 September 2025); Salesloft Trust Center: Drift security updates; Help Net Security: Salesloft Drift data breach, investigation reveals how attackers got in; Security Affairs: hackers breached Salesloft's GitHub in March; TechTarget: Salesloft Drift breach update and timeline.