ShinyHunters SSO Scams: How Vishing & Phishing Attacks Work [2025]

The Rising Threat of Shiny Hunters SSO Scams: What Security Teams Need to Know

It started with a phone call. An employee at your company picks up their desk phone, and on the other end is someone claiming to be from IT support. They sound professional, calm, even a bit urgent. "We've detected some unusual activity on your account," the voice says. "We need to update your multi-factor authentication settings right now. Can you walk me through your current setup?"

Sounds innocent enough, right? It isn't.

This is how Shiny Hunters, one of the most sophisticated extortion gangs operating today, has managed to orchestrate a wave of single sign-on (SSO) attacks that have crippled organizations across virtually every industry. We're talking financial services, healthcare, technology, retail, manufacturing. Nobody's immune.

Google's Mandiant team recently dissected their playbook, and what they found was genuinely alarming: a perfectly choreographed combination of social engineering, custom-built phishing infrastructure, and relentless extortion that turns stolen credentials into millions of dollars. The scary part? It's not complicated. It's just effective.

This guide digs into exactly how Shiny Hunters operate, why their attacks are so successful, and most importantly, what your organization needs to do right now to defend against them. We'll cover the technical details, the human psychology they exploit, the defense mechanisms that actually work, and the frameworks that security teams are adopting to fight back.

If you're responsible for security at your company, this isn't theoretical anymore. The threat is real, it's persistent, and it's targeting your organization specifically.

TL; DR

• Shiny Hunters use multi-stage attacks: vishing (voice phishing) combined with custom phishing pages tailored to each victim's SSO provider
• They steal MFA codes: By manipulating employees through social engineering, attackers obtain multi-factor authentication codes needed to breach SSO-protected accounts
• SSO platforms at risk: Google Workspace, Microsoft 365, Okta, Salesforce, Dropbox, and dozens of other enterprise cloud platforms have been compromised
• Phishing-resistant MFA is critical: Passwordless authentication methods like FIDO2 hardware keys are far more effective than time-based codes
• Zero Trust architecture is essential: Organizations must verify every access request, assume no device is trusted, and implement strict network segmentation
• Bottom line: Defense requires layered security combining employee training, technical controls, and architectural changes

Customer data is often the primary target during data exfiltration, followed by financial information and intellectual property. Estimated data.

Understanding SSO and Why It's Such an Attractive Target

What Is Single Sign-On and Why Do Organizations Use It?

Single sign-on is elegant in its simplicity. Instead of managing dozens of separate passwords across dozens of different cloud applications, employees log in once with a central identity provider. That identity provider—Google, Microsoft, Okta—then vouches for who they are to all the other applications they need to access.

This is brilliant from a user experience perspective. No password sprawl. No resetting forgotten credentials. Employees can get to Salesforce, Slack, Jira, and GitHub with a single login. IT administrators can manage user access in one place, which means when someone leaves the company, you disable one account instead of forty. Security teams can enforce stronger authentication policies globally instead of begging each SaaS vendor to implement two-factor auth.

But here's the thing: SSO is also an incredible target. If you compromise someone's SSO credentials, you don't just get access to one application. You get access to everything. It's like stealing someone's master key. One breach cascades through an entire digital ecosystem.

Why Shiny Hunters Focus on SSO Specifically

Shiny Hunters understand this math perfectly. They don't care about breaking into one system. They want the keys to the kingdom. A compromised SSO account gives them access to:

• Customer databases: Stored in Salesforce, HubSpot, or whatever CRM the company uses
• Financial records: Stripe accounts, payment processing systems, billing platforms
• Source code repositories: GitHub, GitLab, Bitbucket where the company's intellectual property lives
• Employee data: HR systems, payroll databases, benefit platforms
• Confidential communications: Slack, Microsoft Teams, email archives
• Sensitive documents: Dropbox, OneDrive, Google Drive with contracts, negotiations, strategic plans

Once they're in, they exfiltrate whatever's valuable, add it to a data leak site, and contact the company with a ransom demand. Pay, or we sell this to competitors, regulators, journalists, whoever.

The scale is what makes Shiny Hunters particularly dangerous. They're not hitting a few companies per month. They're running dozens of simultaneous campaigns, hitting different targets across different time zones, rotating through different identity providers.

Implementing MFA at

The Anatomy of a Shiny Hunters Attack: Stage One - Vishing

How the Phone Call Works

The attack starts with intelligence gathering. Shiny Hunters have detailed target lists organized by company, industry, and role. They know who works in what department. They know what cloud platforms that company uses. They know what their general organizational structure looks like.

Then comes the call. Usually it's between 9 AM and 5 PM when people are most likely to be at their desks and in a work mindset. The person calling doesn't sound like a criminal. They sound like an overworked IT person from a helpdesk in another office or a contractor hired to do a security audit.

The pitch varies slightly based on who they're calling, but the core message is the same: "We've detected unusual activity on your account." Or: "We're updating MFA settings for everyone in your department." Or: "We're migrating to a new identity provider and need to re-verify your credentials."

What makes these calls effective is that they're not entirely false. Companies do update MFA settings. Companies do upgrade their identity infrastructure. The attacker is leveraging something that sounds plausible, wrapping a malicious request in the language of routine IT operations.

The Social Engineering Psychology

Vishing works because of psychological principles that security training doesn't always address. When someone in a position of authority (real or perceived) calls you during work hours and speaks with confidence, most people's instinct is to cooperate. Authority bias is real. People want to be helpful. If IT is asking you to update your security settings, saying no sounds irresponsible.

