Servicedesk als voordeur: weigert je helpdesk een wachtwoordreset?

TL;DR

• Een aanvaller hoeft je wachtwoord zelden te kraken. Hij belt de servicedesk en vraagt een nieuw wachtwoord, of een MFA-reset.
• Google Cloud meldde in juni 2026, op basis van M-Trends 2026, dat vishing goed was voor 23 procent van de cloudgerelateerde incidenten, en dat aanvallers AI-stemklonen inzetten tijdens drukke helpdeskgesprekken.
• De stem is niet de zwakke plek. Het verificatieproces wel. Wat controleert je desk voor er iets gereset wordt, en gebeurt dat ook nog om vijf voor vijf?
• Een social engineering test belt je desk en toont of het script onder druk gevolgd wordt. De test beoordeelt het proces, nooit de persoon die opnam.

Elke organisatie heeft een deur waar geen firewall voor staat: de servicedesk. Iemand belt, zegt dat hij buitengesloten is, klinkt gehaast en vraagt een wachtwoordreset of een nieuwe MFA-registratie. Wie opneemt, wil helpen. Dat is het werk. Een aanvaller weet dat, en daarom komt dat telefoontje meestal binnen op het drukste uur van de dag.

Onze social engineering assessments bevatten precies dat telefoontje. We testen niet of je helpdeskmedewerkers naïef zijn. We testen of het verificatieproces dat ze meekregen overeind blijft als iemand doorduwt. Waar dat niet lukt, geeft security awareness training de desk een script en, belangrijker, de toestemming om het te gebruiken. Deze post gaat over dat script: wat je controleert, wat je weigert, en wat een test je vertelt dat een beleidsdocument niet kan.

Waarom de servicedesk de voordeur is

De meeste bedrijven hebben jaren besteed aan de buitenkant: overal MFA en conditional access, een degelijke EDR. Dus valt de aanvaller de buitenkant niet meer aan. Staat op elk account MFA, dan is de goedkoopste weg naar binnen iemand die die MFA voor jou reset. De servicedesk kan dat in twee minuten. Niemand anders in het gebouw kan dat.

Google Cloud zette er in juni 2026 een cijfer op. Op basis van M-Trends 2026 was vishing goed voor 23 procent van de cloudgerelateerde incidenten, en Google Threat Intelligence Group en Mandiant zagen aanvallers AI-stemklonen bouwen uit publieke opnames en die inzetten tijdens drukke, gespannen helpdeskgesprekken. Hetzelfde artikel maakt een punt dat wij in bijna elke test terugzien: een desk wordt afgerekend op snelheid. Gemiddelde afhandeltijd beloont de medewerker die snel reset, niet degene die eerst terugbelt.

Wil je weten hoe zo'n gekloonde stem gebouwd wordt en waarom ze mensen overtuigt, lees dan onze post over deepfake vishing. Deze post blijft aan de andere kant van de lijn: wat de desk doet zodra die stem aan de telefoon hangt.

Test het verificatieproces, niet de stemkloon

Of de beller een echte collega is, een zelfverzekerde vreemde of een synthetische stem, voor de medewerker maakt het geen verschil. Die kan het niet horen, en dat verwachten we ook niet. Wat hij wel kan, is de controles uitvoeren. Dus dat is wat we testen.

De meeste verificatiescripts die wij zien vragen een naam, een personeelsnummer, de naam van de leidinggevende en een geboortedatum. Elk van die gegevens staat op LinkedIn, in het bedrijfsadresboek of in een datalek uit 2019. Een script dat op bekende feiten steunt, is een quiz met de antwoorden op de achterkant.

Tijdens een vishingtest bellen we met een voorwendsel dat in de getekende scope is afgesproken: een verkoper op de luchthaven, of een nieuwe collega in zijn eerste week die nog niemand kent. Daarna noteren we welke controles de medewerker uitvoert, welke hij overslaat zodra we wat druk zetten, en op welk moment in het gesprek de reset wordt toegekend. Het rapport beschrijft het proces op groepsniveau. Het noemt de medewerker niet, en resultaten worden nooit gebruikt om iemand te sanctioneren. Hoe een volledig assessment wordt afgebakend en uitgevoerd, staat in onze gids over het social engineering assessment.

Vier maatregelen die aan de telefoon overeind blijven

De eerste: terugbellen op een geregistreerd nummer. Niet het nummer dat de beller opgeeft, maar het nummer dat al in je HR-systeem of adresboek staat. Is de beller daar niet te bereiken, dan wacht de reset. Die ene stap breekt de meeste voorwendsels, want de aanvaller heeft dat toestel niet in handen.

De tweede: goedkeuring van een leidinggevende voor elke MFA-reset. Een wachtwoordreset sluit het oude wachtwoord buiten. Een MFA-reset geeft het account aan wie het nieuwe toestel vasthoudt, en dat verdient een tweede paar ogen. Die goedkeuring loopt via een kanaal dat de beller niet beheerst, bijvoorbeeld een bericht aan de leidinggevende in je eigen chattool.

