Hacker zegt met wachtwoord 123456 Deens persoonsregister te zijn binnengedrongen

De cybercrimineel die gegevens van 8,8 miljoen Denen buitmaakte, kon via een beheerdersaccount binnendringen in het persoonsregister. Dat stelt de Deense krant Politiken op basis van claims van de verantwoordelijke hacker. De aanvaller claimt dat dit account '123456' als wachtwoord gebruikte.

De aanvaller kwam binnen via een bedrijf dat wettelijke toegang heeft tot het bevolkingsregister van Denemarken. Politiken meldt nu dat de aanvaller toegang had tot zeker drie accounts, waaronder het beheerdersaccount. In totaal had hij 21 dagen toegang tot het persoonsregister.

In die tijd downloadde hij de gegevens van miljoenen Deense inwoners. Het gaat om namen, adressen, burgerservicenummers en andere gegevens. De aanvaller claimt zelf dat het om gegevens van 5,5 miljoen levende en 3,3 miljoen overleden Denen gaat.

Het Deense Centraal Register van Personen (CPR) ontdekte het beveiligingsincident op vrijdagavond 2 oktober. Het CPR blokkeerde daarop de toegang van het bedrijf en doet onderzoek naar het incident.

Bron: Witthaya Prasongsin/Moment/Getty Images

Reacties (118)

[laurens0619]

Als je met dit wachtwoord kunt inloggen dan zegt dat eigenlijk 2 dingen:
- Er was een zwak wachtwoord actief
- Er was (schijnbaar) geen phishing resistant MFA

En eigenlijk is het zwakke wachtwoord het minst interessante, de phishing resistant MFA mistte (schijnbaar).
Wachtwoorden moet je sowieso niet op leunen, die kunnen of:
- Geraden
- Social engineered
- Hergebruikt uit dataleaks

[Transferno]

Klopt een goede wachtwoordpolicy had dit geval al kunnen voorkomen. Maar inderdaad, MFA erbij is tegenwoordig ook noodzakelijk.

Knullig dat de wachtwoordpolicy iets eenvoudigs als 123456 toeliet. Als er al een policy actief was.

[darknessblade]

Het kan goed zijn dat dit nog een flink out legacy password is. wat niemand dacht te veranderen.

[kabelmannetje]

Het zegt dat er NOOIT een security audit heeft plaatsgevonden.

[Rhinosaur]

Bij het ministerie waar ik werkte hadden we dit ook tijdens pentesten ontdekten. Veel beheersccounts hadden default username en wachtwoord (admin, admin). Komt doordat de technische beheerders de handleidingen niet goed volgen.

[MuddyMagical]

Het feit dat een applicatie geen beter wachtwoord afdwingt is (zonder beheerders die het instellen vrij te pleiten) natuurlijk ook één van de problemen die hier aan bijdragen.

[HenkEisDS]

Zo’n basisregistratiesysteem is waarschijnlijk 50 jaar oud. En elk kwartaal is er wel een ander brandje te blussen. Ik praat het niet goed, maar ik begrijp het wel.

[mphilipp]

En dat is nou juist het probleem: er wordt te lang gewacht met moderniseren. Ik zit al bijna 40 jaar in de ICT en heb veel oude troep voorbij zien komen. Als 'rondreizend consultant' heb ik jarenlang bij allerlei bedrijven gezeten, van multinational tot (lokaal/landelijke) overheid en ook nog wat brancheorganisaties. En het maakt wat dat betreft niet zoveel uit waar je zit, maar ze hebben allemaal hun lijken in de kast. Niet willen upgraden of beginnen na te denken om een legacy applicatie uit te faseren of te vervangen. En dan bedoel ik op de momenten dat het nog makkelijk kan. Dus niet wachten tot je met je rug tegen de muur staat.
Ik heb ooit bij een multinational een inschatting moeten maken over het upgraden van de database voor een bedrijfskritische applicatie. Die draaide nog op een hele oude Solaris versie, en ook de database wat stokoud. Erger nog: in de applicatie zaten elementen om hardware aan te sturen (een productieproces) en zelfs die machines in de fabriek waren (te) oud. Zij hebben dus meerdere kansen gemist om de boel bij de tijd te houden en dan mis je de boot en kun je eigenlijk niets anders meer dan de hele boel opnieuw te maken.

Dus ja, ik snap inderdaad dat bedrijven met legacy zitten, maar dat is ook (meestal) hun eigen schuld. Als je tijdig begint, kun je nog reageren. Maar ja, gewoon niet patchen en nog steeds een Windows NT (!) printserver hebben draaien in je netwerk is natuurlijk vragen om problemen. Er is geen excuus. Maak een roadmap voor je applicaties als je ze in gebruik neemt.

[Tassadar32]

Hier 16 jaar als consultant developer en precies dezelfde ervaring. Moderniseren of op z'n minst onderhoud/updates staat altijd op de laagste prioriteit. Het veilig houden van systemen zal niemand kunnen gebruiken als argument om promotie te krijgen, shiny new feature X wel.

Beveiligingsproblemen worden tegenwoordig als dagelijkse kost gezien, daar word niemand meer op aangesproken of voor ontslagen.

[vrow]

Nou, wat ook een probleem is, is dat ook al heb je alles wel 100% op orde, dan nóg komen de hackers binnen.

De slogan 'het is niet de vraag óf je gehackt wordt, maar wanneer' helpt daar ook niet aan mee.

Kijk naar de grote hacks bij universiteiten, ziekenhuizen en noem alles maar op het afgelopen jaar. Los of het beveiligingslek, een phising/sociale engineering of een slecht wachtwoord was - bij al deze bedrijven kwamen ze binnen. Dan krijg je op een gegeven moment ook een soort fatalisme: ze hacken ons toch wel, dus dan heeft het ook geen zin om er heel veel geld tegenaan te gooien.