There's also urgency. The attacker frames this as time-sensitive. "We need to do this right now or your account will be locked." "Your security settings are out of compliance." "We're conducting an emergency audit."

Phishing-resistant employees—the ones who've been trained extensively—might push back. But Shiny Hunters have a solution for that too. If the first person says no or seems skeptical, they just call someone else. They're running dozens of these campaigns per week. Even a 5% success rate is profitable.

Credential Harvesting Via the Phone

Once the attacker has the target on the phone, they ask a series of seemingly innocent questions:

• "What's your username or email address so I can look up your account?"
• "Can you confirm your password? I need to verify your account status."
• "What's your current MFA method? Are you using the authenticator app or SMS codes?"
• "Can you walk me through the steps you see on your screen right now?"

Many of these questions sound like normal IT support procedures. Some employees will directly provide passwords. Others won't, and that's fine—the attacker already has them. Others still will be suspicious but won't know what to be suspicious about.

The key insight is that the attacker doesn't need the password on the phone call. They just need to know what authentication method the employee is using. Is it Google Authenticator? Okta Verify? SMS? Windows Hello? This information determines what kind of phishing page they'll need to create next.

Stage Two - Custom Phishing Infrastructure

Why Generic Phishing Pages Fail

Most phishing pages fail because they're generic. An attacker will create a page that looks vaguely like a Google login, or an Okta login, or a Microsoft login. But they're not actually integrated with anything. They're just a form that captures whatever someone types into it.

But modern SSO systems have evolved. If you actually try to log in to a real Okta instance, it doesn't just accept any username and password. It validates against the actual Okta system. If the phishing page is completely fake, users will notice it doesn't work correctly.

This is where Shiny Hunters' sophistication becomes apparent. They're not running generic phishing pages. They're running custom-built infrastructure that actually proxies the login request to the real SSO provider.

How Proxy Phishing Works

Imagine Shiny Hunters sets up a server that looks like accounts-secure.okta-verification.com or something similarly deceptive. When an employee visits this fake page and enters their username and password, here's what happens behind the scenes:

1. The attacker's server receives the username and password
2. The attacker's server immediately sends those same credentials to the real Okta server
3. The real Okta server either accepts or rejects the credentials
4. If accepted, Okta responds to the attacker's server with a challenge: "Okay, now prove you have MFA."
5. The attacker's page shows the user the real MFA prompt—authenticator app, SMS code, push notification, whatever
6. The user provides their MFA code
7. The attacker captures it and passes it through to Okta
8. Okta validates it and says "logged in"
9. The attacker can now log in as this user whenever they want

From the user's perspective, the whole process feels normal. The login page worked. They entered their credentials. They got asked for their second factor. They provided it. Everything behaved exactly as expected.

Modular, Real-Time Customization

What makes Shiny Hunters' infrastructure particularly dangerous is that it's modular. They're not running one phishing page. They're running dozens, each customized for different victim organizations.

An organization using Google Workspace gets a Google-branded fake login. An organization using Microsoft 365 gets a Microsoft-branded fake login. Within Google, if the victim uses Gmail, they get one page. If they use a custom domain, they might get a different page.

Moreover, these pages can be modified in real-time. If security researchers discover one phishing domain, Shiny Hunters can have a completely different one deployed within hours. If they notice that a particular organization started blocking their phishing domain, they can rotate to a new domain and update all their phishing campaigns.

They're also using domain names that are deceptively similar to legitimate ones. Not okta-verify.com, but okta-verifications.com or okta-security-update.com. The differences are subtle enough that people reading URLs quickly won't catch them.

The Role of Email in Phishing Delivery

How does the victim actually get sent to this fake phishing page? Sometimes it's via email. The email looks like it's from IT support or the SSO provider themselves. "Click here to update your MFA settings." Sometimes it's a link that was mentioned on the phone call. "Visit [fake-domain] and log in with your existing credentials."

Other times, Shiny Hunters use more sophisticated techniques. They might compromise a vendor email account and send phishing emails from a trusted source. They might create a fake internal Slack message. They might post a link in comments on public GitHub repositories if the target organization uses GitHub Enterprise.

The delivery mechanism varies, but the underlying attack is the same: get the victim to enter their credentials and MFA code into a page controlled by the attacker.

Authority bias and urgency are the most common tactics used in vishing attacks, each comprising around 25-30% of the approach. Estimated data based on typical vishing strategies.

Why Traditional MFA Fails Against These Attacks

The Problem With Time-Based One-Time Passwords (TOTP)

Many organizations think they're protected because they've deployed multi-factor authentication. They require employees to use Google Authenticator or similar TOTP apps. This is a massive step forward compared to no MFA at all, but it's not sufficient against sophisticated attackers.

Here's why: A TOTP code is just a six-digit number that changes every 30 seconds. It's generated based on a shared secret (stored in the authenticator app) and the current time. The code is valid for the entire 30-60 second window, and by design, these systems are stateless. If you enter a valid code, the authentication server doesn't know or care whether you just generated it on your phone or received it via email.

When Shiny Hunters use a proxy phishing page, they capture the TOTP code in real-time and pass it through to the legitimate authentication server within the 30-second validity window. The server says "yes, this is valid," and boom, the attacker is logged in.

