TL;DR: June and July 2025 Salesforce intrusions used voice phishing plus malicious OAuth Connected Apps to bypass MFA and export CRM data from dozens of organisations, with disclosed victims including Google, Qantas, Allianz Life, LVMH/Chanel, and Workday, according to Obsidian Security. The incident shows that token abuse and consent manipulation can turn routine SaaS access into large-scale NHI exposure.
At a glance
What this is: This is an analysis of the 2025 Salesforce attack wave, showing how voice phishing and malicious OAuth Connected Apps let attackers steal tokens and bulk-export CRM data.
Why it matters: It matters because IAM teams need to treat OAuth consent, API tokens, and connected-app governance as attack surface, not just Salesforce configuration or end-user training.
Context
Salesforce OAuth abuse is a governance problem as much as it is a fraud and intrusion problem. The attack path did not depend on a Salesforce platform flaw. It depended on users being induced to approve a malicious connected app, which turned routine SaaS authorization into delegated access that could be used at scale.
For IAM and NHI teams, the important issue is not the brand of platform but the control model around consent, token issuance, and API scope. Once an OAuth token is granted, the attacker no longer needs password entry or MFA prompts. That shifts the defensive question from authentication at login to governance of what can be authorized after login.
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 OAuth tokens increase the impact of voice phishing?
A: OAuth tokens convert a one-time social engineering success into reusable API authority. Once issued, the attacker no longer needs to keep tricking the user at every step. That makes the harm larger than account takeover alone, because the token can support automated extraction, lateral SaaS abuse, and delayed extortion.
Q: What signals show that mobile app governance is failing?
A: A common signal is high confidence paired with continued incidents or unexplained exposure. Another is AI deployment without monitoring of behaviour in production. If teams can describe the programme but cannot evidence runtime control, the governance model is probably measuring intent rather than actual protection.
Q: How should organisations reduce Salesforce CRM data theft risk?
A: Organisations should treat Salesforce as a governed access surface, not only a business application. That means restricting who can authorise connected apps, reviewing token scope regularly, monitoring API exports, and training help desk and end users on consent phishing. The goal is to make delegated access harder to obtain and easier to revoke.
Technical breakdown
How OAuth connected apps turn consent into delegated API access
OAuth 2.0 lets a user grant a third-party application scoped access without sharing a password. In Salesforce-style abuse, the malicious app sits behind a legitimate consent flow, so the resulting token carries the authority of the user or integration context that approved it. The control failure is not authentication at the front door, but authorization after consent. Once issued, tokens can be used directly against APIs for data export, often outside normal interactive login checks. That is why connected-app governance has to cover scopes, approval workflows, and revocation, not only identity proofing.
Practical implication: review connected-app approval paths and token scope enforcement before treating OAuth as an ordinary login control.
Why voice phishing still works against SaaS identity controls
Voice phishing is effective in SaaS environments because it targets the human decision point that sits in front of authorization. The attacker does not need to break cryptography if they can convince a user to navigate to a consent screen and enter a code that binds the wrong app to the right identity. Help desk impersonation, support-style urgency, and familiar terminology lower resistance. In this campaign, the social engineering and the OAuth flow worked together: the phone call created trust, and the malicious app captured the token that outlived the call. The weakness is procedural, not technical.
Practical implication: treat consent prompts and support channels as security controls that need verification steps, not just awareness training.
Why API exports become the real blast-radius amplifier
The data theft phase matters because API access changes the economics of exfiltration. Interactive attacks are slow and noisy, but token-backed API access can query and export large record sets in bulk, often with fewer behavioural cues than manual browsing. In this case, CRM records and related notes were the target, which makes SaaS telemetry, query patterns, and export volume more important than endpoint alerts. The issue is not merely that an account was accessed. It is that delegated access can be used programmatically at machine speed, multiplying the impact of a single consent event.
Practical implication: monitor for unusual API volume, export size, and connected-app behaviour, not only failed logins or MFA bypass attempts.
Threat narrative
Attacker objective: The attackers sought delegated access to Salesforce data that could be exported quickly, monetised through extortion, and used to pressure victim organisations.
- Entry occurred through voice phishing and helpdesk impersonation that persuaded employees to approve a malicious connected app.
- Credential access followed when the trojanized app captured OAuth tokens after the victim entered the attacker-provided code.
- Escalation happened because the tokens bypassed MFA and granted API-level authority over Salesforce data.
- Impact came from bulk exports of CRM records, followed by extortion pressure and sample-data publication in some cases.
Breaches seen in the wild
- ShinyHunters Salesforce data theft campaign 2025: Vishing calls got staff to approve malicious Salesforce connected apps that bulk-exported CRM data from Qantas, Allianz Life, Google and dozens more.
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Consent is the new trust boundary: This campaign shows that the security decision moved from password entry to app authorization. The attacker did not need to beat Salesforce authentication if they could persuade a user to approve a malicious connected app. That means SaaS governance now has to control what users are allowed to delegate, not only who they are.
OAuth tokens create identity persistence outside the login flow: A token can outlive the social engineering moment that created it and operate without the same friction as an interactive session. That makes the control problem different from classic MFA bypass. The durable risk is not just stolen credentials, but delegated authority that remains usable until revoked.
Connected-app governance is now core NHI governance: This is not an application-only problem because OAuth grants behave like non-human authority once issued. The relevant concept is delegated NHI exposure, where a user action creates a machine-consumable credential with broad API reach. Practitioners should treat app grants, scopes, and revocation as part of NHI lifecycle control, not a side issue.
Identity blast radius is determined by exportability, not just access: CRM records become far more dangerous when an attacker can bulk-export them through APIs. That shifts the governance conversation toward how much data a token can reach and how fast it can be extracted. The implication is that visibility into token use, scope, and export behaviour is now a board-level control question.
Attribution can obscure technique, but the pattern is clear: The article’s discussion of overlapping groups matters less than the repeatable technique stack of social engineering, connected-app abuse, and data extortion. Practitioners should focus on the control pattern because actor names will change faster than the abuse model. The operational lesson is to build controls for the method, not the label.
What this signals
Delegated access is now part of the identity perimeter: Security teams that still separate human login controls from SaaS consent controls are missing the point. Once a connected app is approved, the resulting token behaves like a machine credential that can be used long after the social engineering moment has ended.
The practical implication is that token lifecycle, app approval, and export monitoring need to sit alongside MFA and SSO in the same governance model. If those controls are managed separately, the organisation will keep closing the wrong part of the attack chain.
For practitioners
- Tighten connected-app approval rules Require explicit review for new OAuth Connected Apps, especially those requesting broad Salesforce scopes or offline access. Remove standing permission paths that let users authorize high-risk apps without governance review.
- Revoke and audit dormant tokens Search for unused, long-lived, or suspicious OAuth tokens and revoke them as part of a standing hygiene cycle. Prioritise any token tied to bulk export activity or to apps no longer under business ownership.
- Monitor API export behaviour Alert on large CRM exports, unusual query patterns, and new user-agent or ASN combinations that do not match normal business usage. Treat these signals as delegated-access abuse, not just data activity.
- Train staff on consent phishing Add support impersonation, code-entry scams, and malicious consent prompts to security awareness programmes. The goal is to verify app authorization requests the same way teams verify password reset or help desk requests.
- Reduce token blast radius Limit scopes, separate integration accounts from human users, and remove unnecessary export privileges from connected apps. The smaller the delegated authority, the less damage a stolen token can do.
Key takeaways
- The Salesforce attacks show that social engineering can become a scalable SaaS intrusion method when it is paired with malicious OAuth consent.
- The important control failure is not only MFA bypass but the creation of delegated API access that can persist after the initial phish.
- Reducing the blast radius means governing connected apps, token scope, and export behaviour as first-class identity controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The campaign exploited consent and token capture rather than Salesforce platform flaws. |
| NHI-05 — Overprivileged NHI | Malicious connected apps gained broader API authority than the use case required. | |
| NHI-07 — Long-Lived Secrets | Captured tokens remained usable after the initial voice-phishing event. | |
| Recommendation — Enforce stronger authorization checks around connected-app consent and revoke suspicious OAuth grants quickly. Reduce OAuth scopes and remove unnecessary export privileges from connected apps. Shorten token lifetime and rotate or revoke dormant OAuth credentials routinely. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The attack chain combined token capture with bulk CRM export and extortion. |
| Recommendation — Map consent-phishing detections to credential access and bulk-export behaviours in your threat hunting. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The key control gap was unmanaged entitlement created through app consent and token scope. |
| Recommendation — Govern entitlement grants and app permissions as part of identity authorization reviews. | ||
Key terms
- OAuth Connected App: An OAuth connected app is a third-party integration that uses approved scopes and tokens to act inside another system. For security teams, it functions like a non-human identity with persistent access and therefore needs ownership, review, and offboarding controls. Compromise of the token often becomes compromise of the trust relationship.
- Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
- 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.
- Token Lifecycle: Token lifecycle is the full sequence of issuing, refreshing, expiring, revoking, and reauthorizing a credential. For delegated access, lifecycle state is the real indicator of whether a connection is still legitimate, because a valid-looking token can still be stale, disconnected, or out of scope.
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.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org