When MFA Becomes the Attack Surface: Synchronized Vishing, Real-Time Relay, and Authentication Trust Boundaries

Analysis of synchronized vishing attacks bypassing MFA through real-time authentication orchestration

Executive Summary

Thesis: The ShinyHunters-branded vishing campaign (January 2026) demonstrates that multi-factor authentication is not a security primitive but a user experience optimization when the authentication flow itself can be compromised through real-time adversary-in-the-middle orchestration.

Data: Okta documented custom phishing kits enabling synchronized vishing attacks targeting Google, Microsoft, and Okta SSO platforms (Okta Threat Intelligence, “Phishing kits adapt to the script of callers,” January 22, 2026). Mandiant identified UNC6661 and UNC6671 clusters successfully compromising Okta customer accounts and exfiltrating data from SharePoint, OneDrive, and SaaS platforms in early-to-mid January 2026 (Google Threat Intelligence Group, “Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft,” January 30, 2026). Silent Push detected infrastructure targeting 100+ organizations across fintech, healthcare, energy, and technology sectors (Silent Push, “SLSH Alert,” January 26, 2026). Confirmed victims include Match Group, Panera Bread, SoundCloud, and Crunchbase, with data exfiltration ranging from 2 million to 20 million records per incident.

What to do: Product security teams must architect authentication systems treating MFA not as a boundary but as a procedural step within a larger trust evaluation that includes device identity, network location, behavioral baselines, and phishing-resistant cryptographic authentication that cannot be relayed or orchestrated by an adversary on the phone.

Incident Overview: Real-Time MFA Bypass Through Synchronized Vishing

Between early and mid-January 2026, multiple threat clusters operating under the ShinyHunters brand executed sophisticated voice phishing campaigns that successfully bypassed multi-factor authentication controls at scale. Unlike traditional phishing campaigns that rely on static credential harvesting pages, these operations employed custom adversary-in-the-middle phishing kits specifically engineered to synchronize with live telephone-based social engineering.

Component	Trust Boundary Crossed	Primitive Abused	Impact	Exploitation Status	Fix/Mitigation
Okta/Microsoft/Google SSO	Human-to-system authentication verification	MFA approval mechanisms (push notifications, OTP codes, number matching)	Full SSO account compromise, lateral movement to SaaS platforms, data exfiltration of 2M-20M records per victim	Active exploitation confirmed; 100+ organizations targeted (Silent Push, January 26, 2026)	Phishing-resistant authentication (FIDO2, Okta FastPass, passkeys); network geolocation controls; behavioral anomaly detection

Google Threat Intelligence Group (GTIG) tracks this activity under multiple uncorrelated threat clusters: UNC6661, UNC6671, and the previously identified UNC6040 (ShinyHunters). Mandiant’s analysis confirms these are “seemingly independent groups that are using the same or a similar approach,” suggesting either a shared phishing-kit-as-a-service infrastructure or coordinated operations.

Problem Framing: The Authentication Trust Boundary Inversion

Traditional security architectures treat multi-factor authentication as a trust boundary – a point at which the system verifies “something you know” (password) plus “something you have” (device, token, or phone number) to establish authenticated identity. This architectural assumption rests on an invariant: the MFA challenge-response mechanism cannot be relayed or orchestrated by an attacker in real-time.

The ShinyHunters vishing campaign inverts this assumption. By synchronizing a phishing page with a live telephone call, attackers convert MFA from a boundary into a choreographed user experience where the victim believes they are following legitimate IT support instructions while the attacker simultaneously uses the victim’s credentials to authenticate against the real service.

Defining System Boundaries and Assumptions

The architectural assumptions that failed:

• Assumption 1: Users can distinguish between legitimate IT support and impersonation when calling from spoofed corporate phone numbers.
• Assumption 2: MFA push notifications with number matching provide sufficient anti-phishing protection.
• Assumption 3: Time-based one-time passwords (TOTP) cannot be relayed quickly enough to be useful to attackers.
• Assumption 4: Users will not approve MFA requests they did not initiate.

