On July 24, Health-ISAC issued an advisory warning healthcare and medical technology organizations about a measurable rise in successful attacks by the extortion group ShinyHunters. One line from that advisory is worth pinning to the wall:

“SSO is the control plane, and ShinyHunters’ leverage is created through data theft at cloud scale.”

The pattern the advisory describes is consistent enough to plan against. Voice phishing calls target employees or help desk staff and pressure them into resetting a password, resetting MFA, or enrolling a new device. The attacker then signs in as a real user, lands on the Okta, Entra ID, or Google SSO dashboard, and reads it as a directory of everything that person can reach: Salesforce, Microsoft 365, SharePoint, DocuSign, Slack, Atlassian, Dropbox, Google Drive. What follows is bulk read and export, then extortion.

Health-ISAC is careful about names. The advisory does not identify affected organizations, and it warns that not every claim the group makes has been verified. Its guidance is to defend against the attack pattern rather than the headline. BleepingComputer has reported incidents at healthcare and medtech companies including Medtronic, DentaQuest, iRhythm, and OneMedical, and McKesson disclosed a breach along similar lines in August.

SSO centralizes authentication. It does not secure SaaS.

Single sign-on is genuinely load-bearing, and I have argued for it as a security control rather than a convenience feature. Without it, your MFA policy is only as strong as the app that doesn’t route through it.

But SSO answers exactly one question: is this a real session? It has nothing to say about where they are logging in from, what machine they are sitting at, what that account should be able to reach at all, or whether pulling a hundred thousand patient records in an afternoon is normal for this account. Those are four separate controls, and many organizations have configured none of them.

Gate 1. The help desk: where Health-ISAC starts

Health-ISAC’s first recommendation is to break the chain between the inbound call and the account takeover, and it is the cheapest work on this page. The specific asks:

  • Out-of-band verification for every password reset, MFA reset, and device re-enrollment request. Call the user back on a phone number you already had on file, not the one on the ticket. Even better: use video calling to help validate the user.
  • A no same-call policy. No credential or factor changes during the inbound call that requested them. The request becomes a ticket, the ticket gets a verified callback, and only then does anything change.
  • Manager approval and extra verification for privileged accounts and high-risk groups: executives, IT administrators, security staff, finance.
  • Phishing-resistant MFA (FIDO2 or WebAuthn security keys) for those same groups first. Disable or tightly restrict SMS and voice factors, and gate the registration of a new factor behind a managed device or a conditional access policy.
  • Treat the identity provider as Tier 0. Restrict admin portals to managed devices, block legacy authentication, and require compliant devices for sensitive cloud services.

Health-ISAC frames these as 30 to 60 day priorities.

These controls can also fail on someone. A help desk is a group of people being helpful under time pressure, and a live phish kit with a real-time control panel is built specifically to beat them on a bad afternoon.

So the useful question is not “how do we stop every phishing call.” It is: when an attacker holds a valid, fully authenticated session, what actually stops them?

The attacker does not only have to be right once

There is a line in every security awareness deck: the defender has to be right every time, the attacker only has to be right once. It is memorable, and for this class of attack it is wrong.

A SaaS data theft of this kind is not one lucky break. It is a sequence, and the attacker has to clear every stage of it. Talk a help desk into a reset. Land the session on a machine nobody vetted. Reach the platform from a network nobody restricted. Find an account that already holds standing rights to everything. Then move an enormous volume of data without tripping anything. Five stages, and five separate opportunities to end it.

These breaches do not succeed because an attacker got lucky once. They succeed because all five gates were standing open, which is a different problem with a much better answer. You do not have to be right every time. You have to be right at any one of five points.

Five gates a SaaS data theft has to clear A vertical flow with five decision points, each one a place the attack can be blocked. A voice phishing call reaches the help desk using a lookalike domain, an IT support pretext and an urgent reset request. Gate 1, the help desk, asks whether a human verified the request out of band, using a verified callback to a number already on file, a rule against credential or factor changes on the inbound call, and manager approval for privileged accounts; if enforced the reset never happens and the attack is blocked there. If it is not enforced, the attacker now holds a valid SSO session in which password, MFA and SSO are all satisfied. Gate 2, device trust, asks whether the machine is one we manage, using Okta Device Assurance with FastPass or an Entra Conditional Access compliant device requirement; if enforced, the attacker's laptop is not enrolled. Gate 3, network, asks whether the source is one we trust, using Salesforce Login IP Ranges enforced on every request, Snowflake network policies, Okta network zones, or PrivateLink and Private Service Connect with public access disabled; if enforced, the session comes from the wrong place. Gate 4, standing access, asks whether the account can reach the data right now, using Entra Privileged Identity Management with eligible rather than active assignment, Salesforce permission set groups with expiration dates, and Snowflake bulk unload behind a separate role; if enforced, the account has nothing to dump. Gate 5, detection, asks whether the data volume is normal for the account, using Salesforce Shield Event Monitoring, Snowflake ACCESS_HISTORY on Enterprise Edition or higher, and an alert somebody actually wrote; it does not block the attack but scopes the damage, so you find out in hours rather than months. Each gate passes to the next only when it is not enforced, and data theft at cloud scale is reached only if all five are open. A closing note explains that a blocked gate is usually a pivot rather than an ending: blocked attackers try another route, such as a second help desk call, a device enrollment attempt, an elevation request, or a login from a new address, and every pivot is one more event in a log, which is why the gates and the alerting are worth buying together. Each gate is a separate configuration, and often a separate purchase. VOICE PHISHING CALL TO THE HELP DESK Lookalike domain, IT support pretext, urgent reset request GATE 1 THE HELP DESK Did a human verify this request out of band? Verified callback to a number already on file No credential or factor change on the inbound call Manager approval for privileged accounts ENFORCED → the reset never happens. Blocked here. NOT ENFORCED The attacker now holds a valid SSO session. GATE 2 DEVICE TRUST Is this machine one we manage? Okta Device Assurance + FastPass Entra CA: require compliant device ENFORCED → the attacker's laptop is not enrolled. Blocked here. NOT ENFORCED GATE 3 NETWORK Is this source one we trust? Salesforce Login IP Ranges, enforced on every request Snowflake network policy · Okta network zones PrivateLink / PSC, with public access disabled ENFORCED → the session comes from the wrong place. Blocked here. NOT ENFORCED GATE 4 STANDING ACCESS Can this account reach the data right now? Entra PIM: eligible, not active · approval + time limit Salesforce permission set groups with expiration Snowflake: bulk unload behind a separate role ENFORCED → the account has nothing to dump. Blocked here. NOT ENFORCED GATE 5 DETECTION Is this volume normal for this account? Salesforce Shield Event Monitoring Snowflake ACCESS_HISTORY (Enterprise or higher) and an alert somebody actually wrote ENFORCED → you find out in hours, not months. Damage is scoped. NO ALERT WRITTEN DATA THEFT AT CLOUD SCALE Reached only if all five gates are open. A BLOCKED GATE IS USUALLY A PIVOT, NOT AN ENDING Blocked attackers try another route: a second help desk call, a device enrollment attempt, an elevation request, a login from a new address. Every pivot is one more event in a log. Buy the gates and the alerting together. Each gate is a separate configuration, and often a separate purchase.
The attack chain described in Health-ISAC's July 24 advisory. The attacker only reaches each gate because the last one was never configured.