[mphilipp]

Dat zijn twee aparte problemen. De zaken niet op orde hebben (dus oude, niet gepatchte machines, oud OS, oude applicatie) en gehackt worden is erger dan alles 'goed' doen en alsnog gehackt worden.
In het eerste geval vraag je om problemen en maak je het je aanvallers veel te gemakkelijk. In het tweede geval wordt je alsnog het slachtoffer omdat er bv gebruik wordt gemaakt van een zero-day. Ik ben liever de verantwoordelijke in geval 2 Dan heb ik minder uit te leggen.

Er zijn natuurlijk tal van zaken die je moet doen om veilig te blijven. Bij een groot en belangrijk target, zoals nu AH die aangevallen lijkt, hebben zij eigenlijk geen excuus. Dit is een multinationale onderneming met meer dan genoeg resources om de zaken op orde te hebben. En zij moeten ook heel veel doen, want ze zijn belangrijk en de financiele schade kan aanzienlijk zijn. Kijk naar Maersk.
De bakker op de hoek moet ook wat doen, maar de maatregelen die zo'n onderneming moet nemen, zijn natuurlijk veel kleiner dan een multinational. Voor hen is up to dat zijn met je OS en applicaties, een degelijk backup beleid (ransomware!) en een goede password policy (2FA) al voldoende. En daar tussen zitten tal van bedrijven die echt nog op de Mr.Bean manier omgaan met hun ICT. Geen interesse/kennis en vooral geen inzicht in de riciso's die zij lopen zijn hier de belangrijkste factoren. Je kunt het je anno 2026 haast niet meer voorstellen, maar er zijn echt bedrijven die denken dat zij geen interessant target zijn.

[vrow]

Jahoor, ik ben dat helemaal met je eens.

Waar ik werk, zit er inderdaad mooi tussenin en we nemen dus de 'tussenin'-maatregelen. Maar hier zijn absoluut mijn collega's de zwakste schakel. Als wij hier gehackt worden, is het omdat iemand hier ze het wachtwoord heeft gegeven, schat ik zo in ;-)

[Nox]

Op het moment dat je als hacker een loginpoging kan doen - of je het wachtwoord weet of niet - is het al problematisch.

Je dient je systemen af te schermen voor de buitenwereld en als extra laag te voorzien van een password. Als dat niet kan zal je toch op een andere manier moeten zorgen voor afscherming, bijvoorbeeld een MFA, certificaat e.d.

Een systeem open en bloot maken, niet kunnen updaten en dan maar gewoon zeggen 'dan heeft iemand het password verstrekt' is niet de way to go. Er kunnen in dat soort systemen gewoon zerodays zitten of nog oudere beveiligingslekken. Het draait er echt om zoveel mogelijk laagjes op te werpen.

[Reactie gewijzigd door Nox op 12 oktober 2026 13:19]

[Mextreme]

In deze context zie ik permanente verbinding met internet als een probleem. Hoeveel slimmer zou het niet zijn die verbinding down te gooien, bijvoorbeeld als je zeker weet dat 's nachts toch niet wordt gewerkt? Of ben ik naïef?

[mphilipp]

Als dat 100% zeker is, kan dat inderdaad een oplossing zijn.
Maar er zijn ook application firewalls die gedrag bekijken; wanneer wordt de applicatie gebruikt of de database benaderd, door wie en vanaf welke adressen etc, etc. Dergelijke systemen kunnen alarm slaan of de verbinding afsluiten als een toegangspoging niet in het patroon past.
's-Avonds en in de nacht kunnen vaak weer allerlei processen draaien (batches), worden er bestanden uitgewisseld e.d. Dus de verbinding uitzetten is niet altijd een optie, maar als het kan, prima.

[Mextreme]

Wat ik me aan de hand van jouw uitleg dan afvraag: als een IP adres gespoofed wordt, stinkt zo'n firewall daar dan in?

[mphilipp]

Geen idee... Ik ben geen netwerktechneut en weet niet hoe je een gespoofd adres herkent.

[Tassadar32]

Vaak ook het probleem dat er teveel data in een enkel systeem zit of er sowieso teveel data opgeslagen word die helemaal niet nodig is.

[vrow]

Klopt hoor.

Ik merk dat hier ook wel, bij mijn huidige werk. Hier staat beveiliging ook op een laag pitje - ja, ik doe er zelf wel van alles aan natuurlijk, maar als ik op een gegeven moment via group policies de ingebouwde wachtwoordfuncties van browsers moet gaan uitzetten omdat mensen anders echt niet de wachtwoordmanager willen gebruiken met de directie voorop... Tja, dan wordt het echt heel lastig.

Mensen zeggen dan weer 'pff, het is zo lastig'.
Dan zeg ik altijd: 's ochtends... Eerst je benen uit het bed, dan sokken aandoen, ...., koffie in het apparaat scheppen, pfff, wat een werk.
Bij de auto.. De sleutel in het slot (of digitaal), dan moet je deur open doen (!), een gordel om, wow, wat een handelingen... Wat een gedoe allemaal zeg. Kan je niet gewoon je bed op wielen zetten dat het zo naar je werk rijdt..?

Met als gevolg dat ze wel even lachen, niet meer durven klagen maar daarna alsnog de wachtwoorden op een briefje schrijven, maar dat briefje nu verstoppen onder de monitor in plaats van onder het toetsenbord zodat jij als beheerder denkt dat ze hun leven gebeterd hebben, haha. Mensen zijn héél handig dingen te verbergen zodat jij niet gaat 'zeuren'....

[DropjesLover]

Mensen willen gemak en computers veilig maken is niet gemakkelijk.
De hoeveelheid aan verschillende accounts, wachtwoorden, PIN's en weet ik wat loopt de spuigaten uit. En dan werk ik nog niet eens als sysadmin of dergelijk.

