WK 2026: Scoor de beste deals! Stel jouw winnende opstelling samen met behulp van ons advies.

Epe kon worden gehackt doordat een noodtoegangaccount slecht was beveiligd

Het datalek bij de Nederlandse gemeente Epe eerder dit jaar kon plaatsvinden nadat aanvallers een noodtoegangsaccount konden misbruiken. Ze wisten een beheerderswachtwoord te kraken, schrijf de gemeente in een evaluatierapport. Bij de hack werden de bsn's van alle inwoners gestolen.

De gemeente Epe heeft een evaluatie online gezet van het datalek dat in april dit jaar plaatsvond. Na de hack kwamen de namen, adressen, geboortedata en burgerservicenummers van alle inwoners van de gemeente op straat te liggen. De gemeente verving daarop duizend ID-bewijzen zonder kosten.

Er waren al wel wat details over de hack bekend, maar met de huidige evaluatie wordt nog duidelijker hoe de criminelen de ruim 525.000 documenten wisten te stelen. Zo was al duidelijk dat de criminelen binnenkwamen door een werknemer om de tuin te leiden, die malware te laten downloaden en diens multifactorauthenticatiegegevens te onderscheppen.

Nu is ook duidelijk dat de criminelen vervolgens hogere gebruikersrechten op het systeem kregen 'doordat een beheerderswachtwoord kon worden gekraakt'. De gemeente schrijft ook: "Een break-glass-account, bedoeld als noodtoegang, had onvoldoende aanvullende beveiligingsmaatregelen, waardoor de aanvaller hiermee vergaande rechten kon verkrijgen." Daarover geeft de gemeente ook geen details, maar onder andere Microsoft noemt Globale Beheerder-accounts zo in Entra ID.

Ook opvallend in de evaluatie is dat de gemeente schrijft hoeveel het datalek de gemeente kostte. Die informatie wordt zelden genoemd bij hacks, maar Epe is daar open over: het datalek kostte bijna 350.000 euro. Het technisch onderzoek kostte bijvoorbeeld 120.896 euro, zegt de gemeente. Het inhuren van het incidentresponsebedrijf en 'externe projectleiding' kostte 79.815 euro. Ook de inzet van communicatiewerknemers kostte geld, net als het afhandelen van AVG- en Woo-verzoeken. De gemeente schrijft daarnaast wat het verzenden van alle brieven en het vervangen van alle identiteitsbewijzen kostte.

Datalek/Security/Hackers/Hack. Bron: Boonchai Eedmakawand/Moment/Getty Images

Door Tijs Hofmans

Nieuwscoördinator

05-06-2026 • 20:32

24

Submitter: Cranberry

Reacties (24)

Sorteer op:

Weergave:

Het verbaasd mij dan ook eigenlijk dat een giga bedrijf als MS geen intern lock/unlock systeem heeft voor break-the-glass accounts bij hun enterprise klanten.

Bijvoorbeeld dat je een bepaald MFA-loos account kan aanmaken als een BtG waarna je een code krijgt die je offline moet bewaren. Je daarna naar MS moet bellen die je naar de code vragen om dit account te kunnen ontgrendelen.

Het zijn de extra lagen die ertoe doen.

En als mijn idee niet goed is, dan zullen er vast tonnen goede ideeën zijn.
Microsoft biedt gewoon 'break-the-glass' accounts die je prima kunt beveiligen waardoor dit nagenoeg onmogelijk was geweest. Een aantal best-practices toepassen zoals zeer lange wachtwoorden (50+ chars voor mijn part), FIDO2 keys koppelen en alerting instellingen op pogingen tot inloggen op dat soort accounts. Vervolgens leg je die wachtwoorden en hardware keys in een kluis en haal je die er alleen maar uit om te testen.

Veel veiliger kun je het haast niet maken.
Voor mij is een break-the-glass account alleen een BtG wanneer het geen toeters en bellen heeft, zoals FIDO2. Juist daarom lijkt mij een in-system oplossing vanuit MS zo handig.

Alerting enzo lijken mij inderdaad ook een uiterst belangrijke toevoeging.
Een FIDO2 key zou niet onder "toeters of bellen" moeten vallen. Zolang je dat instelt, er vanaf blijft en consistent test, is dat een vele malen veiligere oplossing. Daar voorkom je in ieder geval mee dat ie wachtwoord brute-forced wordt. Al zou dat eigenlijk al onmogelijk moeten zijn als deze lang genoeg is.
Met een gewone Yubikey of soortgelijke oplossing kun je een letterlijke break-the-glass-oplossing maken. Inclusief alarm als je wil.

Je moet natuurlijk geen passkey aan een Microsoft account koppelen of aan een fysieke laptop-TPM hangen, maar een setje fysieke sleutels die het in elke laptop doen, zijn volgens mij de beste manier om zoiets te doen.