Better yet, TOTP codes are often displayed on your phone in a way that makes them easy to read over a phone call. A skilled social engineer can talk someone into reading their six-digit code aloud. Or they can convince someone that there's a technical issue and their code didn't work, so they need to share it.

SMS-Based MFA Is Even Worse

SMS-based authentication is technically easier for attackers to compromise. They can:

• Conduct SIM swaps, convincing a phone carrier to transfer the victim's phone number to a attacker-controlled SIM
• Use telecom vulnerabilities to intercept SMS messages
• Social engineer the victim into reading their SMS code aloud
• Compromise the phone carrier's systems directly

SMS is better than no MFA, but it's the least secure form of second factor available to modern organizations.

Email-Based MFA Has Similar Problems

If an organization uses email-based MFA ("click this link to verify your login"), attackers can:

• Compromise the email account first (using a phishing page that targets email)
• Set up mail forwarding rules to intercept verification emails
• Proxy the email verification link the same way they proxy password fields

Push Notifications: Better, But Not Perfect

Push notification-based MFA ("Approve this login request on your phone") is better because it requires the user to actively approve from a separate device. An attacker can't capture a push notification through a proxy phishing page.

But Shiny Hunters have found ways around this. They can:

• Social engineer the user into approving the push notification ("It might ask for approval, that's normal")
• Use notification flooding—send dozens of approval requests hoping the user approves one without paying attention
• Target the MDM (mobile device management) system to push fake approvals

The Solution: Phishing-Resistant MFA

What Makes Authentication "Phishing-Resistant"

Phishing-resistant authentication (sometimes called "phishing-proof") works on a fundamentally different principle than codes or SMS. Instead of the user proving who they are with something they know (password) or something they have (phone), phishing-resistant MFA relies on cryptographic proof.

The most common implementation is FIDO2 (Fast Identity Online 2), which is an open standard created by the FIDO Alliance and supported by Microsoft, Google, Apple, Amazon, and virtually every major tech company. Hardware security keys like YubiKeys or Titan Security Keys implement FIDO2.

Here's how FIDO2 works:

1. During registration, the security key generates a public-private key pair and stores the private key on the hardware key
2. The public key is sent to the authentication server (e.g., Okta, Google, Microsoft)
3. When logging in, the authentication server sends a challenge (a random number)
4. The security key uses its stored private key to sign the challenge
5. The signed challenge is sent back to the authentication server
6. The authentication server verifies the signature using the public key it stored during registration
7. If the signature is valid, the user is authenticated

What makes this phishing-resistant is that the authentication is bound to the specific domain. When you're logging in at okta.com, the security key signs a challenge that includes okta.com as part of the signature. If you're tricked into visiting okta-verifications.com, the security key won't sign a challenge for that domain because the domain name is different.

Why Phishing-Resistant MFA Defeats Shiny Hunters

Going back to our proxy phishing scenario: Shiny Hunters capture your credentials and MFA code and pass them through to the real Okta server. But if your MFA is FIDO2, there's nothing to capture. When you plug in your security key at the phishing site, it simply won't sign anything because the domain is wrong. The key is cryptographically locked to the legitimate domain.

Even if Shiny Hunters could somehow get a legitimate challenge from Okta and trick you into using your security key to sign it, the attacker still couldn't use that signature to log in themselves. The signature is non-transferable. It's like a check that can only be deposited once.

This is why industry experts, security researchers, and organizations like Google and Microsoft are pushing so hard for FIDO2 adoption. It's not perfect, but it's the closest thing we have to phishing-proof authentication.

Implementation Challenges

The biggest barrier to FIDO2 adoption isn't technical. It's logistical. Security keys cost money—usually

There's also a user experience burden. People need to carry their security key. They need to plug it in whenever they log in from a new device. For a highly mobile workforce, this can be frustrating.

Because of these challenges, most organizations are taking a phased approach. They're rolling out FIDO2 first to high-risk roles like administrators, executives, and security personnel. Then they're gradually expanding to the broader employee base.

Some organizations are using Windows Hello (facial recognition or fingerprint on Windows devices) or similar platform-specific implementations, which provide some of the same phishing-resistant properties without requiring an external key.

Estimated data shows high adoption rates of FIDO2 among major tech companies, enhancing security against phishing attacks.

Stage Three - Data Exfiltration and Extortion

How Attackers Move Once They're Inside

Once Shiny Hunters have compromised an SSO account, they're not done. They're just getting started. The first thing they do is establish persistence. They create additional accounts that they control. They set up mail forwarding rules on the victim's email account so they can monitor outgoing and incoming messages. They change security settings and backup phone numbers so the legitimate user can't easily regain control.

Then comes lateral movement. From the initial SSO account, they systematically gain access to other accounts and systems:

• They access the identity provider (Okta, Google, Microsoft) to see what other applications are connected and what other users have administrative access
• They compromise other high-value accounts: executives, finance, HR, operations
• They get credentials for systems that aren't connected to SSO: legacy systems, on-premises servers, specialized software
• They escalate privileges, looking for domain administrator accounts that have access to everything

This part of the attack is often undetected for weeks or months. Unlike the initial breach, which might trigger alerts, lateral movement within a corporate network can happen quietly if the attacker is patient and careful.

What They're Looking For

Once they have broad access, Shiny Hunters look for valuable data:

