De Odido-hack: hoe het kon gebeuren en wat er anders had gemoeten

Hoe de aanval werkte: drie stappen

De hack was technisch gezien niet bijzonder geavanceerd. ShinyHunters gebruikte een combinatie van drie bekende technieken die ze stap voor stap combineerden.

Stap 1: Phishing

De aanvallers begonnen met phishing: ze stuurden nep-e-mails naar medewerkers van Odido om inloggegevens te stelen. Waarschijnlijk ging het om medewerkers van een buitenlands callcenter dat Odido inhuurt. Dit soort aanvallen is alledaags en bijna niet volledig te voorkomen, want er is altijd wel iemand die een foute link aanklikt.

Stap 2: Vishing om MFA te omzeilen

Nadat ze het wachtwoord hadden, belden de aanvallers de medewerkers op. Ze deden zich voor als de IT-afdeling van Odido en overtuigden hen om een inlogpoging goed te keuren in hun authenticatie-app. Zo omzeilden ze de tweestapsverificatie, die normaal gesproken juist de extra beveiligingslaag vormt.

Stap 3: Data scrapen via Salesforce

Eenmaal binnen koppelden de hackers een zogenaamde ‘connected app’ aan de Salesforce-omgeving van Odido. Salesforce is het systeem waarin Odido klantgegevens beheert. Die koppeling gaf ze directe toegang tot de database, waarna ze geautomatiseerd begonnen met het downloaden van klantgegevens. Vermoedelijk waren ze dagenlang bezig om al die data ongemerkt buit te maken.

De waarschuwingen die werden genegeerd

Dit is waar het verhaal echt pijnlijk wordt. De aanvalsmethode was namelijk niet onbekend. Salesforce had in de loop van 2025 meerdere keren gewaarschuwd voor precies deze combinatie van phishing en het misbruiken van connected apps. De laatste waarschuwing verscheen eind januari 2026, waarschijnlijk slechts dagen voor de hack bij Odido plaatsvond.

Niet alleen Salesforce sloeg alarm. Ook beveiligingsbedrijf Mandiant (onderdeel van Google) en de Amerikaanse FBI hadden publiekelijk voor deze methode gewaarschuwd. ShinyHunters had dezelfde aanpak eerder al succesvol gebruikt bij Air France-KLM en Google.

Ter vergelijking: een ander groot Nederlands bedrijf dat ook klantdata in Salesforce beheert, was wel op de hoogte van de dreiging. Dat bedrijf had naar aanleiding van eerdere waarschuwingen al personeel getraind om dit soort pogingen te herkennen en direct intern te melden.

Of Odido die waarschuwingen heeft ontvangen en bewust heeft genegeerd, of dat ze er simpelweg niet op heeft gereageerd, is niet bekend. Het bedrijf wil geen commentaar geven op lopende onderzoeken. Maar het feit ligt er: de informatie was beschikbaar.

De menselijke factor: onvermijdelijk, maar beheersbaar

Het is verleidelijk om de schuld neer te leggen bij de medewerker die inging op de phishingmail of de nep-IT’er aan de telefoon. Maar dat is te simpel. Mensen maken fouten. Dat is geen zwakte, dat is menselijk. Een goed beveiligd systeem mag nooit volledig afhangen van de onfeilbaarheid van één persoon.

Wat er wel gedaan had kunnen worden op het menselijke vlak:

• Gerichte training op precies dit type aanval, inclusief het herkennen van vishing via telefoon
• Een duidelijk intern meldproces: wat doe je als je een verdachte loginpoging goedkeurt?
• Extra aandacht voor medewerkers van externe callcenters, die vaak minder binding hebben met het bedrijf en minder securitytraining krijgen
• Phishing-resistente MFA, zoals een hardwaresleutel of passkeys, die niet telefonisch te omzeilen zijn

Dat laatste punt is cruciaal. De MFA die Odido gebruikte, was het type waarbij een medewerker een melding op zijn telefoon moet goedkeuren. Dat klinkt veilig, maar het is precies de variant waarvoor Salesforce expliciet waarschuwde: aanvallers bellen je op en vragen je de melding te bevestigen. Modernere alternatieven, zoals FIDO2-sleutels, zijn immuun voor dit soort aanvallen omdat er niets goed te keuren valt via de telefoon.

De architectuur: waarom de schade zo groot was

