Post cover image

August 13, 2026

Odido Data Breach Explained: How 6.2 Million Records Were Stolen With a Phone Call

By Gowri Shankar Balasubramaniam

8 min read

Odido Hack: How 6.2 Million People's Data Got Stolen With Just One Phone Call

I want to talk about the Odido breach. If you work in tech, especially in the Netherlands, you probably already heard about it. If you didn't, here it is in short: hackers got into one of the biggest telecom companies in the Netherlands, and they walked out with personal data of over 6 million people. Names, addresses, phone numbers, bank account numbers, ID document numbers. All of it.

What makes this story worth writing about is not just the size. Big breaches happen every year. What makes this one interesting for us as engineers is how they got in. It wasn't some fancy zero-day exploit. It wasn't a bug in a firewall. It was a phone call.

In this article I'll walk you through what happened, how the attackers actually pulled it off, and what we as engineers, sysadmins, and security folks can learn from it. I'll also give you practical things you can check in your own company today, not just theory.

By the end of this, you should understand:

  • What social engineering attacks like this actually look like in real life
  • Why MFA alone is not enough anymore
  • What controls you can put in place to catch this kind of thing early
  • How to think about "customer contact systems" as a real attack surface, not just a support tool

Background

Odido is one of the biggest mobile and telecom providers in the Netherlands. It used to be T-Mobile Netherlands and Tele2 Netherlands before they merged and rebranded as Odido in 2023. They also own Ben, a cheaper mobile brand.

On the weekend of February 7–8, 2026, something went wrong. A hacker called an Odido customer service employee, pretending to be from internal IT. The hacker convinced the employee to log into a fake version of the company's internal work environment. This is basically a fake login page dressed up to look real.

Because the employee logged in through this fake page, the attacker got the employee's credentials and, more importantly, tricked them into approving a fraudulent MFA prompt. Several employee accounts were compromised this way. Once inside, the attackers reached Odido's Salesforce environment, which was being used as a customer contact system. From there, they used scraping tools to pull out data on millions of customers.

Here's the part that really got my attention: Odido actually noticed something was wrong on the same day the attack happened. Their internal security team looked into it, and so did an outside cybersecurity firm. Both concluded that nothing had been stolen. No alarm went off when the data was actually being downloaded. It was only two days later, on February 7, when the attackers themselves contacted Odido and told them they had the data, that Odido realized the truth.

The group behind this was ShinyHunters, a well known extortion gang that has hit a bunch of companies through Salesforce environments using similar tricks. When Odido refused to pay the ransom (reportedly a low seven-figure amount), the group started leaking data in batches. First around 649,000 customer records, then IBANs, then driver's license numbers, ID card numbers, and passport numbers. By March 1, 2026, the whole dataset was published on the dark web. Later reports pushed the real number even higher, past 6.5 million people and 600,000 companies, including some very sensitive records tied to diplomats and government-linked individuals.

This has since turned into one of the biggest data breaches in Dutch history, with a criminal investigation and a class action lawsuit against Odido.

Prerequisites

You don't need deep security certifications to follow this article, but it helps if you're familiar with:

  • Basic authentication concepts (passwords, MFA, SSO)
  • What a CRM or customer contact system does (like Salesforce)
  • Basic phishing and social engineering concepts
  • General incident response terms (detection, containment, mitigation)

If you manage any system where support staff log in to view customer data, this article applies directly to you.

Architecture: How the Attack Actually Flowed

Here's a simplified version of what likely happened, based on public reporting.

Attacker
   │
   │  1. Calls support employee, pretends to be "IT"
   ▼
Support Employee
   │
   │  2. Gets tricked into logging into a fake portal
   ▼
Fake Login Page (looks like real internal tool)
   │
   │  3. Captures credentials + MFA approval
   ▼
Attacker (now has valid session)
   │
   │  4. Logs into real Salesforce environment as employee
   ▼
