On the evening of March 1st, the hacker group ShinyHunters dumped the complete dataset of Dutch telecom provider Odido onto the dark web. Names, addresses, bank account numbers, passport numbers, driver’s license details, and deeply sensitive customer service notes — covering over 6.5 million people and 600,000 businesses. That’s more than a third of the Dutch population. As someone who has spent nearly two decades helping enterprises defend against exactly this kind of attack, this one hit close to home. Literally. My family’s data is in there.
This post isn’t a hot take. I’ve spent weeks investigating what happened — combing through technical analyses, public reporting, and talking with peers in the Dutch security community. I want to walk through the attack, how ShinyHunters operates, and — most importantly — what specific controls would have stopped or contained this breach at every stage of the kill chain.
Who Are ShinyHunters?
ShinyHunters has been active since 2020 and has steadily evolved from a mass data theft operation into a sophisticated extortion group. Their portfolio reads like a who’s who of major breaches: Microsoft’s GitHub repositories (500 GB of source code in 2020), Ticketmaster, Wynn Resorts, Adidas, and — most recently — a string of Salesforce-focused attacks across luxury goods, airlines, insurance companies, and telecom providers.
Google’s Mandiant tracks closely related activity clusters as UNC6040 and UNC6240. What makes ShinyHunters particularly dangerous isn’t technical sophistication in the traditional sense — they don’t rely on zero-days or custom malware. Their weapon of choice is social engineering, specifically voice phishing (vishing), combined with abuse of legitimate authentication flows. They talk their way in.
They present themselves as a professional outfit — a “business” with hierarchy, rules, and a spokesperson who signs off with “I’m going to bed, I’ll be back tomorrow morning.” In conversations with journalists, they’ve emphasized their code of conduct: no hospitals, no care facilities. They frame ransom negotiations as “discreet settlements.” It’s reputational management for criminals, and it’s chillingly effective.
The Odido Attack: A Step-by-Step Breakdown
Based on what ShinyHunters shared with journalists, cross-referenced with public reporting and expert analysis, here’s how the attack unfolded:
February 3 — The Phone Call. Someone working for ShinyHunters called Odido’s customer service helpdesk, impersonating an internal IT employee. The caller spoke fluent Dutch. This wasn’t a bot, and it wasn’t broken social engineering — it was a convincing, live human conversation. The attacker persuaded a helpdesk employee to “log in” to what appeared to be a legitimate Odido website. In reality, it was a credential harvesting page built by the group. Username, password, and MFA tokens — all captured.
February 3–5 — Lateral Movement into Salesforce. Using the stolen credentials, the attackers logged into Odido’s environment as if they were a helpdesk employee. They were briefly kicked out but quickly regained access. They then pivoted into Odido’s Salesforce CRM — the system where customer data lives. According to the hackers, the exfiltration of all data took somewhere between “a few minutes and an hour,” using built-in Salesforce API export capabilities.
February 5 — Data Exfiltration Complete. Analysis of the leaked data shows no updates after February 5 at 14:16, supporting the claim that the theft happened on this date. The total haul: approximately 90 GB, 15 million rows of data.
February 7 — Ransom Demand. ShinyHunters emailed Odido’s CEO, CFO, COO, security team, and press department. They demanded €1 million, provided a sample of 10,000 records as proof, and included a link where Odido could verify the data. The hackers confirmed that the sample was downloaded.
February 7–8 — Contact Broken. There was some back-and-forth over email during the weekend, but Odido cut off communication on February 8. The company made a deliberate choice not to negotiate, based on advice from its hired security firm S-RM and the Dutch police’s Team High Tech Crime.
February 24 — Pressure Campaign Begins. With no payment forthcoming, ShinyHunters shared data samples with Dutch media outlets RTL and NOS. They reduced the demand to €500,000. No response from Odido.
February 26–28 — Daily Leaks. ShinyHunters began publishing one million records per day on their dark web site. Each batch revealed increasingly sensitive data: bank account numbers, then ID document numbers, then customer service notes containing information about stalking victims, domestic violence cases, people under financial guardianship, and customers flagged for aggressive behavior.
March 1 — Full Dump. Everything went online. All of it.
What Makes This Attack So Dangerous
Let me be direct about something: the technical sophistication of this attack was low. That’s what makes it so concerning. This wasn’t a supply chain compromise or a zero-day exploit. It was a phone call to a helpdesk, a fake login page, and then bulk data export through legitimate Salesforce APIs. Every single step exploited configuration weaknesses and human trust — not software vulnerabilities.
Three specific failures stand out:
1. No resilience against social engineering at the helpdesk. The first line of defense was a human being answering the phone, and that person had no way to verify the caller was who they claimed to be. There was no out-of-band verification process, no callback procedure, and apparently no alarm bells when someone asked them to log in to an unfamiliar URL.
2. Excessive permissions — the principle of least privilege was not applied. ShinyHunters’ spokesperson reportedly stated that “Odido does not apply the principle of least privilege.” A helpdesk employee’s credentials provided access to bulk-export the entire customer database. That should never be possible. Salesforce explicitly warns its customers about this in its security guidance: restrict user permissions, limit API access, and audit connected apps. Many organizations don’t do this, because locking down permissions in Salesforce requires active, deliberate configuration.
3. No effective detection of mass data exfiltration. The attackers extracted 90 GB of data. Whether it took minutes or hours, that volume of data leaving Salesforce should have triggered alerts. It apparently didn’t — or if it did, nobody acted on it in time.
ShinyHunters’ Broader Playbook: Device Code Phishing and OAuth Abuse
The Odido attack used a relatively straightforward credential phishing method. But ShinyHunters’ evolving toolkit is worth understanding, because their newer techniques are significantly harder to detect and directly target Microsoft Entra ID environments.
In campaigns documented by BleepingComputer and Mandiant in early 2026, ShinyHunters has been combining vishing with device code phishing — an abuse of the OAuth 2.0 Device Authorization Grant flow. Here’s how it works:
The attacker generates a legitimate device code using a real Microsoft OAuth client ID (they can use Microsoft’s own first-party app IDs). They then call the target, impersonate IT support, and convince them to navigate to microsoft.com/devicelogin and enter the code. The victim sees a completely legitimate Microsoft login page. They authenticate with their credentials and MFA — because it is Microsoft’s real authentication flow. Once they approve, the attacker receives a refresh token that provides persistent access to the victim’s Microsoft Entra account, and through SSO, to every connected SaaS application: Microsoft 365, Salesforce, Google Workspace, Slack, Dropbox, SAP, and more.
This is devastatingly effective because there is no phishing page to detect, no malicious URL to block, and the victim completes MFA successfully on Microsoft’s own infrastructure. Traditional anti-phishing controls are blind to it.
What Should Have Been Done: A Defensive Blueprint
So what does effective defense against ShinyHunters look like? Let me walk through the controls that map to each phase of this attack, because too often we discuss these things in the abstract. This needs to be concrete.
Phase 1: Prevent the Initial Compromise
The entry point was a vishing call that led to credential theft. Defending against this requires a combination of identity hardening and user awareness:
Phishing-resistant MFA is non-negotiable. FIDO2 security keys or Windows Hello for Business tied to Microsoft Entra ID would have made the stolen credentials useless. Device code phishing and traditional credential harvesting both fail when authentication is bound to a physical device or biometric that the attacker doesn’t possess. If you’re still relying on SMS codes or push notifications as your primary MFA factor, you’re vulnerable to exactly this attack.
Conditional Access policies should restrict device code flows. In Microsoft Entra, you can create Conditional Access policies that block or limit the OAuth device code authentication flow. Unless your organization has a legitimate business need for it (headless devices, shared terminals), disable it. If you do need it, restrict it to compliant, managed devices only. This single policy would have neutralized ShinyHunters’ newer attack variant entirely.
Enforce token protection. Entra ID supports token binding to ensure that tokens can only be used from the device where the authentication session was initiated. This prevents token theft and replay attacks — exactly the technique ShinyHunters uses to pivot from a compromised device code flow into persistent access.
Phase 2: Limit the Blast Radius
Even if an attacker gets in — and you should always plan for that possibility — the damage should be contained.
Apply least-privilege access rigorously, especially in Salesforce. This means field-level security, object-level permissions, and restricted API access. A helpdesk agent should never have the ability to perform bulk data exports. Salesforce provides the tools for this — profiles, permission sets, sharing rules — but they require active configuration. Default settings in Salesforce are often too permissive.
Use Microsoft Entra Permissions Management to identify over-privileged accounts across your cloud estate. It provides visibility into effective permissions across Azure, AWS, and GCP — and crucially, across SaaS applications integrated through SSO. You can’t fix what you can’t see, and most organizations dramatically underestimate how many of their accounts have excessive access.
Segment access with Privileged Identity Management (PIM). Entra ID’s PIM capabilities allow you to enforce just-in-time access for elevated privileges. Administrative access to CRM systems, bulk export capabilities, and API credentials should require explicit activation with time limits, approval workflows, and audit trails.
Phase 3: Detect and Respond
The 90 GB exfiltration should have been caught. Here’s how:
Microsoft Sentinel, connected to Salesforce audit logs, can detect anomalous data access patterns. Salesforce generates detailed event logs — login events, API calls, report exports, bulk queries. Feeding these into Sentinel and applying analytics rules for unusual volume, unusual hours, or unusual geographic origin would have flagged this exfiltration in near real-time. There are community-contributed and Microsoft-built analytics rules specifically for Salesforce data exfiltration scenarios.
Microsoft Defender for Cloud Apps (MCAS) provides session-level visibility and control for SaaS applications. When configured with Conditional Access App Control, it can enforce real-time session policies: block bulk downloads, require step-up authentication for sensitive operations, and alert on anomalous data movement. This is exactly the kind of control that would have either prevented or immediately flagged a bulk export of 15 million customer records.
Build detection for device code authentication anomalies. In Sentinel, you can query Entra ID sign-in logs for authenticationProtocol == "deviceCode" and correlate these with contextual signals: is this a managed device? Is the user’s risk level elevated? Is this a first-time use of device code auth for this user? These queries can be turned into near real-time analytics rules that trigger automated investigation playbooks.
Phase 4: Protect the Data Itself
The ultimate question in any breach: even if an attacker gets access, can they actually extract and use the data?
Microsoft Purview Information Protection can classify and label sensitive data across your environment, including data stored in Salesforce through integration with Microsoft Defender for Cloud Apps. When data is classified — PII, financial records, government IDs — you can enforce policies that prevent it from being exported, downloaded, or shared outside approved channels. Data loss prevention policies in Purview can act as a final safety net when identity and access controls have been bypassed.
Microsoft Purview Data Loss Prevention extends to SaaS applications, endpoints, and email. Even if an attacker manages to bulk-export data through Salesforce APIs, DLP policies can detect sensitive content patterns (passport numbers, IBANs, BSN numbers) in transit and block or quarantine the transfer. This requires investment in DLP policy configuration and testing, but it’s one of the most effective last-line defenses against exactly this type of data theft.
The Ransom Question
One of the most debated aspects of this case is Odido’s decision not to pay. Dutch police publicly supported the decision. ShinyHunters’ own reputation problems played a role — recent reports linked the group to the “COM” network, which is associated with extortion of minors and extreme violence. Whether those links are substantiated (several security experts have said they haven’t seen convincing evidence), the mere allegation gave Odido additional justification to refuse payment.
The security community is split. Some experts argue that when this much is at stake — passport numbers, BSN numbers, data about stalking victims — the societal cost of a full leak outweighs the ransom. Others point to the reality that payment offers no guarantees: data can be resold, and internal group conflicts (ShinyHunters reportedly has factional tensions) can lead to leaks regardless.
What I’ll say is this: the ransom question is the wrong question. The right question is why we’re in a position where a single phone call to a helpdesk can expose a third of a country’s population. The investment in preventive and detective controls I described above costs a fraction of what this breach will ultimately cost — in regulatory fines, in class-action lawsuits, in years of downstream fraud, and in the very real human cost to people whose abuse histories are now public.
What’s Next
ShinyHunters isn’t done. Their spokesperson reportedly sent journalists a message on a Sunday morning, cheerfully pointing to a new Salesforce security advisory about a fresh wave of attacks on Salesforce customers. “Salesforce under fire again! Lol.” Four hundred companies were reportedly affected.
The group is evolving. They’re recruiting insiders. They’re using AI voice tools like Vapi and Bland AI for scalable, natural-sounding vishing calls. They’re targeting not just credentials but the entire identity graph — Okta, Entra, Salesforce SSO — because once you own the identity layer, you own everything behind it.
If there’s one takeaway from the Odido breach, it’s this: identity is the perimeter, and your SaaS applications are the crown jewels. If you’re not treating identity security, conditional access, privilege management, and SaaS monitoring with the same urgency as endpoint and network security, you’re building a fortress with the front door wide open.
Take the time this week to audit your own environment. Check your Conditional Access policies in Entra. Review your Salesforce permission sets. Connect your SaaS audit logs to Sentinel. Run a Permissions Management discovery scan. And train your helpdesk to verify — really verify — before they trust a voice on the phone.
The next ShinyHunters target might be a phone call away.
Sources: This post draws on reporting from NRC (including direct conversations with ShinyHunters), BleepingComputer, Cybernews, NL Times, The Register, Google Mandiant, and Picus Security.