Your SSO Is the Skeleton Key: How ShinyHunters Are Weaponizing Okta to Own Entire Enterprises

There's a common assumption in enterprise security that goes something like this: "We use SSO with MFA. We're good." That assumption is getting companies gutted right now.

A massive, active campaign -- attributed to the cybercriminal alliance known as SLSH (Scattered LAPSUS$ Hunters, which includes ShinyHunters, Scattered Spider, and LAPSUS$) -- is systematically targeting Okta Single Sign-On accounts across more than 100 high-value organizations. They're not exploiting a zero-day. They're not breaking encryption. They're calling your employees on the phone and talking their way in.

And it's working.

What's Actually Happening

Since at least late 2025, threat actors operating under the ShinyHunters brand have been running a coordinated voice phishing (vishing) campaign that targets organizations using Okta, Microsoft Entra ID, and Google Workspace for SSO. On January 22, 2026, Okta Threat Intelligence published a detailed analysis of the custom phishing kits being used in these operations. Six days later, Google's Mandiant confirmed this is an active and ongoing campaign, and they're tracking it across multiple threat clusters: UNC6661 (initial access and lateral movement), UNC6671 (parallel operations with more aggressive tactics), and UNC6240 (extortion, associated with the ShinyHunters brand).

The confirmed victim list so far includes Betterment (20+ million records), Crunchbase (2+ million records), and SoundCloud (~30 million user records exposed after a December 2025 breach). But Silent Push researchers identified active targeting infrastructure aimed at over 100 enterprises, including names like Atlassian, Canva, Epic Games, HubSpot, RingCentral, and ZoomInfo. ShinyHunters themselves told The Register that the number 100 was "close."

This isn't spray-and-pray. This is surgical.

The Kill Chain: Step by Step

Here's how the attack unfolds, broken down in a way that makes the sophistication -- and the simplicity -- painfully clear.

Phase 1: Reconnaissance

Before a single call is made, the attackers do their homework. They identify target employees by name, determine which applications the organization uses, and find the real phone numbers used by the company's IT support and helpdesk. This information isn't hard to get. LinkedIn profiles, corporate websites, job postings, and previous data breaches all provide a rich intelligence picture.

Phase 2: Infrastructure Setup

The attackers register custom phishing domains designed to look like the target company's SSO portal. The naming convention is predictable and effective: [companyname]sso.com or [companyname]internal.com. UNC6661 tends to register these through NICENIC, while UNC6671 favors Tucows. Behind these domains sits a real-time adversary-in-the-middle (AiTM) phishing platform -- not a static fake login page, but a live, interactive system controlled by a command-and-control (C2) panel.

Phase 3: The Vishing Call

The attacker calls the target employee, spoofing the company's real IT support number. The pretext varies but commonly sounds like:

  • "We're helping you set up passkeys for our new Okta SSO configuration."
  • "There's been suspicious activity on your account and we need to verify your identity."
  • "We're rolling out an MFA update and need you to re-authenticate."

The social engineering is polished, confident, and rehearsed. These aren't amateurs reading from a script. According to Okta's threat intelligence team, vishing expertise is now sold as a service within The Com ecosystem, meaning the callers may be specialists hired specifically for their persuasion skills.

Phase 4: Real-Time Credential Harvesting

While still on the phone, the attacker directs the victim to the phishing domain. Here's where the custom phishing kit earns its keep. As the victim enters their username and password, the credentials are immediately forwarded to the attacker's backend -- often relayed through Telegram channels. The attacker then uses those credentials to initiate a real login attempt against the legitimate Okta portal.

Phase 5: MFA Bypass (The Critical Moment)

This is the part that breaks many people's mental model of security. The phishing kit includes a C2 panel that gives the caller real-time control over what the victim sees in their browser. When Okta responds with an MFA challenge, the attacker can adapt on the fly:

  • Push notifications: Tell the victim to expect a push notification and approve it. The phishing site simultaneously displays a fake "verification sent" page to make it feel legitimate.
  • OTP/TOTP codes: Ask the victim to read the code from their authenticator app. The attacker enters it on the real login page before it expires.
  • Number matching: This is the one that surprises people. Push notifications with number matching are widely considered a stronger form of MFA. But when a human being is on the phone with you, they can simply say: "Can you tap the number 67 on your screen? Great, that verifies it's you." You tap 67. The attacker taps 67 on the real login. Authentication complete.