Salesforce Customer Contact System
   │
   │  5. Uses scraping tool to pull customer records
   ▼
Millions of customer records exfiltrated
   │
   │  6. Attacker contacts company, demands ransom
   ▼
Company refuses → Data leaked on dark web

Notice something here. There's no "hacking" in the Hollywood sense. No brute force, no exploit chain. Every step is a person making a decision, or a system trusting that decision. That's the real lesson of this whole thing.

Step-by-Step: What Went Wrong (And What Should Have Caught It)

1. The Human Layer Was the Weak Point

The attacker didn't need to break any encryption. They just needed one employee to believe a phone call. This is called vishing (voice phishing), and it's becoming very common against companies that use Salesforce, because Salesforce environments often hold large amounts of customer data in one place.

What should exist here: a strict internal policy that IT never asks employees to log in through a link sent over the phone or a message. Verification callbacks through a separate, known channel should be mandatory before any credential reset or login "help."

Expected outcome: even if the employee gets a call, they hang up, call the real IT helpdesk number, and the attack stops right there.

2. MFA Was Bypassed, Not Broken

This is the part a lot of people get wrong when they hear "MFA was bypassed." The attacker didn't crack any code. They tricked the employee into approving a push notification, or the fake portal relayed the real login attempt in real time (a technique called an adversary-in-the-middle attack). Either way, the employee approved something without realizing what they were approving.

# This is the kind of MFA prompt an employee sees.
# If it comes at an unexpected time, it should ALWAYS be denied by default.
Push Notification: "Approve login to Salesforce from IP 91.x.x.x?"
[Approve] [Deny]

If your organization still uses simple push-approval MFA (tap yes/no), you're exposed to this exact style of attack. This is why security teams have been pushing companies toward number matching MFA instead, where the user has to type in a number shown on the login screen into their phone. It's a small change, but it kills the "just tap approve without thinking" problem.

3. No Alarm Went Off During the Actual Data Theft

This is the scariest part for me as an engineer. Odido's own security team looked at the logs on the day of the attack and found nothing. The download of millions of records didn't trigger any alert.

This usually happens because:

  • The scraping tool used normal, authenticated API calls, so nothing looked "malicious" on the surface
  • There was no rate limiting or anomaly detection on bulk data exports
  • Nobody was watching for "one account suddenly pulling way more records than usual"

What should exist here: data loss prevention (DLP) rules and export volume alerts. If an account that normally looks up 20–30 customer records a day suddenly pulls 100,000, that should trigger an automatic alert or even a temporary lock, regardless of whether the login itself looked "normal."

// Simple pseudo-logic for an export anomaly alert
function checkExportVolume(userId, recordCount) {
  const avgDailyExports = getAverageExportVolume(userId); // e.g. 30
  const threshold = avgDailyExports * 20; // adjust per environment

  if (recordCount > threshold) {
    triggerSecurityAlert(userId, recordCount);
    // Optionally: pause the session pending review
  }
}

This kind of logic is not hard to build. Salesforce and most CRMs support event monitoring APIs that can feed this data into your SIEM. The problem is usually that nobody set the threshold, not that the tooling doesn't exist.

4. Data Retention Was Too Broad

One of the complaints from the Dutch consumer group that later sued Odido was that the company kept too much data for too long, including data on former customers. This is a really common problem. Systems accumulate data over years, and nobody goes back to clean it up.

What should exist here: a data retention policy that's actually enforced with automated jobs, not just written in a document somewhere. If a customer left five years ago, why is their passport number still sitting in a live customer support database?

Best Practices

Based on everything above, here's what I'd actually recommend to any team running a customer support or CRM system:

Security

  • Use number-matching MFA, not simple push approval
  • Require callback verification for any account or password related request from "IT"
  • Apply least privilege access — support staff should only see what they need for the ticket in front of them, not full customer records by default

Performance & Scalability

  • Rate-limit bulk exports at the application layer, not just at the network layer
  • Separate read-heavy reporting queries from live support system queries so a scraping tool doesn't quietly degrade service for everyone else