All four assumptions proved unsafe when the attacker controls both the authentication context (the phishing page the victim sees) and the social context (the voice call providing instructions).

Separating Threat Models

This analysis addresses three intersecting threat models:

1. Traditional phishing (credential theft): Attackers harvest usernames and passwords through static phishing pages. Defense: password managers, phishing awareness training, email security gateways.

2. Adversary-in-the-middle (AitM) phishing (session hijacking): Attackers proxy authentication flows to capture session tokens. Defense: device binding, certificate pinning, behavioral analytics.

3. Synchronized vishing + AitM (this campaign): Attackers orchestrate both the phishing page UI and victim instructions in real-time through voice calls, enabling MFA bypass through voluntary user cooperation. Defense: phishing-resistant authentication, out-of-band verification, network geolocation controls.

The third model is qualitatively different because it exploits the procedural nature of authentication rather than technical weaknesses in cryptographic protocols.

Technical Analysis: Attack Chain Mechanics

Phase 1: Reconnaissance and Infrastructure Preparation

Okta’s threat intelligence documented that attackers perform extensive reconnaissance before initiating vishing calls. This includes:

• Identifying employee names, titles, and work applications through LinkedIn, company websites, and OSINT
• Collecting phone numbers associated with corporate IT support or helpdesk teams
• Creating victim-branded phishing domains using patterns like companyname-internal.com or companynamesso.com
• Registering domains through NICENIC (UNC6661) or Tucows (UNC6671) to evade detection

Silent Push researchers identified phishing infrastructure targeting 100+ organizations spanning fintech (Betterment, Crunchbase), dating platforms (Match Group, Hinge, OkCupid, Bumble), food services (Panera Bread), media (SoundCloud), technology (Atlassian, Canva, Epic Games, HubSpot, RingCentral), healthcare (Moderna, Biogen), and energy sectors.

Phase 2: Synchronized Vishing Attack

The attack follows a precise choreography documented by Okta and Mandiant:

Step 1: Attacker calls victim using spoofed corporate or IT helpdesk phone number.

Step 2: Attacker impersonates IT support staff, claiming the organization is “updating MFA settings” or “performing a security audit” requiring the employee to verify their account.

Step 3: Attacker directs victim to a custom phishing page matching the company’s branding and SSO provider (Okta, Microsoft, Google).

Step 4: Victim enters username and password. Credentials are immediately relayed to attacker’s backend (Okta observed Telegram channels as the relay mechanism).

Step 5: Attacker uses stolen credentials to attempt authentication against the real SSO service, triggering an MFA challenge.

Step 6: Based on the MFA challenge type (push notification, TOTP code, number matching), the attacker uses the phishing kit’s control panel to dynamically update the phishing page to display matching instructions.

Step 7: Victim approves MFA request or enters OTP code, believing they are following IT support instructions. The approval authenticates the attacker’s session, not the victim’s.

Step 8: Attacker gains full SSO access, registers their own device for persistent MFA enrollment, and begins lateral movement.

Critical Finding: Okta Threat Intelligence states, “A social engineer interacting on the phone with a targeted user can simply request a user to choose or enter a specific number” to defeat number-matching MFA. This demonstrates that MFA mechanisms relying on user procedural compliance are vulnerable to real-time orchestration attacks where the attacker controls the instruction context.

Phase 3: Post-Compromise Activity and Data Exfiltration

Mandiant documented specific post-compromise behaviors by UNC6661 and UNC6671:

UNC6661 activities:

• Registered attacker-controlled devices for MFA to establish persistence
• Searched for documents containing personally identifiable information (PII)
• Targeted documents with keywords: “poc,” “confidential,” “internal,” “proposal,” “salesforce,” “vpn”
• Deleted “Security method enrolled” emails from Okta to hinder detection
• Deleted phishing emails sent from compromised accounts to cryptocurrency-focused contacts

UNC6671 activities:

• Leveraged PowerShell to download sensitive data from SharePoint and OneDrive
• Employed aggressive extortion tactics including harassment of victim personnel
• Used unbranded extortion emails with different Tox IDs (suggesting operational separation from UNC6661)

