ShinyHunters' Vishing Playbook: How a Phone Call Is Breaching SaaS-Connected Companies

A healthcare company gets breached, and the entry point isn’t a zero-day or a leaked password. It’s a phone call. Someone claiming to be internal IT support talks an employee through a screen they’ve seen a hundred times before, a Salesforce OAuth consent prompt, and gets them to click “Allow” on an app dressed up as a routine data tool. No malware, no exploit, no MFA prompt to fail. That’s the attack Microsoft spent the past year tracking under the ShinyHunters name, and it’s still working.

The three doors Microsoft found

Microsoft’s security team mapped roughly a year of ShinyHunters intrusion activity against Salesforce and adjacent SaaS platforms and found the attackers relying on three distinct access paths, not one exploit repeated at scale.

Path	How it works
Voice phishing	Attacker calls, poses as IT support, walks the victim through authorizing a malicious OAuth app disguised as a legitimate tool
Supply chain compromise	Stolen credentials from a trusted integration (Salesloft Drift was one confirmed source) expose OAuth connection secrets for every environment that integration touches
Guest access misconfiguration	Overly permissive Experience Cloud guest access gets manipulated directly, no phishing required

Voice phishing is the most common of the three, and it’s worth sitting with why: it doesn’t require a vulnerability, a leaked credential, or any technical foothold at all. It requires one employee, one convincing phone call, and about five minutes of them following instructions they have every reason to believe are legitimate.

How the call actually works

The script Microsoft observed is specific enough to be worth knowing in detail, because recognizing it is the actual defense. An attacker calls an employee, usually someone in a role likely to have Salesforce access, and identifies themselves as internal IT support handling a routine issue: a data sync problem, an integration that needs re-authorizing, something plausible and mildly urgent. They walk the employee to Salesforce’s real, legitimate OAuth consent screen and talk them through approving a connected app.

The app itself is the trick. It’s typically presented as Salesforce’s own Data Loader tool, familiar enough that an employee who isn’t a security specialist has no reason to question it. What they’re actually authorizing is an attacker-controlled application requesting the same scopes a real data tool would need: read and write access to CRM records, in many cases enough to export the entire customer database.

Once approved, that OAuth grant is a durable credential. It isn’t tied to the employee’s password, so a forced password reset doesn’t revoke it. It doesn’t trigger an MFA challenge on subsequent use, because MFA protects the login step, and this token skips the login step entirely. It keeps working until someone specifically finds and revokes that connected app’s authorization, which is the part most organizations aren’t set up to notice quickly.

Why this beat the defenses everyone already has

Most enterprise security postures in 2026 are built around a specific threat model: stop credential theft, and stop it with MFA. That model is sound against phishing that steals a password, or even against phishing that tries to relay an MFA code in real time. It has almost nothing to say about an OAuth consent grant, because from the platform’s perspective, an authenticated, MFA’d user made a deliberate, informed decision to authorize an app. The system did exactly what it was designed to do. The employee just was not informed by the party they thought they were talking to.

Abbott Laboratories learned this the hard way in July 2026, when ShinyHunters compromised a corporate Microsoft Entra single sign-on account tied to the company’s Cancer Diagnostics business, reportedly through this exact vishing approach targeting employees the prior month. Abbott joins a list of organizations hit by overlapping ShinyHunters tradecraft over the past year, some through the vishing path directly, others through the Salesloft Drift and Gainsight supply chain compromises that exposed OAuth secrets for every downstream Salesforce environment those integrations touched.

What actually closes the gap

Patching software doesn’t help here, because nothing is unpatched. The fix is process and visibility, not a version number:

• Audit every OAuth-connected app authorized against your CRM and other core SaaS platforms. Flag anything inactive for 90 days or more, since one-off integrations that nobody removed afterward are exactly what attackers count on finding.
• Log OAuth application activity, not just logins. A user login audit trail won’t show you a connected app quietly pulling records on a schedule. Salesforce Shield Event Monitoring and Microsoft’s updated Defender for Cloud Apps connector both now surface connected-app attribution and OAuth scope details specifically because this gap was common enough to need closing.
• Scope guest access as narrowly as the actual use case requires, and review it on a schedule rather than assuming a configuration set years ago is still appropriate.
• Train the specific script, not generic phishing awareness. “Don’t click suspicious links” doesn’t prepare anyone for a phone call that ends at a real, official consent screen. The training that works names the scenario: IT support does not call and ask you to authorize a new app over the phone, full stop, and any request to do so goes through a callback to a verified internal number first.

This same pattern, trusted infrastructure turned into an attack surface through legitimate-looking authorization rather than a bug, is the same underlying shape behind the Langflow IDOR flaw we covered when it hit CISA’s KEV catalog: the platform worked exactly as designed, and the design assumed a level of trust the attacker didn’t deserve. Vishing doesn’t need a CVE number to be dangerous. It just needs one employee to believe the person on the phone is who they say they are.