Een overtuigend telefoontje kan genoeg zijn om toegang tot een hele grote database te krijgen. De Odido-hack en een eigen Cybernext-test laten zien hoe social engineering vertrouwen misbruikt. Je servicedeskmedewerker neemt op. Aan de lijn: een collega in paniek. Zou jíj de deur wagenwijd openzetten? Mensen op een servicedesk wíllen helpen; dat is hun vak en hun kracht. Maar precies dat behulpzame instinct is wat hackers genadeloos uitbuiten.
Wat gebeurde er bij de Odido-hack?
Nadat de politie al in juli aanwijzingen meldde voor Nederlandse betrokkenheid, maakte zij op 7 september 2026 een stemfragment openbaar van een verdachte in het onderzoek naar de Odido-hack. Een Nederlandssprekende man had de klantenservice gebeld en zich voorgedaan als een collega van de IT-afdeling. Hij gebruikte interne terminologie en zei een probleem te moeten oplossen. Daardoor dacht de medewerker daadwerkelijk een collega te helpen.
De medewerker kwam via zijn aanwijzingen op een nagebouwde inlogpagina terecht en voerde daar een gebruikersnaam, wachtwoord en verificatiecode in. Daarmee kregen criminelen toegang tot interne systemen. Bij de aanval kwamen gegevens van meer dan zes miljoen klanten in criminele handen. De politie beschrijft de volledige werkwijze in haar onderzoeksupdate.
Dit is vishing: telefonische misleiding waarmee een aanvaller informatie of medewerking probeert te krijgen. Het valt onder social engineering, het misbruiken van menselijk vertrouwen om toegang te verkrijgen. Het herkenbare zit in de alledaagsheid: een collega belt, kent de juiste woorden en vraagt om hulp.
Onze eigen social engineering-test bij een servicedesk
Bij Cybernext testen we met toestemming hoe organisaties reageren op zulke verzoeken. Tijdens een opdracht vroeg een organisatie ons om haar servicedesk telefonisch te benaderen. Konden we wachtwoorden, verificatiecodes of andere inloggegevens verkrijgen? Hun beleid was kraakhelder: geef nooit telefonisch inloggegevens door.
We bereidden een pretext voor: een geloofwaardig achtergrondverhaal voor het gesprek. We speelden een medewerker die thuiswerkte, maar niet kon inloggen en een algehele baaldag had. De servicedeskmedewerker reageerde begripvol op ons zielige verhaal. Vervolgens bood hij aan het wachtwoord te resetten. Daarna gaf hij het nieuwe wachtwoord telefonisch door.
Bij het inloggen verscheen de volgende beveiligingsstap: Microsoft Authenticator. De medewerker legde uit waarom tweefactorauthenticatie belangrijk is en waarom je verificatiecodes nooit met anderen moet delen. Toch werd vervolgens ook de MFA gereset. Daarmee konden we inloggen als de medewerker die we beweerden te zijn.
We belden binnen deze opdracht meerdere keren. Pas bij het vierde telefoontje hielp een medewerker ons niet verder. Waarschijnlijk omdat we op dat moment brutaal ook om meer rechten vroegen. Of juist dat verzoek de doorslag gaf, weten we niet. Deze test is geen statistiek over alle servicedesks, maar laat wel zien dat een vastgelegde regel binnen één organisatie verschillend kan uitpakken.
MFA is een slot, maar wie beheert de loper?
De Odido-aanval en onze test hadden verschillende technische routes. Bij Odido werden inloggegevens en een verificatiecode op een nagemaakte pagina ingevoerd. In onze test kregen we toegang via resets door de servicedesk. De overeenkomst is het misbruik van vertrouwen tijdens een telefoongesprek.
IT-verantwoordelijken kunnen zich daarom afvragen: wie mag nieuwe toegang geven als iemand zegt zijn bestaande toegang kwijt te zijn? MFA is als een extra slot op de deur. Maar als iemand ook dat slot kan laten vervangen zonder controle, helpt dat tweede slot niet meer.
Het resetten van wachtwoorden en MFA na telefonische misleiding, zoals in onze test, is ook een bekende aanvalstechniek. Een gezamenlijk advies van CISA en de FBI beschrijft hoe aanvallers helpdeskmedewerkers overtuigen om wachtwoorden en MFA-tokens te resetten. Dat onderstreept het belang van een veilige herstelprocedure. Het gaat hier om een andere werkwijze dan het ontfutselen van inloggegevens en een verificatiecode via een nagemaakte inlogpagina, zoals bij Odido is beschreven.
Maak helpen veiliger (en nog steeds uitvoerbaar)
Een medewerker kan de beveiligingsregel kennen en toch een onveilige uitzondering maken. Dat zagen we in ons gesprek: de uitleg over MFA klopte, de daaropvolgende handeling gaf ons toegang.
Dit is waar de mens super kwetsbaar is; de theorie kende de medewerker feilloos. Maar in de waan van de dag won de behoefte om een collega in nood uit de brand te helpen het van de protocollen. Alleen herhalen dat medewerkers beter moeten opletten, neemt die druk niet weg. Zorg er daarom voor dat de veilige route duidelijk én uitvoerbaar is.
Neem deze onderdelen mee in je resetprocedure:
- Controleer de identiteit vóór een wachtwoord- of MFA-reset.
- Gebruik een vooraf vastgelegd, onafhankelijk controlekanaal.
- Behandel MFA-herstel als een aparte, gevoelige handeling.
- Leg resets, uitzonderingen en herhaalde verzoeken vast.
- Geef medewerkers ruimte om te stoppen en te escaleren.
Een naam, personeelsnummer of overtuigend verhaal bewijst niet wie er belt. Gebruik voor een terugbelcontrole dus geen nummer dat de beller zelf aanlevert. Bepaal ook vooraf wat er gebeurt wanneer de normale identiteitscontrole niet mogelijk is. (Anders moet een medewerker tijdens het gesprek zelf een uitzondering bedenken.) Voor accounts met uitgebreide rechten kan aanvullende goedkeuring een vereiste zijn.
Wat Cybernext in de praktijk onderzoekt
Met een social engineering-test van Cybernext maak je zichtbaar hoe mensen, systemen en processen op elkaar aansluiten. Vooraf spreken we de scope en grenzen af. Bij een telefonisch scenario onderzoeken we bijvoorbeeld hoe de servicedesk identiteit controleert, verzoeken afhandelt en omgaat met twijfel. Je krijgt een duidelijke rapportage met bevindingen en concrete verbeterpunten. Vaak volgt op zo’n test een awareness-sessie, zodat de inzichten ook echt landen op de werkvloer.
Het doel is niet om een behulpzame medewerker schuldig te verklaren. Wel wil je weten op welk moment het proces onvoldoende steun geeft en welke aanpassing dat kan verbeteren. Denk aan een betere herstelprocedure, passende bevoegdheden of training met herkenbare situaties uit het eigen werk.
Wil je weten of jouw servicedesk ook onder druk veilig toegang herstelt? Bespreek je vraag met Cybernext. Samen bepalen we welk scenario zinvol is om te testen.
