Russische staatshackers stelen Microsoft-inloggegevens via DNS-hacks van routers

Een Russische hackersgroep met overheidsbanden steelt wereldwijd inloggegevens voor Microsoft 365 door tienduizenden routers voor kleine en middelgrote bedrijven te hacken. Ze passen daarvoor DNS-instellingen aan om authenticatieverzoeken te onderscheppen.

Het Britse National Cyber Security Centre (NCSC) waarschuwt nu voor deze aanvallen. Het gaat om routers vooral van leveranciers TP-Link en MikroTik. In totaal zijn zeker 18.000 routers in 120 landen gecompromitteerd door de Russische hackersgroep APT28, melden securityonderzoekers van Black Lotus Labs.

Mogelijk ligt het totale aantal gehackte routers hoger, op 40.000 stuks. De onderzoekers zagen 40.000 IP-adressen die contact legden met DNS-servers van de aanvallers, maar het aantal DNS-verzoeken van die routers was relatief laag. Voor 18.000 IP-adressen waren de DNS-verzoeken hoog genoeg om met zekerheid te stellen dat daar sprake was van deze hackaanval.

Dit hacken van routers voor het mkb (midden- en kleinbedrijf) begon kleinschalig en gericht in mei vorig jaar. Dat veranderde daags nadat het Britse NCSC het rapport 'Authentic Antics' publiceerde over Windows-malware voor het stelen van inloggegevens voor Microsoft Office. Na die openbaarmaking van gebruikte malware schakelden de aanvallers van APT28 over naar DNS-omleiding via gehackte routers.

Doelwitten: overheidsorganisaties

Het NCSC-rapport verscheen op 5 augustus en op 6 augustus waren er al grootschalige hackaanvallen op routers. Telecombedrijf Lumen Technologies, waarvan Black Lotus Labs de securitytak is, detecteerde dit toen. De piek van deze hackaanvallen was in december vorig jaar. De voornaamste doelwitten waren overheidsorganisaties en aanbieders van e-maildiensten. De door de aanvallers gebruikte infrastructuur is offline gehaald in een gecoördineerde actie van Lumen, Microsoft, de FBI, het Amerikaanse ministerie van Justitie en diverse internationale partners.

Rusland. Bron: Ayhan Altun/Moment/Getty Images

Reacties (65)

[Prince]

Ik vraag me af hoe ze dit doen.
Eens dat aan een fout/ander IP terugsturen eenvoudig is, maar dan nog zou je met https beschermd moeten zijn, toch?

[Triblade_8472]

Als ik de bron bij Lumen lees, dan zit er meer achter dan doorsturen.

When targeted domains were requested by a user, the actor redirected traffic to an Attacker-in-the-Middle (AitM)node, where those credentials were harvested and exfiltrated.

Het is, naar wat ik lees, ook helemaal niet volledig onzichtbaar.

We assess that the actors employed the following methodology:
[...]
4. The actor ran a proxy service as the AitM that the end user was directed to via DNS. The only sign of this attack would be a pop-up warning about connecting to an untrusted source because of the “break and inspect".
5. If warnings were present and ignored or clicked through, the actor proxied requests to the legitimate services, collecting the data at the midpoint and collecting data associated with the targeted account by passing the valid OAuth token.

Ofwel, https werkt gewoon, de mens is de zwakke schakel doordat iemand akkoord is gegaan met bijvoorbeeld een redirect oid.

[R4gnax]

:: is aan het inloggen op een account ::
:: negeert een waarschuwing dat de site in kwestie niet vertrouwd is ::

Serieus? Sorry- maar dan moet je dus echt op digitale (her)opvoedcursus. Jezus ...

[moonlander]

Hoe vaak zie je mensen de cookie popup wegklikken? Met datzelfde gemak gaat dat ook met andere meldingen hoe serieus ze soms zijn.

[Annihilism]

