ShinyHunters: Breaking Help Desks via Vishing and Bulk Stealing SaaS via SSO

ShinyHunters: Breaking Help Desks via Vishing and Bulk Stealing SaaS via SSO

1. Basic Information

• Article Title: Health-ISAC warns of rising ShinyHunters data theft attacks on healthcare
• Publisher: BleepingComputer
• Publication Date: July 29, 2026
• Original URL: https://www.bleepingcomputer.com/news/security/health-isac-warns-of-rising-shinyhunters-data-theft-attacks-on-healthcare/
• Related Sources:
  • Health-ISAC: https://health-isac.org/shiny-hunters-impact-to-health-sector-and-recommended-mitigation-strategies/
• Related Entities: ShinyHunters, Microsoft Entra ID, Okta, Google SSO, Microsoft 365, SharePoint, Salesforce, OAuth, FIDO2/WebAuthn
• Severity: High

2. Summary

This is an attack where threat actors manipulate users or help desks over the phone. They change passwords, MFA, and device registrations to take over SSO. Then, they access M365, SharePoint, Salesforce, and other services across the organization to steal a large amount of data in a short time.

3. Attack Flow

User Vishing Chain

1. The attacker researches the target employee’s name, job title, contact info, and IdP.
2. The attacker calls while pretending to be IT support and leads the user to a real-time phishing screen.
3. The attacker steals passwords, MFA codes, authentication actions, and OAuth consent.
4. The attacker registers a new MFA factor or the attacker’s own device.
5. The attacker logs in to Entra, Okta, or Google SSO dashboards.
6. The attacker moves to listed SaaS apps, searches for data, and steals it in bulk.

Help Desk Reset Chain

1. The attacker calls the help desk while pretending to be the legitimate user.
2. The attacker asks for a password reset, MFA removal, and device re-registration.
3. The attacker passes weak identity verification during the same phone call.
4. The attacker authenticates to SSO from their own device right after the change.
5. The attacker moves laterally to M365, SharePoint, Salesforce, DocuSign, Slack, Atlassian, Dropbox, Google Drive, etc.
6. The attacker steals data via API or bulk downloads and extorts the victim.

Supply Chain / OAuth Chain

1. The attacker compromises a third-party integration partner.
2. The attacker steals OAuth tokens for Salesforce, Snowflake, etc.
3. The attacker accesses the target organization’s SaaS as a legitimate integration.
4. The attacker extracts a large amount of data.

4. Attacker Position and Execution Location

• The attacker operates from phone calls, phishing infrastructure, and cloud hosts.
• Authentication changes happen on the target organization’s help desk or IAM management surfaces.
• Data theft happens via legitimate web and API sessions between IdP and connected SaaS apps.
• Endpoint malware is often absent, so the main evidence remains on the identity and SaaS sides.

5. Visibility for Victims and Administrators

• To the user, it looks like urgent identity verification, MFA recovery, or IT support.
• To the help desk, it looks like a normal account lockout or device change request.
• To the administrator, it looks like a sequence of resets, new MFA/device registrations, and logins from new locations right after.
• In SaaS apps, it looks like searches, API enumerations, and bulk downloads by a legitimate user.

6. Success and Failure Conditions

Success Conditions

• The attacker can complete authentication factor changes with just a phone call.
• There are no callbacks to known numbers or manager approvals.
• SMS/voice MFA or weak fallbacks are available.
• New factor registration is allowed from unmanaged devices.
• SSO users have broad permissions across many SaaS apps.
• SaaS audit logs and IdP logs are not correlated.

Failure Conditions

• A “no changes on the same call” rule and callbacks to known numbers.
• Manager or separate team approval for high-risk user changes.
• FIDO2/WebAuthn and managed device requirements.
• Mandatory step-up for new MFA, OAuth consent, and device registrations.
• Immediate session revocation and SaaS-specific token revocation.

7. What Happens on Success

An attacker accesses multiple cloud services from a single SSO account and collects/steals emails, documents, contracts, customer data, sales data, and medical-related data in a short time. Not all claims handled by Health-ISAC are verified, but successful cases involving data theft from M365, SharePoint, and other systems have been reported.

8. Observable Logs

Email

• Password and MFA change notifications.
• New device registrations, OAuth consent, and SaaS sharing notifications.
• Post-compromise searches, forwarding rules, and bulk email collection.

Proxy / SWG / DNS

• Phishing domains accessed at the same time as the phone call.
• Connections to IdP/SaaS from new ASNs, residential proxies, or cloud VPS.

Endpoint / EDR

• Malware may be absent.
• Browser history, phishing pages, remote support tools, and authentication actions during phone calls.
• New device IDs that are not managed devices.

Identity / IdP

• Password/MFA resets by the help desk.
• New MFA factors, devices, passkeys, and OAuth grants.
• Successful logins from new locations, ASNs, and devices right after a reset.
• Impossible travel, MFA method downgrades, and continued sessions.

SaaS / Cloud

• Heavy searches, downloads, and API usage in M365, SharePoint, Salesforce, etc.
• First-time access to apps that are not normally used.
• Creation of OAuth apps, token generation, and integration changes.