[TEAser_]

Ja en zo lang de boetes op dit soort lekkages laag blijven kunnen bedrijven dit risico gewoon jaarlijks afschrijven, net zoals Meta doet met misbruik van persoonsgegevens uit de EU, boete is laag genoeg dat ze nog steeds winstgevender zijn als ze de data misbruiken en de boete betalen dan als ze braaf omgaan met de data en zo is de AVG wet natuurlijk een beetje nutteloos. Overheid zou echt moeten kijken om dit soort praktijken zwaarder te kunnen straffen in de toekomst als het bewezen wordt dat het makkelijk te voorkomen was.

[Piemol]

Ik heb ook wel gezien dat een bedrijf bewust niet overstapt, omdat legacy in de lucht houden bedrijfszekerder is dan overstappen naar software geregeerd door mega investeringsmaatschappijen met vendor lock in (incl hardware !).

Dan is legacy 'de minst slechte oplossing'.
En dan regelmatig kritisch kijken of je in beweging moet komen, dat wordt dan wel erg belangrijk.

[mphilipp]

Ja, of het is gewoon koudwatervrees. De verantwoordelijke persoon durft het niet aan, want als het migreren onder zijn/haar leiding faalt, is die persoon de sigaar. Dus uitzingen is dan het veiligste.
Ik kan mij voorstellen dat je in die positie zit en het niet aandurft, maar wees je dan wel bewust van de risico's en communiceer dat helder naar de top. Die moeten weten welke risico's zij lopen. En als het bedrijf de kennis niet heeft om die keuze tussen upgraden/migreren/uitzingen goed te kunnen maken, huur je daar iemand voor in.

Het kan wat dat betreft ook een communicatieprobleem zijn tussen de techneuten en het management. Die kunnen vaak niet goed communiceren. Management denkt dat de techneuten overdrijven en denken dat het wel meevalt. Daarom is het goed om dit in Jip&Janneke taal uit te kunnen leggen. Ze snappen meer dan je denkt, als je het maar op hun nivo uitlegt.

[msnarf]

Maar waarom moeten die techneuten zich altijd aanpassen aan het kennisniveau van het management? Wordt het zo langzamerhand niet eens tijd dat het management voldoende kennis heeft om de techneuten te begrijpen?

Zij (het management) moeten ook altijd de beslissingen nemen over de technologie, dan zou het toch handig zijn als ze er ook iets vanaf weten.

[mphilipp]

Ja, je kunt wachten tot de wereld zich aan jou aanpast, maar beter is het om te snappen hoe zij de informatie willen hebben. Een bestuurder , net als een minister, hoeft niet tot in detail te weten hoe alles gaat. Ze willen weten wat de impact is van een change, waarom het nodig is, wat het kost, en (vooral) wat het kost als je het niet doet. Als je dit zodanig uit kunt leggen dat een leek dat snapt, ben je er. De technische details zijn alleen voor jou belangrijk. Die hoeft de manager niet te weten.

Dit is iets dat heel vaak mis gaat.

[R4gnax]

Aan de andere kant heb je ook - vooral bij middle management die aan een hoger iemand nog verantwoording af moet leggen - het geval 'niet snappen; of niet willen snappen?' wat parten speelt.

Plausible deniability. De mogelijkheid om te ontkennen dat er budget nodig is en aan de hoger geplaatsten te laten zien dat de afdeling lekker efficient bezig is; en tegelijkertijd de mogelijkheid om te stellen dat het afdelingspersoneel de manager niet voldoende ingelicht heeft om adequaat te beslissen.

[mphilipp]

en tegelijkertijd de mogelijkheid om te stellen dat het afdelingspersoneel de manager niet voldoende ingelicht heeft om adequaat te beslissen.

Dat is wel erg devious, maar in principe is het de taak van de manager om zichzelf goed te informeren en zorg te dragen dat zijn personeen hem goed informeert. Je kunt je als manager niet verschuilen achter zo'n smoes. Wie dat doet, moet direct ontslagen worden.

[mbbs1024]

Het is soms ook wel een miljoenen investering om een bepaald apparaat te vervangen, of biedt een nieuwere versie niet meer de vereiste functies, je kan dat niet zomaar als koudwatervrees of een communicatieprobleem afdoen .

Maar misschien is het in zo een geval wel mogelijk om een extra systeem tussen de gebruiker en het systeem te zetten, waardoor de beveiliging wel ok wordt.

[Reactie gewijzigd door mbbs1024 op 12 oktober 2026 19:02]

[mphilipp]

Ik kan ook moeilijk alle voorkomende situaties opnoemen. Wat ik aangeef zijn een greep uit de dingen die mij zijn opgevallen door de jaren heen. Er zijn vast meerdere oorzaken, of combinaties van oorzaken.

Dat iets miljoenen kost, is geen reden om het niet te doen. Tenminste, niet puur op basis van dat bedrag. Je moet dan meer weten. Als het bedrijfmiljarden omzet, is een paar miljoen voor een systeem niet vreselijk veel. Als dat systeem geld oplevert. Je kunt soms ook de vraag omdraaien: wat kost het als ik het niet doe? Dat is soms ook wat het management vraagt: Wat als ik niets doe? Als jij dan zegt dat het lastig wordt, maar het wel aan kunt, komt er geen nieuw systeem. Geef je aan dat het bedrijf dan kwetsbaarder is voor cyberaanvallen en ransomware, en jullie dan ook niet meer voldoen aan eisen die klantsystemen stellen, krijg je je nieuwe systeem wel. Ik versimplificeer het natuurlijk, maar zo ongeveer kan zoiets gaan.

[Mextreme]

Ik begrijp de faalangst wel, maar als een konijn in het licht van de koplampen wachten totdat de auto het aanrijdt lijkt me ook niet geweldig.