One honest qualification, because a closed gate does not always end an attack. Somebody holding a valid SSO session has room to maneuver. Blocked by device trust, they can go back and try to talk the help desk into enrolling a device for them. Blocked by network policy, they can hunt for the one application nobody brought behind the policy, or route through a residential proxy in the right metro area. Blocked by standing access, they can file an elevation request, or go phish somebody who already holds the entitlement.

Every one of those pivots is a new event, though. A second call to the help desk. A device enrollment. An elevation request landing in an approval queue that a human reads. A failed login from an address you have never seen. A quiet attack turns into a loud one, and the dwell time that lets somebody move a terabyte unnoticed depends entirely on staying quiet.

That is the real argument for treating the gates and the alerting as one purchase rather than competing line items. Controls that only block are worth less than they look. Controls that block and generate a signal when somebody tries to work around them are what turn a silent export into a sequence of events with your name on the ticket.

Gate 2. Device trust: the attacker’s laptop is not your laptop

Once the help desk gate is behind you, the cheapest structural fix is refusing to accept authentication from unmanaged hardware. An attacker who social-engineers a password and an MFA push is still sitting at their own machine. That machine is not enrolled in your MDM, has no management certificate, and fails a device posture check every time.

In Okta, this is Device Assurance policies combined with Okta Verify and FastPass, bound into your authentication policies as a “registered and managed device” requirement. In Entra ID, it is a Conditional Access grant requiring a compliant or hybrid-joined device. Both are the same idea: possession of the credential is not sufficient, possession of the credential on a machine we manage is.

Two things make this worth prioritizing over almost anything else on the list:

  • It fails closed against credential theft, MFA fatigue, help desk impersonation, and session hijacking all at once, because none of those attacks come with your laptop attached.
  • It composes with phishing-resistant MFA rather than duplicating it. FIDO2 stops the credential from being relayed. Device trust stops the session from landing anywhere useful if it is.

Scope it to your crown-jewel applications first. You do not need to boil the ocean to protect the Salesforce org holding patient records.

That is as far as this post goes, because gates 1 and 2 are what decide whether an attacker gets a working session at all. The remaining three decide what that session is worth, and each has enough platform detail to need its own post:

  • Standing Access Is the Blast Radius takes gate 4. The attacker in this chain never escalates privilege, because the account they compromised already held rights to everything. Just-in-time access, PIM, SCIM group provisioning, and what each vendor charges for it.
  • Network Limits and the Logs You Have to Buy takes gates 3 and 5. Salesforce Login IP traps, private connectivity for Snowflake and Databricks, and the audit logging your license tier quietly leaves out.

What to do this quarter

If your organization runs sensitive data in SaaS, this is the short list:

  1. Harden the help desk to Health-ISAC’s spec: verified callback, no same-call resets, manager approval for privileged accounts. Every one of these attacks runs through a human being on a phone call, and this is the cheapest gate on the list.
  2. Inventory which SaaS platforms hold your regulated data. For most healthcare and healthcare-adjacent companies this is a shorter list than expected, and it tells you where to spend.
  3. Turn on device trust for those platforms. Managed device required, no exceptions beyond a documented, reviewed, and time-bound list.
  4. Find out who holds standing bulk-export rights in the platforms on that list, and start taking them away. That is gate 4.
  5. Work out what your license tier does not cover. Network restrictions and audit logging are decided at renewal rather than in a config screen. That is gates 3 and 5.

None of this makes an organization unbreachable. That is not the standard. The standard is whether an attacker working this chain hits a wall at one of five points, gets noticed on day one instead of month four, and leaves behind logs that let you scope the damage.

If you want help working out where you stand, our SaaS Security & Access Assessment covers device trust, conditional access, network restrictions, and the license-tier question across Microsoft 365, Google Workspace, Salesforce, and the rest of your stack. If your exposure runs through the vendors and platforms you depend on rather than your own tenant, pair it with a vendor risk assessment.

And if you think something is happening right now, call (608) 448-6075 or email with INCIDENT in the subject line.