The Salesloft–Drift Breach: An Attack Path Case Study

TL;DR This post analyzes the Salesloft–Drift incident through an attack path lens, showing how violations of the clean source principle, identities in transit, and hidden hybrid paths combined to turn a single compromise into a multi-organization breach.

Introduction

The recent Salesloft–Drift breach highlights the fragility of modern SaaS ecosystems. Reporting has made clear that attackers were able to compromise Salesloft’s GitHub environment, pivot into their AWS infrastructure, and from there exfiltrate OAuth tokens used by Drift integrations with Salesforce. With those tokens in hand, the attackers gained trusted access to hundreds of Salesforce tenants, ultimately stealing customer data and even uncovering additional secrets like API keys stored inside Salesforce records.

While some details are known, there are still gaps in the public story. For example, exactly how the attackers first gained access to Salesloft’s GitHub remains unclear. Likewise, we don’t know the precise mechanism by which they derived OAuth tokens from Salesloft’s AWS environment and then replayed those tokens into customer Salesforce instances. In this post, I’ll draw on what has been reported and add informed speculation where necessary, not to sensationalize, but to illustrate how the attack might have unfolded from the perspective of an adversary navigating an interconnected set of platforms.

Rather than focusing solely on point-in-time failures, we’ll examine this incident through the lens of attack paths. By following the sequence of compromises across GitHub, AWS, Drift, and Salesforce, we can see how dependencies between systems became the real story, and how attackers can exploit those dependencies in ways defenders rarely anticipate.

Clean Source Principle

The clean source principle can be summarized simply: all security dependencies must be as trustworthy as the object being secured. If a dependency is compromised, then the object that relies on it is also necessarily compromised. The Salesloft–Drift breach illustrated this directly. When attackers gained access to Salesloft’s GitHub organization, they were able to use that position to compromise Salesloft’s AWS environment. By storing and managing deployment secrets in GitHub, Salesloft had effectively made GitHub a security dependency of AWS. When GitHub fell, AWS fell with it.

That framing makes the rest of the incident easier to understand. This wasn’t just a matter of Salesforce “being breached.” What really happened is that customers, by enabling Drift, created a hybrid path between their Salesforce tenant and Salesloft’s AWS tenant. OAuth tokens lived on Salesloft’s side of that integration, which meant that if Salesloft’s AWS environment was compromised, so too was the customer’s Salesforce tenant. Most customers probably never thought of it that way, they just saw Drift as an approved app in the Salesforce ecosystem. However, in practice, they had extended their trust boundary outward into Salesloft’s cloud.

The situation was further complicated by the way many organizations utilized Salesforce itself. Credentials, API keys, and other sensitive information were often stored directly within Salesforce records, attached to cases or comments. That created yet another layer of ad hoc hybrid paths: a stolen Salesforce token could now cascade into Snowflake, AWS, or other downstream systems.

When viewed through the clean source lens, the picture is clear: GitHub became a dependency of Salesloft’s AWS, Salesloft’s AWS became a dependency of Drift, and Drift became a dependency of hundreds of Salesforce tenants. At every step, the clean source principle was violated. The result was an attack path that spanned multiple companies, multiple clouds, and ultimately hundreds of unsuspecting victims.

Identities in Transit vs. Identities at Rest

To understand the mechanics of the Salesloft–Drift breach, it’s important to distinguish between identities at rest and identities in transit.

Identities at rest exist in a pre-authentication state. These are credentials, such as usernames and passwords, stored in a vault, or recovery keys that remain unused until a human or system attempts to log in with them. They’re static and inert until they’re presented to an authentication service. Controls such as password rotation, vaulting, and multifactor authentication are designed to reduce the risk of these at-rest identities being compromised. Importantly, the attacker doesn’t need to be “outside” the system to target it; they may already have access somewhere inside, but still need to transition into a more privileged identity context by presenting the at-rest credential.

Identities in transit, by contrast, exist in a post-authentication state. These are artifacts created or consumed once a login has already succeeded. Examples include session cookies, Kerberos tickets, OAuth tokens, and API keys embedded in build pipelines or configuration systems. They aren’t waiting to be checked out; they’re live, trusted credentials already in use. By their nature, these identities are ephemeral; however, their lifetimes vary widely depending on the type and use case. A browser cookie might last only hours, an OAuth token a few days, while an API key used by a build pipeline could persist unchanged for months. That longevity makes some in-transit identities especially dangerous: if an attacker can steal one, they bypass the login ceremony entirely and inherit the success of the original authentication event.

The Drift incident gave us two clear examples of identities in transit. First, the pivot from GitHub to AWS was made possible by AWS access keys stored in repositories. Those keys weren’t dormant vault entries; deployment processes actively used them to assume AWS roles, making them a form of in-transit identity. Second, once inside AWS, the attackers were able to exfiltrate OAuth tokens tied to the Drift–Salesforce integration. Those tokens represented already-authenticated sessions. Replaying them against Salesforce gave the attackers the same trusted access Drift itself enjoyed.

Taken together, these two steps highlight why in-transit identities are so dangerous. A single compromised token or key can bypass nearly every identity control that organizations rely on. The problem isn’t limited to OAuth or API keys; these artifacts manifest in various forms across modern enterprise environments. Each one creates a potential edge in the attack graph, silently connecting platforms in ways most organizations never map.

