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: reading technical analyses and public reporting, and talking with peers in the Dutch security community. Some detail still comes from ShinyHunters’ account to journalists, so I label it as such. The defensive question is where the chain could have been broken or contained.
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
The sequence below combines what ShinyHunters told journalists with public reporting and expert analysis:
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.
- February 3A fluent Dutch speaker calls the helpdesk posing as internal IT. Credentials and MFA tokens are captured on a fake login page.
- February 3–5Login as the helpdesk employee, briefly kicked out, then a pivot into the Salesforce CRM.
- February 5Exfiltration completes: roughly 90 GB, 15 million rows, via built-in Salesforce API export.
- February 7Ransom email to the CEO, CFO, COO, security team and press. €1 million, with 10,000 records as proof.
- February 7–8Some back and forth over the weekend, then Odido cuts contact on advice from S-RM and the Dutch police.sixteen days of silence
- February 24Pressure campaign: samples to RTL and NOS, demand reduced to €500,000.
- February 26–28One million records published per day, each batch more sensitive than the last.
- March 1The full dump goes online.
What makes this attack so dangerous
The technical sequence was simple. 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, according to the attackers, a bulk export through legitimate Salesforce APIs. The chain exploited human trust and authorised functionality.
Three specific failures stand out:
1. The helpdesk process did not resist the call. A fluent Dutch speaker impersonated internal IT and persuaded an employee to follow the attacker’s instructions. The public evidence does not establish whether Odido lacked callback or out-of-band verification procedures, only that whatever procedures and training existed did not stop this interaction.
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. Mass export was not contained in time. The attackers claim they extracted 90 GB. Public reporting does not tell us whether a relevant alert fired, arrived too late or was not acted upon. Any serious Salesforce monitoring design should be able to answer that question after an incident.
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 for an OAuth client, then calls the target, impersonates IT support and asks them to visit microsoft.com/devicelogin. The victim sees Microsoft’s real authentication page and completes MFA. If they approve the request, the attacker receives tokens for the client, resources and scopes involved in that authorisation. Those tokens may provide persistent access, but they do not automatically unlock every SaaS application connected to the tenant.
There may be no fake login page or malicious sign-in domain to block, and the victim completes MFA on Microsoft’s infrastructure. That removes several signals used by conventional phishing controls, which is why Microsoft recommends controlling the authentication flow itself.
A defensive blueprint
Effective defence maps controls to each phase of the attack and states what each control can actually cover.
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:
Use phishing-resistant MFA. FIDO2 security keys or Windows Hello for Business make credentials captured on a fake login page far less useful. They are strong protection against credential harvesting and adversary-in-the-middle phishing. They do not, by themselves, prevent a victim from authorising an attacker’s device-code request on Microsoft’s legitimate page.
Restrict device-code flow with Conditional Access. Unless your organisation has a documented business need for it, block the OAuth device-code authentication flow. Where it is needed, scope the exception narrowly and monitor its use. This control addresses the newer device-code variant directly.
Use token protection where Microsoft supports it. Device-bound tokens reduce replay in supported Windows, application and resource combinations. They are useful defence in depth, not a universal control for every OAuth token or SaaS application.
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.
Review app assignments and Salesforce permissions as separate control planes. Entra ID Governance access reviews can help recertify group and enterprise-application assignments. Salesforce profiles, permission sets, connected apps and API permissions still need Salesforce-native review. Entra Permissions Management is not an option here; Microsoft retired the product on 1 October 2025.
Use just-in-time elevation where the integration supports it. Entra PIM can govern privileged Entra roles and eligible group membership. If a Salesforce permission set is mapped through a governed group, that pattern can provide time-limited elevation. PIM does not automatically control a native Salesforce bulk-export permission.
Phase 3: detect and respond
A monitoring design for this system should make a claimed 90 GB export explainable after the fact. These controls could also have detected or interrupted it:
Connect Salesforce event data to Microsoft Sentinel. Salesforce Event Monitoring can expose login events, API calls, report exports and bulk queries, depending on licensing and log availability. Sentinel can analyse those events for unusual volume, time or origin. It could have surfaced the export if the required event type, connector latency and analytics rule were all in place; “would have detected it” is too strong without Odido’s telemetry.
Use the control that sits on the actual export path. Defender for Cloud Apps Conditional Access App Control can govern supported browser sessions, including browser downloads and step-up authentication. It should not be described as a guaranteed block for a Salesforce API export. For API and bulk-query activity, use Salesforce Event Monitoring and Transaction Security Policies, backed by least-privilege API permissions.
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?
Classify and protect content where the integration supports it. Purview labels and DLP can protect supported files, Microsoft 365 locations, endpoints and integrated cloud-app scenarios. They remain valuable once Salesforce data is placed in a covered file or channel. They do not automatically label every Salesforce record or intercept every CRM API response.
Put export restrictions close to the data. Salesforce-native permissions and Transaction Security Policies are the primary controls for API and report exports. Purview and Defender for Cloud Apps add defence in depth only for the locations, files and sessions they can inspect. A policy that never sees the traffic cannot block it.
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 comes next
ShinyHunters isn’t done. NRC reported that the group’s spokesperson sent journalists a message pointing to a new Salesforce security advisory about another wave of attacks. “Salesforce under fire again! Lol.”
The group is evolving. Reporting describes insider recruitment and experimentation with AI voice tooling for scalable vishing. Cheaper AI-assisted effort changes which targets and techniques are economical. Its campaigns target the identity relationships between systems such as Okta, Entra and Salesforce SSO because one trusted identity can open several paths.
If there’s one takeaway from the Odido breach, it’s this: identity is the perimeter, and your SaaS applications are the crown jewels. The graph-versus-list model is useful here because a trusted identity can connect several systems. 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 device-code policy in Conditional Access. Review Salesforce permission sets, connected apps and export rights. Connect the relevant event logs to your SIEM. Test Salesforce Transaction Security Policies against a bulk query. And train the helpdesk to verify before it trusts a voice on the phone.
The next ShinyHunters target might be a phone call away.
Sources:
- Incident reporting and attacker claims: NRC, BleepingComputer, Cybernews, NL Times and The Register.
- Dutch investigation and ransom guidance: Police update on the Dutch-speaking fake-IT call and Dutch police advice not to pay.
- Campaign behaviour: Google Mandiant and Picus Security.
- Control boundaries: Microsoft on device-code Conditional Access, token protection and Defender for Cloud Apps session policies; Salesforce on Transaction Security policy types and Event Monitoring.