Salesforce OAuth abuse shows how social engineering scales NHI risk

At a glance

What this is: Obsidian Security’s analysis says the 2025 Salesforce attacks combined voice phishing with malicious OAuth app consent to steal CRM data at scale.

Why it matters: For IAM and NHI teams, the case shows that MFA alone does not stop consent-driven token abuse when users can authorize risky connected apps.

👉 Read Obsidian Security's analysis of the 2025 Salesforce OAuth abuse campaign

Context

Salesforce data exposure through OAuth abuse is a governance problem, not a platform defect. When attackers can socially engineer consent and obtain tokens, they move through NHI pathways that many IAM programs still treat as routine application access.

The article centers on how social engineering, connected apps, and API tokens combined to bypass normal control expectations. That pattern is now familiar across SaaS environments, which makes Salesforce less an outlier than a warning about where NHI governance breaks down.

Key questions

Q: How should security teams reduce the risk of OAuth consent abuse in SaaS platforms?

A: Security teams should restrict who can approve connected apps, require review for high-risk scopes, and continuously monitor new grants and token use. Consent events should be treated as privileged changes because they can create durable API access even when MFA is enabled. Pair that with fast revocation and export anomaly detection.

Q: Why do MFA controls fail against token-based SaaS attacks?

A: MFA stops many interactive logins, but it does not govern what happens after a user authorizes a third-party app. If attackers obtain OAuth tokens, they can use legitimate API paths without repeating the login step. The control gap is in delegated authorization and token lifecycle management, not just authentication strength.

Q: What is the difference between a stolen password and a stolen OAuth token?

A: A stolen password is a direct credential for logging in, while a stolen OAuth token is delegated access already granted through a trusted app or session. Tokens often bypass repeated authentication checks and can be used through APIs for specific scopes. That makes token theft especially dangerous in SaaS environments.

Q: When should organisations treat connected apps as high-risk identities?

A: Organisations should treat connected apps as high-risk identities whenever they can access customer data, administrative functions, or bulk export capabilities. If the app can act at scale through APIs, it deserves lifecycle controls, scope review, and revocation procedures similar to privileged access. Convenience is not a safe default.

Technical breakdown

How OAuth connected apps become an NHI attack path

OAuth connected apps create delegated access by letting an application act on a user’s behalf after consent is granted. In this campaign, the attacker did not need Salesforce platform exploitation. Instead, the malicious app captured OAuth tokens that were then reused through the API, which means the access layer itself became the compromise point. That matters because tokens often inherit trust from the consenting user and can outlive the original session, especially when monitoring is weak. Practical implication: treat connected app grants as privileged events, not ordinary configuration noise.

Practical implication: Review and restrict OAuth consent flows with the same discipline used for privileged account changes.

Why MFA did not stop the Salesforce data theft

MFA protects the authentication step, but it does not automatically govern what happens after a user authorizes a third-party app. Once the attacker captured tokens, the API path bypassed the interactive login boundary and could be used for bulk export activity. This is a classic NHI failure mode: the identity is valid, the session is delegated, and the downstream permissions are broader than defenders expect. Practical implication: pair phishing-resistant MFA with token lifecycle controls, app approval rules, and export anomaly detection.

Practical implication: Do not treat MFA as a complete defense when token issuance and app consent remain exposed.

Why bulk exports are the real operational signal

The meaningful technical indicator is not simply that access occurred, but that the attackers were able to use the Salesforce API for large data exports. In NHI terms, this is an entitlement misuse problem with business impact. Records such as names, emails, phone numbers, account notes, and loyalty data can be exfiltrated through legitimate interfaces without malware or persistence on endpoints. Practical implication: monitor for abnormal API volume, unusual query patterns, and connected apps that begin behaving like extraction tools.

Practical implication: Use API and export telemetry to detect when delegated access turns into data harvesting.

Threat narrative

Attacker objective: The objective was to steal high-value CRM data at scale and use the exposure for pay-or-leak extortion.

1. Entry occurred through voice phishing and helpdesk-style social engineering that convinced users to authorize a malicious Salesforce connected app.
2. Escalation followed when the trojanized app captured OAuth tokens, giving the attackers API access that bypassed MFA controls.
3. Impact came from bulk Salesforce exports that exposed CRM records and enabled extortion against multiple organisations.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

