Salesforce OAuth token abuse shows the NHI trust gap in integrations

At a glance

What this is: This is an analysis of a Salesforce data-theft campaign that abused stolen OAuth tokens to move through trusted integrations and search for higher-value secrets.

Why it matters: It matters because many IAM programmes still treat third-party application access as routine integration management rather than governed NHI exposure across NHI, autonomous, and human identity boundaries.

👉 Read Astrix Security's analysis of the Salesforce OAuth token abuse campaign

Context

OAuth tokens are non-human identities, and in this campaign they acted as a trusted entry point into Salesforce data rather than a secondary artifact. When an attacker can use a stolen token to query business systems directly, MFA does not help and the real control question becomes how integrations are governed, scoped, and monitored.

The article's core issue is not just data theft. It is that connected applications often carry persistent access, broad visibility, and weak lifecycle oversight, which turns a compromise in one service into a search path for more secrets in others. That is a familiar NHI problem, but it still gets handled as routine app integration risk in many programmes.

Key questions

Q: What breaks when an OAuth-connected app is compromised in Salesforce?

A: When a Salesforce-connected app is compromised, the token becomes a trusted identity that can query data, export records, and search for embedded secrets without bypassing MFA. The failure is not the login flow, but the assumption that approved integrations are low-risk. Teams should treat each token as a governed NHI with explicit scope, ownership, and revocation controls.

Q: Why do third-party integrations create so much NHI risk?

A: Third-party integrations create NHI risk because they often hold persistent access to valuable business data while operating outside day-to-day user supervision. If the integration stores or exposes secrets, one compromised token can reveal other credentials and expand the blast radius across environments. This is why lifecycle oversight matters as much as initial approval.

Q: How do security teams know if a SaaS integration is overprivileged?

A: A SaaS integration is overprivileged when it can read more objects, export more records, or access more sensitive fields than it needs for its stated purpose. Strong indicators include broad read access, bulk export capability, and scope creep after onboarding. Teams should compare granted permissions to actual usage and remove anything not justified by business function.

Q: Who is accountable when a stolen OAuth token exposes cloud secrets?

A: Accountability sits with the organization that approved, owned, and monitored the integration, not only with the vendor whose app was abused. Once a token is issued, the enterprise must govern its lifecycle, logging, and revocation, and it must also assume exported data may contain other credentials. That makes IAM, security operations, and application owners jointly responsible.

Technical breakdown

Stolen OAuth tokens as trusted integration access

OAuth tokens let one application act on behalf of another without repeated user authentication. In a Salesforce context, that makes the token itself the identity control plane for the connection, because the downstream app trusts the token until it is revoked or expires. Once a token is stolen, the attacker does not need to defeat MFA or steal a password. They inherit the authorization boundary already granted to the integration. That is why token protection, scope limitation, and revocation hygiene matter more than the authentication ceremony around the original user sign-in.

Practical implication: inventory every third-party OAuth connection and treat each token as a governed NHI with a lifecycle, scope, and revocation owner.

Why data export becomes secret harvesting

This campaign used Salesforce access as a discovery layer, not just a theft endpoint. Attackers exported large volumes of records and then searched them for high-value secrets such as AWS keys and Snowflake tokens. That pattern matters because business applications often become accidental secret stores when teams paste credentials into tickets, notes, objects, or attachments. The attacker is not limited to the application's native data. They can use one compromised NHI to uncover other NHIs, creating a chain of exposure that crosses platforms and teams.

Practical implication: extend secret discovery and DLP-style detection into SaaS objects, not just code repositories and vaults.

Log retention is what makes investigation possible

GTIG noted that query jobs were deleted, but Salesforce logs remained intact for investigation. That distinction is important because adversaries often try to erase the obvious evidence while leaving the authoritative audit trail in place. In integration abuse cases, logs are the only reliable record of which token acted, what it accessed, and how much was exported. Without retained application and identity logs, teams cannot reconstruct the blast radius or prove whether other integrated systems were reached through the same credential path.

Practical implication: verify that SaaS audit logs, API logs, and integration telemetry are retained long enough to support token-abuse investigations.

Threat narrative

Attacker objective: The objective was to turn trusted SaaS integration access into a broader credential-harvesting operation that could unlock further environments.

1. Entry occurred through stolen OAuth tokens tied to the Salesloft Drift integration, which gave the actor trusted access into Salesforce instances.
2. Credential access followed as the actor exported data at scale and searched the content for AWS access keys, Snowflake tokens, and other high-value secrets.
3. Impact was data-theft exposure across Salesforce organizations, with the added risk that any harvested secrets could support follow-on compromise in cloud and analytics environments.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Third-party OAuth tokens are not a convenience layer, they are governed NHI credentials. This campaign worked because the integration identity was trusted inside Salesforce even after the original token was compromised. That means the security boundary was defined by the token's privileges, not by the user's MFA state or workstation hygiene. For IAM teams, the practical conclusion is that every connected app needs lifecycle ownership, scope review, and revocation accountability as part of NHI governance.

Integration access without secret hygiene creates an identity blast radius. The attacker used one trusted path to search for another class of credentials, which shows how SaaS objects can become a bridge between business data and infrastructure access. This is the failure mode that matters: a single over-trusted NHI can expose multiple downstream systems when secrets are stored in the wrong place. Practitioners should read this as a governance problem, not just a detection problem.