Every Non-Phishing-Resistant MFA Method Is Vulnerable

As Okta threat researcher Moussa Diallo stated: "The threat actor can use this synchronization to defeat any form of MFA that is not phishing-resistant." The C2 panel lets the attacker control the authentication flow in the victim's browser in perfect sync with the verbal instructions they're delivering on the call. Push, OTP, SMS, number matching -- all of them fall.

Phase 6: SSO Becomes the Skeleton Key

Once the attacker has a valid Okta session, the SSO dashboard becomes a roadmap to everything. Every connected application -- Salesforce, Slack, Microsoft 365, SharePoint, OneDrive, DocuSign, financial platforms -- is now accessible. The attacker doesn't need to compromise each one individually. SSO did the work for them.

Mandiant observed attackers enrolling their own devices into the victim's MFA solution, establishing persistence that survives a simple password reset. In at least one case, UNC6661 enabled the ToogleBox Recall add-on for a victim's Google Workspace account -- a tool designed to search for and permanently delete emails -- likely to destroy evidence of security notifications.

Phase 7: Data Exfiltration and Extortion

The attackers prioritize rapid data exfiltration, pulling sensitive information from SaaS platforms -- particularly Salesforce environments, a consistent pattern in ShinyHunters campaigns. Mandiant has observed UNC6671 using PowerShell to download data from SharePoint and OneDrive. In at least one incident, UNC6661 used access to compromised email accounts to send additional phishing emails to contacts at cryptocurrency-focused companies, then deleted the outbound messages to cover their tracks.

After exfiltration, the extortion demand arrives -- typically a Bitcoin payment within 72 hours. If the victim doesn't pay, the data gets published on ShinyHunters' dark web leak site. In some cases, UNC6671 escalated with more aggressive tactics, including direct harassment of victim personnel. The use of different Tox IDs for negotiation and different domain registrars between UNC6661 and UNC6671 suggests separate individuals may be operating under the same umbrella, illustrating the amorphous, affiliate-like nature of these groups.

Why Traditional MFA Is Failing

Let's be direct about this: if your organization relies on push notifications, one-time passcodes, SMS codes, or even push with number matching as your MFA method, you are vulnerable to this exact attack. These are not phishing-resistant authentication methods. They rely on a shared secret or a human decision that can be socially engineered.

The entire security model of these MFA types assumes the user is interacting with a legitimate service in a non-coerced environment. When an attacker is on the phone actively guiding the authentication flow in real time, that assumption collapses entirely.

Okta's own analysis is unambiguous: phishing-resistant authenticators like Okta FastPass with device-bound credentials are cryptographically bound to the legitimate domain. Even if a user visits a phishing site, the authenticator refuses to complete the challenge because the domain doesn't match. FastPass logs these attempts as declined phishing events, providing both a block and a detection signal. There is no code to read aloud. There is no push to approve. The math simply doesn't work on a fake domain.

What Actually Works: Defenses That Matter

1. Deploy Phishing-Resistant MFA (Non-Negotiable)

This is the single most important action. FIDO2 security keys, WebAuthn passkeys, Okta FastPass, and smart cards/PIV provide authentication that is cryptographically bound to the legitimate domain. Even if a user visits a phishing site, the authenticator will refuse to complete the challenge because the domain doesn't match.

For organizations using Okta: enroll users in FastPass and passkeys, ideally both for redundancy. Enforce phishing-resistant authentication in your sign-on policies, especially for administrative accounts and access to sensitive applications.

For organizations using Microsoft Entra ID: enforce FIDO2 security keys through Conditional Access authentication strength policies.

For organizations using Google Workspace: implement context-aware access policies requiring phishing-resistant credentials.

2. Harden the Helpdesk

