Inside the Salesloft-Drift Breach: Why Cross-Vendor Attacks Are the Next Big Threat

Read full article from Silverfort here:  https://www.silverfort.com/blog/the-salesloft-drift-breach-a-cross-vendor-lateral-movement-attack-that-requires-a-new-shared-security-model/?utm_source=nhimg

In August 2025, the Salesloft–Drift OAuth breach shook the SaaS ecosystem, impacting major enterprises like Salesforce, Cloudflare, Palo Alto Networks, and Proofpoint. Attackers compromised hundreds of OAuth tokens, enabling access to sensitive Salesforce environments and exfiltration of confidential customer data.

While many called it another supply chain incident, the reality runs deeper. This was not a linear supply chain compromise—it was a cross-vendor lateral movement attack, powered by non-human identity (NHI) theft and federated trust abuse. In essence, it was a Business-to-Business-to-Business breach, or what I call a (B2)ⁿ attack—where each integration link multiplies exposure across vendors, customers, and downstream partners.

The Attack in Context

How It Started

In mid-August 2025, threat actor UNC6395 gained unauthorized access to Salesloft’s Drift integration with Salesforce, stealing OAuth refresh tokens that granted persistent access to Salesforce instances for more than 700 organizations.

From there, attackers:

• Queried Salesforce APIs on behalf of Drift customers
• Exfiltrated contact records, support tickets, and embedded API keys
• Accessed Salesloft GitHub repositories, expanding reconnaissance
• Abused Drift Email OAuth tokens in Google Workspace environments

The breach rapidly evolved from an integration compromise into a multi-vendor infiltration campaign, where OAuth tokens functioned as legitimate credentials across trusted SaaS connections.

Not a Supply Chain Attack — A (B2)ⁿ Breach

Traditional supply chain attacks typically flow in one direction—from vendor to customer.
In contrast, this was a bidirectional, multi-node compromise across interlinked SaaS ecosystems.

Attack chain example:

Attacker → Drift → Salesloft → Salesforce → Customer → Customer’s Customer

Each hop represented an independent SaaS integration — yet attackers could laterally move across them using valid tokens and shared APIs.

This cross-vendor trust collapse reveals a hard truth: we lack a true shared responsibility model for SaaS-to-SaaS integrations.

Why This Attack Matters

1. Tokens Are Non-Human Identities (NHIs)

OAuth tokens are identities, not just authentication artifacts.
They represent application-level trust between vendors. Once stolen, attackers assume the full permissions of the legitimate integration.

Proper NHI security requires:

• Short-lived and scoped tokens
• Continuous rotation and revocation
• Usage monitoring and anomaly detection

2. Lateral Movement Across Vendors

Once a Drift token was compromised, adversaries could use it to:

• Access Salesforce data for multiple organizations
• Harvest API keys from tickets and attachments
• Expand into AWS, Snowflake, and GCP via discovered credentials

This is cross-vendor lateral movement — attackers exploiting one SaaS trust boundary to infiltrate another.

3. Data Becomes a Credential Source

Compromised CRMs, ticketing tools, and collaboration apps often store plaintext secrets.
Attackers mine these platforms to harvest:

• API tokens
• SSH keys
• OAuth refresh credentials
• Snowflake and AWS access keys

This turns SaaS environments into credential goldmines once initial access is achieved.

The Need for a Shared SaaS Security Model

Cloud infrastructure providers (AWS, Microsoft, Google) adopted shared responsibility frameworks years ago. SaaS ecosystems haven’t caught up.
The Salesloft–Drift–Salesforce breach underscores the urgent need for a shared security model for SaaS vendors.

Without alignment across these domains, (B2)ⁿ attacks will continue to multiply risk faster than organizations can respond.

Mitigation & Recommendations

For Customers and CISOs

1. Demand visibility: Require vendors to disclose token lifecycle telemetry and rotation intervals.
2. Audit SaaS integrations: Maintain an inventory of every active OAuth app and its scope.
3. Implement kill-switch readiness: Ensure rapid token revocation capability.
4. Adopt secret scanning in CRMs, ticketing systems, and shared repositories.

For SaaS Vendors

1. Adopt OAuth least privilege: Short-lived tokens, minimal scopes, and automated rotation.
2. Expose security metrics: Allow customers to view and manage token usage analytics.
3. Integrate emergency revocation: Similar to Salesforce’s global revoke function.
4. Collaborate on shared response: Coordinate incident containment with downstream partners.

Beyond Trust: Redefining Resilience

The Salesloft–Drift incident was a wake-up call.
It exposed the fragile web of federated trust across modern SaaS ecosystems and reminded us that security no longer stops at organizational boundaries.

OAuth tokens, service accounts, and AI agents — all non-human identities — now form the fabric of business connectivity.
Without shared visibility, governance, and revocation mechanisms, every integration becomes a potential attack corridor.

The way forward isn’t isolation — it’s interoperable responsibility.