Die cookie meldingen zijn dan ook echt bloedirritant en bereiken naar mijn idee het tegenovergestelde van waar ze voor bedoelt zijn. Als jij bij elke website die je aanklikt standaard zon melding krijgt waarbij je eerst helemaal naar onderen moet scrollen en van alles uit moet vinken en de "ACCEPT" button in koeienletters en groen is en de "decline" in lichtgrijs met witte achtergrond is, dan kan ik me voorstellen dat mensen dat niet gaan lezen en maar hetgeen aanklikken waardoor ze het snelst van het gezeik af zijn. Het is net zo idioot als die 300 paginas tellende voorwaarden die sommige installers je voorschotelen (een goede vat het samen in hooguit een paar alineas), dat gaat echt niemand lezen. Het probleem is daar dan ook niet domme gebruikers maar malafide websitebeheerders die er alles aan doen om toch jou data te verkrijgen. Een goede website heeft een "decline all" of iets vergelijkbaars die net zo duidelijk is als "agree". Gelukkig treden er regelmatig instanties op tegen deze wanpraktijken.

Een https fout is vaak overduidelijk en in een paar zinnen samengevat, en dan moet je ook nog op "proceed anyway" klikken. Dat is tenminste duidelijk, als je dat negeert zit het probleem inderdaad bij de gebruiker en mag je die ook rustig dom noemen.

[sympa]

Tja, moeten ze wat op vinden, op die lange voorwaarden. Misschien dat je de rekening van je jurist mag sturen naar ze, om ze te lezen en te beoordelen?

[drdelta]

Het is compleet stompzinnig dat zoiets als Do Not Track een stille dood sterft, en we voor iedere site aan moeten geven of we iets wel of niet willen.

En dan natuurlijk nog de complete cowboy wereld aangaande de stappen die soms nodig zijn om alleen "essentiele" cookies te accepteren.

[Commendatore]

Deze waarschuwingen zijn meestal iets moeilijker weg te klikken.

[Triblade_8472]

Ik snap je helemaal, maar de meeste mensen zijn meldingsmoe. Net als met cookies. Gewoon next-next en door. Anders krijg je niks meer voor elkaar als je alles moet gaan lezen, doorgronden en bewuste keuzes maken.

We (IT) moeten leven met mitigatie en vulnerability fixes, de mens kan je simpelweg niet vertrouwen. Laat staan gebruikers.


Toevallig van ConsentFix gehoord? Een variant van ClickFix. Dit doet mij daar erg aan denken namelijk.

Zie ook: https://pushsecurity.com/blog/consentfix

[Daoka]

Ik zie een vrijwilliger die mijn vader dit dus wel wil leren. Ik zal je alvast wat tips geven om te beginnen.

Tip 1: Gebruik geen moeilijke woorden. Browsen is onbekend. In plaats van zeg programma waarmee je op internet gaat. Url en http(s) misschien dat de dit ooit wel eens gezien heeft maar waarschijnlijk geen idee wat het is. Ook kan hij geen Engels.

Tip 2: Hou zijn hand vast. Met andere woorden precies zeggen wat die moet doen. Niet open de instellingen. Nee precies als in zie je in de rechter bovenhoek de 3 puntjes? Met de linker muisknop mag je daar 1 keer op klikken en loslaten. In die menu staat bijna onderaan instellingen, nogmaals 1 keer links klikken.

Tip 3: Hij kan goed napraten zonder het echt te snappen. Grote kans dat hij dus zegt dat hij het snapt maar dus niet echt.

Disclaimer: Psychiater, Psycholoog of andere vormen van therapie of je mentale stabiliteit verbeteren worden niet vergoed.

[R4gnax]

De waarschuwingen die browsers hiervoor geven zijn geen simpele [ok maar ga toch maar door] popups.
Het zijn schermvullende popups die in menselijk leesbare taal en grootletterschrift weergeven: "LET OP! Veiligheidsprobleem! Niet doorgaan!" waarbij je op diverse knoppen moet klikken om verder naar beneden te spitten en door technische details heen moet gaan om 'toch door te gaan.'