In the Match Group incident specifically, BleepingComputer reported that attackers gained access to AppsFlyer (mobile marketing analytics platform), Google Drive, and Dropbox cloud storage accounts after compromising an Okta SSO account. The leaked dataset included approximately 2 million unique advertising IDs (MAIDs), 85,000 email addresses, Hinge subscription transaction details, and internal corporate documents.

Root Cause: Architectural Anti-Pattern in Authentication Design

The fundamental failure is not in MFA implementation but in the assumption that authentication is a point-in-time verification rather than a continuous trust evaluation.

Traditional authentication architecture treats MFA as a binary gate:

Authentication Step	Trust Decision	Invariant Assumed
Username + Password	Knowledge factor verified	User knows secret
MFA Challenge (push/OTP)	Possession factor verified	User possesses device
Session Issued	Trust established	User is authenticated entity

The ShinyHunters campaign exploits the invariant violation in Step 2: the MFA challenge verifies that someone possesses the device, not that the legitimate user is performing the authentication. When an attacker can orchestrate the victim’s actions through real-time voice instructions, possession of the device becomes irrelevant – the victim voluntarily performs the authentication on behalf of the attacker.

This maps to CWE-287: Improper Authentication (at the architectural level) and OWASP A07:2021 – Identification and Authentication Failures, specifically the subcategory of authentication bypass through social engineering rather than technical exploitation.

Synthesis: The Procedural Authentication Failure Mode

We can generalize this attack into a reusable threat pattern: Procedural Authentication Bypass. This occurs when:

• Authentication relies on user procedural compliance (approving push notifications, entering codes)
• The attacker controls the instruction context (voice call, help desk interaction, support ticket)
• The authentication challenge can be relayed in near-real-time (within seconds to minutes)
• The system cannot distinguish between user-initiated and attacker-orchestrated authentication attempts

The defensive architecture that preserves the authentication invariant must replace procedural compliance with cryptographic proof that cannot be relayed or orchestrated:

Invariant to preserve: Authentication must cryptographically bind the user’s device to the authentication session such that the authentication cannot succeed unless the request originated from a device the user physically controls and the user’s physical interaction occurred in response to their own initiated action, not an attacker’s orchestration.

This invariant is satisfied by FIDO2/WebAuthn, where the private key never leaves the authenticator device and challenge-response occurs locally, or Okta FastPass, which uses device-bound cryptographic attestation. It is not satisfied by push notifications (can be approved under orchestration), TOTP codes (can be relayed), or SMS OTP (can be intercepted or relayed).

Threat Modeling Implications

What Assumptions Change

Traditional Assumption	Modern Reality	Control Implications	Residual Risk
MFA provides strong authentication	MFA provides procedural friction but can be bypassed through real-time orchestration when not cryptographically phishing-resistant	Migrate to FIDO2, WebAuthn, or platform authenticators with device binding	Users may lose hardware tokens; enrollment friction may drive shadow IT adoption of non-compliant auth methods
Users will recognize phishing attempts	Users cannot reliably distinguish legitimate IT support from sophisticated impersonation when caller ID is spoofed and branding is replicated	Eliminate phone-based authentication workflows; implement out-of-band verification through known-good channels	Legitimate support workflows become more cumbersome; user frustration may drive security bypasses
Session tokens are secure after authentication	Once attacker registers their own device for MFA, they maintain persistent access and can create additional sessions	Implement continuous device attestation; alert on new device enrollments; require step-up authentication for sensitive actions	Device loss or replacement triggers security alerts; users traveling or using new devices face friction
SSO centralizes security control	SSO creates a single point of compromise with blast radius across all integrated SaaS applications	Implement least-privilege app assignments; require step-up auth for high-value apps (finance, CRM, admin consoles); monitor for unusual SaaS access patterns	Complexity increases; some legitimate workflows may span multiple privilege levels; alert fatigue from cross-app access patterns
IT helpdesk can authenticate users over phone	Phone-based authentication is inherently vulnerable to impersonation when attackers control caller ID and have OSINT on IT processes	Eliminate phone-based password resets; require in-person or video verification for account recovery; implement callback verification on known-good numbers	Account recovery becomes slower; users locked out during off-hours may be unable to work; video verification requires privacy considerations