• Customer data: Names, email addresses, phone numbers, subscription information. This is gold for other attackers
• Financial information: Invoices, payment processor accounts, billing data, tax returns
• Intellectual property: Source code, product roadmaps, architectural diagrams, research data
• Strategic information: Board meeting minutes, M&A plans, partnership agreements, pricing strategies
• Employee data: Social security numbers, background checks, medical information, salary information

The volume of data exfiltrated is often staggering. We're talking hundreds of gigabytes or terabytes. In one recent compromise, attackers downloaded years worth of company emails, customer databases, and development infrastructure documentation.

The Data Leak Site

Once they've exfiltrated the data, Shiny Hunters upload a sample to a data leak site that they control. This is crucial for their extortion tactics. They need proof that they actually have the data, not just claims.

Their leak site shows:

• The victim company's name and logo
• Sample files from the exfiltration
• File counts and sizes
• Sometimes, preview images of confidential documents

The leak site is hosted on the dark web (hidden services on Tor) because it needs to be anonymous and uncensorable.

The Extortion Demand

Then comes the message. Usually it's sent via email, or posted as a comment on the company's website, or delivered through an anonymous tip to a journalist. Sometimes it's more direct:

"We have your customer database, employee records, and source code. We're asking for [X amount of cryptocurrency] to be paid within [timeframe]. If you don't pay, we'll contact your customers, regulators, and the media."

Because the attacker has already posted proof (sample data on the leak site), the threat is credible. Organizations face a terrible choice:

