Salesforce OAuth token abuse shows the NHI trust gap in integrations

At a glance

What this is: This analysis explains how stolen OAuth tokens tied to the Salesloft Drift app let UNC6395 access Salesforce orgs and hunt for higher-value secrets inside exfiltrated data.

Why it matters: It matters because integration tokens can bypass MFA and become a hidden credential layer that IAM, PAM, and NHI governance must inventory, scope, and revoke quickly.

Context

OAuth-connected integrations create a trust layer that often sits outside the same controls used for human authentication. When those tokens are stolen, the attacker does not need to beat MFA or phish a user session, because the integration itself already carries standing access into business systems.

This article focuses on a Salesforce campaign in which compromised Drift OAuth tokens were used to export data and search for secrets inside Salesforce content. The governance problem is not limited to one vendor or one platform; it is the assumption that third-party application access is less sensitive than direct user access.

For IAM and NHI teams, the key issue is lifecycle control over integration tokens, their scope, and their revocation path. Once a SaaS-to-SaaS token can read large volumes of data, it becomes a high-value identity in its own right.

Key questions

Q: Who is accountable when a SaaS integration token is stolen?

A: Accountability should be shared, but operational ownership must be explicit. The business owner, identity team, and vendor all have different responsibilities, yet someone inside the enterprise must own review, rotation, and revocation. Without a named owner, the credential becomes a governance orphan and attackers benefit from the gap.

Q: Why do delegated NHI tokens create more risk than direct user login in SaaS?

A: Delegated tokens can outlive the login session that created them and often retain access until explicitly revoked. That makes them attractive to attackers because they can operate without password resets or MFA prompts. The risk is highest when the token can read or export data that contains other secrets, turning one compromise into several.

Q: What do security teams get wrong about OAuth and connected apps?

A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust. OAuth grants can outlive the original need, inherit too much scope, or become a bridge into multiple SaaS tenants. Security teams should treat each grant as a revocable access path, not a permanent integration.

Q: How should organisations respond when a third-party Salesforce integration leaks secrets?

A: Contain the integration first by revoking the affected tokens, then check whether the exported or queried data contains reusable credentials such as cloud keys or API tokens. After containment, review whether the integration had broader object access than needed and whether similar connections exist elsewhere in the SaaS estate.

Technical breakdown

How stolen OAuth tokens become trusted Salesforce access

OAuth tokens are bearer credentials, which means possession is enough to present the identity and its granted scope. In a SaaS integration, the token often inherits access that was approved once at connection time and then reused without continuous human interaction. That changes the defensive problem from login protection to credential lifecycle management. If a token is copied, replayed, or exfiltrated from a connected app, the attacker can operate through a legitimate path and avoid the normal friction that protects interactive users. This is why integration scope, token revocation, and service ownership matter as much as authentication strength.

Practical implication: treat integration tokens as revocable identities with explicit ownership, scope review, and expiry discipline.

Why MFA does not protect delegated SaaS-to-SaaS access

MFA protects interactive authentication, not every downstream credential that an approved application holds. Once a third-party app receives an OAuth token, the subsequent access path can bypass user-facing challenge steps entirely. That makes MFA an incomplete control when the real exposure is delegated access, especially in environments where apps can read records, export data, or query objects at scale. The correct security question is not whether the user logged in securely, but whether the delegated token should have existed, what it could see, and how quickly it can be removed when the relationship changes.

Practical implication: pair MFA with strict app governance, token scoping, and rapid revocation for delegated access.

How credential harvesting turns business data into a second-stage attack surface

Credential harvesting is a follow-on objective where the attacker searches exfiltrated business data for secrets such as cloud keys, tokens, or certificates. In this campaign, the threat actor reportedly hunted for AWS keys and Snowflake tokens after entering Salesforce, which shows that SaaS compromise is often a stepping stone into other environments. The architecture lesson is that business applications can become secret repositories whether or not they were designed that way. That means data classification and secret detection must extend into collaboration and CRM systems, not stop at code repositories and vaults.