What Product Teams Commonly Miss (and What to Add to Your Threat Model)

When threat modeling authentication systems, product security teams should add these specific prompts:

1. Can an attacker control the instruction context during authentication? If users receive authentication instructions from support staff, help desk, or automated systems, can an attacker impersonate that instruction source convincingly enough to orchestrate user actions?
2. What is the temporal window for MFA relay? How quickly can an attacker relay authentication challenges and responses? If the window is measured in seconds (typical for push notifications or TOTP), assume real-time relay is feasible.
3. Does MFA cryptographically bind authentication to device ownership, or does it rely on procedural compliance? Push notifications and TOTP codes rely on users “doing the right thing.” FIDO2 and device attestation create cryptographic binding that cannot be relayed.
4. What is the blast radius of SSO compromise? Map every SaaS application, data store, and administrative console accessible through a single compromised SSO account. This becomes the attacker’s lateral movement surface.
5. Can an attacker persist after initial authentication? If attackers can register their own MFA devices, create service accounts, or generate API tokens, they maintain access even after the victim realizes compromise. How quickly can you detect and revoke unauthorized device enrollments?
6. Do your authentication logs capture device identity, geolocation, and behavioral anomalies? When reviewing authentication logs post-incident, can you distinguish between legitimate user authentication and attacker-orchestrated authentication based on device fingerprints, network location, time-of-day patterns, and access sequences?
7. Is your help desk a security boundary or an attack vector? Does your IT support process allow phone-based authentication, password resets, or MFA enrollment changes? These workflows become social engineering opportunities.
8. Can users distinguish between phishing and legitimate corporate infrastructure? If legitimate company processes involve clicking links in emails, visiting SSO portals from unknown URLs, or following phone-based instructions, you’ve normalized the exact behaviors that attackers exploit.

Actionable Recommendations

Do First (0-30 Days): Stop the Bleeding

• Audit and revoke suspicious MFA device enrollments: Review all device enrollments in Okta, Microsoft Entra, and Google Workspace from the past 90 days. Flag enrollments that occurred during off-hours, from unusual geolocations, or coinciding with support ticket activity. Mandiant observed attackers registering their own devices immediately after gaining access.
• Implement emergency out-of-band verification for password resets: Temporarily route all password and MFA resets through manual identity verification using video calls or in-person verification. This breaks the vishing attack chain by requiring attackers to physically impersonate the victim.
• Enable geo-fencing for SSO authentication: If your organization operates from known office locations or countries, implement network zones or tenant ACLs that deny authentication attempts from anonymizing services (Tor, VPNs) and geographic regions where you have no business presence. Okta recommends: “The key is to know where your legitimate requests come from, and allowlist those networks.”
• Hunt for IOCs in authentication logs: Search for authentication patterns matching the attack chain: credential validation followed within 10 minutes by MFA device enrollment from a different IP address or user agent. Mandiant provides detection queries in their defense guidance.
• Alert security team and users: Brief employees on the specific vishing tactics being used. Emphasize that IT support will never call asking for MFA codes or requesting users to approve push notifications. Provide a trusted callback number for verification.

Validation: Can your SOC detect a vishing attack in progress? Run a red team exercise where an internal team attempts vishing against consenting volunteers. Measure time-to-detection and time-to-containment.

Do Next (30-90 Days): Harden Authentication Architecture