• Pay the ransom and hope the attacker actually deletes the data (they often don't)
• Don't pay and risk the data being released publicly
• Negotiate for a lower amount
• Go to law enforcement and hope they can recover the data (recovery rates are low)

Why Extortion is Hard to Fight

Law enforcement has made some progress against ransomware gangs. They've seized servers, arrested operators, and recovered some funds. But Shiny Hunters operate in jurisdictions with limited law enforcement cooperation with the U.S., and they use cryptocurrency, which is difficult to trace.

Many organizations end up paying because the alternative—public disclosure of customer data, employee records, and proprietary information—seems worse than the financial loss. A data breach affecting millions of customers could tank a company's reputation, trigger regulatory fines, and spark lawsuits.

Zero Trust Architecture: The Framework for Defense

What Is Zero Trust?

Zero Trust is a security framework built on a simple principle: never trust, always verify. Traditional security assumed that if you were inside the corporate network, you were trustworthy. Zero Trust assumes that every user, device, and request is potentially compromised and needs to be verified.

Zero Trust doesn't rely on a single authentication event. Instead, it continuously verifies:

• Is this the legitimate user? (continuous authentication)
• Is this device compliant with security standards? (device posture checking)
• Is this access pattern normal for this user? (behavioral analysis)
• Is this request coming from a legitimate location? (geolocation verification)
• Is this user trying to access data that's appropriate for their role? (least privilege access)

If any of these checks fail, the request is denied, even if the user's password and MFA code are correct.

Core Principles of Zero Trust

Verify Explicitly: Use all available data points to authenticate users. Don't just check passwords and MFA. Check device health, location, time of access, role, and history.

Secure Every Path: Implement security controls for every access path, not just VPN. Network access, cloud access, application access, API access—all should be secured.

Assume Breach: Design your security systems assuming that an attacker has already breached some part of your network. Make it difficult for them to move laterally. Segment networks so that compromise of one system doesn't automatically grant access to everything.

Principle of Least Privilege: Users should have the minimum access needed to do their job, nothing more. A customer service representative shouldn't have access to the database of customer payment information.

Verify Device Health: Don't trust any device automatically. Require devices to meet minimum security standards: OS is up to date, antivirus is installed and running, disk encryption is enabled. If a device fails these checks, it gets quarantined until it's fixed.

Implementation: Identity and Access Management (IAM)

The foundation of Zero Trust is strong identity and access management. This means:

• Centralized identity provider: Use a platform like Okta, Azure AD, or OneLogin as the single source of truth for who is allowed to access what
• Multi-factor authentication: Require MFA for all access, especially privileged access
• Conditional access policies: Define rules that restrict access based on risk factors
• Access reviews: Regularly audit who has access to what and remove unnecessary permissions
• Privileged access management (PAM): For highly sensitive accounts (database administrators, domain administrators), implement additional controls like requiring approval before access is granted

Implementation: Network Segmentation

Zero Trust networks are microsegmented. Instead of a flat network where anyone can talk to anyone, you create network zones and strictly control what can communicate with what:

• Employees are in one zone
• Contractors are in another, more restricted zone
• Development systems are isolated from production
• Finance and HR systems are segmented from operational systems
• Database servers can only be accessed from specific application servers, not from arbitrary workstations

This is implemented using firewalls, security groups in cloud environments, and network access control lists. If an attacker compromises one zone, they can't automatically move to another zone without clearing additional security checks.

Implementation: Device Management

Zero Trust requires visibility into every device that connects to the network. This means:

• Mobile Device Management (MDM): Control and monitor phones and tablets
• Endpoint Detection and Response (EDR): Monitor laptops and desktops for suspicious activity
• Device compliance checking: Require devices to meet security standards before access is granted
• Forced updates: Ensure all devices have the latest security patches

If a device is compromised or not compliant, it's cut off from sensitive resources until it's cleaned up.

Estimated data shows that customer databases and source code repositories are the most targeted access points when SSO credentials are compromised, each accounting for 20% of the focus.

Detecting and Responding to SSO Compromises

Warning Signs of SSO Compromise

The problem with SSO attacks is that they're often detected late. But there are signs that a security team should watch for:

Unusual login activity: Users logging in from unexpected geographies, at unusual times, or from unusual devices. If someone logs in from their home at 2 AM and then immediately logs in from the office at 9 AM (thousands of miles away in one hour), that's a red flag.

MFA bypass: Users reporting that their MFA prompts appear without them trying to log in. Push notification MFA showing requests they didn't initiate. TOTP codes being used multiple times.

New user accounts: Administrators noticing accounts they didn't create, or accounts being created by other administrators at odd times.

Permission changes: Users gaining permissions they didn't request. Roles being modified unexpectedly.

Email rule changes: Mail forwarding rules being created, or rules in the trash or recovered items folders.

Large data access: Users accessing far more data than normal. A customer service representative accessing financial databases. An accountant downloading the entire customer database.

API access changes: Applications that don't normally use APIs suddenly making API calls. Or API keys being created in systems that don't use them.

Failed authentication attempts: A spike in failed login attempts, especially if they're for administrative accounts.

Detection Systems

Detecting these signs manually is impossible at enterprise scale. Organizations need automated detection systems:

Security Information and Event Management (SIEM): Centralized systems that collect logs from all systems (authentication systems, firewalls, cloud platforms, applications) and detect patterns that indicate attacks. Tools like Splunk, ELK, or cloud-native options like Azure Sentinel.

User and Entity Behavior Analytics (UEBA): AI systems that learn what normal behavior looks like for each user and alert when behavior deviates significantly. Tools like Rapid7 InsightIDR or Varonis.

Cloud Access Security Brokers (CASB): Monitor traffic to cloud applications and detect suspicious behavior. Tools like Netskope or Zscaler.

Identity Threat Detection and Response (ITDR): Specialized systems that monitor identity systems specifically. Tools like CrowdStrike's Identity Graph or Microsoft's Defender for Identity.

These systems aren't perfect, but they dramatically improve detection speed. The difference between detecting a compromise after one day versus one month is the difference between losing one customer's data and losing millions.

Response Procedures

When a compromise is suspected, the response needs to be immediate and coordinated:

1. Isolate the affected account: Disable the compromised SSO account immediately. Yes, this will disrupt the user, but it stops the attacker from using it.

2. Force a global password reset: Don't just change the affected user's password. Force a password reset for all users, especially all users who might have access to high-value systems.

3. Revoke all sessions: Log out all active sessions globally. This means users will need to re-authenticate, which will be inconvenient, but it stops the attacker from using existing session tokens.

4. Revoke API keys and tokens: Check for any API keys or tokens that were created by the compromised account. Revoke them.

5. Audit recent access: Review what the compromised account accessed in the past 24-48 hours. What data did they touch? What systems did they access?

6. Preserve evidence: Don't start cleaning up immediately. Preserve logs and artifacts for forensic analysis and potential law enforcement involvement.

7. Notify stakeholders: Internal notification to executives and security teams. External notification to customers whose data may have been compromised. Notification to regulators if required.

8. Engage law enforcement: For large or extortion-based breaches, notify the FBI or relevant law enforcement agency. They can't guarantee recovery, but they have investigative resources.

Employee Training and Security Culture

Why Traditional Phishing Training Doesn't Work

Most organizations do phishing training once per year. They send out a test phishing email, and if employees click it, they get sent to a training module about "how to spot phishing." Then nothing happens for another year.

This approach has a success rate approaching zero. Why? Because knowledge without practice doesn't stick. Because the training is generic and doesn't apply to the specific attacks your organization faces. Because people forget things, especially when the training is dry and forgettable.

Shiny Hunters' vishing attacks are particularly difficult to train against because they're not obvious mistakes. A skilled social engineer sounds legitimate because they're mimicking legitimate IT procedures.

Effective Security Awareness Programs

What actually works is continuous, targeted, specific training:

Simulated attacks: Instead of once per year, run phishing simulations monthly or quarterly. Test employees with emails that mimic your organization's actual environment, not generic examples. Over time, employees become better at spotting fakes.

Vishing simulations: Run simulated vishing (voice phishing) campaigns. Call employees and try to social engineer them into revealing information. The ones who fall for it get targeted coaching.

Role-specific training: A developer shouldn't receive the same training as a customer service representative. Developers should learn about code injection attacks and supply chain risks. Customer service reps should learn about social engineering specific to their role.

Real incident response: When an actual phishing or vishing attack hits your organization, use it as a teaching moment. Share (anonymously if needed) what happened, how it happened, and what people should have done.

Executive buy-in: Security culture comes from the top. If executives brush off security training as irrelevant, so will everyone else. If executives take it seriously, apply to themselves, and talk about security culture, it spreads.

Reporting incentives: Make it safe to report phishing and social engineering attempts. If someone reports that they received a vishing call, thank them for the report and investigate. Don't punish them for being targeted.

Google and Microsoft are the most targeted SSO providers by ShinyHunters, reflecting their widespread use. (Estimated data)

How Other Threat Groups Are Copying Shiny Hunters' Tactics

Copycat Operations

Shiny Hunters didn't invent vishing or phishing. But they've refined these techniques into an extremely effective operation. And other threat groups have taken notice.

Security researchers have documented multiple threat groups using similar attack patterns:

• Initial vishing to gather intelligence and determine SSO environment
• Custom-built phishing pages tailored to the victim's specific identity provider
• Simultaneous campaigns against dozens of targets
• Exfiltration of customer and employee data
• Posting on data leak sites and extortion

The specific details vary, but the playbook is the same. This suggests that either these are offshoots of Shiny Hunters, or they've simply copied a successful attack pattern.

Convergent Evolution in Cybercrime

In nature, evolution often produces similar solutions to the same problem. Fish developed fins, and dolphin ancestors independently developed flippers for the same purpose.

In cybercrime, threat groups independently discover attack patterns that work. The vishing + phishing + SSO compromise approach works because it exploits fundamental weaknesses in human psychology and current authentication practices. Other groups are finding the same approach and adopting it.

This means that defending against Shiny Hunters alone isn't sufficient. Organizations need defenses against the entire category of attack, because multiple threat groups are now using variations of it.

Cloud Platform Vulnerabilities: SSO Across Providers

Google Workspace and Google Cloud Identity

Google Workspace is a common target because millions of organizations use it. The authentication flow is relatively standard: users authenticate to Google's identity provider, which then grants access to Gmail, Drive, Sheets, and other Google services.

Google has implemented several protective measures:

• FIDO2 hardware key support (available since 2018)
• Advanced Protection Program, a special tier of security for high-risk users
• Real-time phishing and malware protection
• Detailed login security notifications

But these protections require opt-in from organizations or users. An organization using basic Google Workspace with password-only authentication is vulnerable to exactly the attack pattern that Shiny Hunters uses.

Microsoft 365 and Azure Active Directory

Microsoft's cloud offerings are similarly vulnerable. Azure Active Directory (now called Entra ID) handles authentication for Microsoft 365, but also for thousands of third-party applications that integrate with it.

Microsoft has pushed hard on phishing-resistant MFA, making FIDO2 support standard across all their authentication systems. They've also implemented passwordless authentication options like Windows Hello and Microsoft Authenticator.

But like Google, these advanced protections require explicit configuration by the organization.

Okta

Okta is particularly interesting because it's a dedicated identity provider used by thousands of enterprises. If Okta gets compromised—either for a specific customer or across multiple customers—the blast radius is enormous.

In 2023, Okta suffered a breach where attackers accessed customer systems. The incident was a wake-up call for the industry and for Okta customers specifically. It highlighted that identity providers themselves are targets.

Salesforce, Dropbox, and Others

Every SaaS platform is a potential target. Salesforce, Dropbox, Slack, GitHub, Jira, HubSpot—if it stores customer data or company information, it's worth targeting.

Most of these platforms support FIDO2 and modern MFA options, but adoption among users is low.

Regulatory and Compliance Implications

GDPR and Data Breach Notification

If your organization suffers an SSO compromise that leads to exfiltration of EU resident data, GDPR applies. You have 72 hours to notify regulators and affected individuals. There's potential for significant fines.

The GDPR also requires organizations to implement "technical and organizational measures" to protect personal data. This is interpreted to include:

• Multi-factor authentication for administrative access
• Encryption of data at rest and in transit
• Regular security assessments
• Incident response plans

Organizations that suffer a compromise and can show they had inadequate MFA (passwords only, or MFA that was easily bypassed) face higher fines because they failed to implement appropriate measures.

SOC 2 and Other Compliance Frameworks

If your organization is SOC 2 Type II certified (common for SaaS and cloud companies), your auditors will be examining your authentication systems closely. If they discover that you're not using MFA for sensitive access, or that your incident response procedures are inadequate, you could lose your certification.

Industry-Specific Regulations

• Healthcare (HIPAA): Requires access controls and audit logging
• Finance (PCI DSS): Requires MFA for access to cardholder data
• Education (FERPA): Requires reasonable safeguards of student records

The Business Case for Better Security

Beyond compliance, there's a financial argument. The cost of implementing FIDO2 or other phishing-resistant MFA is relatively small compared to the cost of a data breach.

Consider the math:

• Cost to deploy FIDO2 to 1,000 employees: $30,000-80,000
• Cost to respond to a major data breach:
  $4 million+ (direct costs) to$
  20 million+ (including regulatory fines, lawsuits, lost business)

Even if the probability of breach is only 5%, the expected cost of breach is

Building a Security Team Response to SSO Threats

Organizational Structure

Responding effectively to SSO threats requires coordination across multiple teams:

Identity and Access Management (IAM) Team: Manages identity providers, MFA deployment, and access policies. They're the ones who configure Okta or Entra ID. They need to move quickly when a compromise is detected.

Incident Response Team: When a breach happens, the incident response team coordinates the response. They preserve evidence, communicate with stakeholders, and determine what happened.

Security Operations Center (SOC): Monitors for signs of compromise 24/7. They watch for unusual login activity, data access patterns, and other indicators of breach.

Threat Intelligence Team: Monitors the threat landscape. They track threat groups like Shiny Hunters, understand their tactics, and ensure the organization is defending against current threats.

Forensics and Malware Analysis: For serious breaches, they perform detailed analysis of what happened, how data was exfiltrated, and where it went.

Tools and Technologies

To detect and respond to SSO compromises, organizations typically deploy:

• Identity and Access Management platform (Okta, Entra ID, Ping Identity)
• SIEM (Splunk, ELK, Azure Sentinel)
• UEBA (Rapid7, Varonis)
• CASB (Netskope, Zscaler)
• ITDR (CrowdStrike, Microsoft Defender for Identity)
• Endpoint Detection and Response (EDR) (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint)
• Vulnerability scanner (Qualys, Rapid7 InsightVM)
• Secrets management (HashiCorp Vault, AWS Secrets Manager)

This is a substantial tech stack, and many organizations are still building it out.

Incident Response Playbook

Organizations should have documented procedures for SSO compromise:

1. Detection and alerting mechanisms
2. Incident declaration criteria
3. Notification procedures (internal and external)
4. System isolation steps
5. Data preservation procedures
6. Investigation procedures
7. Remediation steps
8. Communication templates
9. Recovery procedures
10. Post-incident review procedures

These procedures should be tested regularly. "We have a playbook" doesn't help if the playbook is outdated or has never been tested.

Future Trends: How Attacks Will Evolve

AI-Powered Vishing

Current vishing attacks rely on human social engineers. But with advances in text-to-speech and AI, it's possible to automate voice phishing at scale.

Imagine an AI that can:

• Synthesize realistic human voices
• Understand context and adapt responses on the fly
• Impersonate specific people (CEO, IT director)
• Conduct conversations in multiple languages
• Handle objections and skepticism

This would allow attackers to run vishing campaigns at far greater scale than is currently possible. Instead of hiring dozens of people to make phone calls, they could deploy automated systems to call thousands of employees.

Defense: This makes security training more important, not less. Employees need to learn to verify requests independently, not just "listen for signs of phishing."

OAuth/OpenID Connect Attacks

Many modern applications use OAuth or OpenID Connect to delegate authentication to identity providers. This is convenient for users but creates new attack surfaces.

Imagine a legitimate-looking application that requests access to your Google account. You approve, and the app gains access to your calendar, email, Drive, and other information. An attacker could create a malicious application that requests far more permissions than it needs, or that exfiltrates data from multiple applications.

Defense: Better permission management and transparency about what applications can access.

Supply Chain Identity Attacks

Vendors and contractors often have access to customer data or internal systems. If a vendor's identity is compromised, the attacker gains access to customer systems.

This is already happening. In 2020, attackers compromised SolarWinds, a software vendor, and used that access to breach multiple U.S. government agencies.

Defense: Strict vendor access controls, continuous monitoring of vendor activity, Zero Trust architecture.

Identity Synthetic Accounts

Attackers could create realistic synthetic identities that are difficult to distinguish from legitimate users. These synthetic identities could be used for various attacks:

• Insider threat (a fake employee that actually exists in the identity system)
• Privilege escalation (a synthetic admin account)
• Long-term persistence (an account that sits dormant until activated for a specific attack)

Defense: Behavioral analysis that can detect accounts that don't behave like humans, regular identity audits to identify accounts that shouldn't exist.

Practical Implementation Roadmap

Month 1-2: Assessment and Planning

Conduct an identity and access audit:

• Catalog all identity providers in use (Google, Microsoft, Okta, others)
• Catalog all applications connected to each identity provider
• Identify high-value systems that should have the strongest protection
• Assess current MFA deployment and identify gaps

Develop a comprehensive security strategy:

• Define a phased rollout plan for phishing-resistant MFA
• Design Zero Trust architecture for high-value systems
• Plan security awareness program improvements
• Budget for tools and personnel

Month 3-4: Quick Wins

Deploy FIDO2 to critical roles:

• Start with administrators, security team, and executives
• Select and procure security keys
• Implement key management procedures

Enable advanced detection:

• Configure detailed logging in identity providers
• Deploy UEBA or similar for anomaly detection
• Set up alerts for suspicious login patterns

Improve MFA baseline:

• Require MFA for all VPN access
• Require MFA for administrative access
• Move from SMS to authenticator apps where possible

Month 5-8: Major Initiatives

Expand FIDO2 deployment:

• Roll out to all technical staff, finance, HR, and management
• Establish key replacement procedures
• Provide user training and support

Implement Zero Trust network architecture:

• Segment networks by sensitivity level
• Implement conditional access policies
• Deploy endpoint detection and response (EDR)

Security awareness program overhaul:

• Launch monthly phishing simulations
• Create vishing simulation program
• Develop role-specific training modules

Month 9-12: Continuous Improvement

Expand FIDO2 further:

• Roll out to general employee population
• Make organizational policy that FIDO2 is preferred MFA method

Implement advanced threat detection:

• Deploy SIEM if not already in place
• Implement CASB for cloud applications
• Set up threat intelligence feeds

Incident response readiness:

• Develop and test incident response playbooks
• Conduct tabletop exercises
• Train incident response team

FAQ

What exactly is Shiny Hunters and why are they so dangerous?

Shiny Hunters is an extortion gang that specializes in compromising single sign-on (SSO) accounts through sophisticated vishing and phishing attacks, then exfiltrating valuable data and demanding ransom. They're dangerous because they've automated their attack process, can target hundreds of organizations simultaneously, and have stolen data from Fortune 500 companies, small businesses, and government contractors. Their attacks often go undetected for weeks or months, giving them time to thoroughly explore compromised networks and steal massive amounts of data.

How does the vishing part of the attack work?

The attack begins with a phone call from someone impersonating IT support or a security contractor. The attacker uses social engineering tactics to convince the employee that their authentication settings need to be updated or that a security audit requires verification of credentials. During the call, the attacker gathers information about which SSO provider the company uses (Google, Microsoft, Okta, etc.) and which MFA method the target employee uses (authenticator app, SMS, push notifications, etc.). This information is critical for the next stage of the attack.

Why can't they just use captured passwords?

Most modern SSO systems require multi-factor authentication in addition to passwords. Simply having the password isn't enough—you also need the second factor (MFA code, push approval, security key, etc.). This is why Shiny Hunters doesn't just steal passwords; they need to capture both the password and the MFA code to actually log in. Their sophisticated phishing pages do this by proxying the authentication request to the real SSO provider, so they can capture both pieces of information in real-time.

Is phishing-resistant MFA like FIDO2 really the solution?

FIDO2 and other phishing-resistant authentication methods are the closest thing we have to a solution for this specific attack. Unlike traditional MFA codes that can be captured through a phishing page, FIDO2 is cryptographically bound to the legitimate domain. If you're tricked into using your security key on a phishing site, the key won't sign anything because the domain is wrong. However, FIDO2 alone isn't sufficient—it needs to be combined with employee training, Zero Trust architecture, and good detection systems.

How quickly should we implement FIDO2 across our organization?

The implementation timeline depends on your organization's size and risk profile. Start with a phased approach: deploy first to high-risk roles (administrators, executives, security staff) in the first 3-6 months. Expand to all technical staff and sensitive departments (finance, HR) in months 6-12. Then progressively expand to the rest of the organization. Most organizations find that the first phase (administrators and high-risk roles) provides the most security benefit, and this can be accomplished in 3-4 months with proper planning and budget.

What should we do if we discover we've been compromised?

If you discover an SSO compromise, immediate action is critical. First, isolate and disable the compromised account. Force a global password reset for all users, especially administrative accounts. Revoke all active sessions. Check for unauthorized API keys or tokens and revoke them. Preserve logs and evidence for forensic analysis. Audit recent access logs to determine what data may have been accessed. Notify law enforcement and regulatory bodies if required. Engage forensic experts to determine the scope and timeline of the breach. And communicate transparently with customers and stakeholders about what happened and what you're doing about it.

How do we know if Zero Trust architecture is working?

Measure the effectiveness of your Zero Trust implementation through security metrics and incident response outcomes. Track metrics like: time to detect a potential compromise, number of unauthorized access attempts that are blocked, compliance with least-privilege access (are users only accessing data they need?), and frequency of successful lateral movement attempts during simulations. In a well-implemented Zero Trust environment, you should see fewer successful attacks, faster detection of attempted attacks, and limited lateral movement when compromises do occur.

Can we really prevent all vishing attacks with training?

No. Even the best-trained employees can be social engineered by skilled attackers, especially under the right circumstances (time pressure, authority figures, legitimate-sounding requests). Training reduces the success rate but doesn't eliminate it. This is why vishing defense needs to be layered: training reduces the initial success rate, but then phishing-resistant MFA prevents the attacker from actually using captured credentials, and detection systems catch the attacker if they do get in. No single defense is sufficient; you need defense in depth.

Conclusion: Building a Culture of Security

Shiny Hunters represent a new reality in cybersecurity: sophisticated, well-resourced threat groups that specialize in identity compromise and extortion. They've cracked the code on attacking SSO systems at scale, and their success has attracted imitators.

But here's the encouraging part: their attacks aren't unpatchable. They exploit weaknesses in authentication systems that we know how to fix. FIDO2 security keys directly defeat their phishing pages. Zero Trust architecture limits their lateral movement. Behavioral analysis and SIEM systems detect their presence.

The challenge isn't technical. It's organizational. Implementing these defenses requires investment in tools, personnel, and training. It requires executives to prioritize security even when it's inconvenient or disruptive. It requires creating a culture where reporting security issues is encouraged and not punished.

The organizations that will survive the next wave of attacks are those that take a comprehensive approach: phishing-resistant MFA for critical access, Zero Trust architecture for network isolation, continuous monitoring for detection, and a security-aware culture where employees understand that security is everyone's job.

Start with your highest-value targets: your identity provider, your finance systems, your customer databases. Implement phishing-resistant MFA there first. Deploy detection systems. Test your incident response procedures. Then progressively extend these defenses to the rest of your organization.

The cost of a data breach is millions of dollars. The cost of preventive security is thousands. The math is straightforward. The only question is how quickly your organization will act.

Key Takeaways

• ShinyHunters use multi-stage attacks combining vishing, custom phishing, and data exfiltration to compromise SSO accounts and demand ransom from target organizations
• Proxy phishing pages bypass traditional MFA by capturing credentials and codes in real-time, then forwarding them to legitimate authentication servers
• FIDO2 hardware security keys are cryptographically bound to legitimate domains and provide the most effective defense against phishing-based credential capture
• Zero Trust architecture with network microsegmentation, continuous verification, and least-privilege access limits attacker lateral movement even after initial compromise
• Defense requires layered approach combining phishing-resistant MFA, behavioral monitoring, employee training, Zero Trust architecture, and continuous threat detection

Related Articles

• Bumble & Match Cyberattack: What Happened & How to Protect Your Data [2025]
• WinRAR Security Flaw CVE-2025-8088: Complete Defense Guide [2025]
• Agentic AI Security Risk: What Enterprise Teams Must Know [2025]
• Fake Moltbot AI Assistant Malware Scam: What You Need to Know [2025]
• Upwind Security's $250M Series B: Runtime Cloud Security's Defining Moment [2025]
• Notepad++ Supply Chain Attack: Chinese Hackers Hijack Updates [2025]