Wat jouw vader in zo'n geval moet doen, is wat de browser al duidelijk zegt:
NIET DOORGAAN.

Venster sluiten, klaar.

[jozuf]

Speculatief allemaal maar daar had HSTS dan kunnen helpen. Dan kan je niet door klikken en de certificaat fout negeren

[Triblade_8472]

Als ik daar over lees gaat dat meer over http --> https doorverwijzingen, niet tussen sites/(sub) domeinen.

[jozuf]

HSTS zorgt er o.a. Voor dat certs die niet uitgegeven zijn voor de FQDN of op een andere manier invalid is, niet werkt.

Public key pinning kan ook en biedt nog meer zekerheid als het over de certs gaat.

[Triblade_8472]

Maar wat nou als je doorverwijst naar een andere site, die wel goed is? Dat is wat er lijkt te gebeuren.

Zoals ms.com -> ms.hack -> ms.com

Pinning lijkt steeds meer uitgefaseerd te worden omdat het meer ellende oplevert dan voordeel. Iig voor beheerders. Dan nog, de tussensite is gewoon goed dus wat doet het hiervoor?

[Niema]

Grote browsers als Chrome en Edge passen wel degelijk pinning toe voor Microsoft domeinen als office 365. Lijkt me logisch als office 365 dat ook deed. Iemand doorverwijzen van ms.com naar ms.hack kan logischerwijs alleen als je al op de (neppe) ms.com bent geweest. Ik zie niet in waarom een router jouw kan redirecten naar nieuwe websites, tenzij https. Hsts had kunnen helpen. Die waarschuwing klik je ook niet zomaar weg, maar schijnt onhandig te zijn voor beheer. We hebben meermaals gezien hoe grote bedrijven hun ssl-certificaten laten lopen. Doe dat bij hsts en veel success dingen weer goed te krijgen. Misschien is het meer gebruikers proof, maar hsts is niet bestendig tegen incompetentie van de andere kant op meerdere vlakken

[R4gnax]

De initiële request naar ms.com moet met de juiste certificaatinformatie op de proppen komen om ingeladen en verwerkt te worden. Ook als het om een 301 of 302 redirect richting een ander domein gaat. Dat wil zeggen dat als verzoeken naar ms.com middels een DNS MitM naar een ander IP adres als bedoeld verstuurd worden, dat andere IP adres nog steeds geen verzoeken voor ms.com over HTTPS kan beantwoorden omdat ze niet over de privè-sleutel v/h benodigde certificaat beschikken. Ze kunnen e.e.a. niet correct signeren en dus zal een browser de respons weigeren te verwerken en een dikke vette waarschuwing tonen.


De exploit zit er in dat Microsoft voor Office applicaties, in tegenstelling tot wat browsers keurig veilig afhandelen, de validiteit v/h certificaat voor ms.com niet controleert - met de intentie dat dat het 'makkelijk' maakt om office ook op third-party domeinen makkelijk te laten verbinden en werken, zoals bij grote enterprises die eigen portals opgezet hebben in hun infrastructuur en alles aan hun eigen interne domeinen vast willen hangen, waar ms.com niet ms.com is en ook niet company.ms.com maar eerder ms.company.com - wat met een certificaat wat enkel geldig is voor *.ms.com niet gaat werken.

Dat zorgt er natuurlijk ook voor dat als er een DNS MitM in effect is en ms.com ergens anders heen wijst, de servers die 'ergens anders' staan - vrolijk een HTTPS respons terug kunnen sturen die ondertekend is met welk certificaat dan ook - want Office zal niet valideren of het domein v/h certificaat wel overeenkomt met wat er toegestaan is.

En daar heb je je veiligheidslek/-fout.


