- In August 2025, an actor used stolen OAuth tokens for the Drift integration to query Salesforce instances at many organisations, then searched the data for secrets such as AWS keys and Snowflake tokens.
- The tokens were taken from the integration vendor's environment, reached through an intrusion into its GitHub account months earlier. None of the victims' own passwords or MFA were involved.
- A parallel campaign used phone calls posing as IT support to get staff to authorise an attacker-controlled connected app.
- Treat every OAuth grant as a standing credential: inventory it, limit its scope, restrict where it can be used from, monitor it, and have a revocation plan.
What happened in the Salesloft Drift compromise?
Google Threat Intelligence tracked the activity as UNC6395. Between 8 and 18 August 2025, the actor used OAuth access and refresh tokens belonging to the Drift chat integration to query Salesforce objects, including Users, Accounts, Opportunities, and Cases, across many customer organisations. It then searched the stolen data for credentials, including AWS access keys, passwords, Snowflake tokens, and VPN and SSO URLs, to move into other systems.
Salesloft's investigation, carried out with Mandiant, found that the attacker had been in Salesloft's GitHub account from March to June 2025, downloading repositories, adding a guest user, and creating workflows. From there they reached Drift's AWS environment and took the OAuth tokens that customers' integrations relied on. On 20 August 2025, Salesloft and Salesforce revoked all Drift access and refresh tokens. Google later reported that tokens for the "Drift Email" integration had also been compromised.
Indicators published by Google included the user agents Salesforce-Multi-Org-Fetcher/1.0 and python-requests/2.32.4 in API logs. They are worth searching for in historical logs.
How did the voice phishing campaigns work?
Separately, Google tracked UNC6040, a group that phoned employees while posing as IT support and walked them through authorising a connected app in Salesforce, often a modified version of the Data Loader tool that the attacker controlled. The app then had legitimate API access to export data. Extortion followed, under the "ShinyHunters" name. In January 2026, Google reported the same approach expanding to SharePoint and Microsoft 365, DocuSign, Slack, and Google Workspace, using victim-branded single sign-on phishing pages to capture credentials and MFA codes.
In both campaigns, attackers did not need a vulnerability. They needed an authorised integration with broad API access and nobody watching how it was used.
Why are OAuth integrations such an attractive target?
- They bypass MFA. A refresh token keeps working without the user present.
- They are over-scoped. Integrations often request full API access when they need to read one object type.
- They are rarely reviewed. Connected apps accumulate for years, and many belong to tools nobody uses any more.
- Their activity looks normal. Bulk API reads by an integration are exactly what integrations do.
- They aggregate risk. One vendor breach exposes the tokens of every customer at once.
How do you audit your own SaaS integrations?
1. Inventory every grant
For each major platform (CRM, email and collaboration, source control, cloud, ticketing), list the connected apps, the user or service that authorised each one, the scopes granted, and when the token was last used. Remove anything unused.
2. Reduce scope and reach
- Replace broad scopes such as full API access with the narrowest scopes the integration really needs.
- Where the platform supports it, restrict tokens to the vendor's published IP ranges and set session or refresh-token lifetimes.
- Require administrator approval for new connected apps, so an employee on the phone with "IT" cannot authorise one.
3. Stop storing secrets in business data
The Drift actor searched support cases and CRM records for keys and passwords because people paste them there. Scan these systems for secrets, rotate what you find, and give support teams a proper way to share credentials.
4. Monitor integration behaviour
- Alert on bulk exports, unusual query volume, new user agents, and API access from unexpected networks for each integration.
- Send SaaS audit logs to your SIEM. Many platforms keep them for only a short time by default.
5. Plan revocation
Know how to revoke every token for a given integration quickly, and what breaks when you do. In the Drift case, fast revocation by the vendor and the platform limited further damage.
What should you ask vendors that hold your tokens?
- Where are our OAuth tokens stored, how are they encrypted, and who can access them?
- Are source code, CI/CD, and cloud accounts protected with phishing-resistant MFA?
- Do you monitor for misuse of customer tokens, and how quickly will you tell us?
- Can we restrict your access to specific IP ranges and scopes?
How we test this: our cloud security review and attack surface review include a SaaS integration and OAuth grant review, and our red teaming can test whether your help desk and staff resist the voice phishing techniques used in these campaigns.
Sources
- Google Threat Intelligence: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift
- Salesloft Trust Center: Mandiant investigation update
- Google Threat Intelligence: The Cost of a Call (UNC6040)
- Google Threat Intelligence: UNC6040 hardening recommendations
- Google Threat Intelligence: Expansion of ShinyHunters SaaS data theft (Jan 2026)
- NIST and CISA: Draft IR 8597 on protecting tokens and assertions