Practical implication: scan SaaS data stores for embedded secrets and treat CRM exports as potential credential spill zones.

Threat narrative

Attacker objective: The attacker sought to turn Salesforce data access into reusable credentials for broader cloud compromise and deeper data theft.

1. Entry occurred through stolen OAuth tokens tied to the Salesloft Drift application, giving the actor legitimate delegated access into Salesforce organisations.
2. Credential abuse followed as the actor used that access to export data and search for embedded secrets such as AWS keys and Snowflake tokens.
3. Impact came from potential follow-on compromise of other environments if harvested credentials were reused beyond Salesforce.

Breaches seen in the wild

• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Delegated OAuth access is part of the NHI attack surface, not a separate application convenience layer. The campaign shows that a third-party token can function as a durable identity with enough privilege to expose business data and search for secrets. That makes SaaS-to-SaaS connectivity a governance domain, not a simple integration feature. Practitioners should classify these tokens with the same seriousness they apply to service accounts and other non-human credentials.

Trust in integrations collapsed because the control model assumed the token would remain lower risk than the data it could reach. That assumption fails when a bearer token can silently query and export large volumes of content while bypassing MFA. The implication is that least privilege must be evaluated at the integration layer, not only at the human account layer.

Credential harvesting from business applications is now a repeatable identity threat pattern. Once attackers can search CRM exports for keys and tokens, a single SaaS compromise can become a staging point for cloud compromise elsewhere. NHI governance therefore needs to treat downstream secret exposure as a first-class risk, not an incidental consequence.

Salesforce integration governance belongs in the same conversation as PAM and lifecycle control. The question is not only who approved the connection, but who owns it, how often it is recertified, and how quickly access can be revoked when the vendor relationship changes. Practitioners should fold third-party app governance into standard identity review cycles.

Identity blast radius is the right concept for this kind of incident. A single token can reach far beyond its original application boundary if the connected platform stores operational secrets or sensitive customer data. Teams need to map where delegated access can widen the blast radius before an attacker does.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Identity blast radius: Once a delegated token can read operational data, the question shifts from login security to how far one credential can propagate across connected systems. For IAM teams, that means mapping not only who can log in, but which integrations can expose secrets to the next environment in the chain.

SaaS-to-SaaS governance is becoming a core NHI discipline because the integration layer now carries long-lived trust and often escapes human-centric review. The practical test is simple: if an attacker stole the token, would the current programme notice the loss before the token had time to be used?

For practitioners

• Inventory all OAuth-connected apps Build a complete list of third-party integrations connected to Salesforce and other business SaaS platforms, then identify which tokens can export data or read sensitive objects.
• Revoke and reissue standing tokens Remove tokens that are no longer required, shorten token lifetimes where possible, and define an emergency revocation path for compromised integrations.
• Scope integration permissions to minimum access Review each connected app for object-level and export permissions, then remove any access that is not required for the app's actual function.
• Hunt for secrets inside SaaS exports Search Salesforce records, attachments, and exported datasets for cloud keys, tokens, certificates, and similar secrets that could be reused in follow-on attacks.
• Fold third-party app access into recertification Include delegated application access in regular access reviews so owners must confirm both the business need and the current scope of each integration.

Key takeaways

• The core risk is not the Salesforce platform itself but the delegated trust granted to a third-party OAuth token.
• The campaign used stolen integration credentials to export data and search for cloud secrets, which can widen impact beyond the original SaaS.
• Teams should treat connected-app tokens as governed identities, with tight scope, fast revocation, and lifecycle review.

Key terms

• OAuth Token Abuse: The misuse of valid OAuth access or refresh tokens to gain unauthorized access without repeating the original login. In NHI terms, the token becomes the credential, so the real control problem is issuance, storage, scope, and revocation rather than passwords alone.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 building or maturing an IAM programme, it is worth exploring.