E.e.a. heeft natuurlijk een heel simpele oplossing, en dat is dat je voor een federated log-in oplossing de login-pagina's gewoon ALTIJD via het officiële domein benadert en NOOIT via het bedrijfspecifieke domein. Maar ja- jaren van legacy houtje-touwtje ductape code, etc. etc. ...

Er is tenslotte een reden dat er als meme gehanteerd wordt dat het Office team het 'strafkamp' team van Microsoft is, waar je heen gedemoveerd wordt als je het teveel verkloot hebt. Niets in Office producten werkt zoals het zou horen te werken, en alles is een overgecompliceerde janboel.

[Reactie gewijzigd door R4gnax op 9 april 2026 00:08]

[bilgy_no1]

Maar hoe zit het met het hacken van die routers? Daar zit kennelijk de kwetsbaarheid die vervolgens wordt uitgebuit. Maar een router heeft ook een beheerdersaccount en wachtwoord. Of staan die allemaal nog op standaard "admin" + "welcome"??? Dat lijkt me ook nogal sterk...

Ik vind het artikel maar warrig geschreven wat dat betreft.

Ik heb nu thuis een TP Link Mesh systeem (hoewel die niet de routing doet, want dat zit bij de provider router). Moet ik nu bijv daar iets aan doen?

[Noxious]

Omdat het blijkbaar vooral om overheidsinstanties gaat zou ik denken dat ze meer toegang hebben dan enkel dat en de lokale/interne CA misbruiken; anders is het inderdaad niet erg duidelijk hoe dit mogelijk is.

[zx9r_mario]

De DNS resolvers zullen waarschijnlijk zijn aangepast naar die van de hackers. Ipv het originele IP van microsoft.com wordt het IP van de phishing site doorgegeven. Met DNSSEC had dit voorkomen kunnen worden. Dit is een Kaminsky-aanval, oftewel DNS cache poisoning, is tenslotte al sinds 2008 bekend.

[Sorcerer8472]

SSL-certificaten zoals voor https gelden juist voor de hostname.