• Migrate to phishing-resistant MFA: Enroll users in Okta FastPass, FIDO2 security keys, or platform authenticators (Windows Hello, Touch ID, Face ID). Deprecate push notifications and TOTP for primary authentication. Okta states unambiguously: “There is no substitute for enforcing phishing resistance for access to resources.”
• Implement step-up authentication for high-value applications: Require phishing-resistant MFA re-authentication before accessing CRM systems (Salesforce), financial applications, administrative consoles, or source code repositories. This limits blast radius even if SSO is compromised.
• Deploy behavioral anomaly detection: Implement UEBA or SIEM rules that flag authentication patterns inconsistent with user baselines: unusual time-of-day, new device types, geographic anomalies, rapid sequential access to multiple SaaS applications, or bulk data export operations. Mandiant noted attackers immediately downloading sensitive data from SharePoint and OneDrive after gaining access.
• Reduce SSO blast radius through least-privilege app assignments: Audit which users have access to which SaaS applications through SSO. Remove unnecessary app assignments. Implement just-in-time access provisioning for administrative functions.
• Eliminate phone-based account recovery: Redesign password reset and account recovery workflows to remove phone calls as an authentication channel. Implement self-service recovery using pre-registered recovery codes, trusted device verification, or in-person identity validation for high-privilege accounts.

Validation: Conduct tabletop exercises simulating SSO compromise. Can your team detect lateral movement to SaaS platforms? Can you revoke sessions and device enrollments within 15 minutes of detection?

Hardening (90-180 Days): Architectural Resilience

• Implement continuous device attestation: Deploy endpoint detection and response (EDR) or mobile device management (MDM) that continuously validates device health and compliance before allowing authentication. Devices showing signs of compromise should be automatically denied access regardless of MFA status.
• Build behavioral baselines per user and service account: Create profiles of normal authentication patterns (time windows, geographies, accessed applications, data volumes) for each user. Alert on statistically significant deviations. This addresses the reality that attackers will obtain valid credentials – detection must focus on how those credentials are used.
• Deploy API-level DLP for SaaS platforms: Implement Cloud Access Security Broker (CASB) or native SaaS DLP controls that monitor for bulk exports, unusual query patterns, or access to sensitive data stores. Mandiant observed PowerShell-based downloads from SharePoint – API-aware monitoring would detect this.
• Implement live caller verification systems: For financial institutions and high-security environments, deploy systems (similar to those being tested by Monzo Bank and cryptocurrency exchanges) that allow users to verify in a mobile app whether an authorized representative is currently on the phone with them. This breaks impersonation attacks.
• Create fast-containment playbooks: Document and automate response procedures for suspected SSO compromise: revoke all active sessions, invalidate refresh tokens, reset MFA devices, hunt for downstream SaaS access, pull authentication logs, notify affected users. Practice these playbooks quarterly. Mandiant emphasizes: “If an adversary gains access through vishing and MFA manipulation, the first reliable signals will appear in the SSO control plane, not inside a workstation.”

Validation: Measure mean time to detect (MTTD) and mean time to contain (MTTC) for authentication compromise. Target: MTTD <15 minutes, MTTC <1 hour.

If This Control Had Been in Place: Counterfactual Analysis

Let’s examine which attack steps would have failed had specific controls been implemented, with appropriate qualifiers:

If phishing-resistant MFA (FIDO2) had been enforced: The attack would likely have failed at Step 7. FIDO2 authentication requires cryptographic proof from the authenticator device that cannot be relayed to the attacker’s session. The victim approving the request would generate a signature valid only for the phishing domain, not the legitimate SSO provider. However, this assumes universal FIDO2 enrollment; if attackers targeted users with fallback authentication methods (SMS OTP recovery codes), they could still succeed.

If network geo-fencing had been implemented: The attack would possibly have failed at Step 5, when the attacker attempted authentication from an IP address outside allowlisted networks. However, this depends on where the attacker’s infrastructure was hosted; if they used residential proxies in the victim’s geography (as some threat actors do), they could bypass geo-fencing.

If new MFA device enrollments required out-of-band verification: The attack would likely have been detected at Step 8, when the attacker registered their own device for persistent access. If enrollment required video verification or manager approval, attackers could not establish persistence, limiting their operational window to the lifetime of the stolen session token (typically hours to days).

If behavioral anomaly detection had been deployed: The attack might have been detected during post-compromise activity (Phase 3), when attackers accessed unusual applications, downloaded bulk data, or exhibited access patterns inconsistent with the victim’s baseline. However, detection is not prevention; by this point, data exfiltration may have already occurred.

