You've trained your team on phishing emails, deployed MFA across most systems, and your helpdesk follows a password reset script. Yet, a single vishing call just gave an attacker the keys to your entire SaaS environment.
This isn't a theoretical risk. ShinyHunters has compromised multiple healthcare organizations recently, including Medtronic, iRhythm, OneMedical, DentaQuest, AdaptHealth, and Him & Hers, using the same playbook: call the helpdesk, manipulate an employee into resetting credentials, log into the SSO dashboard, and exfiltrate data at cloud scale. Health-ISAC's recent alert makes clear that traditional IAM controls are failing against voice-based social engineering combined with SSO account takeovers.
Why These Mistakes Keep Happening
Healthcare IAM programs were built for a different threat model. Your controls were designed to prevent unauthorized network access and protect on-premises systems. SSO platforms like Microsoft Entra, Okta, and Google Workspace changed the architecture: compromise one account, gain a dashboard listing every application that account touches. Microsoft 365, Salesforce, Dropbox, SharePoint, internal platforms, all accessible through a single pane of glass.
Meanwhile, your security awareness training still focuses on spotting malicious emails, not recognizing voice manipulation tactics. Your helpdesk procedures prioritize user convenience over identity verification. And your MFA implementation likely includes SMS or voice fallback methods that attackers can reset with a convincing story.
The gap isn't in your technology stack. It's in the assumptions underlying your IAM workflows.
Mistake 1: Allowing Same-Call Password and MFA Resets
Why it happens: Your helpdesk wants to resolve tickets quickly. An employee calls, says they're locked out, answers a few knowledge-based questions (information often available through OSINT or LinkedIn), and the agent resets their password and re-enrolls their device on the same call.
Real consequence: ShinyHunters claimed to have called multiple employees at one healthcare organization until finding someone who completed the reset process. Once the attacker had a valid Microsoft Entra account, they logged into the SSO dashboard and moved laterally across SaaS platforms. The helpdesk agent followed the script. The attack succeeded anyway.
The fix: Implement out-of-band identity proofing for any password reset, MFA reset, or device re-enrollment. The agent must hang up and call back to a previously verified number before completing the request. For privileged users, require manager approval before processing the reset. Make it procedurally impossible to complete authentication changes on the inbound call itself. This adds friction but breaks the attack chain between the vishing attempt and account takeover.
Mistake 2: Treating SSO Platforms Like Standard IT Systems
Why it happens: You classify SSO as an identity tool, not as a critical asset. It gets the same conditional access policies and monitoring as your other cloud services. Your security team thinks about protecting individual applications, not the dashboard that grants access to all of them.
Real consequence: An attacker who compromises an SSO account doesn't need to pivot through your network or exploit vulnerabilities. The platform itself provides an inventory of accessible applications. They can exfiltrate data from Microsoft 365, SharePoint, Salesforce, and third-party storage platforms in hours, not weeks.
The fix: Reclassify SSO systems as Tier 0 assets, the most critical infrastructure in your environment. Require phishing-resistant MFA (FIDO2/WebAuthn security keys) for all administrative access. Enforce compliant device requirements for accessing the SSO dashboard. Block legacy authentication protocols entirely. Implement geo-velocity and impossible travel checks that flag logins from unexpected locations. Your SSO platform deserves the same protective controls you apply to domain controllers and financial systems.
Mistake 3: Deploying MFA Without Hardening Reset Workflows
Why it happens: You rolled out MFA to meet compliance requirements or pass an audit. You chose SMS or voice-based methods because they're easy to deploy and don't require hardware tokens. You didn't redesign the processes for resetting or re-enrolling MFA factors.
Real consequence: Attackers don't break MFA, they reset it. ShinyHunters uses vishing to convince helpdesk staff to enroll a new device or reset the MFA factor entirely. SMS and voice methods are particularly vulnerable because they can be socially engineered or intercepted. Your MFA deployment becomes security theater if the reset process has weaker controls than the authentication itself.
The fix: Disable SMS and voice MFA for privileged accounts immediately. Implement phishing-resistant MFA using FIDO2/WebAuthn security keys for administrators and high-risk user groups. Extend this to all users within Health-ISAC's recommended 30- to 60-day timeline. Implement strict controls for MFA factor registration, treat new device enrollment as a high-risk event requiring verification. Configure alerts in your SIEM for MFA factor registration events, OAuth reset events, and new device enrollments. You're not just deploying MFA; you're hardening the entire identity lifecycle.
Mistake 4: Training Staff Only on Email-Based Phishing
Why it happens: Your security awareness program uses phishing simulation platforms that send fake emails. You measure click rates and congratulate yourself on improving employee vigilance. Vishing isn't part of the curriculum because it's harder to simulate and your vendor doesn't offer voice-based training modules.
Real consequence: Your employees can spot a suspicious link but can't recognize voice manipulation tactics. An attacker calls claiming to be from IT, creates urgency ("your account will be locked in 10 minutes"), and guides the employee through "verification steps" that actually reset their credentials. Helpdesk staff, new hires, and remote workers are particularly vulnerable because they lack the institutional context to question unusual requests.
The fix: Add vishing scenarios to your security awareness training immediately. Run vishing simulations targeting privileged account holders, helpdesk staff, new employees, and remote workers. Teach employees to recognize urgency tactics, requests to bypass normal procedures, and pressure to act during the call. Train helpdesk staff specifically on identity proofing requirements and how to politely end calls that don't follow verification protocols. Update your incident response playbook to include vishing as an initial access vector.
Mistake 5: Failing to Monitor for Post-Compromise Activity
Why it happens: Your logging focuses on network perimeter events and endpoint detection. You collect Microsoft Entra sign-in logs but don't have alerts configured for identity-specific indicators of compromise. Your SIEM ingests SaaS audit logs but doesn't correlate them with authentication events.
Real consequence: Even if an attacker gains access, you have a detection window before large-scale exfiltration occurs. ShinyHunters moves quickly, but bulk downloads, unusual API calls, and new OAuth app registrations leave traces. Without monitoring, you learn about the breach when the attacker contacts you demanding ransom, not when the account is first compromised.
The fix: Centralize Microsoft Entra sign-in logs, audit logs, and SaaS platform logs into your SIEM. Configure alerts for new device enrollments, MFA factor registration, OAuth reset events, unusual consent grants to third-party apps, bulk downloads exceeding normal patterns, atypical API calls, new email forwarding rules, and mailbox delegation changes. These indicators flag account takeover in progress. You're looking for behavioral anomalies that suggest an attacker is exploring your environment, not just failed login attempts.
Prevention Checklist
Use this to audit your current IAM posture against vishing and SSO takeover risks:
Helpdesk and Identity Workflows
- Out-of-band verification required for all password resets (callback to verified number)
- Manager approval required for privileged account resets
- Same-call password/MFA reset procedurally blocked
- Identity proofing procedures documented and enforced
MFA Hardening
- Phishing-resistant MFA deployed for administrators (FIDO2/WebAuthn)
- SMS/voice MFA disabled for privileged accounts
- MFA factor registration treated as high-risk event
- Weak fallback methods eliminated or tightly restricted
SSO Platform Controls
- SSO systems classified as Tier 0 assets
- Compliant device requirement enforced for SSO access
- Legacy authentication protocols blocked
- Geo-velocity and impossible travel checks implemented
- Administrative portal access limited to managed devices
Detection and Monitoring
- Microsoft Entra logs centralized in SIEM
- SaaS audit logs ingested and correlated
- Alerts configured for new device enrollments
- Alerts configured for MFA factor registration and OAuth resets
- Alerts configured for bulk downloads and unusual API activity
- Alerts configured for email forwarding rules and delegation changes
Training and Awareness
- Vishing scenarios added to security awareness program
- Vishing simulations conducted for privileged users
- Helpdesk staff trained on identity proofing requirements
- New hire training includes voice-based social engineering
Incident Response
- Tabletop exercises conducted for compromised cloud accounts
- Token and session revocation procedures documented
- Playbook includes vishing as initial access vector
Your IAM program wasn't designed for attackers who bypass technical controls by manipulating people. Health-ISAC recommends a 30- to 60-day implementation timeline starting with phishing-resistant MFA for high-risk users, strengthened helpdesk procedures, and conditional access enforcement. The organizations ShinyHunters compromised had MFA deployed. They had helpdesk scripts. They failed anyway because their IAM controls assumed attackers would try to break in, not call and ask for the keys.