Een lang wachtwoord kan ook, maar in een panieksituatie vijftig karakters can een papiertje moeten overtypen is niet heel bevorderlijk voor de geestelijke gesteldheid van degene die het systeem moet herstellen.
BtG accounts beveilig je met een FIDO2 key die je in een kluis legt. Die FIDO2 key is alles wat je nodig hebt om in te loggen met dat account, en dat account is uitgezonderd van alle Conditional Access policies.

Uiteraard gaan er bij inloggen diverse alarmeringen af, mocht een kwaadwillende toch toegang hebben gekregen tot het account en de key.
Het is inderdaad vrijwel zeker entra id wat gebruikt wordt. Beetje off topic: Maar als je nu denkt goh, hoe zit dat bij mij?

Je kunt gratis met de open source tooling maester heel veel dingen al opsporen en automatisch fixen: https://maester.dev/ - Gemaakt door Merill Fernando de ex program manager van entra bij microsoft.
Ik ben altijd huiverig om voor mij onbekende script van onbekende sites van onbekende mensen te draaien.
De scope is CurrentUser, en dat betekend dus dat de gemiddelde admin dit met Global Admin aftrapt...
Brrrr.

Zijn er betrouwbare mensen die door de gehele code gegaan zijn om te kijken of het echt betrouwbaar is?

Het zal niet de eerste keer zijn dat er enge dingen gebeuren in vertrouwde tools van vertrouwde mensen.
Ik mag toch hopen dat de gemiddelde admin niet standaard GA is in zijn tenant ...
Je zal ze de kost geven....
"Nee, we maken slechts 2 mensen GA, dat is veiliger".
Aldus een manager bij één van mijn vorige werkgevers 🤡
Ik ook. Ik heb wel vorige week geleerd dat het alleen leesrechten nodig heeft
Gebeurt wel vaker.

Ik stelde leidinggevende voor om Shamir’s Secret Sharing algoritme te gebruiken voor het breakglass account. Krijg ik glazen ogen gevolgd door een mededeling dat de MSP (leverancier) dat moet beheren. Zij bewaren het in een ticketsysteem, in plain tekst!

Maar volgens de accountant zijn zij wel ISO27001 gecertificeerd dus het zal wel goed zijn!

[Reactie gewijzigd door Mushroomician op 5 juni 2026 20:57]

Als je MSP dit plain text bewaard, dan zou ik per direct een andere MSP zoeken!
Minimaal een klacht indienen bij hun CISO oid.

Ik neem aan dat ze ISO27001 gecertificeerd zijn, wat zou betekenen dat dit absoluut niet kan. Kan je ook meteen klagen bij degene die het certificaat heeft uitgegeven.
Iso27001 gaat veelal over het proces niet de inhoud

Secure want compliant komt niet vaak voor helaas
Hun argument is dat het op een server staat die met bitlocker is encrypted. Daarmee is elke leek verkocht. Wat weet die nieuwe 30’er nou wat een bijna gepensioneerde niet weet?

Ik werk er gelukkig niet meer, maar het is een maatschappelijk probleem dat de verkeerde mensen de verkeerde verantwoordelijkheden hebben. En als je voorstelt om het uit te leggen letterlijk claimen: “zij hoeven en willen het niet te begrijpen”

[Reactie gewijzigd door Mushroomician op 5 juni 2026 21:38]

Knullig maar wel zeer transparant.
MFA moet ook op break the glass accounts aanstaan. Dan is het gebruik van een FIDO key hiervoor wel het makkelijkst, die je vervolgens weer in de kluis opbergt. Uiteraard periodiek testen en uiteraard ook alerting aanzetten op het moment er mee ingelogd wordt.

[Reactie gewijzigd door zeezuiper op 5 juni 2026 20:45]

Mmm.. Het begon voornamelijk omdat werknemers op hun desktop gewoon windows+r (run) konden gebruiken, cmd.exe konden starten en powershell niet geblokkeerd stond of was ingesteld om alleen vertrouwde scripts te draaien. Die eerste layer of defense was er gewoon niet. Was die defensie er wel geweest (bv via ms applocker, ivanti application control, mss zelfs gpo's) dan was deze hack een stuk lastiger geweest.
Waarom werd er geen yubikey gebruikt?
Delete

[Reactie gewijzigd door Cooyco op 5 juni 2026 21:09]

Wat voor mij de grote vraag is: wie besluit dit op deze manier te doen om dit zo op deze manier te beveiligen? En wie controleert diegene dan? Zo’n besluit neem je niet in je eentje. Bovendien is er een controlerende externe partij? Ik snap dit niet, we hebben het over zo’n bak met gegevens… Het siert de gemeente dat ze transparant willen zijn en dat daarmee bekend wordt wat er mis is gegaan, ondanks de fouten die zijn gemaakt.
Die had geen zin om met hardwarekeys te slepe
Een gemeentelijk IT-er in Epe

Had van beveiliging niet veel begrepen

Hij zette de deur zo wijd open

Dat hackers lachend binnen konden lopen

Om heel Epe leeg te screpe

Om te kunnen reageren moet je ingelogd zijn