De phishing was de sleutel. Maar de architectuur was de deur die wagenwijd openstond. Want zelfs als één medewerker gehackt wordt, hoeft dat niet te leiden tot het lekken van zes miljoen klantdossiers. Daarvoor moeten er fundamentele ontwerpfouten zijn in hoe een systeem is opgezet.

Probleem 1: Te ruime toegangsrechten

Een klantenservicemedewerker moet een individuele klant kunnen helpen. Die medewerker heeft daarvoor de gegevens van die ene klant nodig, niet van zes miljoen anderen tegelijk. Het principe dat iemand alleen toegang krijgt tot wat strikt noodzakelijk is voor zijn werk, heet ‘Least Privilege’. Bij Odido ontbrak dit principe volledig. Toen de hackers inlogden op het account van een medewerker, konden ze de hele database benaderen.

Probleem 2: Geen detectie van afwijkend gedrag

De aanvallers hebben dagenlang onopgemerkt data gescrapet. Een goed beveiligd systeem detecteert afwijkend gedrag: iemand die midden in de nacht inlogt, of ineens duizenden klantprofielen opvraagt in korte tijd. Dat zijn alarmsignalen. Automatische detectie en blokkering van zulk gedrag had de aanval veel eerder kunnen stoppen en de schade drastisch kunnen beperken.

Probleem 3: Onnodige dataopslag

De Autoriteit Persoonsgegevens heeft Odido al om uitleg gevraagd over de mogelijk te lange opslag van gegevens. En dat is terecht. Waarom had Odido nog paspoortnummers van klanten die al jaren weg zijn? Na de initiële verificatie bij het afsluiten van een abonnement is een paspoortnummer niet meer nodig. Data die je niet (meer) hebt, kan ook niet lekken.

Probleem 4: Salesforce-configuratie

In een goed geconfigureerde Salesforce-omgeving kan een gewone gebruiker geen externe app koppelen zonder goedkeuring van een beheerder. Bij Odido kon dat wel, of de rechtenstructuur was zo opgezet dat de gekoppelde app direct toegang had tot miljoenen records. Salesforce heeft benadrukt dat hun platform zelf niet lek was, maar dat de inrichting door Odido de zwakke plek vormde.

De kern van het probleem: het kasteel-model werkt niet meer

Veel bedrijven denken nog in het ‘kasteel-model’: bouw een dikke muur om het bedrijf, en wie er eenmaal in is, wordt vertrouwd. Dat model stamt uit een tijd van lokale servers en vaste werkplekken. In een wereld van cloudoplossingen, thuiswerken en externe callcenters is het achterhaald.

Het alternatief heet ‘Zero Trust’: vertrouw niets, verifieer alles, altijd. Ook als iemand het juiste wachtwoord heeft. Logt iemand in op een onbekend apparaat? Vraag extra verificatie. Vraagt een account ineens duizenden records op? Blokkeer automatisch en stuur een alert. Wil een gebruiker een nieuwe app koppelen? Vereis goedkeuring van een beheerder.

Zero Trust gaat ervan uit dat elk account ooit gecompromitteerd kan worden. Niet als worst-case scenario, maar als basisaanname. De vraag is dan niet hoe je dat voorkomt, maar hoe je de schade beperkt als het toch gebeurt.

Geen pech, maar een keuze

De hack bij Odido was geen onvermijdelijke ramp en ook geen onvoorstelbaar geavanceerde aanval. Het was een bekende methode, uitgevoerd door een groep die het eerder had gedaan, tegen een systeem dat ondanks expliciete waarschuwingen niet adequaat was beveiligd.

De menselijke factor speelde een rol, zoals bij vrijwel elke hack. Maar de menselijke factor is nooit de diepste oorzaak. Mensen zijn te misleiden. Dat weten we. Een veilig systeem houdt daar rekening mee en is zo ontworpen dat één gecompromitteerd account niet kan leiden tot het lekken van data van zes miljoen mensen.

De lessen zijn niet nieuw. Least Privilege, Zero Trust, data minimalisatie, anomaly detection, phishing-resistente MFA: dit zijn geen experimentele ideeën, maar bewezen standaarden. De vraag is niet of bedrijven ze kennen. De vraag is of ze de keuze maken om ze ook echt door te voeren.

Bronnen
NOS – Odido-hackers kwamen binnen via phishing, deden zich voor als ICT-afdeling
NOS – Toeleverancier Odido waarschuwde voor gebruikte hackmethode
ICT Magazine – Odido-hack was resultaat van phishing: mens is zwakke schakel
Salesforce – Protecting Salesforce data after an identity compromise