Network

• Short-time access from IdP to multiple SaaS apps.
• Large data transfers, compression, and uploads to cloud storage.

9. Attack Success Judgment

• Contact Only: Vishing call received, phishing URL received.
• User Interaction: URL opened, credentials entered, MFA approved, help desk change request completed.
• Initial Execution: Password, MFA, or device change completed.
• Authentication Success: SSO successful from the attacker’s device and new location.
• Information Theft & Session Compromise: SaaS bulk downloads, API enumeration, OAuth token usage.
• Post-compromise Confirmation: Lateral movement to multiple SaaS apps, inviting other users, external sharing, extortion.

10. Investigation Playbook

Trigger

• New device authentication right after an MFA/password reset.
• New OAuth grants and bulk downloads.
• Vishing reports from users.

Initial Check

1. Verify facts with users and the help desk via a separate channel.
2. Put resets, factors, devices, sessions, IPs, and ASNs in chronological order.
3. List all SaaS apps accessible from the IdP.
4. Judge the success stage based on logs, not just claims.

Devices

• Check browser history, phishing URLs, remote support, cookies, and registered devices.
• Do not rule out identity compromise even if malware is absent.

Authentication & Cloud

• Revoke all active sessions and reset passwords, MFA, recovery methods, and OAuth tokens.
• Check SaaS audit logs for searches, downloads, sharing, and API usage.

Subsequent Actions

• Investigate email forwarding, external sharing, OAuth apps, API tokens, additional administrators, and data exports.

Containment

• Temporarily suspend accounts, revoke all sessions, and remove malicious factors, devices, and apps.
• Freeze high-risk resets and re-verify identity via callbacks to known numbers.
• Determine affected data and handle legal/privacy requirements.

Judgment Categories

• Vishing Only / User Interaction / IAM Change / SSO Takeover / SaaS Access / Data Theft / Extortion

11. Defense and Detection Ideas

Single Events

• MFA removal and re-registration by administrators.
• New OAuth grants.
• SaaS bulk downloads.

Chronological Correlation

Help desk ticket/call → Password/MFA reset → New device → New ASN login → First-time access to multiple SaaS apps → Bulk download

Threat Hunting Perspectives

• Multiple resets by the same help desk agent in a short time.
• New countries, ASNs, or devices within 30 minutes of a reset.
• Sequential access by one account to multiple SaaS apps it does not normally use.

Log Gaps

• Help desk tickets, call records, IdP factor changes, device IDs, OAuth logs, and SaaS download logs are required.

Priority Mitigations

1. “No-same-call” rules and verified callbacks.
2. FIDO2/WebAuthn for high-risk users.
3. Mandatory managed device and step-up requirements for factor registration.
4. Centralization of IdP and SaaS audit logs.
5. Exercises for immediate session and OAuth revocation procedures.

12. Facts / Inference / Hypothesis

Facts

• Health-ISAC warned of an increase in successful attacks in healthcare and MedTech.
• Attacks progress from vishing to password/MFA/device changes and SSO takeovers.
• Data theft from M365, SharePoint, and other systems using compromised SSOs has been reported.
• Not all attacker claims are verified.

Inference

• Identity and SaaS compromise can succeed even if endpoints are clean.
• The same attacks can happen in organizations outside of healthcare if they use similar help desks and SSO structures.

Hypothesis

• Using the speed of post-reset SaaS lateral movement can help detect deviations from normal usage with high accuracy.

13. MITRE ATT&CK Mapping

High Confidence

• T1566 Phishing
• T1598.004 Spearphishing Voice
• T1078.004 Cloud Accounts
• T1098.005 Device Registration
• T1528 Steal Application Access Token
• T1213.002 Sharepoint
• T1530 Data from Cloud Storage

Medium Confidence

• T1556.006 Modify Authentication Process: MFA
• T1136.003 Cloud Account
• T1567.002 Exfiltration to Cloud Storage

14. Unknowns and Additional Investigations

• Number of affected organizations, timeframes, and stolen data.
• IdPs, MFA methods, and OAuth apps used in each case.
• Attacker IPs, phishing kit IOCs, and exfiltration destinations.
• The strength of technical attribution to ShinyHunters.

15. Impact on SOCs and General Organizations

Organizations often share the same attack surface: help desks that rely on phone calls and employee details for identity verification, SMS fallbacks, and SSO setups that include remote offices or third-party vendors. Across industries such as manufacturing, finance, trade, and enterprise group environments, shared IdPs allow attackers to spread from a single account to many SaaS applications.

16. Summary

For SOCs

• Correlate resets, new devices, SaaS lateral movement, and bulk downloads.
• Do not use clean EDR status to assume safety.

For Administrators

• Prioritize the implementation of “no-same-call” rules, verified callbacks, FIDO2, and managed device requirements.
• Prepare procedures to revoke sessions and OAuth tokens across all SaaS apps.

For Users

• Do not change passwords, MFA, or device registrations during a phone call. If you receive a suspicious request, hang up and call back using a known internal phone number to verify.