In het verleden werkte ik in het onderwijs. De hele handel (server, clients, hardware, bekabeling) ging op de schop. Ik heb de plannen die er toen waren tegengehouden, omdat ik totaal geen uitwijkscenario's zag.

Heb toen de taak opgepakt om per techneut en leidinggevende wensen, mogelijkheden, risico's en beperkingen in kaart te brengen. Bakkie pleur d'rbij en doorvragen. De oplossing was zó simpel dat niemand er blijkbaar aan dacht: de zaak nog even 'up' laten (het was inmiddels half april) en als iedereen de pleiterik had gemaakt in de zomervakantie de zaak onder handen nemen.

Wat mij verbijsterde was dat niemand daar blijkbaar opgekomen was; zo simpel!

Maanden later (bijna kerstvakantie) commentaar van mijn leidinggevende: ,,Hoe je het voor elkaar hebt gekregen om dat zooitje met elkaar te laten communiceren is me een raadsel, maar mocht je het onderwijs ooit niks meer aan vinden, adviseer ik je om de politiek in te gaan."

Nooit gedaan

[Mirjam1971]

Niet alleen koud water vrees, ook gewoon de belofte van het management om volgend jaar te migreren naar "HET NIEUWE SYSTEEM" waar dan eindelijk budget voor is die alle gerapporteerde tekortkomingen niet hebben. en om dan einde van het jaar overgenomen te worden en alle personeel de laan uit is gestuurd die er enige kijk op hadden. en zo komt van uitstel afstel en verdwijnt het van de radar, om er pas weer op te verschijnen wanneer er iets volledig in de soep loopt. terug naar regel 1

[Wim Cossement]

Het probleem is wel soms dat die machines nog in perfecte staat zijn, want ze zijn altijd onderhouden en goed gebruikt, maar men voor een nieuwe pc van 500 euro en wat software gewoonweg tienduizenden euro's durft te vragen!
En het invoerformaat van die sturing/software is gewoon nog hetzelfde bestandsformaat, de software zelf ook, er is gewoon geport naar een nieuw OS. Eigenlijk moet je gewoon aan een gedeelde map kunnen, waar je die bestanden in gooit, de operator moet die dan gewoon inladen en op start drukken. Dat is dan gewoon in een apart VLAN in de meeste bedrijven en eventueel wat extra firewallregels voor die toestellen.
Want je gaat mij niet vertellen dat software die op XP draait niet meer op 11 aan de praat te krijgen is, de verbinding is dan meestal nog via een seriële verbinding (soms nog met een USB-adapter tussen). Of het is over TCP maar dan rechtstreeks ingeplugd op de stuur-pc, niet via een netwerk.

[Reactie gewijzigd door Wim Cossement op 12 oktober 2026 10:06]

[Tim_bots]

