The OAuth App Attacks Skipping MFA — What Small Practices Should Do

No Exploit Required

The most unsettling security story of the week is not about a new zero-day. It is about attackers walking straight into corporate cloud environments without exploiting anything at all. On July 14, The Hacker News reported that Microsoft mapped a full year of intrusions — from mid-2025 into mid-2026 — tied to the data-extortion group ShinyHunters, and the through-line was blunt: “No exploit was involved.”

Instead, the attackers abused the trust an organization had already extended, “usually through the OAuth connections that tie Salesforce to the apps and third-party vendors around it.” When access comes from a real user who approved a connected app, or from an integration the company already trusts, the traffic reads as ordinary use. Sign-in and authentication monitoring — the controls most teams lean on — “barely registers it.”

Three Ways In, One Common Thread

Microsoft, working with Salesforce, grouped the campaigns into three techniques. First, vishing calls: attackers posed as IT support and walked employees through Salesforce’s OAuth consent screen to authorize an attacker-controlled app “dressed up as Salesforce’s own Data Loader tool.” Once approved, that app could make API calls as the user, enumerate data, and hunt for credentials into other platforms.

Second, stolen vendor tokens. When third-party vendors like Salesloft Drift (August 2025), Gainsight (November 2025), and Klue (June 2026) were compromised, the OAuth and refresh tokens they held for their customers became keys to those customers’ data. The Drift incident alone “potentially exposed more than 700 organizations.” Third, misconfigured guest access to Salesforce sites, where an over-permissioned guest role let actors pull records they should never have seen.

The identity controls built for human logins — MFA, conditional access, session policies — do not cover the OAuth apps, integration accounts, and service credentials that do the actual work in a modern cloud stack.

That last point is the one to sit with. As Microsoft put it, those machine identities “mostly sit outside all of it, unwatched and over-permissioned.” And it is not a Salesforce-only problem. The same week, BleepingComputer detailed new phishing kits — Jalisco and OmegaLord — built to defeat MFA on Microsoft 365, including device-code phishing that “abuses the OAuth 2.0 Device Authorization Grant flow” to get an attacker’s device authorized without ever needing a password.

Why This Matters for a Small Practice

It is easy to read “Salesforce” and “Chanel” and assume this is an enterprise story. It is not. A small medical or dental practice runs on cloud software too — practice-management systems, patient-communication platforms, billing services, scheduling tools, an AI note-taker someone tried last quarter. Many of those are connected to your Microsoft 365 or Google Workspace with a single “Allow” click, and each of those connections can read or move data on a staff member’s behalf. Some of that data is electronic protected health information (ePHI).

If you have turned on multi-factor authentication where it matters — and you should — that is real progress against password theft. But MFA protects the human login. It does not, by itself, watch what an approved app does once it is inside, and it does not stop a compromised vendor from misusing a token you granted months ago. This is the same lesson underneath the shared-responsibility model for healthcare SaaS: the platform secures its side, but the connections you approve are yours to govern.

Where to Start

You do not need enterprise tooling to close most of this gap. Microsoft’s own advice reduces to plain steps any practice can take: “Inventory the connected apps, cut the ones nobody uses, scope the rest to least privilege, and be ready to revoke and rotate tokens the moment an integration starts behaving oddly.” Turn on and actually review the event logs your SaaS platforms already offer, and lock down guest access.

Two practical moves this week: open the third-party app permissions page in your Microsoft 365 or Google Workspace admin console and look at what has access — you will likely find apps nobody remembers approving — and confirm that every vendor touching ePHI has a signed business associate agreement on file. For a full walkthrough of how to run that review, see our companion guide on auditing third-party app access. Cybersecurity is a team effort, and this is one review a practice and its IT partner can do together in an afternoon.

Byzantine takeaway: The attackers in this story did not break a lock. They used a door someone had already propped open. Knowing which apps can reach your patient data — and closing the ones that shouldn’t — is a small, unglamorous habit that shrinks exactly the kind of trusted-connection foothold behind this year’s run of SaaS breaches.