What happened
On 26 August 2025, Google's threat intelligence group published an advisory describing a group it tracks as UNC6395 using stolen OAuth tokens tied to the Salesloft Drift chat integration to query and export data from customers' Salesforce instances between 8 and 18 August. The actor pulled account, contact, case and opportunity records, then searched the exported text for embedded secrets such as AWS keys, passwords and Snowflake credentials. Google's follow-up update widened the scope to a Drift-to-Google-Workspace integration. Two affected customers described their own experience. Cloudflare's account says the actor reached its Salesforce case data in a four-minute export on 17 August and that Cloudflare found and rotated 104 of its own API tokens inside the exposed text. PagerDuty's update says some customers had shared access tokens with its support team, and those were exposed and revoked.
Confidence and limits
A named threat-intelligence source and two independently affected companies describe the same mechanism, window and cleanup, which is strong corroboration. What remains vendor-reported rather than independently audited is scale: Google's advisory describes hundreds of affected Salesforce tenants without a public, verified count, and no regulator or court document has yet assessed the incident's full reach or attributed it beyond the UNC6395 label Google itself assigns.
Why it mattered
Nothing here was a flaw in Salesforce or Google Workspace. A third-party chatbot's connection to both, authorised once and left standing, was the entire attack surface. That is the ordinary shape of a modern SaaS estate: dozens of integrations, each holding a token with broad read access, each rarely reviewed after setup. Once inside, the actor did not need to escalate; it read what the integration was already permitted to read, then hunted the harvest for further credentials, turning a support tool's data into a key to other systems.
Defensive takeaway
List every third-party application with standing OAuth access to your CRM or support platform, check what scope each one actually needs against what it was granted, and search your own case and ticket text for anything that looks like a password, key or token before someone else does.
- Which connected apps in your CRM hold read access to contact, case or opportunity records, and who approved that access?
- Would your logging tell you if a connected app suddenly queried far more records than its normal usage pattern?
- Do your support agents know not to paste live credentials into a ticket, even temporarily?
The tokens here were never phished from an employee; they belonged to an application employees already trusted. Treating integration credentials with the same scrutiny given to human ones is the shift this incident argues for, not a new tool but a new habit of review.