The helpdesk is now an attack surface. Threat actors impersonate IT staff, but they also call actual helpdesks pretending to be employees requesting MFA resets or device changes. Mandate out-of-band verification for any identity-sensitive request. During heightened threat periods, Mandiant recommends requiring live video calls where the requestor holds a physical government ID next to their face.

3. Restrict Network Access

Implement network zones or tenant access control lists that deny authentication attempts from anonymizing services (VPNs, Tor, residential proxies) commonly used by attackers. As Diallo put it: "The key is to know where your legitimate requests come from, and allowlist those networks."

4. Monitor the SSO Control Plane

If an attacker gets in through vishing, the first reliable detection signals will appear in your identity provider logs, not on a workstation. Monitor for:

  • New device enrollment events followed by logins from unfamiliar IP addresses
  • MFA factor changes or additions
  • Unusual OAuth application authorizations
  • Bulk data access patterns in connected SaaS applications
  • Mailbox rule creation or deletion (attackers delete security notification emails)
  • Microsoft 365 and SharePoint downloads where the User-Agent identifies PowerShell

5. Shrink the SSO Blast Radius

Apply least privilege to application assignments. Implement step-up authentication for high-value applications like CRM, financial systems, and admin consoles. Ensure that compromising one user's SSO session doesn't hand the attacker the keys to every system in the environment.

6. Prepare for Rapid Containment

Have a playbook ready. If you suspect SSO compromise: immediately revoke all active sessions, reset credentials, invalidate OAuth tokens, audit downstream application access, and check for unauthorized device enrollments. Mandiant recommends temporarily pausing MFA enrollment and password resets during active incident containment.

7. Train Employees -- But Be Realistic

Standard security awareness training has limited effectiveness against this specific threat because the attackers use highly persuasive, human-led tactics rather than automation. The call comes from what looks like a real IT number. The person on the other end sounds professional and knowledgeable. The phishing page looks exactly like the real login portal.

Train employees that IT will never ask them to approve an MFA challenge they didn't initiate, enter credentials on a link sent during a phone call, or read authentication codes aloud to anyone. But also accept that training alone is insufficient -- technical controls must be the primary barrier.

The Bigger Picture

This campaign represents a fundamental shift in how identity-based attacks operate. The attackers aren't breaking technology. They're exploiting the gap between how we authenticate (a single moment in time) and how we authorize access (an ongoing session). Once a session token exists, possession equals access.

The convergence of ShinyHunters, Scattered Spider, and LAPSUS$ into the SLSH alliance means that social engineering expertise, cloud platform knowledge, and extortion infrastructure are being combined and shared across a growing network of threat actors. The phishing kits are being sold as a service. The vishing callers are being hired as specialists. The entire operation is professionalizing.

And at the center of it all sits your SSO provider -- the single point of trust that, if compromised, cascades access across every connected application in your environment.

The irony is sharp: SSO was designed to simplify and centralize authentication. It succeeded. And now attackers are exploiting that centralization to achieve single-point-of-compromise across entire enterprises.

The fix isn't to abandon SSO. It's to defend it like the critical infrastructure it is.

Key Takeaways

  1. ShinyHunters/SLSH is actively targeting 100+ organizations through vishing attacks on Okta SSO accounts, with Mandiant tracking the activity across three distinct threat clusters.
  2. Custom AiTM phishing kits allow attackers to bypass push MFA, OTP, and number matching in real time by giving the caller C2-level control over what the victim sees in their browser during the phone call.
  3. Once SSO is compromised, every connected SaaS application is accessible -- Salesforce, Slack, M365, SharePoint, DocuSign, and more. Attackers are enrolling their own devices for persistence.
  4. FIDO2 security keys and passkeys are the only MFA methods that reliably defeat this attack chain. They are cryptographically bound to the legitimate domain and cannot be relayed through a phishing proxy.
  5. Detection must focus on identity provider logs: device enrollments, MFA changes, unusual OAuth authorizations, and PowerShell-based downloads from SharePoint/OneDrive.
  6. The helpdesk is now an attack surface and requires out-of-band verification for sensitive requests. During active threat periods, consider video-based identity verification.
Back to all articles