ShinyHunters Turned OAuth Consent Into a Master Key: The 2026 Salesforce Breach Wave

In July 2026, Microsoft detailed how the extortion crew ShinyHunters spent a year quietly draining Salesforce tenants across retail, healthcare, aviation, and tech — and it did so without cracking a single password. The ShinyHunters Salesforce OAuth campaign abused the one thing multi-factor authentication was never designed to stop: a user who voluntarily clicks "Allow." Where older breaches stole credentials, this one stole trust, tricking employees into authorizing a malicious connected app that then held a valid API token indefinitely.

That distinction matters for anyone running a SaaS stack. The attackers rarely touched the login screen, so MFA prompts, impossible-travel rules, and sign-in alerts mostly stayed silent. If your security model assumes "we have MFA, so we're covered," this campaign is the case study that proves otherwise.

What actually happened

Between mid-2025 and mid-2026, ShinyHunters (tracked by Google's Mandiant as UNC6040 for the vishing activity and UNC6395 for the token theft) ran an industrial-scale operation against Salesforce customers. The Hacker News summary of Microsoft's threat intel puts the affiliate claims at close to 1,000 organizations touched, though many remain unconfirmed. The prize was CRM data — customer records, support tickets, contact lists — which the group then used for extortion, threatening to leak it unless victims paid.

The clever part was persistence. A stolen OAuth token doesn't expire when a password is reset or when the phished employee changes their MFA device. As Microsoft noted, most Salesforce logging "was not built to show" what happens after authorization, so the malicious API calls blended into normal automation traffic for weeks.

The three ways in

Microsoft and Google Cloud's threat intelligence team describe three distinct entry paths, all of which end in the same place: an attacker-controlled OAuth grant.

Attack path	How it worked	Key detail
Voice phishing (vishing)	Callers posed as IT support and walked employees through Salesforce's OAuth consent screen	Victims authorized a malicious app impersonating Salesforce's Data Loader, sometimes renamed "My Ticket Portal"
Supply-chain token theft	Attackers breached trusted integrations and reused their OAuth tokens against downstream tenants	Salesloft/Drift (Aug 2025), Gainsight (Nov 2025), and Klue (June 2026); reporting puts the downstream exposure at 700+ and 200+ orgs respectively
Misconfigured guest access	Over-permissioned Experience Cloud guest roles let unauthenticated users read data	Actors used GraphQL pagination to slip past the 2,000-record query limit

The vishing path is the headline because it needs no software vulnerability at all — just a convincing phone call and a distracted admin. The supply-chain path is arguably worse: a single breach at a vendor like Salesloft handed the attackers a ring of keys to hundreds of customer orgs that never made a mistake themselves.

Why OAuth abuse walks straight past MFA

This is the detail most coverage glosses over, and it's the reason the campaign worked for so long. OAuth consent is designed to delegate access. When an employee approves a connected app, Salesforce issues a long-lived token that lets that app call the API on the user's behalf — no repeated login, no fresh MFA challenge. That is the entire point of OAuth, and it's why "just turn on MFA" is not a defense here.

Once the token exists, the attacker operates as a trusted application, not as a suspicious login. There's no anomalous geolocation to flag because the API calls originate from the app's own infrastructure. Sign-in risk policies never fire because there's no sign-in. Password rotation does nothing because no password is involved. Revoking the token is the only real kill switch — and you can only revoke what you can see, which is precisely what Salesforce's default logging made hard. This is the same "identity is the new perimeter" lesson behind zero trust migrations: the network edge is irrelevant when the attacker arrives holding a valid credential.

Who got hit

The victim list reads like a corporate who's-who. Public reporting and leak-site postings tie the broader ShinyHunters Salesforce activity to Google, Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, Qantas, Allianz Life, Adidas, Chanel, Pandora, and several LVMH brands, among others. Security vendors were not spared — Tanium, Huntress, and Recorded Future appear in reporting too, a pointed reminder that OAuth consent risk is universal, not a small-company problem.

Healthcare drew specific attention. Health-ISAC issued mitigation guidance after the group's activity spilled into the sector, and financial regulator FINRA published its own Salesforce Experience Cloud alert covering the guest-access misconfiguration path.

How to lock down OAuth consent in your own org

The fix is governance, not a patch — and it applies to any SaaS platform that supports third-party app authorization (Google Workspace and Microsoft 365 have the same exposure). A practical checklist:

• Restrict who can consent. Turn off end-user OAuth consent and route all new connected-app approvals through an admin review queue. In Salesforce, lock down the "Connected Apps OAuth Usage" settings; in Microsoft 365, use app consent policies and conditional access.
• Inventory and prune existing grants. Review every authorized connected app and revoke anything unused, unrecognized, or dormant. A token from an app nobody remembers installing is your highest risk.
• Watch the right logs. Sign-in logs won't catch this. Monitor OAuth authorization events, connected-app API call volume, and bulk data-export patterns instead. Sudden mass reads from a rarely used app are the tell.
• Train staff on consent-screen vishing. The final click is human. Make sure employees know IT will never phone them and talk them through an OAuth "Allow" prompt.
• Vet your integration vendors. The Salesloft and Gainsight breaches show your Salesforce security is only as strong as the third parties you've granted tokens to — the same supply-chain lesson from the npm Shai-Hulud crisis.

FAQ

Did ShinyHunters exploit a Salesforce vulnerability? No. There was no flaw in Salesforce itself. The attackers abused legitimate OAuth consent and misconfigured guest access — a case of features working as designed being turned against users.

Would MFA have stopped this? Not on its own. MFA protects the login, but OAuth token abuse happens after a user has already authorized an app. The defense is consent governance and token monitoring, not stronger login factors.

What is a "connected app" in this context? It's a third-party application granted API access to a Salesforce org via OAuth. Legitimate ones (Data Loader, analytics tools) are common, which is exactly why a malicious clone slips through.

How do I know if I was affected? Audit your authorized connected apps and OAuth grants, revoke anything unfamiliar, and review API call logs for unusual bulk exports. If you use Salesloft, Gainsight, or Klue, treat their disclosed incidents as a prompt to rotate tokens.

Is this only a Salesforce problem? No. Any SaaS platform with third-party OAuth — Google Workspace, Microsoft 365, Slack, GitHub — carries the same consent-phishing risk. The playbook above is platform-agnostic.

Sources

• Microsoft Security — Defending SaaS-based applications against ShinyHunters OAuth abuse (July 13, 2026) — primary threat-intel disclosure and defensive recommendations.
• The Hacker News — Microsoft maps year-long ShinyHunters activity — attack-path summary, scale, and victim reporting.
• Google Cloud Threat Intelligence — Proactive defense against ShinyHunters SaaS extortion — UNC6040/UNC6395 tracking and detection guidance.
• Varonis — Salesforce vishing threat (UNC6040) — Data Loader impersonation mechanics.
• Mitiga — ShinyHunters and UNC6395: the Salesforce and Salesloft breaches — supply-chain token theft detail.
• Health-ISAC — ShinyHunters impact to the health sector — sector mitigation guidance.
• FINRA — Salesforce Experience Cloud security alert — guest-access misconfiguration path.