If help desk workflows prohibited phone-based authentication: The attack would likely have failed at Step 2-3, as the attacker’s social engineering pretext (“IT support updating MFA settings”) would not align with established IT processes. However, this assumes users are aware of policy and do not fall back to old habits when pressured by authority figures on the phone.

What This Does NOT Mean: Limits and Non-Goals

This analysis should not be interpreted to mean:

• MFA is useless: Multi-factor authentication remains essential defense-in-depth. The ShinyHunters campaign succeeds because MFA creates friction that must be overcome through social engineering – automated credential stuffing attacks are stopped entirely by MFA. The lesson is not to abandon MFA but to deploy MFA technologies resistant to real-time relay attacks.
• All vishing attacks succeed: These attacks require significant operational investment: reconnaissance, custom infrastructure, skilled social engineers, and real-time coordination. Many vishing attempts fail because victims recognize impersonation, refuse to follow instructions, or report suspicious calls to security teams.
• Phishing-resistant MFA is a silver bullet: FIDO2 and WebAuthn eliminate the specific relay attack demonstrated in this campaign, but they do not address device compromise (malware on user’s laptop), social engineering to authorize malicious OAuth applications, or physical device theft. Defense-in-depth remains necessary.
• Help desk workflows must be eliminated entirely: Legitimate IT support is essential for business operations. The goal is not to prohibit help desk interactions but to redesign authentication workflows so that help desk personnel cannot directly authenticate users or reset MFA without additional verification steps that attackers cannot feasibly bypass.
• This attack only affects Okta: While Okta SSO was prominently targeted, the same techniques apply to Microsoft Entra ID, Google Workspace, and any SSO platform that relies on push notifications, TOTP, or SMS OTP for MFA. The architectural lesson generalizes across all identity providers that do not enforce phishing-resistant authentication.

Pattern Card: Synchronized Vishing + Adversary-in-the-Middle MFA Bypass

Pattern Name	Preconditions	Exploit Mechanics	Signals	Mitigations	Residual Risk
Synchronized Vishing + AitM	1) Target uses SSO with procedural MFA (push, TOTP, SMS). 2) Attacker obtains employee names/phone numbers. 3) Attacker can register phishing domains mimicking corporate SSO. 4) Attacker has skilled social engineers.	1) Attacker calls victim impersonating IT support. 2) Directs victim to phishing page. 3) Victim enters credentials. 4) Attacker relays credentials to real SSO, triggering MFA challenge. 5) Attacker updates phishing page to match MFA challenge type. 6) Victim approves MFA under attacker instruction. 7) Attacker session authenticated; registers own device for persistence.	1) Authentication from unusual geography/IP. 2) New MFA device enrollment shortly after successful authentication. 3) User reports suspicious IT support call. 4) Unusual post-auth activity: bulk SaaS data exports, access to apps user rarely uses. 5) Authentication logs show session from unknown user agent or device fingerprint.	1) Phishing-resistant MFA (FIDO2, WebAuthn, Okta FastPass). 2) Network geo-fencing + anomaly detection. 3) Out-of-band verification for MFA device enrollment. 4) Help desk workflows prohibiting phone-based authentication. 5) User education on vishing tactics.	1) Users lose FIDO2 tokens requiring re-enrollment. 2) Legitimate travel triggers geo-fencing alerts. 3) Attackers using residential proxies may bypass network controls. 4) Determined attackers may attempt physical impersonation or device theft. 5) Users under high stress may approve requests despite training.

Broader Context: Regulatory and Insurance Implications

While not the primary focus of this analysis, the ShinyHunters campaign has implications for regulatory compliance and cyber insurance:

Regulatory: Organizations subject to data protection regulations (GDPR, CCPA, HIPAA) may face breach notification requirements when PII is exfiltrated. The Match Group incident exposed user IDs, IP addresses, transaction details, and email addresses – data elements triggering notification obligations in many jurisdictions. Regulatory inquiries may focus on whether the organization implemented reasonable security measures, including whether phishing-resistant MFA was available but not deployed.