Probeer maar eens te communiceren met een PLC van (I don't know) zeg 2000. De software om met die PLC te praten werkt nog prima op XP (geschreven voor windows 95/98) maar kan echt niet meer overweg met een 64 bit systeem (16 bit programma).

De machine zelf werkt na 26 jaar nog prima. De programmeer software loopt alleen achter. Maar wat als je nu toch een wijziging moet maken in de code. Dan is die laptop met XP erop toch echt een uitkomst.

[Nox]

Gek genoeg kunnen wij nog steeds via seriele bus communiceren ondanks dat ik op windows 11 zit. Het kan wel, maar zal wel proprietary software zijn voor die PLC. Beter maken ze dat soort applicaties in programmeertalen die veel langer ondersteund worden door meer OS'en.

[Tim_bots]

Dit is ook een stukje lifecycle uitdagingen.

Machines worden gekocht op een levensduur van 20/30 jaar. IT apparatuur is na een fractie van die tijd al aan vervenging toe. Als je dan onderhoud moet toepassen op zo'n machine kan het een uitdaging worden.

[Nox]

Waarom is it apparatuur na een fractie van die tijd aan vervanging toe? Zat spul wat gemaakt is om ook 20+ jaar mee te gaan. Zat switches bijvoorbeeld die 20 jaar halen. Beetje fatsoenlijke switch kost nieuw 2000 euro, moet je die dan na 3-4 jaar maar wegdonderen? Samen helpen we de berg ewaste wel naar de maan.

We zouden blij moeten zijn dat er hardware bestaat die 20 jaar haalt.

[DropjesLover]

Een plc uit 2000 is ondertussen ook end of life / obsolete / niet meer verkrijgbaar. Als die kapot gaat, gaat je machine en dus de hele lijn ook. Ja er zijn wat specialistische reparatie-toko's, maar puur vanuit risicomanagement moet je die plc al lang op een roadmap hebben om te vervangen voor een recenter model, dus incl de software.

Wij hebben nog een paar Siemens S5 plc's draaien waar mensen heeeeeel nerveus van worden

[Tim_bots]

Maar zo'n S5 blijft draaien tot "het einde der dagen" mits er niets bijzonders gebeurd. Dingen als blikseminslag is natuurlijk weinig tegen te doen.

[DropjesLover]

Elektrische componenten degraderen weldegelijk, en power-cycles, al is het 1x per jaar, zijn gewoonweg niet te voorkomen.

[catfish]

Sorry, maar dit is compleet naast de kwestie.
Een goed paswoord kiezen heeft niets te maken met het krijgen van extra geld voor updates.
Het eerste is een keuze van de IT'er zelf, het tweede is de verantwoordelijkheid van de baas.

Er zijn echt wel genoeg moderne systemen te vinden met slechte paswoorden en dat heeft enkel te maken met de mentaliteit van de beheerder.

[curkey]

Zonder een excuus te willen geven, maar vaak is het probleem dat een nieuwe versie bepaalde functies niet meer ondersteunt, waardoor je ineens allemaal extra systemen in je scope hebt zitten die dan óók aangepast moet worden. Zeker als je dan in GxP / SOx gecertificeerde processen zit, dan is dat best een stuk hoofdpijn waar je in terechtkomt.

Ik heb 't al eens gezien met bijvoorbeeld de uitfasering van een bepaalde Java versie, waardoor er direct 2 platforms geraakt werden, maar indirect er 200 applicaties, interfaces en aanpalende zaken allemaal de sjaak waren die je niet 1 voor 1 kon laten migreren.

[supersnathan94]

maar indirect er 200 applicaties, interfaces en aanpalende zaken allemaal de sjaak waren die je niet 1 voor 1 kon laten migreren.

Mijn vraag is dan, waarom niet? Ik snap dat er met Java upgrades dingen aangepast moeten worden (heb ik zelf ook vaak zat gedaan), maar de interface naar buiten toe hoeft niet te wijzigen. Misschien duurt een bepaalde actie wat langer, maar de bestaande API tijdelijk behouden en de nieuwe er naast aanbieden is dan toch redelijk the way to go?

Juist interfaces zijn toch bedoelt om die ontkoppeling te kunnen maken?

[curkey]

Ik zat niet in dat migratieteam, dus de details ken ik niet.

De oude app gebruikte functies in de oude Java 8 die niet in hogere zaten. De nieuwere versie van de enterprise software was herontworpen en draaide een hele andere kernel, met een nieuwe API etc.

Dientengevolge moesten services op een hele andere manier gaan werken, werden sommige functies helemaal niet meer ondersteund door de applicatie (en zou je dus of maatwerk hebben moeten bouwen of een tweede pakket kopen die dat zou kunnen). Ook aan netwerkkant veranderde er dan veel, dus firewalls etc herinrichten (deels omdat de nieuwe tool cloud-only was en via AD moest gaan werken met SSO, iets wat de oude tool niet deed), en het herschrijven van GxP gevalideerde IT policies. Ook voor de gebruikers zou er enorm veel veranderen, dus veel trainingen, en change mgmt activiteiten.

Dus pandora's box in alle glorie.

Wat een simpele upgrade van wat initieel ik noem maar $50k leek, groeide al snel uit naar een scope van over de 3 miljoen en een programma van 3 jaar. Puur voor de basale functionaliteit.

[supersnathan94]

De oude app gebruikte functies in de oude Java 8 die niet in hogere zaten. De nieuwere versie van de enterprise software was herontworpen en draaide een hele andere kernel, met een nieuwe API etc.

aha okay. Dus eigenlijk gewoon 2 zaken in een die niet hadden gehoeven. Java 8 naar 11 kon namelijk prima zonder verlies van functionaliteit aan de leverancierskant.

Dat is jammer want dan wordt zo'n traject inderdaad ineens heel snel heel groot.

[Tassadar32]

Ook wel eens bij een klant gezien dat alle software op een mainframe draaide en het hele mainframe in een keer over moest naar een nieuwe Java versie. Dan is er ook geen geleidelijk aan upgraden aan maar een big-bang met alle risico van dien.

[supersnathan94]

dat snap ik, maar dan ga je toch juist proberen om zoveel mogelijk je interface naar buiten toe gelijk te houden? dus dat je intern wijzigingen moet doen of dependencies toe moet voegen (zoals alternatieven voor Java enterprise modules) is dan prima.

Je gaat dan toch juist niet én én doen maar 1 voor 1. eerst java versie, daarna kijken naar API vernieuwing. Juist om de druk van de ketel te krijgen en de migratie makkelijker te maken. Ik heb zelf ook van 8 jaar 11 gedaan toentertijd, was een paar uur werk.

[Tusk]

IT wordt bij veel bedrijven gewoon gezien als een kostenpost. Waarbij investeringen gezien worden als geld dat nooit meer wordt terugverdiend.

Een transportbedrijf vond het belachelijk om een paar 15 jaar oude switches en hun firewall te upgraden, want "het werkt toch?!" Maar ondertussen wel 3 nieuwe vrachtwagens met alle toeters (letterlijk) en bellen bestellen alsof het een pak wc-papier is.

[mphilipp]

Dan heb je een communicatieprobleem.
Die trucks zijn letterlijk de moneymakers. Dat begrijpt men. Dus moet je die switches uitleggen alsof het trucks zijn. Maar dan de trucks van de ICT. En dat is ook de backbone van het bedrijf.

[SPee]

Kan ook zijn dat ze een nieuw systeem hebben gekocht, maar dat die nog niet af is. In de tussentijd wordt er dan niets met het oude systeem gedaan, want al het geld gaat naar de nieuwe ontwikkeling. En helaas heeft die vertraging, loopt uit, heeft nog niet alle features en zijn er problemen met de ontwikkelaar waardoor het nóg later wordt. En zo ben je jaren verder en is het OS waarop je productiesysteem draait ineens niet meer ondersteund.

Op mijn huidige project hoor ik al drie jaar "5 december" als datum waarop het nieuwe systeem live gaat/zou gaan.

[mphilipp]

Dat zijn allemaal keuzes die gemaakt worden. Als je een belangrijk systeem gaat vervangen en blindelings vertrouwd op de planning en geen backup plan hebt, ben je eigenlijk verkeerd bezig. Je moet een bepaalde deadline hebben, waarop je duidelijkheid hebt of het nieuwe systeem op tijd klaar is. Zo niet, dan moet je maatregelen nemen om het oude langer te kunnen handhaven. Tegenwoordig kun je niet meer zeggen dat je geen patches meer toepast.
Eerste les bij een cursus planning is 'plan for contingency'.

[DigitalExorcist]

Ja maar dit is meer als iemand die een jerrycan benzine in het bos leegkiepert en vervolgens met brandende fakkels gaat jongleren..

[GrooV]

Ook 50 jaar geleden was het geen goed idee

[hqql]

Er is imo ook een bepaalde mate van verantwoordelijkheid die je zelf draagt voor de gegevens waar je toegang tot hebt. Als je toegang krijgt tot gegevens van miljoenen burgers moet er wel ergens een lampje gaan branden dat 123456 geen geweldig wachtwoord is.

[Tassadar32]

Helaas werken er ook mensen met erg weinig IT vaardigheid, gezond verstand of die gewoon erg dom zijn in die posities. Een check of een wachtwoord in grote lekken zit of te simpel is is wel het minste wat je kan doen.

[hqql]

Als onbekwaamheid de zwakste schakel in je veiligheidsketen is dan zijn IT 'oplossingen' niet alleen noodzakelijk maar schieten deze ook ver tekort om dat volledig op te kunnen vangen imo.

Natuurlijk kun je iets simpels als 'complexe wachtwoord vereisten' instellen in je organisatie om een wachtwoord als 123456 te voorkomen, en dat moet ook en zal ook helpen, maar je kunt het nog zo mooi met persoonlijke 3FA werken en alles mooi up to date hebben etc. etc. als er iemand met 'meer toegang dan kunde' gebeld wordt door "IT" dat ze even een "Teams Update" moeten installeren en vwoep alles ligt op straat

[T-men]

Wie verwacht in de huidige tijd nog dat iemand 123456 als wachtwoord kiest... ? Is het niet JUIST een heel goed wachtwoord?

Ik denk dat iemand de software geïnstalleerd heeft en vervolgens is het aan de echte gebruikers om een goed wachtwoord te kiezen. Die gebruikers hebben de kennis niet of zitten niet hoog genoeg in de boom om dat wachtwoord te veranderen. Waarschijnlijk is dat wachtwoord na installatie zelden of nooit meer gebruikt. Zo overleeft een wachtwoord zonder dat iemand het in de gaten heeft.

Achteraf denk je, stom, maar als het diep in het systeem zit waar niemand ooit komt, dan snap ik het ook wel. Niet dat ik het goed praat, maar zo gaan die dingen.

[hqql]

Als je zo low tech en totaal oblivious voor security bent hoor je niet zomaar toegang tot zulke gegevens te hebben via een digitale weg. Daarbij, juist als het om dit soort systemen gaat zou toegang daartoe goed gemonitord (op zijn minst gelogd) moeten zijn incl. logins en op zijn minst last login en password reset info, zo'n wachtwoord zou helemaal niet moeten bestaan, dat dat wel gebeurt laat zien dat meerdere partijen hier een steek hebben laten vallen.

[willieverhoef]

En MFA verplicht zou je op dit soort systemen ook verwachten. Misschien zelf nog alleen bereikbaar met bepaalde IP's. Maar ja overheid houd zich meestal niet zelf aan hun advies.

[Honytawk]

Het is gewoon het default paswoord.
Default accounts zijn bedoeld om vervangen te worden vanaf het systeem op staat.
Dan is het dus puur de schuld van de gebruiker als die nog steeds online is.

[supersnathan94]

En de schuld van het systeem dat het geen wijziging afdwingt. In keycloak kun je ook gewoon een standaard wachtwoordje neerzetten in je realm, maar dan moet je die direct de eerste keer wijzigen als je het een beetje configureert.

[lDDQD]

Yup, iets met secure by design... Maar goed, dit gaat bijna zeker om legacy applicaties die gemaakt zijn in een tijd waarbij security optioneel was.

[Reactie gewijzigd door lDDQD op 12 oktober 2026 08:55]

[Vaevictis_]

Dan nog kun je een beveiliging ervoor zetten zodat toegang gecontroleerd mogelijk is. Met een pentest was dit zeker naar boven gekomen. Dat iets niet secure by design is is geen excuus om het niet te beveiligen.

[catfish]

Niet akkoord.
Dat bv mijn moeder of een kind niet beseft dat ze een veilig wachtwoord moeten kiezen snap ik, maar een IT professional weet donders goed dat dit nodig is.
En indien niet is het eigenlijk een amateur en zou hij/zij direct moeten worden ontslagen.

In de industrie zit de werkvloer vol met veiligheidsregels waar heel streng naar wordt gekeken, maar om de een of andere reden vinden sommigen bij IT dat ze slordig mogen zijn.

[LigeTRy]

Depends, de meeste leveranciersinstrucies die ik voorbij zie komen zeggen iets in de richting van:

- Voor implementatie hebben we een global admin acccount nodig, MFA is niet mogelijk.

Er zit verbetering in, maar vooral bij legacy partijen blijft het ellende

[MuddyMagical]

Voor zover ik weet voldoe je in NL dan niet aan de BIO en zou de applicatie dus niet gebruikt mogen worden voor dit soort gegevens.

[LigeTRy]

Ik doelde ook niet specifiek op overheid, maar dit soort baselines/beleid zijn helaas wel een van de weinige manieren om leveranciers op het matje te roepen en/of ze erop af te wijzen.

[StackMySwitchUp]

Soms levert zo'n partij een nicheproduct of maatwerk, dan kun je heel hard gaan dreigen, maar als je hele bedrijfsvoering ervan afhangt dan houdt iedereen zn mond dicht en wordt er zo nu en dan bij een audit een verzoek gedaan tot verbetering. Pas als er daadwerkelijk een lek is dan komt dit (verplicht) aan het licht, de partij die het pakket gemaakt heeft gaat failliet en weg is je support. Ik praat het absoluut niet goed want ik heb er een bloedhekel aan, maar dit is een scenario dat ik in de afgelopen 20 jaar al zo vaak voorbij heb zien komen..

[consolefreak]

Welkom in de wondere wereld van risicoacceptaties, moet wel het risico geïdentificeerd zijn natuurlijk.

[Pinkys Brain]

Als iedereen nou volhield dat voor koop mogelijkheid tot airgapped inbedrijfsname en werking noodzakelijk is en anders maar niet, was het snel over.

[Praetorian]

Als een handleiding in plaats van common sense dat soort wachtwoorden moet voorkomen voor privileged accounts is het voor een organisatie een dweilen met de kraan open.

[Uchy]

Maar, zelfs dan, iets met 2FA? Hoe kan het nou dat zo'n belangrijk systeem zulke basics niet ingericht heeft Droevig

[mcmd]

Nou ja, volgens mij zie je tegenwoordig op veel plekken dat makkelijke wachtwoorden niet meer gebruikt worden. Ook niet initieel. Denk bijvoorbeeld aan modems, waarbij je op de sticker het random wachtwoord terug vindt. Iets dergelijks zou normaal moeten zijn voor alle systemen, zeker voor systemen met persoonsgegevens.

[Miglow]

En dat is dan het bestaansrecht voor Post-it notitieblaadjes toch? 🤣 Ik zie ze in elk geval nog dagelijks bij bedrijven waar ik kom laden of lossen. Al dan niet met updates als ********12 *******13, etc

[supersnathan94]

Ook niet initieel. Denk bijvoorbeeld aan modems, waarbij je op de sticker het random wachtwoord terug vindt

Het probleem is, zelfs met een gegenereerd wachtwoord, als er iets wordt gebruikt van data van het device om het random password te genereren ben je alsnog F-ed als de berekening uitlekt. Zoals Thomson speedtouch een kleine 20 jaar geleden had.

[Arthur Tromp]

Je mag anders aannemen dat zo'n beheerder wel eens gebruik moet maken van dat admin account. Als je je dan nog steeds niet afvraagt of een wachtwoord als admin wel zo'n goed idee is, ben je als beheerder simpelweg geen knip voor de neus waard. Daar is geen handleiding tegen opgewassen, lijkt mij.

[Jedotw]

Nu is het zeker bij de overheid vaak het geval dat externe partijen voor de ontwikkeling zorgen en het vervolgens in de productiefase voor beheer over de schutting gooien. Inbeheername trajecten zijn vaak niet goed gespecificeerd en uitgevoerd, waardoor default inlog credentials niet aangepast worden.

[MaikelD]

Waarom zou je hiervoor een handleiding nodig hebben om zoiets aan te passen? Het zou voor elke beheerder common sense moeten zijn om de defaults aan te passen, incl nedenken hoe je toegang beperkt tot X systeem / VLAN.

Met dit soort verhalen vraag je gewoon de ellende en is het kwestie van tijd dat je aan de beurt bent. (omdat iemand dacht lekker makkelijk zo'n wachtwoord)

[beerten]

Gezond verstand niet verwarren met RTFM...

[FPSUsername]

Veel goed geschreven software dwingt je een ander wachtwoord in te stellen nadat je met de default credentials inlogt. Zo moeilijk kan het niet zijn en geen handleiding of common sense voor nodig.

[Yariva]

Hacken is strafbaar en dit is gewoon fout / illegaal wat deze persoon doet.

Maaaarrrr... Een wachtwoord zoals deze anno 2026? Wanneer je hersencellen al niet zeggen "goh dit is een slecht idee" zouden verplichte wachtwoord controles dit zeker moeten opvangen! En voor zo lang in een systeem data inzien en downloaden zonder dat er een belletje af gaat is al helemaal gek. Zeker voor bijvoorbeeld een beheerders account welke dit gedrag standaard niet vertoont.

Al met al een echte blamage wat mij betreft. Hopelijk zorgt dit incident voor verbeteringen maar de schade is voor de burgers inmiddels al geschied.

[Reactie gewijzigd door Yariva op 12 oktober 2026 08:50]

[Rataplan_]

Ik schaar dit niet echt onder hacken... meer gewoon een open deur inlopen. Wat hij daarna deed is gewoon strafbaar (hier althans).

[Reactie gewijzigd door Rataplan_ op 12 oktober 2026 08:57]

[vickypollard]

Ook een huis met open deur binnenlopen is strafbaar als jij niet gewenst bent

[Rataplan_]

En je snapt precies wat ik bedoel.

[vickypollard]

Nou ja, volgens mij bedoel je te zeggen dat je het niet strafbaar acht dat deze persoon het systeem binnen is gekomen, omdat je het geen hacken vindt (want pas wat hij daarna deed vind je strafbaar). Dat je het geen hacken vindt snap ik nog wel, maar strafbaar is het bij mijn weten wel gewoon.

[supersnathan94]

Het ligt geheel aan de intentie. Een open deur binnengaan die onder verdachte situaties open is, kijken of er iemand aanwezig is en in welke staat, is absoluut niet strafbaar. Ga jij naar binnen voor je volgende TV dan is het een heel ander verhaal.

Intentions matter.

[vickypollard]

... als jij niet gewenst bent

[supersnathan94]

Is niet voldoende om het strafbaar te maken. Pas als je duidelijk is gemaakt dat het niet gewenst is en je daarna niet binnen redelijke termijn weer buiten bent wel (art 138). Daarvoor is er nog gewoon sprake van een uitzondering door een rechtvaardigingsgrond.

Zo ook hier. "per ongeluk" (je bent dan wel redelijk op zoek) het systeem binnenkomen met 123456 als PW, vaststellen dat het daadwerkelijk een admin account is met live data, en dan authoriteiten op de hoogte brengen is niet strafbaar per se.

[mbbs1024]

Tja, wat klasseer je onder strafbaar, als AI bedrijven/systemen straffeloos mogen hacken ?

[The-Source]

Pure aanname maar zou ook als volgt gegaan kunnen zijn. Installatie software admin login 123456,
Volgende stap maak admin gebruiker aan: De admin stelt deze is met wel een complex wachtwoord.
Ga verder met configuratie.
etc etc
Ergens als tussendoor stap / laatste stap, disable configuratie account.
En als die stap wordt vergeten is natuurlijk gewoon slecht en had met pentesting al veel eerder naar voren moeten komen.

[Bas170]

Beginnersfout inderdaad, 132456 was een betere optie geweest.

[IStealYourGun]

Was het dan ooit wel een goed idee?

[tijsvb]

21 dagen is erg lang dat ze zoiets niet opmerken, daar zou je toch een melding van kunnen binnenkrijgen als ict? En ze hebben daar ook een erg goed wachtwoord belijd... 👍

[lDDQD]

Ze lijden zonder wachtwoordbeleid.

[cricque]

Sorry maar velen hebben geen "dedicted" cybersecurity team zitten dat alles gaat monitoren hoor. En al zeker niet bij overheden. Dat is set & forget ... Zeker omdat ze kunnen besparen op onderhoud. Het draait al jaren, waarom tijd en geld in steken.

En zo zijn 90% van de apps die je gebruikt. Alleen de echt grote doen wat moeite. De rest is pas = hey je bent gehacked, maak mij x bitcoin over. Dan pas weten ze dat, anders not going to happen

[StackMySwitchUp]

Zou je zeggen, maar dan moet je hele beleid en omgeving al afgestemd zijn op dataloss prevention. Dat is een pittig traject, en als je al met default wachtwoorden zit dan gok ik dat deze organisatie daar nog lang niet aan toe was.

[tijsvb]

Nee idd, maar in deze tijd is dat wel zuur...

[Sine]

Dark Helmet: So the combination is... one, two, three, four, five? That's the stupidest combination I've ever heard in my life! That's the kind of thing an idiot would have on his luggage!

- Spaceballs ... 1987!!

[Reactie gewijzigd door Sine op 12 oktober 2026 10:04]

[AnonymousGerbil]

Skroob: One, two, three, four, five? That's amazing! I've got the same combination on my luggage!

[rbr320]

"Prepare Spaceball One for immediate departure... and change the combination on my luggage!"

[all_by_myself]

Ach, ik werk inmiddels al 31 jaar in de ICT en neem van mij aan, de meeste IT afdelingen hebben heus wel in het snotje dat bepaalde zaken 'aandacht nodig hebben'. Probleem is het management daarboven (of daar weer boven) die alleen maar naar de kosten kijken en dan besluiten om zaken niet op te lossen.

Verantwoordelijkheid ligt dan op een ander niveau, tot frustratie van de daadwerkelijke ICT medewerkers.... die vervolgens wel de schuld krijgen als het fout gaat.

Het zou zoveel schelen als de managementlagen die dit soort veiligheidsissues 'downplayen' als het fout gaat op een zwarte lijst worden gezet om nooit meer aan het werk kunnen op zo'n positie. Dat maakt Nederland echt veiliger.

[MPAnnihilator]

Die management lagen lullen zich overal uit. Met NIS2 kan management persoonlijk verantwoordelijk worden gesteld, maar dat wil niet nog zeggen dat ze op een zwarte lijst komen als men in gebreke zou gesteld worden. Die zwarte lijst bestaat niet. Die hoppen als luizen gewoon naar het volgende mooie hoofd. Ook voor ICT'ers die ingebroken hebben bij banken bijv. bestaat geen zwarte lijst, die gaan gewoon weer aan de slag bij ... een andere ICT firma als ... jawel, security specialist...

Dit kan gewoon allemaal, triestig.

[Isnowiz]

Je mag toch hopen dat zoiets consequenties heeft voor het verkrijgen van een VOG of VGB...

[RefriedNoodle]

Paar weken terug installeerde ik een nieuwe printer bij m'n schoonouders, en was aangenaam verrast dat de webinterface out-of-the-box beveiligd was met een wachtwoord wat a) niet standaard was maar op een gedrukte sticker achterop het apparaat stond (en er aardig random uitzag), en b) direct gewijzigd moest worden.

Dus langzaam worden er gelukkig stappen gezet richting secure-by-default principes. Zal nog wel een paar jaar duren voordat elk IT-systeem zoiets ook heeft, maar je moet ergens beginnen.

[Malon]

Ik vraag me af waar de legale last nu valt in deze situatie, want dit is gewoon nalatigheid langs beide kanten.

Bij de dienst of de medewerker of beide, want het mogelijkmaken van dit wachtwoord, ook al is het een legacy systeem waar het mogelijk niet mogelijk is af te dwingen is niet ok, maar als medewerker/gebruiker van deze systemen zou je ook beter moeten weten.

[IStealYourGun]

Voor de verzekering kan dit wel een ding zijn, maar of je nu een makkelijk of moeilijk wachtwoord gebruikt, de uitkomst blijft het zelfde. Als je ongeoorloofd toegang hebt verschaft ben je in fout.

De persoon had het ook gewoon kunnen melden.

[Desiler]

Het plaatje bij het artikel had ik eerder verwacht bij een AD, niet bij een Tweakers.

[zwiep]

Alle artikels die ik heb gelezen rond dit incident draaien rond het zwakke wachtwoord en leggen de verantwoordelijkheid bij deze gebruiker. Wat ontbreekt in dit artikel is dat de hackers die gegevens gewoon uit een lek hebben geplukt en dan 21 dagen (let that sink in) gewoon hebben kunnen rondneuzen. Zelfs met een sterk wachtwoord was het resultaat hetzelfde geweest.
Als je met zoveel gevoelige data zit is Access Control echt geen bijzaak. Het laks omgaan met gevoelige data, data niet encrypteren, geen of slechte policies rond authorizatie, geen of gebrekkige audit logging en log analyse. Er zijn tig dingen die deze situaties kunnen voorkomen of mitigeren, de schuld bij de gebruiker met een zwak paswoord leggen is echter niet correct.