In mid-August 2025, the Salesloft Drift breach was reported, impacting giants such as Palo Alto Networks, Salesforce, Cloudflare and their customers. Attackers stole and abused hundreds of OAuth tokens to access Salesforce environments and extract sensitive data, demonstrating both proven and potential large-scale consequences.
When reading through the reports, I resisted classifying it as another “supply chain attack.” This attack was different.
It was related to non-human identities theft and a trust breach with a lateral movement TTP on steroids, otherwise known as a cross-vendor lateral movement. It was a business-to-business-to-business attack. Or, labeled in a much more scientific way, a (B2)ⁿ Attack. This chain of broken trust makes it very hard for the victims of the attack to protect themselves.
Think about it: Attacker → Drift → Salesloft → Salesforce → Customer → Customer’s Customer.
Each hop extended the attack surface, and once OAuth tokens were stolen, attackers had a trusted pathway through each vendor. The proven impact already includes hundreds of affected orgs, stolen case records, and more than 100+ exposed API tokens, with the potential for far broader compromise as adversaries mine that data for cloud keys and other credentials.
Large organizations maintain thousands of partnerships and integrations, and they do not really have a “safe integration” model. This integration chain results in a more than 1:1 relationship. So how can we prevent, detect or more quickly respond to these kinds of attacks, and be protected from domino effects?
Obviously, this also raises a bigger question: do we need to push for a shared security model for SaaS providers, not just for cloud infrastructure giants like AWS, Microsoft, and Google Cloud, who made similar calls back in 2020? In this piece, I will explain where the real problem lies, and how both vendors and CISOs can build a framework for shared responsibility that accounts for all dependencies and ultimately reduces lateral movement risk.
Sound interesting? Keep reading. If it proves useful, I would love to hear your thoughts.
Further details of the breach
Based on different sources (noted below), in August 2025, attackers tracked as UNC6395 stole OAuth refresh tokens from Salesloft’s Drift integration with Salesforce. These tokens allowed Drift to query Salesforce instances on behalf of over 700 customers. Once in, the attackers exported contact data, case records, and even API keys embedded in tickets or attachments.
Impacted companies included high-profile firms like Cloudflare, Proofpoint, and Palo Alto Networks. Cloudflare disclosed that 104 API tokens and sensitive case data were compromised. Salesforce and Salesloft responded by revoking Drift tokens and removing the app from AppExchange, and end customers as well deactivated this integration as a counter measure. For some it was too late, as their data, including access secrets, had already leaked.
Further analysis revealed that the attackers had access to Salesloft’s GitHub repositories, enabling deeper reconnaissance and possibly aiding token theft. Google also reported limited abuse of Drift Email OAuth tokens in Google Workspace environments. Worse, adversaries searched the stolen data for AWS keys, Snowflake tokens, and other credentials, multiplying the potential impact.
While many of the posts and articles that have been published in the last few weeks float around the angle that this cyberattack was a “traditional” data breach, SaaS exploitation, or even an AI agent compromise, this incident is different. It’s a pure example of IAM complexity, or to put it simply, a total IAM mess (not mesh) we’re all confronting in the age of SaaS, AI, and the explosion of non-human identities (NHIs). The Drift chatbot is a software application designed to automate conversations, so it doesn’t act with autonomy or independent decision-making. Instead, it operates within pre-defined workflows and integrations. And the OAuth used for the integration is an NHI (non-human identity).
What we can learn
We, as customers, are not ready to protect against (B2)ⁿ NHI attacks
It’s not easy to answer the basic question of, “Which of our vendors were impacted?” and “What data and access did they hold in Salesforce about us?” These kinds of lateral movement attacks that uncover the interconnectedness of our digital systems emphasize that it’s more difficult than we think to stop hackers, because we are often the last ones to be aware of the impact along the food chain.
B2B2B risk is real, and we need a shared responsibility model
This was not just Drift → Salesforce → customers. It was Drift → Salesforce → customer SaaS data → cloud services. Each hop widened the blast radius. Vendors must account for their vendors’ vendors.
Tokens are identities – and should be managed as such, regardless of the B2B distance
OAuth tokens are not just ‘technical glue.’ They are non-human identities that should be treated with the same rigor as human accounts: short-lived, scoped, rotated, and monitored. They are identities that everybody (including attackers) can assume, if they aren’t secured properly.
Your secrets and credentials also live in the data – not just yours, but also your partners’
Case notes and attachments often contain sensitive keys or configs. Once breached, CRMs and support systems become credential goldmines. Scanning and redacting secrets in SaaS data must become standard practice.
Centralized kill-switches matter
Salesforce’s ability to globally revoke Drift tokens helped contain spread. All platforms should have the capacity to enable emergency revocation at scale.
Beyond the supply chain: Understanding (B2)ⁿ
It is tempting to categorize this simply as a supply chain attack or third-party risk. But that framing is too broad and hides the unique mechanics.
What we saw here is closer to a (B2)ⁿ crossing attack, a form of cross-vendor lateral movement.
At its core, it looks like this:
- A customer, e.g., Palo Alto Networks, uses a SaaS Platform, such as Salesforce.
- To enhance value, Palo Alto Networks connects a 3rd party app – Salesloft to Salesforce.
- Salesloft acquires Drift, which held OAuth tokens that granted access from Saleloft to Salesforce on behalf of Palo Alto Networks.
- If Palo Alto Networks’ Salesforce data contains embedded secrets (like API keys), attackers who breach Drift can exploit Salesforce’s data to reach further into another vendor’s environment.
This is federated trust—as well as implicit trust—turning into federated risk. Each integration looks benign in isolation, but when chained together, they create an attacker’s pathway across multiple organizations. Hence the idea of (B2)ⁿ: business-to-business links multiplied, compounding exposure.
Building a shared responsibility model for (B2)ⁿ SaaS integrations
In the table below, you’ll see where each part of the chain assumes responsibility to prevent cross-vendor lateral movement attacks:
The path forward through shared responsibility
Until a mutual agreement on a new shared security model comes about, for every integration or token/key/certificate/identity created for a third or fourth party, CISO and IAM leaders should demand their vendors provide them with some sort of visibility to the token lifecycle, volume of usage, basic monitoring for anomalies in using it and more. At the very least, working with vendors to confirm the availability of a “kill switch” or refresh button.
And for the vendors themselves, let’s make sure we empower our integration partners and end-customers with this visibility, and as part of the paywall, part of the basic packages.
References
Google Threat Analysis Group: UNC6395 updates –
https://cloud.google.com/blog/topics/threat-intelligence/unc6395-drift-attack
Salesforce advisory on Drift app removal
https://help.salesforce.com/s/articleView?id=005134951&language=en_US&type=1
Palo Alto Networks Unit 42 analysis
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/
Cloudflare disclosure on compromised tokens
https://blog.cloudflare.com/response-to-salesloft-drift-incident/
Mandiant investigation of Salesloft GitHub compromise –
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift