Salesloft Drift compromise exposes OAuth token risk across apps

At a glance

What this is: This is a WideField Security analysis of a Salesloft Drift compromise that extended beyond Salesforce into Gmail, driven by stolen OAuth tokens and follow-on access to other environments.

Why it matters: It matters because connected-app consent, token revocation, and secret storage in SaaS systems can turn one compromised integration into a multi-platform identity incident for NHI, IAM, and PAM teams.

By the numbers:

• 700 Salesforce customers were potentially impacted, y impacted, according to a Google Threat Intelligence Group analyst.
• The incident generated 191 suspicious log events across Gmail and Salesforce during the August 9 to 19 window.
• WideField observed 183 Gmail access events from one IP address tied to the compromised Drift Email activity.

👉 Read WideField Security's analysis of the Salesloft Drift OAuth token compromise

Context

Salesloft Drift is a connected application, which means it relies on OAuth grants to access customer environments such as Salesforce and Gmail. When those tokens are compromised, the issue is no longer a simple application breach. It becomes an identity problem because the attacker inherits the permissions that users or administrators previously approved.

The governance gap is not limited to the original integration. This incident shows how third-party app consent, refresh token persistence, and insecure secret storage in downstream SaaS systems can combine into a wider identity supply-chain failure. For IAM and NHI teams, the question is not whether the app was trusted at install time, but whether that trust is still valid after compromise.

This is an NHI governance issue because the token, not the person, carried the effective access. Once that token was used to reach Salesforce and Gmail, the attacker could pivot into other secrets and sessions that were never meant to sit inside business applications.

Key questions

Q: What breaks when a third-party SaaS app token is compromised?

A: A compromised SaaS app token turns delegated access into attacker-controlled access, often without triggering normal login alarms. The attacker can act as the approved integration, reach the granted scopes, and pivot into data or secrets stored in the connected system. If revocation is incomplete, the breach can continue after the initial compromise is detected.

Q: Why do connected apps increase identity risk in SaaS environments?

A: Connected apps extend trust beyond the user session and create durable non-human access paths through OAuth grants and refresh tokens. That makes them identity assets, not just convenience features. If the app is compromised, the resulting access may look legitimate to the target platform while still enabling data theft and downstream credential discovery.

Q: How can security teams know whether token revocation actually worked?

A: Teams should test whether old access paths fail, not just whether the app shows as disconnected. Verify that refresh tokens, cached sessions, and legacy grant objects cannot be reused. Then confirm that the connected app no longer appears in active activity logs and that follow-on API calls are rejected.

Q: Who is accountable when a third-party integration breach spreads across SaaS systems?

A: Accountability sits with the organisation that approved the integration, the team that owns the data exposed through it, and the vendors that provide the connected-app controls. Frameworks such as OWASP Non-Human Identity Top 10 and NIST CSF support shared governance, but the security team still needs an owned revocation and review process.

Technical breakdown

OAuth-connected apps turn consent into standing access

OAuth 2.0 lets a connected app operate with delegated permissions after a user or administrator approves access. In normal conditions, the token and refresh token model is useful because it avoids repeated prompts and supports background access. The problem is that refresh tokens can behave like durable identity artifacts once issued. If an attacker steals them, they can reuse the granted scope until revocation or expiry breaks the chain. In SaaS integrations, the token often becomes more important than the account password because it can bypass interactive authentication and reach application data directly.

Practical implication: map every connected app to the exact scopes it can still exercise after initial consent.

Why token revocation is the control that actually changes the outcome

In a compromise like this, the decisive control is not detection alone. Once the attacker holds a valid OAuth token, the environment often treats the access as legitimate. That means the defensive boundary sits at revocation, reauthorization, and confirmation that old grants no longer work. If integrations are not centrally tracked, teams may revoke one app path while leaving parallel product lines or legacy connections active. This is why third-party app governance has to cover the full connected-app inventory, not just the named incident path.

Practical implication: verify that revocation terminates all related app connections, not just the visibly affected one.

Secrets stored in SaaS platforms expand breach impact

The post-compromise discovery phase matters because attackers often search for credentials cached inside the business platform they already reached. Salesforce records, case notes, and support artifacts can contain API keys, VPN credentials, Snowflake tokens, or other secrets that were never intended for long-term storage there. That creates a second identity risk: the first token breach exposes the platform, and the platform exposes still more credentials. This is why SaaS data hygiene and secrets management are linked. A compromise becomes wider when the application becomes an accidental vault.

Practical implication: search SaaS data stores for embedded secrets and remove them before they become an attacker’s next pivot point.

Threat narrative

Attacker objective: The attacker’s objective was to turn a stolen third-party integration token into access across multiple SaaS and infrastructure environments, then harvest more secrets for wider compromise.

1. Entry occurred through compromise of Salesloft Drift OAuth access tokens, giving the actor valid access to customer SaaS environments without needing fresh user credentials.
2. Escalation came from using those tokens against Salesforce and Gmail, then querying data to locate additional embedded secrets and expand access into other systems.
3. Impact followed when the actor accessed business records and discovered credentials that could be reused in AWS, VPN, and other downstream environments, broadening the breach beyond the original integration.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connected app consent is not a one-time trust decision: it is a standing identity relationship that can outlive the security assumptions made at approval time. In this incident, the token became the real subject of trust, not the user who granted access. That means third-party app governance has to be treated as an ongoing lifecycle control, not a procurement-time checkbox. Practitioners should treat every OAuth grant as an active identity object with expiry, scope, and revocation state.

Token persistence is the governance failure this breach exposes: OAuth refresh tokens were designed for convenience and continuity, but that design becomes brittle when an attacker can reuse them outside the original trust context. The failure mode is not simply compromised authentication. It is durable delegated access with no visible human session behind it. IAM and NHI programmes need to classify these tokens as high-value non-human identities because they can function longer and wider than the user who approved them.

Secrets stored inside business applications create identity blast radius: once an attacker reaches SaaS data through a compromised integration, they can often find the next credential there. That is not a separate problem, but a compounding one: the breach path moves from delegated access to credential discovery to further identity abuse. The practical implication is that SaaS platforms must be treated as potential secret repositories, not just records systems, whenever connected apps are in scope.

Third-party application control is now part of identity supply-chain defense: the incident shows how a compromise in one vendor-managed integration can propagate across customer environments with very little friction. This is the same structural problem seen in other identity supply-chain incidents. Security teams should re-evaluate whether they have a complete inventory of connected apps, whether revocation is testable, and whether downstream SaaS activity can be tied back to a specific token or grant.

Salesloft Drift exposes the gap between access approval and access accountability: the approval event happened once, but the risk lasted until the connection was revoked and the tokens were invalidated. That gap matters because governance teams often track who approved access, not how long the approval remains exploitable. Practitioners need to move from static consent records to continuous oversight of connected-app entitlements and the data they can still reach.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Forward look: Use the Guide to the Secret Sprawl Challenge to separate token revocation from broader secrets hygiene and cut off the next pivot path.

What this signals

Connected-app governance is becoming a first-class identity discipline: organisations that still treat SaaS integrations as peripheral tooling will keep missing the real control point. The practical shift is toward active oversight of consent, refresh token scope, and revocation verification across the full integration estate, not just the most visible app.

Secret sprawl inside SaaS systems is now part of breach containment: once attackers can query business platforms, they will look for credentials hidden in records, cases, and attachments. Teams should expect data loss to cascade into identity loss unless they continuously scan for secrets in SaaS content and eliminate them at source.

Identity supply-chain risk will keep widening until organisations map the full trust chain: the token, the app, the downstream SaaS, and the hidden secret are all part of one attack path. That makes this a governance problem for IAM, NHI, and SecOps together, not a point incident owned by one team.

For practitioners

• Inventory every connected app grant Build a current register of all Drift and similar third-party app connections, including which users, tenants, and scopes each grant can still exercise. Prioritise apps with refresh tokens or admin-wide consent.
• Revoke and verify token invalidation Revoke affected app connections and then test whether old access tokens, refresh tokens, and legacy app links truly fail. Do not assume reauthorization removes every active path without validation.
• Search SaaS records for embedded secrets Query Salesforce and other SaaS platforms for API keys, VPN credentials, Snowflake tokens, and similar secrets stored in notes, cases, fields, or attachments. Remove them, replace them, and investigate any use during the exposure window.
• Tighten third-party consent controls Restrict which apps can receive tenant-wide consent, require approval for high-risk scopes, and review whether user consent should be disabled for sensitive integrations. Use this incident to challenge standing approvals that were never re-reviewed.
• Instrument connected-app detection and response Ensure OAuth activity, session reuse, and anomalous app-to-data access patterns are visible in SIEM and can trigger response playbooks. Separate normal integration traffic from token abuse so revocation decisions are faster and better targeted.

Key takeaways

• The breach shows that a compromised OAuth token can behave like durable identity, not temporary access, when connected-app controls are weak.
• The scale matters because the incident extended beyond the original Salesforce path into Gmail and exposed additional secrets inside downstream systems.
• The control that would have limited this most directly is complete token revocation with verified invalidation, backed by SaaS secrets hygiene and connected-app inventory.

Key terms

• Connected App: A connected app is a third-party application that is granted access to another platform through an authorisation flow such as OAuth. In identity terms, it is a non-human access path with its own permissions, lifecycle, and revocation requirements, not just an integration convenience.
• Refresh Token: A refresh token is a credential that allows an application to obtain new access tokens without asking the user to authenticate again. In SaaS and NHI governance, it can become a durable access artifact that extends risk far beyond the original login if it is stolen or not revoked.
• Identity Supply Chain: Identity supply chain refers to the chain of trust created when one system, vendor, or integration can access another system using delegated credentials. It matters because compromise at one point can propagate through tokens, APIs, and stored secrets into unrelated environments.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials, keys, and tokens across code, tickets, chats, documents, and business applications. It increases breach impact because attackers who reach one system can often discover additional access material that was never meant to be stored there.

What's in the full article

WideField Security's full research covers the operational detail this post intentionally leaves for the source:

• The per-application impact breakdown across Drift-Salesforce and Drift Email-Gmail paths, including the specific log patterns used to validate compromise
• The incident response guidance for revoking connected app access and reauthorizing integrations in Salesforce and related systems
• The IOCs and malicious IP context that support threat hunting in SaaS activity logs
• The follow-on discussion of logging gaps, response workflow weaknesses, and why many organisations miss OAuth abuse until after data access occurs

👉 WideField Security's full post covers the Salesforce and Gmail activity, compromised token evidence, and response guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.