OAuth consent is now a privileged action, not a user convenience. When a social engineer can convert a routine app approval into durable API access, the real control failure sits in identity governance rather than the application tier. Security teams that still treat connected app consent as low-risk are leaving a direct path into SaaS data stores. The practitioner conclusion is to manage consent events as high-signal identity changes.

Salesforce is not the issue, delegated trust is. The campaign shows how a valid SaaS login can be turned into a non-human access channel that behaves like a workload identity without workload controls. That is the governance gap: human workflows are being used to mint machine-grade access. Teams need policy, logging, and review controls that understand delegated tokens as a separate risk class.

Identity blast radius is the right concept for this class of attack. A stolen token can be narrow in issuance but broad in effect once it reaches APIs, exports, and downstream data. The problem is not only compromise, but how far that compromise can travel before controls notice. Practitioners should map where a single consent grant can expand into enterprise-scale exposure.

Social engineering and OAuth abuse are converging into a repeatable NHI pattern. The article’s overlap between groups matters less than the mechanism they used, because the same playbook can be reused across SaaS platforms. This points to a category problem, not a one-off incident. Security leaders should treat consent abuse, token replay, and export abuse as a single governance domain.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and a further 47% only partial visibility.
• That visibility gap is one reason teams should anchor their response in Ultimate Guide to NHIs , Key Challenges and Risks and tighten control over delegated access paths.

What this signals

Ephemeral-looking SaaS access still creates long-tail identity risk. When tokens can outlast the interaction that created them, the programme problem is lifecycle control, not password hygiene. IAM teams should expect consent abuse to keep surfacing wherever business users can authorize powerful apps without a separate approval step.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is moving toward explicit control of tokens, service accounts, and connected apps. For readers, that means existing visibility tools are no longer enough unless they can explain who authorized access, what scope was granted, and when it should be revoked.

For practitioners

• Restrict OAuth connected app consent Require approval workflows for new connected apps, limit who can authorize them, and block high-risk scopes by default. Review grants as part of access governance, not just application administration.
• Monitor token-driven export behaviour Alert on abnormal Salesforce API volume, large object exports, unfamiliar user-agent patterns, and anomalous ASN geographies. These signals often surface earlier than obvious account takeover indicators.
• Harden helpdesk and user verification paths Train support staff and users to treat app-authorization requests as suspicious until verified through an out-of-band process. Voice phishing remains effective because it shortcuts normal trust decisions.
• Map delegated access to NHI controls Classify OAuth tokens, integration users, and connected apps as non-human identities with their own lifecycle, review, and revocation requirements. That gives IAM teams a way to govern the access path actually used in the attack.

Key takeaways

• The attack path used legitimate SaaS trust to turn user consent into scalable non-human access.
• Bulk API exports, not login success alone, are the operational signal that matters most to defenders.
• Teams need to govern connected apps, tokens, and delegated access as part of the NHI lifecycle.

Key terms

• OAuth Connected App: An OAuth connected app is a third-party application that receives delegated access to a platform after a user grants consent. In SaaS environments, it can act with the user’s permissions through API calls, which makes app approval and token scope management central to identity governance.
• OAuth Token: An OAuth token is a bearer credential issued after authorization that lets an application access resources without re-entering the user’s password. In practice, it becomes a high-value non-human credential because whoever holds it can often use the associated API permissions until it expires or is revoked.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and systems that can be reached if a credential, token, or delegated grant is abused. It is a useful NHI governance concept because it shifts attention from whether access was obtained to how far that access can spread before controls stop it.
• Delegated Access: Delegated access is a permission model where one identity or application acts on behalf of another after explicit authorization. It is common in SaaS and API integrations, but it also creates hidden trust paths that must be governed like privileged access when the delegated entity can read, export, or modify sensitive data.

Deepen your knowledge

Salesforce OAuth abuse, delegated tokens, and connected app governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for SaaS identity risk, it is worth exploring.

This post draws on content published by Obsidian Security: ShinyHunters and Scattered Spider: A Merger of Chaos in the 2025 Salesforce Attacks. Read the original.