Insurance: Cyber insurance underwriters are increasingly scrutinizing authentication controls. Insurers may deny claims or increase premiums for organizations that experienced vishing-based breaches where phishing-resistant MFA was available but not mandated. The trend noted by Google Cloud’s head of business risk and insurance – “organizations without MFA won’t just pay more – they won’t get coverage” – is extending to type of MFA deployed, not just presence/absence.

Conclusion: Architecting for Adversarial Instruction Contexts

The ShinyHunters vishing campaign demonstrates a fundamental architectural lesson: security controls that rely on users performing correct procedures under instruction are vulnerable to attacks where the attacker controls the instruction context.

Multi-factor authentication as typically deployed (push notifications, TOTP codes, SMS OTP) is not a cryptographic security primitive – it is a user experience optimization that creates procedural friction. When an attacker can synchronize a phishing page with live voice instructions, that friction becomes choreographed cooperation.

The defensive architecture that preserves authentication integrity must eliminate relayable authentication factors entirely and replace them with cryptographic proof-of-possession that cannot be orchestrated: FIDO2, WebAuthn, platform authenticators with device binding. This shifts authentication from “did the user approve?” to “did the cryptographic key stored on the user’s device sign this challenge?” – a question that cannot be answered through social engineering.

Product security teams building authentication systems should apply this checklist question tomorrow:

Forcing Function: If an attacker gains control of the instruction context (phone call, help desk ticket, support chat), can they orchestrate our users into performing authentication actions that benefit the attacker? If yes, the authentication system relies on procedural compliance, not cryptographic security, and is vulnerable to synchronized social engineering attacks.

References & Data Sources

Primary Sources:

• Okta Threat Intelligence, “Phishing kits adapt to the script of callers,” January 22, 2026. https://www.okta.com/blog/threat-intelligence/phishing-kits-adapt-to-the-script-of-callers/
• Google Threat Intelligence Group (Mandiant), “Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft,” January 30, 2026. https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft
• Google Threat Intelligence Group (Mandiant), “Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS,” January 30, 2026. https://cloud.google.com/blog/topics/threat-intelligence/defense-against-shinyhunters-cybercrime-saas
• Silent Push, “SLSH Alert: Massive Vishing Attack Targeting SSO Accounts,” January 26, 2026. https://www.silentpush.com/blog/slsh-alert/

Secondary Sources (Incident Coverage):

• BleepingComputer, “Match Group breach exposes data from Hinge, Tinder, OkCupid, and Match,” January 29, 2026. https://www.bleepingcomputer.com/news/security/match-group-breach-exposes-data-from-hinge-tinder-okcupid-and-match/
• BleepingComputer, “Okta SSO accounts targeted in vishing-based data theft attacks,” January 23, 2026. https://www.bleepingcomputer.com/news/security/okta-sso-accounts-targeted-in-vishing-based-data-theft-attacks/
• Help Net Security, “ShinyHunters flip the script on MFA in new data theft attacks,” February 2, 2026. https://www.helpnetsecurity.com/2026/02/02/shinyhunters-mfa-social-engineering/
• CSO Online, “ShinyHunters ramp up new vishing campaign with 100s in crosshairs,” January 29, 2026. https://www.csoonline.com/article/4124684/shinyhunters-ramp-up-new-vishing-campaign-with-100s-in-crosshairs.html

Statistics mapped to sources:

• 100+ organizations targeted: Silent Push researchers, January 26, 2026 detection of phishing infrastructure
• UNC6661 and UNC6671 compromise Okta customer accounts: Mandiant, “Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft,” January 30, 2026
• 2 million unique advertising IDs, 85,000 email addresses (Match Group): DataBreach.com analysis, January 2026
• Early to mid-January 2026 exploitation window: Mandiant, “Tracking the Expansion,” January 30, 2026
• Custom phishing kits sold as-a-service: Okta Threat Intelligence, “Phishing kits adapt to the script of callers,” January 22, 2026