Writing
Anatomy of an Identity Incident

Seven Hundred Breaches, One Stolen Integration

Anatomy of an Identity Incident — the Salesloft Drift campaign, 2025. The attackers didn't breach 700 companies. They breached one integration that already had the keys to all of them.

Michael AbramovichSeptember 15, 20255 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

In August 2025, attackers pulled data from the Salesforce environments of hundreds of organizations — reporting put the blast radius north of 700, with roughly 1.5 billion records exfiltrated — without breaching a single one of those companies directly. They breached one thing: the OAuth tokens belonging to Drift, a third-party chat and marketing application owned by Salesloft, that customers had connected to their Salesforce. The tokens were obtained earlier, via a compromise of the vendor's source-control environment, and then used over a tight window in mid-August to reach every customer that had ever connected the integration.

The math is the whole story. One integration held standing, token-based access into the Salesforce of every customer who used it. Steal that integration's tokens and you inherit all of that access at once. No customer's password was phished, no customer's MFA was defeated. The keys were copied from the company in the middle.

The identity timeline

Only identity-relevant events.

  • March–June 2025 — Attackers compromise the third-party vendor's development environment (source control), where OAuth tokens for the integration were reachable.
  • A quiet period — The access sits unused for a stretch, which is itself a tell: the value wasn't the vendor; it was what the vendor's tokens unlocked downstream.
  • Aug 8–18, 2025 — Using the stolen OAuth tokens for the Drift–Salesforce integration, the attackers authenticate as the integration into customer Salesforce environments and exfiltrate data at scale.
  • The fan-out — Because the integration had access to many customers, a single set of stolen tokens reaches 700-plus organizations, including major technology and security firms, totaling on the order of 1.5 billion records.
  • Late August onward — Affected companies disclose, revoke the integration's tokens, and hunt for what was taken. The remediation is the same everywhere: kill the connected app, rotate anything it could see.

The pivot point

The pivot is the standing OAuth access the integration held — and the fact that it lived at the vendor, not the customer.

A connected integration is a non-human identity with delegated authority: the customer authorized Drift to access their Salesforce, on purpose, so it could do its job. That grant is token-based and long-lived; the integration doesn't re-prove itself on every call, and it doesn't carry the customer's MFA. So the security of every customer's Salesforce data quietly came to depend on how well a different company protected that integration's tokens. When those tokens were copied out of the vendor's source control, the attacker didn't need to touch any customer. They held a credential that every customer's Salesforce already trusted.

That is the pivot, and it's worth separating from the consent-phishing attacks in the same ecosystem. In those, a user is tricked into authorizing a malicious app. Here the app was entirely legitimate and the authorization was real and reasonable; the failure was that the legitimate integration's tokens were stealable, and that they unlocked everyone at once. The customer made a sensible decision — connect a useful tool — and inherited the blast radius of that tool's vendor's security, with no visibility into it.

What would have caught it

Naming controls, not products.

Scoping integration access to the minimum. Every connected app should hold the least access it can do its job with. A marketing chat tool that can read your entire CRM is a bigger bearer credential than it needs to be. Tight scopes shrink what stolen tokens are worth.

Inventorying connected apps and their blast radius. You can only reason about this risk if you know which integrations are connected, what each can reach, and which vendor holds the tokens. Most companies cannot produce that list — which is the real finding.

Monitoring integration behavior, not just human logins. A connected app suddenly pulling bulk data, or authenticating from new infrastructure, is detectable — but only if anyone is watching non-human identities the way they watch people.

Short-lived and revocable integration credentials. The longer an integration's tokens live and the harder they are to rotate, the more a vendor compromise is worth. Favoring short-lived, easily revoked grants caps the damage window.

Treating third-party integrations as part of your attack surface. The vendor's security posture is now your posture. Diligence on who holds your delegated tokens, and how, is identity work, not just procurement.

The last mile

This is the supply-chain shape of the last mile, and it's the one growing fastest.

Salesforce did its job; the integration's authorization was a legitimate, intended feature. The vendor's compromise is the vendor's to answer for. But step back to the customer's position, because that's where the incident actually landed. A customer connected a useful tool — a completely normal act — and in doing so created a standing, token-based trust relationship that they did not control, could not see into, and were not monitoring. The span between "we connected an integration" and "we govern, scope, and watch every non-human identity that can reach our data, including the ones living at other companies" is exactly the last mile, and it was owned by no one. Not the platform (the grant was valid), not the vendor (their job was to themselves), and not the customer (who had handed over access and moved on).

What makes this version urgent is the multiplier. Every company now runs dozens or hundreds of these integrations, each a non-human identity holding delegated access, each only as safe as a third party you don't audit. The human-identity controls we spent a decade building — MFA, conditional access, phishing-resistant factors — do nothing here, because no human was in the loop at exploitation time. The attackers have noticed that the soft, ownerless ground has moved from human credentials to machine ones, and they are mining it: one vendor compromise, seven hundred companies' data. The mile didn't disappear when authentication got strong. It relocated to the integrations nobody owns.

For defenders

Five things you can check this week.

  1. Produce an inventory of connected apps across your SaaS, with each app's scopes, owner, and which vendor holds the tokens. If you can't, that's job one.
  2. Right-size integration permissions. Revoke access scopes a tool doesn't strictly need, especially broad CRM or bulk-read access.
  3. Monitor non-human identities for anomalous bulk access and logins from new infrastructure.
  4. Prefer short-lived, easily revocable integration credentials, and practice revoking them.
  5. Add third-party integrations to your incident plan. "A vendor whose app we connected gets breached" should have a named owner and a rotation runbook.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#salesloft #drift #salesforce #oauth #supply-chain #nhi #last-mile