Enige dat ik me kan voorstellen is dat er een redirect is via http, maar ik dacht dat de meeste moderne browsers dan waarschuwingen zouden geven? (en sowieso geen onbeveiligde content laden als je expliciet https:// gebruikt).

[Mellow Jack]

Het is toch een redirect naar een ander https domein? Je doet een inlog bij login.microsoftonline.com en daarna stuur je een request naar bijv portal.office.com. Ben wel benieuwd wat er gebeurd als je die tweede vervangt door een ander IP. In theorie zou je browser dan geen verbinding maken en je cookies versturen

[Snow_King]

Nee, je kan niet even in een SSL-chain een redirect stoppen. Ik snap dus ook niet helemaal hoe dit werkt

[lenwar]

Meerdere namen achter een certificaat, of meerdere certificaten. Het is tenslotte een nieuwe sessie. Token-informatie delen kan gewoon aan de achterkant worden gedaan. Dat staat los van namen.

[Snow_King]

Huh? Nee. Je kan niet zo maar even meerdere namen in een certificaat krijgen. En je kan al helemaal niet aan een certificaat komen waar microsoft.com in staat, daar is TLS juist op ontworpen.

[lenwar]

https://www.ssllabs.com/ssltest/analyze.html?d=microsoft.com&s=150.171.109.149

kijk is naar de lijst van de Alternative names. (Een browser accepteert dit certificaat voor al die namen.)

https://www.ssllabs.com/ssltest/analyze.html?d=yarp.dot.net&s=20.231.239.246&latest

yarp.dot.net heeft ook een certificaat met de CN van microsoft.com.

Edit: uiteraard is Microsoft de eigenaar van die domeinen.


Edit2: Letsencrypt ondersteund maximaal 100 domeinen per certificaat:
https://letsencrypt.org/docs/rate-limits/#new-orders-per-account

UCC doet er maximaal 500 per certificaat:
https://www.ssl.com/nl/certificaten/ucc/

[Reactie gewijzigd door lenwar op 8 april 2026 19:31]

[lenwar]

https://www.ssllabs.com/ssltest/analyze.html?d=portal.office.com&s=150.171.73.13&hideResults=on

Sowieso hebben portal.office.com en diverse andere login-domeinen hetzelfde TLS-certificaat. Maar ze kunnen aan de achterkant sessietokens delen.

[xorinzor]

Maar als die server geen geldig certificaat voor de betreffende hostname (in jouw voorbeeld login.microsoftonline.com) heeft, dan komt de TLS handshake niet tot stand.

als alles alleen op IP basis was heeft HTTPS natuurlijk totaal geen zin, dan kan iedereen alsnog alles onderscheppen.

[faim]

IP adressen hebben geen (geldige) certificaten.

[Blokker_1999]

In de SAN van een certificaat kan je perfect een IP address opnemen ipv DNS naam, en dan is dat certificaat gewoon geldig voor dat IP adres.

[Jaldea]

Dan moet de CA die het certificaat uitgeeft dus dat SAN hebben goedgekeurd. Of als je een ssl spoof doet, de CA erkend zijn door die browser, zo niet heeft de persoon die dan doorklikt op "ga door op onveilige pagina" de misstap begaan.

[GertMenkel]

IP-adres-certificaten bestaan al veel langer (maar waren lang ongebruikt want wie betaalt daar nu voor). et's Encrypt biedt ze inmiddels al meer dan een half jaar gratis aan: https://community.letsencrypt.org/t/upcoming-changes-to-let-s-encrypt-certificates/243873

Die worden voor veel protocollen niet gebruikt, maar het kan wel.

Voor DNS-records heb je altijd nog DNSSEC, maar dat is buiten een paar Europese landen eigenlijk niet gebruikt.

[Reactie gewijzigd door GertMenkel op 8 april 2026 16:23]

[Alfa1970]

Een grote misvatting van DNSSEc is dat het veilig is.
Ten eerste er wordt niets encrypted verzonden. Ook bij DNSSec worden DNS records in "plain text" verzonden.
Het enige dat DNSSec doet is een hash aanmaken die gecontroleerd kan worden.
Maar aangezien de hackers de volledige controle over de DNS server hebben is het kinderspel om de correcte hashes te genereren.
Gezien het om staats gelieerde hackers betreft bieden DNSSEC en HTTPS geen enkele vorm van veiligheid, want die hebben toegang tot registrars die in de algemene trust chain staan.

[Triblade_8472]

Nee? https://www.askssl.com/ssl-certificate-for-an-ip-address/

Het is extreem ongebruikelijk, dat klopt, maar je laat het nu lijken alsof het niet kan, maar het is zeker wel mogelijk!

[FLA NL]

Quad9 en Cloudflare dns is dat juist handig voor dns over https, daar kan je ook dit gebruiken:
https://9.9.9.9/dns-query
https://1.1.1.1/dns-query

Hierdoor hoef je geen Bootstrap dns te gebruiken.

[Reactie gewijzigd door FLA NL op 8 april 2026 23:07]

[djwice]

Op vallend. Ik heb in 2023 of eerder dit risico al aangekaart bij de Microsoft account manager en hun tech architect die verantwoordelijk was voor de uitrol bij de bank/verzekeraar waar ik werkte.

Incl. mitigaties.
Het werd toen afgedaan als niet realistisch scenario en men vond deze bewust onveilige inrichting noodzakelijk. Organisaties kunnen daardoor op Microsoft domeinnamen hun eigen niet door Microsoft ondertekende certificaten uitgeven. Gevolg is dus dat elke man in the middle dat dus kan zonder enig alarm.

[Blokker_1999]

Dan mag je gerust wat meer details geven over wat voor scenario jij toen voor ogen had. Want na het artikel hier 3x gelezen te hebben snap ik nog altijd geen bal van hoe ze het gedaan zouden hebben. Ja, je kan met DNS het verkeer naar een URL omleiden naar een andere server, maar je moet nog wel altijd een geldig, vertrouwd certificaat hebben naar die URL, iets wat moeilijker en moeilijker wordt bijvoorbeeld.

[Triblade_8472]

Lees mn stukje hieronder: Triblade_8472 in 'Russische staatshackers stelen Microsoft-inlogs via DNS-hacks van routers'

Maar het komt erop neer dat de gebruiker een onveilige redirect moet accepteren. Het is dus niet puur en alleen DNS.

The actor ran a proxy service as the AitM that the end user was directed to via DNS. The only sign of this attack would be a pop-up warning about connecting to an untrusted source because of the “break and inspect".

[djwice]

En dat laatste is niet nodig bij Microsoft het accepteert elk certificaat dat zegt geautoriseerde te zijn voor dat domein en er zit geen restrictie op certificaat of dns provider.

En corporate clients zijn gewend dat ook te doen voor dat domein.
En hoeveel corporate providers zijn er van interne certificaten? Noem maar een aantal bekende firewall / security providers. Dus zelfs met je "Zero Trust" netwerk wordt dit vertrouwd.

Geen DNSSec dus what's there to check..

[Reactie gewijzigd door djwice op 8 april 2026 16:56]

[Scriptkid]

En dat laatste is niet nodig bij Microsoft

dit is wel een hele blund statement want dat is binnen MS eco systeem ook gewoon nodig,

Edge geeft alle waarschuwingen als je geen vertrouwde root cetificaten gebruikt en inloggen op een niet azure domein met azure credentials is iets wat je zelf zou moeten zien.

[djwice]

Kijk nog maar eens goed naar je certificaat als je inlogt binnen een organisatie op M365, bij een behoorlijk aantal komt die niet van Microsoft.

[Scriptkid]

Dat hoeft toch ook niet, dat is trusted root, er zijn een 30 tal root servers die trusted zijn zolang de site maar een cert hebben van een van die.

En die certs zijn authenticated door de domain owner.

Een doorverwijzonv naar een andere site kan alleen als je untrusted redirects toestaat maar dat geeft normaal veel popups.

Enige manjer om dit te fake is door al controle op het device te hebben en een trusted root toegevoegd te hebben.

[SmokingSig]

Jup, een dikke 75 % van alle malware / cyber attacks beginnen bij DNS.

[StackMySwitchUp]

Heb je dit zwart op wit? Kan nog een leuke zaak worden dan..

[djwice]

Als de werkgever de e-mails heeft bewaard na mijn vertrek hebben ze dat potentieel. Maar wat heb je aan mosterd na de maaltijd.

Sterker nog als Microsoft het nu dicht zet werken veel omgevingen niet meer.

[Reactie gewijzigd door djwice op 8 april 2026 16:47]

[striper]

Heb je hier een link voor met meer informatie, want dit klinkt wel heel bijzonder?

[Prince]

Kan je technisch zeggen wat er exact gebeurd?
Dus ok, ze passen DNS aan en je krijgt een ander IP terug.
Maar daarna? Wat is er net onveilig en wat is er net gebeurd?

[djwice]

In het kort: als je de Microsoft omgeving door de internet.nl test haalt, is niet alles groen.

Zorg dat al je omgevingen, van al je SaaS en inter-netwerk (en liefst ook intern) altijd alles in die test groen heeft en geen resterende tips.

[Scriptkid]

Kun je hier details van geven want volgensmijn klopt je statement niet.

Als je goede statement heb ga ik me zelf hier hard voor maken.

#MSFT

[Pendora]

Wordt straks in de VS nog makkelijker met hun verbod voor buitenlandse routers.

[DigitalExorcist]

Dan bén je al zo ver dat je Mikrotik gebruikt, waarom heb je dan je management interface open aan het internet hangen...??

[djwice]

Omdat de beheerder de IT-er om de hoek is en die er op afstand bij wil. Maar wat dacht je van: gewoon gecompromitteerd zonderdat de admin publiek geconfigureerd was: firmware issue?

[Reactie gewijzigd door djwice op 8 april 2026 17:02]

[rko4u]

Opvallend dat het artikel over microsoft gaat, terwijl het werkelijke probleem is dat de routers van TP-Link en MikroTik dus niet veilig blijken te zijn.

[Bux666]

Dat veranderde daags nadat het Britse NCSC het rapport 'Authentic Antics' publiceerde over Windows-malware voor het stelen van inloggegevens voor Microsoft Office.

Ik gebruik al jaren Linux (Mint) en LibreOffice en ben ver weg van Microsoft producten. Kan iemand mij vertellen waarom Microsoft inloggegevens wil als je een document wil typen of een sheet wil vullen?

[euchromatic]

Aan alle Office documenten op een persoonlijke Onedrive kan je met meerdere personen tegelijk samenwerken. De inloggegevens zijn nodig om te checken of iemand die rechten wél heeft.

[_trickster_]

Dit wordt voornamelijk gebruikt voor de Licentie Check voor Office gebruik & online opslag via Onedrive

[Scriptkid]

Omdat daar de live services aan hangen die je hele data governance onder controle houden,

Het hele Purview stuk voor labeling, DLP, IRM , en rechten uit delen + cloud based AI , proving, weather location services, etc zit er allemaal aan vast.

[Triblade_8472]

Wat wil je nou toevoegen aan dit artikel? Microsoft bashen? Geweldige bijdrage, chapeau.

Als je nog een serieus antwoord wil: wat denk je van licentie checks? Als je een bedrijf hebt die licenties dynamisch wil hebben en elk moment wil kunnen op- en afschalen, dan is dit (dus) online. Iets anders waarom MS je ingelogd wil hebben is bijvoorbeeld online opslag. En tegenwoordig gebruiken steeds meer mensen Copilot. (even wat je daarvan vindt daargelaten)

Een betere vraag zou zijn: als je online diensten gebruikt, hoe zou je dit doen zonder inloggegevens?

[djwice]

Also je Copilot noemt voor M365:
nieuws: Microsoft wijzigt Copilot voor 365: dataverwerking kan ineens buiten ...

[Bux666]

Wat wil je nou toevoegen aan dit artikel? Microsoft bashen? Geweldige bijdrage, chapeau.

Wat een botte reactie zeg! 😟 Ik wilde niets toevoegen aan het artikel maar een vraag erover stellen omdat ik niet snapte waarom je voor een Word document moet inloggen. Niet iedereen werkt met 'corporate' oplossingen zoals jij noemt.

De laatste keer dat ik Windows en Office gebruikte, werkte dat met licentie sleutels die je eenmalig in moest voeren. Dat kan goed 15 jaar geleden zijn. Daarna ben ik overgestapt naar Linux en daar heb ik niet te maken met licentie checks...

[Reactie gewijzigd door Bux666 op 8 april 2026 17:26]

[ibmpc]

Dus Windows Hello for Business en FIDO2 keys zijn niet veilig meer met deze DNS hacks? Of gaat het alleen om non-attested passkeys die niet meer veilig zijn?

[Reactie gewijzigd door ibmpc op 8 april 2026 18:18]

[sympa]

Heeft dit te maken met de al te ruime vormgeefmogelijkheden voor het loginscherm? Of is dat gat ondertussen gesloten?

Put was dat je een ander domein nam, en via CSS en zelfs eigen fonts het te hacken domein kon nabouwen.

[kuurtjes]

Het gaat hier niet over de specifieke exploit maar over de man-in-the-middle aanval die wordt uitgevoerd na dat de router gehackt is.