Attack Graph View of the Breach

One of the most useful ways to frame this incident is to contrast an access graph with an attack graph.

In an access graph, we describe relationships in isolation. For example, “GitHub user Bob has the ability to read the contents of a GitHub repository.” That’s a true statement, but it doesn’t capture the full security impact of that access. An attack graph adds context: if that repository contains an AWS access key, then Bob’s read access is not just about source code visibility; it can also be leveraged to assume control of an AWS identity.

When we examine the Drift breach through this lens, the story shifts from a collection of isolated permissions to a single, coherent attack path. A simplified view might look like this:

• GitHub User → AWS Role → SFDC User → SFDC Record

Each edge represents more than just access; it represents the ability to change security contexts. A GitHub user with read access can pivot into AWS. From there, AWS access can be leveraged to obtain OAuth tokens tied to Salesforce. Those tokens grant control of a Salesforce user, which in turn grants access to Salesforce records that may contain additional secrets.

Individually, none of these relationships would appear catastrophic in an access graph. But when chained together in an attack graph, they define a clear path from an external developer identity all the way to sensitive customer data. This is the essence of why attack graphs matter: they enable us to view systems from the perspective of adversaries, not as silos but as interconnected dependencies waiting to be traversed.

Hybrid Attack Paths and SaaS Ecosystem Risk

The Drift breach also highlights a broader truth about modern identity systems: hybrid attack paths are everywhere. We often discuss hybrid paths in the context of a single company, such as Active Directory connected to Entra ID or Okta federated into AWS. But in this case, the hybrid path extended across organizations. By enabling the Drift integration, Salesforce customers effectively created a bridge between their own Salesforce tenant and Salesloft’s AWS tenant. Most didn’t recognize that decision as expanding their trust boundary, but that’s precisely what happened. When Salesloft’s AWS environment was compromised, the compromise directly affected hundreds of Salesforce customer tenants.

The situation was further complicated by the way customers used Salesforce itself. Many organizations stored secrets in records, AWS keys, Snowflake tokens, service account passwords, often tucked into case notes or custom fields. This created another layer of ad hoc hybrid paths: once Salesforce was compromised, the attacker could step from CRM data into entirely different platforms. In practice, Salesforce was functioning as a credentials broker, not because it was designed to do so, but because users treated it that way.

This problem isn’t unique to Drift or Salesforce. The modern SaaS ecosystem is stitched together by countless integrations, such as Okta into Slack, GitHub into Jira, and Zoom into Google. Each connector adds another edge to the attack graph, often without security teams fully appreciating what new dependencies they’ve introduced. Hybrid attack paths are the connective tissue that binds these systems together. They are the routes adversaries exploit precisely because no single team or platform owner is tasked with mapping them.

The Drift incident makes that risk visible. It wasn’t just about a GitHub repo, an AWS tenant, or an OAuth token. It was about the hidden hybrid paths that silently spanned multiple companies and multiple platforms, and how attackers were able to walk them with ease.

BloodHound Enterprise

The Drift breach is a clear reminder that identity risk doesn’t exist in isolation. It manifests as attack paths that link systems together, often across platforms, and in this case, across organizations. The challenge for defenders is that most of these relationships are invisible until they’re abused.

This is precisely where BloodHound Enterprise comes in. With BloodHound OpenGraph, organizations can model the kinds of relationships that defined this incident: OAuth tokens, API keys, and SaaS integrations as first-class edges in the graph. Instead of seeing only that “Drift has access to Salesforce,” the attack graph makes visible the larger chain: GitHub → AWS → Drift → Salesforce → downstream secrets. The graph illustrates that read access to a GitHub repository can cascade to control of a Salesforce tenant, and subsequently, into other systems where credentials are stored.

The value of this visibility is that it gives defenders options. If a security dependency is too risky, you can cut the edge. If an integration creates a broad path into sensitive systems, you can rotate tokens, restructure trust, or isolate that zone. The point isn’t just to understand the path after the fact, but to manage those paths proactively so attackers can’t walk them in the first place.

The lesson of Drift is not that Salesforce, GitHub, or AWS are uniquely vulnerable. It’s that modern identity ecosystems are stitched together by hybrid paths that are easy for adversaries to exploit and difficult for defenders to even see. Identity attack path management is how you shift that balance. BloodHound Enterprise provides the lens to map those paths and the means to reduce them, turning a hidden liability into something you can actively manage.

Conclusion

The Salesloft–Drift breach illustrates how identity risk manifests in real-world scenarios. It wasn’t just a case of a GitHub account being compromised, or an AWS tenant being misconfigured, or Salesforce records being mishandled. It was the chain of dependencies between those systems that mattered most.

Seen through the clean source principle, the breach made clear that every system you rely on becomes a security dependency. When GitHub was compromised, AWS was compromised. When AWS was compromised, Drift was compromised. And when Drift was compromised, hundreds of Salesforce tenants were compromised. Each link violated the principle that a dependency must be as trustworthy as the object it protects.

The breach also underscored the unique danger of identities in transit. Tokens and keys don’t need to be cracked or brute-forced; they are already authenticated. Once stolen, they bypass MFA, vaulting, and conditional access, allowing attackers to inherit trust that has already been granted. Whether it was AWS keys in a repository or OAuth tokens connecting Drift to Salesforce, in-transit identities were the pivots that made the attack path possible.