ShinyHunters' 2026 Vishing Campaign: How Attackers Are Hijacking Okta SSO to Breach Bank-Grade SaaS Platforms

A sophisticated extortion campaign attributed to ShinyHunters (tracked as UNC6661) has demonstrated a chilling new attack pattern in early 2026: threat actors are calling bank and enterprise employees in real time, impersonating IT helpdesk staff, and walking them through fake Okta SSO portals — capturing credentials and MFA codes as they speak. The result is full access to every SaaS application connected through that SSO, including Zendesk, Salesforce, Slack, and Microsoft 365. Telehealth giant Hims & Hers confirmed it was breached this way in April 2026, with millions of Zendesk support tickets stolen. Saudi financial institutions running identical SaaS architectures are squarely in the crosshairs.

How the Attack Actually Works: Real-Time Phishing in Three Phases

What makes the ShinyHunters 2026 campaign operationally distinct from conventional credential phishing is its human-in-the-loop design. In the first phase, attackers register typosquatted domains formatted as <companyname>sso.com or <companyname>internal.com, mirroring the target organization's legitimate Okta login portal down to the favicon. In the second phase, a caller — fluent in English, trained to sound like an internal IT technician — contacts an employee and claims the company is rolling out a new MFA enrollment. The employee is directed to the fake portal while still on the call. In the third phase, the attacker, watching the session in real time, synchronizes the pages displayed in the victim's browser with their spoken prompts, intercepting the one-time MFA code the moment it is entered. By the time the call ends, the attacker has registered their own device as a trusted MFA factor and owns the session entirely.

What Attackers Do After They're Inside the SSO

The post-compromise behavior is systematic. Once an Okta session is authenticated with a registered attacker-controlled device, the threat actors pivot immediately to connected SaaS applications — not just email. In the Hims & Hers incident, the attackers targeted Zendesk, exfiltrating millions of support tickets containing customer names, physical addresses, email addresses, phone numbers, and sensitive healthcare communications spanning over a year. Silent Push and Obsidian Security have documented the same group targeting Salesforce CRM records, Slack workspace archives, Atlassian Confluence pages, and internal SharePoint documentation. For a financial institution, each of these platforms is a goldmine: KYC records, credit application data, internal risk assessments, and privileged communications between relationship managers and clients all flow through these systems daily.

Why Saudi Financial Institutions Face Amplified Risk

SAMA's Cyber Security Framework (CSCC) mandates rigorous third-party risk management under Domain 3 (Cyber Security Operations), and NCA's Essential Cybersecurity Controls (ECC-1:2018) require that member organizations apply equivalent security controls to outsourced services. The challenge is that most SAMA-regulated institutions have treated Okta, Zendesk, and Salesforce as trusted infrastructure rather than external attack surfaces subject to vendor risk assessments. In practice, an Okta SSO session compromised through vishing bypasses every network perimeter control, every WAF, and every SIEM detection rule that watches for external intrusion — because the attacker is authenticated as a legitimate internal user. PDPL (Saudi Personal Data Protection Law) adds a legal dimension: customer data exfiltrated from Zendesk or Salesforce must be reported to SDAIA within 72 hours of discovery, with penalties up to SAR 5 million for material failures in protective controls.

Detection Indicators Your SOC Should Be Monitoring

Several behavioral indicators distinguish a ShinyHunters-style SSO takeover from legitimate employee activity. First, watch for Okta authentication events where a new MFA device is enrolled immediately after a successful login — particularly from an IP address or ASN not previously seen in the user's login history. Second, monitor for sudden high-volume SaaS API calls immediately after a new device enrollment: bulk ticket exports in Zendesk, mass record downloads in Salesforce, or large Slack export requests are not normal user behavior. Third, track the typosquatted domain pattern: your threat intelligence feed should flag registrations of <yourcompanyname>sso.com, <yourcompanyname>-internal.com, and similar lookalike domains. Tools like Silent Push, DomainTools Iris, and Recorded Future all surface this pattern. Fourth, correlate your telephony logs — if your organization uses a corporate phone directory, calls from unknown external numbers claiming to be IT helpdesk in the minutes before an anomalous Okta event are a near-certain indicator of a live vishing attempt in progress.

Practical Hardening Steps for SAMA-Regulated Institutions

1. Enforce phishing-resistant MFA across all Okta applications. Deprecate TOTP and SMS-based OTP for privileged and customer-facing roles. Mandate FIDO2/WebAuthn hardware keys (YubiKey, Google Titan) or Okta FastPass with device trust. A vishing attacker cannot intercept a FIDO2 challenge — it is cryptographically bound to the legitimate domain.
2. Enable Okta ThreatInsight and set login policy to deny high-risk IPs. Okta's built-in threat intelligence flags login attempts originating from anonymizing proxies, Tor exit nodes, and known attack infrastructure. Pair this with Okta's Device Assurance policy to block unmanaged devices from accessing Zendesk, Salesforce, and other SaaS platforms connected via SSO.
3. Conduct a SaaS application inventory under SAMA CSCC Domain 3. Map every application connected to your Okta tenant, assign a data sensitivity classification, and verify that each vendor has completed your standard third-party risk questionnaire. Applications handling customer PII under PDPL should require contractual SLA obligations covering breach notification and log retention.
4. Run a vishing simulation as part of your next social engineering assessment. NCA ECC-2:2020 Control 2-11 requires periodic security awareness testing. Extend your current phishing simulation program to include voice phishing scenarios: have your red team call helpdesk and customer service staff claiming to be IT, and measure how many employees provide credentials or navigate to test portals. The failure rate across the industry is above 40%.
5. Implement Zendesk and Salesforce API rate-limiting and anomaly detection. Both platforms expose native audit log APIs. Ingest these logs into your SIEM and write rules that alert on bulk export operations, new OAuth application authorizations, and API calls from new IP addresses on existing authenticated sessions.
6. Establish a Suspicious Call Reporting Protocol. Employees should have a single-click internal channel to report suspicious calls from individuals claiming to be IT. A documented response runbook should trigger immediate review of that user's Okta session and MFA device history.

Conclusion

The ShinyHunters 2026 vishing campaign is not a theoretical threat — it has already resulted in the confirmed exfiltration of millions of records from a publicly traded company. The attack vector exploits trust: trust in a phone call, trust in a familiar-looking login page, trust in the MFA enrollment flow. Saudi financial institutions that have invested in network-layer defenses but have not extended that rigor to SSO identity governance and SaaS vendor risk management are exposed in exactly the way ShinyHunters needs. SAMA CSCC and NCA ECC provide the regulatory framework; the question now is whether your controls are implemented with the specificity this threat demands.

Is your organization prepared? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment — including a review of your Okta configuration, SaaS application inventory, and social engineering resilience.