Monitoring

  • Set up export volume alerts (shown above)
  • Log every data access event, not just logins, and feed it into a SIEM with real alerting, not just storage

Maintainability

  • Regularly audit which employee accounts have access to sensitive fields like IBANs, passport numbers, ID scans
  • Rotate and review third-party integrations connected to your CRM

Logging & Error Handling

  • Never log full sensitive fields (like full IBANs or ID numbers) in plaintext logs
  • Make sure failed login attempts and MFA approvals are logged with enough context to investigate later

Deployment

  • Treat your CRM/support system with the same security rigor as your production application. It's not "just internal tooling," it's often where the most sensitive data lives.

Common Mistakes

  1. Treating MFA as a solved problem. MFA reduces risk, but push-approval MFA without number matching is still very phishable.
  2. Assuming "no alert triggered" means "nothing happened." As Odido learned, absence of alerts doesn't mean absence of an attack. You need volume-based and behavior-based detection, not just signature-based detection.
  3. Keeping data "just in case." Old customer data sitting around for years with no active use is pure liability with no upside.
  4. Not training support staff on vishing specifically. Most phishing training focuses on email. Phone-based social engineering deserves its own training track.
  5. Underestimating a CRM as an attack surface. Salesforce and similar tools often get less security attention than the "main" application, even though they can hold more sensitive data than the app itself.

Performance Considerations

Interestingly, performance and security overlap here more than people expect. If you build rate limiting and export throttling into your CRM access layer, you get two benefits at once: you reduce the blast radius of a scraping attack, and you protect your database from being hammered by any single account, malicious or not. A sudden spike from one account pulling tens of thousands of records is bad for security and bad for everyone else's response times.

If you're running your own event monitoring pipeline (pushing CRM events into a SIEM), keep an eye on the volume of events you're generating. Full audit logging on every field access can get expensive fast, both in storage and query performance. A reasonable middle ground is logging every export and every access to sensitive fields, while sampling normal read-only queries.

Security Considerations

This whole incident is basically a case study in identity security, so let's go through the standard checklist:

Authentication — Push-based MFA without number matching is not enough anymore. Consider FIDO2 security keys for staff who have access to sensitive customer data.

Authorization — Apply role-based access control strictly. A support agent handling billing questions shouldn't be able to bulk export ID document numbers.

Secrets Management — Make sure internal tools (like the fake portal used here) can be quickly identified as fake by comparing against known good domains, ideally enforced through browser policies or DNS filtering on company devices.

HTTPS & Secure Headers — Basic, but still worth saying: all internal portals should enforce HSTS and have clear, consistent branding so employees can be trained to spot inconsistencies.

Input Validation & Rate Limiting — Any API endpoint that can export customer records in bulk needs hard rate limits, independent of the user's normal permissions.

Logging — Log access to sensitive fields specifically, separate from general application logs, so security teams can review them without wading through noise.

OWASP-style thinking — This breach lines up closely with broken access control and insufficient logging & monitoring, two categories that show up again and again in the OWASP Top 10, even though this wasn't a typical web app attack.

Summary

The Odido breach isn't a story about some genius hacker breaking unbreakable encryption. It's a story about a phone call, a fake login page, and monitoring that didn't catch a massive data pull happening in plain sight. That's actually the uncomfortable part. Most companies could be hit the exact same way tomorrow.

If you're responsible for any system that holds customer data, especially a CRM or support tool, take this as a prompt to go check a few things this week: your MFA setup, your export monitoring, and your data retention policy. None of these are expensive fixes. They just require someone to actually sit down and configure them properly.

Use the practices in this article if your organization handles customer data through a CRM, support desk, or similar system with human operators. If you're running a fully automated system with no human-in-the-loop access to sensitive data, your risk profile is different, and you'll want to focus more on API security and service-to-service authentication instead.