De derde: geen verificatie op gegevens die online te vinden zijn. Schrap personeelsnummer, geboortedatum en naam van de leidinggevende uit het script, of hou ze alleen als eerste filter. Vervang ze door iets wat de aanvaller niet vooraf kan opzoeken: een code naar het geregistreerde toestel, een vraag die alleen de echte persoon en jouw systeem kennen, of een fysieke check aan de balie voor wie in het gebouw zit.

De vierde: een vaste weigerprocedure zonder schuldgevoel. Het onderzoeksteam van Sophos zegt het zonder omwegen: maak het aanvaardbaar dat helpdeskmedewerkers niet helpen, en geef ze het recht om een verzoek dat ze niet kunnen bevestigen beleefd te weigeren, ook als het van hogerhand komt. Dat werkt alleen als de weigering een geschreven stap is met een volgende actie ("ik kan dit nu niet afronden, ik stuur het verzoek naar je leidinggevende en bel je terug op je geregistreerde nummer"), en als niemand achteraf een klacht krijgt omdat hij die stap gevolgd heeft.

Wat een test toont: of het script onder druk gevolgd wordt

Een beleid zegt wat de desk hoort te doen. Een test zegt wat de desk doet op een dinsdagnamiddag met elf tickets in de wachtrij. Dat zijn twee verschillende documenten.

We bellen in golven, volgen de gesprekken live op en stoppen een scenario zodra het echte schade zou veroorzaken. Daarna krijg je een rapport met wat er per scenario gebeurde, waar het script standhield en waar het brak, en een concrete lijst verbeterpunten met een stappenplan. Typische vaststellingen: het terugbellen werd overgeslagen toen de beller zei dat hij in het buitenland zat; de goedkeuring werd gevraagd aan een leidinggevende die de beller zelf had genoemd; de desk had geen vaste zin om te weigeren en improviseerde. Niets daarvan betekent dat je mensen slordig zijn. Het betekent dat het script ruimte laat om vriendelijk te zijn, en aanvallers buiten vriendelijkheid uit.

Een hertest een paar maanden later toont of de verbeteringen bleven hangen. Een desk die een keer gebeld en goed nabesproken is, is naar onze ervaring een lastiger doelwit dan een desk die twee keer getraind en nooit gebeld is.

Veelgestelde vragen

Wat is social engineering via de servicedesk?

Een aanval waarbij iemand je helpdesk belt of aanschrijft, zich voordoet als medewerker en een wachtwoordreset, een MFA-reset of nieuwe toegang vraagt. De aanvaller breekt de techniek niet; hij vraagt een mens om de deur open te doen.

Waarom richten aanvallers zich op de servicedesk en niet op de loginpagina?

Omdat de loginpagina MFA heeft en de servicedesk die kan weghalen. Een reset duurt enkele minuten, laat weinig sporen na en hoort bij de gewone dag van de desk, dus slaat er zelden een alarm aan.

Maakt een AI-stemkloon verschil voor de helpdesk?

Minder dan je denkt. De medewerker kan een kloon toch niet van een echte stem onderscheiden, dus de verdediging mocht nooit afhangen van het herkennen van de stem. Ze hangt af van terugbellen op een geregistreerd nummer en een goedkeuringsstap die de beller niet beheerst.

Wat houdt een social engineering test van de servicedesk in?

We leggen scope, voorwendsels en spelregels vast in een getekende overeenkomst, bellen de desk in gecontroleerde golven en noteren welke verificatiestappen onder druk worden uitgevoerd, overgeslagen of omzeild. Je krijgt een rapport op groepsniveau met concrete verbeterpunten. Zie onze dienst social engineering.

Krijgen mijn helpdeskmedewerkers problemen na een test?

Nee. Rapportage gebeurt op groepsniveau en resultaten worden nooit gebruikt om individuele medewerkers te sanctioneren. Het doel is een beter script en de toestemming om het te volgen, geen lijst met namen.

Hoe vaak test je de servicedesk best?

Na elke wijziging aan het verificatiescript, na de start van een nieuw team of een uitbestede desk, en verder ongeveer een keer per jaar. Een hertest toont of de verbeteringen uit de eerste ronde standhielden.

Gerelateerde diensten en bronnen

Het telefoontje naar je helpdesk is een scenario binnen onze social engineering assessments, naast phishing, smishing en een fysieke mystery guest; het telefonische deel staat uitgebreider op onze pagina over vishing. Het script en de toestemming om te weigeren komen uit security awareness training, en wat zo'n programma moet bevatten lees je in onze gids over security awareness training of in onze post over gamified phishingsimulatie. Achtergrond over gekloonde stemmen vind je in deepfake vishing uitgelegd, en hoe een volledig assessment wordt afgebakend in de gids over het social engineering assessment.