Persistent app trust is the real control gap this incident exposes. The campaign succeeded because organizations often assume third-party access is harmless once approved, even when the app can read large data sets and search for secrets. That assumption fails when the app becomes an exfiltration channel. The implication is that access approvals for integrations must be treated as living entitlements, not one-time onboarding events.

Salesforce-style integration sprawl now demands cross-domain identity oversight. The same connected app can sit at the intersection of human approvals, NHI tokens, and cloud secrets stored in application data. That makes cross-domain visibility more valuable than isolated product controls. Security teams need a single view of who or what can act, what data it can export, and which other credentials it can reveal.

Secret discovery in SaaS data should be treated as a primary threat path. Attackers are increasingly using business platforms as hunting grounds for cloud keys, API tokens, and service credentials. That means the old separation between “application data” and “identity secrets” no longer holds. The control model has to assume that exported records may themselves contain the next compromise vector, and practitioners should prioritize visibility into secret-bearing data stores.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, increasing the risk of accidental exposure and making downstream remediation slower.
• Forward look: The right lens is not just token rotation, but full lifecycle visibility across NHI credentials, as set out in Ultimate Guide to NHIs.

What this signals

Identity blast radius is now the most useful way to think about connected-app risk. A single integration token can expose business data, surface additional secrets, and create a secondary compromise path into cloud services. That means IAM teams need to manage not just who can connect an app, but what the app can reveal if it is abused. The difference between a routine integration and an exploitable identity surface is often the amount of secret-bearing data it can read.

Persistent trust in SaaS integrations will keep failing until lifecycle ownership becomes explicit. The article points to a wider programme gap: approvals are often granted at onboarding, but review, monitoring, and offboarding lag behind. As the 2025 State of NHIs and Secrets in Cybersecurity shows, 44% of NHI tokens are exposed in the wild, which makes dormant integration trust a structural risk rather than an edge case.

Secret-sprawl controls need to move into collaboration platforms and SaaS data stores. If attackers can harvest cloud keys from exported records, then the control boundary extends beyond source code and vaults. Teams should align SaaS logging, content scanning, and entitlement review to the same standard they already expect from other NHI control planes.

For practitioners

• Revoke and re-authorize third-party integrations on a schedule Assign an owner to every OAuth-connected application, review scopes quarterly, and force re-authorization when business purpose or permissions change. Treat stale app access as an NHI lifecycle failure, not a housekeeping issue.
• Search SaaS content for embedded secrets Scan Salesforce objects, tickets, notes, and attachments for AWS keys, Snowflake tokens, GCP service-account keys, and other credentials that attackers can harvest after bulk export. Include both historical and newly created content in the search scope.
• Retain and centralize integration logs Keep API, query, and audit logs long enough to reconstruct bulk export activity and token misuse. Correlate application logs with identity telemetry so investigators can trace which integration acted and what it touched.
• Constrain app scopes to the minimum usable data set Limit third-party applications to the smallest object set and permission set they genuinely need. Reassess whether any integration can read sensitive fields or bulk-export records without a specific business justification.
• Link secret discovery to incident response When a connected app is compromised, assume exported data may contain credentials for other platforms and trigger a hunt for reused or exposed secrets across cloud and analytics systems.

Key takeaways

• This incident shows that stolen integration tokens can function as full identity credentials inside core SaaS platforms.
• The exposure scales because exported business data can contain the next wave of secrets, turning one compromise into several.
• The limiting control is not MFA, but token lifecycle governance, scope restriction, and retained audit evidence.

Key terms

• OAuth Token: An OAuth token is a delegated credential that lets one application act inside another system without repeated user sign-in. In NHI governance, the token itself becomes the identity artifact to secure, scope, rotate, and revoke because it can carry trusted access long after the original approval moment.
• Third-Party Integration: A third-party integration is a connection between a core business system and an external application that can read, write, or export data. These connections often become NHI risk points because they inherit broad trust, persistent permissions, and weak lifecycle oversight unless they are actively governed.
• Secret Sprawl: Secret sprawl is the uncontrolled duplication and placement of credentials, tokens, keys, and certificates across systems that were never meant to store them. It increases exposure because attackers only need to find one leaked copy to expand compromise into other environments.
• Identity Blast Radius: Identity blast radius is the amount of damage that can follow from the compromise of one identity, token, or integration. For NHIs, it is measured by how many systems, data sets, and downstream secrets the compromised credential can reach before it is detected or revoked.

What's in the full article

Astrix Security's full article covers the operational detail this post intentionally leaves for the source:

• GTIG advisory timing, incident sequence, and the specific Salesforce/Drift response actions
• Practical remediation steps for revoking Drift-related access tokens and validating affected exports
• The article's recommended process for hunting secrets inside potentially exfiltrated Salesforce data
• Astrix Security's guidance on investigating third-party integrations across the wider NHI estate

👉 The full Astrix Security post covers the attack sequence, token response, and remediation steps

Deepen your knowledge

OAuth token governance and secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are managing third-party integrations that can read or export sensitive data, it is worth exploring.