Home   2026-08-03 17:31:33

←

Hackers stelen Microsoft 365-inloggegevens via hotelwifi

Original article

Cybercriminelen veranderen de DNS-instellingen op wifiapparaten van hotels en conferentiecentra om gebruikers om te leiden naar valse Microsoft 365-inlogpagina's. Daarmee hopen ze toegang te krijgen tot de accounts van die gebruikers.

Beveiligingsbedrijf ReliaQuest ontdekte de campagne, die al sinds juni loopt, meldt Bleeping Computer. ReliaQuest trof gecompromitteerde wifigateways aan in diverse Amerikaanse steden, maar ook in andere landen. Het gaat onder meer om India en Saoedi-Arabië. Organisaties gebruiken de apparaten bijvoorbeeld voor zakelijke evenementen. Aanvallers kunnen hiermee dus toegang krijgen tot gevoelige zakelijke informatie, communicatie en privédocumenten.

Zo werkt de aanval

Hoe de aanvallers toegang krijgen tot de wifiapparaten, is onduidelijk. Eenmaal binnen, passen ze de DNS-instellingen van de gateway aan om legitieme domeinen naar hun eigen infrastructuur te laten verwijzen. Gebruikers die deze inlogportalen proberen te bezoeken, komen vervolgens op de phishingpagina's terecht. Daar stelen de aanvallers hun inloggegevens. Ze gebruiken in ieder geval vier domeinen voor de inlogportalen: m365-owa.com, owa-ms365.com, ms365-device.com en ms365-live.com.

Bij sommige aanvallen gebruiken cybercriminelen een valse Microsoft-prompt voor devicecodeauthenticatie om de Microsoft 365-omgeving binnen te dringen. De valse prompt vraagt je om een apparaat te verifiëren. Daarvoor vul je de getoonde code in op je smartphone of een ander apparaat en keur je het inloggen goed. In legitieme gevallen kun je zo inloggen op het account. Bij de aanval keur je echter de sessie van de cybercriminelen goed, zodat zij op het account kunnen inloggen.

Aanvallers probeerden in een derde van de onderzochte gevallen ook misbruik te maken van Web Proxy Auto-Discovery, of WPAD. Dat is een protocol waarmee Windows-systemen en browsers automatisch proxyconfiguratiebestanden op een netwerk kunnen vinden. In theorie kunnen de aanvallers daarmee webverkeer omleiden via een proxy die ze zelf beheren. Maar de onderzoekers kunnen niet bevestigen of deze aanvallen zijn geslaagd.

Beveiligingsadviezen

De onderzoekers benadrukken dat het gebruik van publieke DNS-services de aanval niet voorkomt. De gateway vervalst verzoeken al voordat ze bij de bedoelde resolver aankomen.

In plaats daarvan adviseert ReliaQuest om altijd een vpn die al het verkeer versleutelt te gebruiken. Daarnaast moet versleutelde DNS in strikte modus ingezet worden, waarbij alleen geauthenticeerde DNS-servers gebruikt worden. Ook raadt het bedrijf aan om WPAD uit te schakelen en logs op verdachte activiteiten te controleren. Tot slot adviseert het bedrijf om de devicecodeflow in Microsoft Entra ID uit te schakelen wanneer die niet nodig is.

Hack/Security. Bron: C Nokel/iStock/Getty Images
Bron: C Nokel/iStock/Getty Images

Door Eveline Meijer

Nieuwsredacteur

Feedback • 27-07-2026 12:11
137 • submitter: demianmonteverd

27-07-2026 • 12:11

137

Submitter: demianmonteverd

Lees meer

Reacties (137)

Ik mis een beetje achtergrond over een belangrijk detail van deze aanval. Waar gebeurt de redirect, en waarom slaagt deze?

https://login.microsoftonline.com/ gebruikt HSTS. Dit houdt in dat browsers weigeren de pagina over http te openen, alleen https zal werken. Een normale redirect gaat je dus niet lukken zonder het certificaat voor login.microsoftonline.com te hebben.

Dat ze DNS overnemen is leuk, maar zou hier geen verschil in moeten maken. Welk ip adres deze DNS servers ook terug-geven, ze kunnen nooit* het juiste certificaat sturen.
offtopic:
*Als de hackers geldige microsoft certificaten hebben is er wel heel veel meer aan de hand
Stop je iemand met een enigszins moderne browser in zo'n hotelkamer, gaat deze hack in de beschreven vorm gewoon niet werken.

Er moet dus ook iets anders aan de hand zijn waardoor de gebruikers op de nep site komen. Het lijkt mij voor de hand liggender dat de hackers bijvoorbeeld een captive portal window (zo'n soort scherm) gebruiken om de nep-pagina te serveren... die worden wél over http geserveerd...

Edit: Dit artikel geeft wat meer informatie
The only visible sign of fraud for the victim would have been a warning for an invalid TLS certificate, which could have easily been dismissed. However, ignoring the alert gave the threat actor access to the victim's unencrypted internet communication.
Niet zo heel spannend dus eigenlijk. Een beetje browser zou absoluut moeten weigeren deze pagina's te tonen. zie dit voorbeeld
You cannot visit <xxxx> right now becaue this website uses HSTS. Network errors and attacks are usually temporary, so this page will probably work later.
Hier kan je niet per ongeluk doorheen klikken.

[Reactie gewijzigd door svane op 27 juli 2026 13:15]

Volgens het oorspronkelijke bericht wordt je ook niet naar de URL gestuurd, maar geeft de DNS een redirect af naar een ander domein dat eigendom is van de aanvaller en waar ze dus hun eigen certificaat op hebben staan.

Dit is een van de aanvallen waar bank applicaties zich tegen wapenen door het certificaat van de andere kant altijd te vergelijken met goedgekeurde certificaten en als die niet matched de verbinding te blokkeren.

[Reactie gewijzigd door SunnieNL op 27 juli 2026 13:25]

Volgens het oorspronkelijke bericht wordt je ook niet naar de URL gestuurd, maar geeft de DNS een redirect af naar een ander domein dat eigendom is van de aanvaller en waar ze dus hun eigen certificaat op hebben staan.
Dat is nog steeds geen duidelijke verklaring. Redirects bestaan niet echt op DNS niveau, tenzij je een CNAME record een redirect noemt, maar dat is niet echt relevant als het op web browsers aankomt.

Stel een gebruiker gaat naar https://www.microsoft.com/ , de aanvaller heeft een CNAME record www.microsoft.com -> www.myevilphishingserver.com . Dat levert geen browser-redirect op. Het enige wat gebeurd is dat de resolver dan het IP-adres van www.myevilphishingserver.com opvraagt. De browser zal vervolgens contact opnemen met dat IP adres een een request doen voor www.microsoft.com . Tot zoverre kan de aanvaller nog meespelen door op de HTTPS server een virtual host www.microsoft.com te maken. Maar daarna loopt het spaak, de aanvaller moet een valide certificaat voor www.microsoft.com gebruiken, maar heeft dit niet. De browser zal een foutmelding geven dat de site niet veilig is. Het is onwaarschijnlijk dat de gebruiker per ongeluk naar http://www.microsoft.com/ kan gaan wegens HSTS. Bovendien staan Microsoft hosts in de HSTS preload list.

Ik gok dat het eerder iets is als:
  • De klikt aan de TLS foutmelding te negeren, ook al is dat bij sommige browsers best wat gedoe. Tsja, als je dat soort fouten begaat ben je op heel veel manieren to compromitteren.
  • Ze hebben de captive portal gebruikt om mensen met een HTTP redirect naar een neppe Microsoft site te sturen.

[Reactie gewijzigd door danieldk op 27 juli 2026 14:12]

Ik vond het ook allemaal een raar verhaal.

In het gelinkte artikel staat dit beschreven:

Er waren een paar niet-bestaande ms-domeinen geregistreerd. Er werden redirects geforceerd via transparante proxies en DNS-hacks. Je browser komt dus bij één van die echt-uitziende-domeinen van Microsoft ipv de echte sites.

Dus je gaat van 'legitieme-microsoft-dns-dienst.com' naar 'nepsite-die-lijkt-op-microsoft.com'. Deze redirect gebeurd voordat er een http(s)-sessie is opgestart, dus hsts gaat hier niks voor doen.

Wat hier dus lijkt te gebeuren is:

microsoftlogin.com --> 1.2.3.4 (malafide server 1)
Die doet een 302 redirect (dit gebeurd VOORDAT er een volledige https-handshake gebeurd en daarmee dus voordat hsts wat gaat doen) naar lijkt-op-microsoftlogin.com.
En vanaf daar gewoon een standaard https-sessie naar de diensten van de hackers.
Dus je gaat van 'legitieme-microsoft-dns-dienst.com' naar 'nepsite-die-lijkt-op-microsoft.com'. Deze redirect gebeurd voordat er een http(s)-sessie is opgestart, dus hsts gaat hier niks voor doen.
HSTS zorgt er alleen voor dat de connectie altijd geupgraded wordt van HTTP naar HTTPS.

Als een site via HTTPS benaderd wordt, kun je geen redirect doen voordat een HTTPS sessie is opgezet. De client zal altijd eerst een sessie doen en de redirect header zal over het encrypted kanaal gaan.

Anders zou HTTPS ook vrij nutteloos zijn, als je zomaar headers zou kunnen gaan manipuleren als een MITM.
Wat hier dus lijkt te gebeuren is:

microsoftlogin.com --> 1.2.3.4 (malafide server 1)
Die doet een 302 redirect (dit gebeurd VOORDAT er een volledige https-handshake gebeurd en daarmee dus voordat hsts wat gaat doen)
HSTS is hardcoded voor Microsoft domeinen in alle mainstream browsers. Verder is HSTS helemaal niet relevant. Het is niet mogelijk een HTTPS server te laten redirected voor de handshake. De TLS handshake is het eerste wat er gebeurt na een TCP SYN + ACK. Van een autoriteit:

https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
Als ik op mijn thuisnetwerk in mijn router's dns resolver een domeinnaam verwijs naar een willekeurig ip adres (lokaal of online) gaat dat toch prima? Het dns-verzoek komt dan niet eens in de buurt van de de dns-records van dat hsts-domein.

Zo werken toch ook de advertentieblockers: door de advertentiedomeinen naar een black hole te verwijzen?

Jij gaat er vanuit dat ze de dns records van de site ofzo hebben veranderd. Dat is niet aan de orde, het verkeer wordt al omgeleid voordat het publieke dns-servers gebruikt.
Als ik op mijn thuisnetwerk in mijn router's dns resolver een domeinnaam verwijs naar een willekeurig ip adres (lokaal of online) gaat dat toch prima? Het dns-verzoek komt dan niet eens in de buurt van de de dns-records van dat hsts-domein.
HSTS heeft weinig met DNS records records te maken, het vertelt de browser alleen dat HTTP altijd opgewaardeerd moet worden naar HTTPS voor een gegeven host. Ja, je kunt www.microsoft.com naar een ander IP adres laten wijzen, maar dan gaat je browser een foutmelding geven omdat die site geen geldige certificaat opdient.
Zo werken toch ook de advertentieblockers: door de advertentiedomeinen naar een black hole te verwijzen?
Browser blockers schakelen blokkereren gewoon de fetch. Als je DNS blockers bedoelt, ja, soort van, maar die resolven gewoonlijk naar niet-legitieme IP adressen als 0.0.0.0. Dus dat faalt al bij het maken van een verbinding. Dus stel je browser verbindt met https://ad.doubleclick.net , eerst vraagt de browser ad.doubleclick.net te resolven. Dat resulteert in 0.0.0.0. De browser kan geen TCP socket openen naar dat adres, einde verhaal. Als je je DNS blocker zou configureren ad.doubleclick.net naar een ander IP adres te sturen dan die van Google en op die machine een HTTPS server op zou zetten met een vhost ad.doubleclick.net, dan zal de request alsnog falen aan de browserkant, omdat jij geen certificaat hebt met de hostnaam ad.doubleclick.net dat door een certificaatautoriteit getekend is.
Jij gaat er vanuit dat ze de dns records van de site ofzo hebben veranderd. Dat is niet aan de orde, het verkeer wordt al omgeleid voordat het publieke dns-servers gebruikt.
Nee, daar ga ik helemaal niet van uit. DNS A/AAAA records vormen een simpel adresboek, hostnaam naar IP adres. Er is geen fundamenteel verschil tussen het hacken van de autoratieve DNS om microsoft.com naar 1.2.3.4 te laten verwijzen, of een gecompromiteerde DNS server via DHCP uit te delen die microsoft.com naar 1.2.3.4 verwijst. In beide gevallen resolved je systeem naar 1.2.3.4.

Ik denk dat heel erg veel mensen in de verschillende draadjes twee denkfouten maken:
  • Een de hostnaam bestaat niet alleen op DNS-niveau. Als dat het geval was, zou een webserver slechts één hostnaam kunnen serveren. Een hostnaam bestaat zowel op DNS-niveau als op HTTP niveau. De hostnaam wordt namelijk ook gestuurd in de header van een HTTP request.
  • HTTPS is fundamenteel anders dan HTTP. Als een client een HTTPS request doet op www.microsoft.com, dan zit de hostnaam in de request header, zodat de server van Microsoft (of van de aanvaller) weet welke site (vhost) opgediend moet worden. Echter, bij het opzetten van een HTTPS verbinding vereist de browser ook dat dit wordt gedaan met een certificaat waarin de naam www.microsoft.com (of een wildcard) staat en dat het certificaat is getekend door een autoriteit. En een autoriteit gaat een aanvaller geen certificaat voor www.microsoft.com uitgeven. Als een certificaatautoriteit die fout zou maken is de kans groot dat ze zichzelf kunnen gaan opdoeken. Anders gezegd: HTTPS versleutelt niet alleen de verbinding, maar verifieert ook dat de sever waarmee de verbinding gemaakt word, geautoriseerd is verkeer voor de gegeven hostnaam af te handelen.
HSTS is de kers op de taart en zorgt ervoor dat als een gebruiker bijv. http://www.microsoft.com/ tikt (let op, geen s), dat de verbinding opgewaardeerd wordt naar HTTPS.

[Reactie gewijzigd door danieldk op 27 juli 2026 15:56]

Ok... Mooi verhaal, maar volgens mij ga je een stap te ver: bij de originele AAAA en CNAME records daar komen deze slachtoffers niet eens uit. Het misleiden zit daarvoor al.

Als ik microsoft.com afvang met een eigen DNS server en die doorverwijs naar een eigen server met malafide website, desnoods zonder https, werkt dat gewoon. Er is slechts een kleine groep mensen die mogelijk zelf https:// intypt voordat ze naar een website gaan. En volgens mij maakt het een dns-server niet uit of het http/https is, dat komt pas bij het DNS-record van de echte website aan bod.

Dus je kunt zelfs naar een proxy doorverwijzen en een ander certificaat op je malafide website zetten.
Als ik microsoft.com afvang met een eigen DNS server en die doorverwijs naar een eigen server met malafide website, desnoods zonder https, werkt dat gewoon.
Nope, om twee redenen. Ten eerste geven de meeste van dit soort sites een HSTS header. Dit verteld de browser voor een langere periode (bijvoorbeeld een jaar) elke HTTP connectie naar die site te upgraden naar HTTPS.

Wat als een persoon nog nooit in die browser een site zou hebben bezocht (onwaarschijnlijk)? Dan kan het theoretisch werken. Ware het niet dat alle mainstream browser een gigantische voorgedefinieerde lijst van hosts hebben waar HSTS altijd toegepast moet worden. En ja, Microsoft zit daar ook in.

Ik moedig mensen aan, aangezien dit Tweakers is, zelf deze aanval uit te proberen. Gebruik een DNS server waarop je microsoft.com naar je eigen webserver stuurt en kijk wat er gebeurt.
Done. Heb Microsoft.com geridect naar mijn inlogpagina van mijn nas via http. In Nginx Proxy Manager geregeld. En ik heb via NextDNS ingevoerd dat microsoft.com moet antwoorden: ip adres en poort van mijn nas.

Werkt hier gewoon. Zonder waarschuwingen.

https://imgur.com/a/6Z42VEN

[Reactie gewijzigd door MulMonkey op 27 juli 2026 21:30]

Interessant, dat zou niet mogen gebeuren en gebeurt hier niet. Als je een Chrome-gebaseerde browser hebt, zou je eens naar

about://net-internals#hsts

kunnen gaan en dan een query op microsoft.com kunnen doen?

Nog een vraag: hoe kun je in NextDNS een poort voor je NAS geven? DNS doet verder niets met poorten.

[Reactie gewijzigd door danieldk op 27 juli 2026 23:13]

Oh, ik legde het verkeerd uit, ik denk doordat ik een deel herschreven had. Ik heb in Nginx Proxy Manager (NPM) het lokale ip-adres + poort van mijn NAS doorgegeven. Gekoppeld aan microsoft.com.

En ik heb in NextDNS slechts het ip-adres van NPM gezet.

Dus als ik surf naar microsoft.com gaat er een DNS verzoek naar de externe server van NextDNS. Die vertaalt dat rechtstreeks naar het ip-adres van NPM. En NPM stuurt een binnenkomend verzoek op poort 80 van microsoft.com door naar mijn NAS.
Heel erg interessant, dan gaat er ergens iets fout in de browser security. Ik heb www.microsoft.com (via onze Unifi router, tevens DNS server) laten verwijzen naar een machine met HTTP en HTTPS. En zowel in Chrome als Safari, wordt een http request meteen geupgraded naar https en faalt dan wegens een incorrect certificaat:

https://drive.proton.me/urls/FWGT26DWN0#HEe3y3lbjBTP

Ik ben erg nieuwsgierig waarom het bij jou niet werkt. Hier meer informatie over hoe het zou moeten werken:

https://www.chromium.org/hsts/

En ik zie microsoft ook in de voorgedefinieerde lijst:

https://source.chromium.org/chromium/chromium/src/+/main:net/http/transport_security_state_static.json

[Reactie gewijzigd door danieldk op 28 juli 2026 08:54]

Als ik microsoft.com afvang met een eigen DNS server en die doorverwijs naar een eigen server met malafide website, desnoods zonder https, werkt dat gewoon.
Probeer maar eens! Hier is mijn poging:

In m'n /etc/host heb ik een ander ip adres aan mijn bank gehangen. Net zoals bij deze hack wordt de dns query direct afgevangen; ik krijg een 'verkeerd' ip-adres terug.

Vervolgens ga ik naar http://mijn.ing.nl. (zonder http), en wat zie ik? Deze foutmeldingen

Het werkt simpelweg niet. De browser heeft ooit een keer gezien dat HSTS aanstaat, het gevolg: weigering om de site over http te laden.
mijn.ing.nl has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can't add an exception to visit this site.
Heel duidelijk: de browser weigert. De site over HTTPS laden lukt ook niet, want de aanvaller heeft niet het juiste certificaat.
Dus je kunt zelfs naar een proxy doorverwijzen en een ander certificaat op je malafide website zetten.
En die proxy heeft het verkeerde certificaat, en je browser zal dus weigeren dit te laten zien. Zoals als de screenshots te zien is. Ik zou zeggen, probeer het ook een keer :)
Zet een DNS server in de uitgegeven DHCP-info. En geef malicious IP als men naar ms wil.
Zoals ik in mijn comment al uitleg, gaat dat niet werken. Als een gebruiker naar https://www.microsoft.com/ gaat, kan je wel een vals IP adres geven, maar de browser gaat nog steeds controleren dat het certificaat dat gebruikt word de naam www.microsoft.com heeft. Een certificaat-authoriteit gaat je geen certificaat met www.microsoft.com geven, tenzij je Microsoft bent. (Of je de authoriteit gehacked hebt, maar dan heeft de wereld grotere problemen dan alleen wat hotel-WiFis met bedriegende DNS servers.)
Een vangpagina op de wifi? Of een redirect bij bezoek van iets wat je wel kent.

[Reactie gewijzigd door Krommetenen op 28 juli 2026 08:20]

Dus als ik het lees is dit een typische man-in-the-middle attack?

Goed om te lezen dat een VPN hiertegen helpt, want ik zit regelmatig in een hotel en dan gebruik ik ook veelal VPN om gebruik te maken van het hotelnetwerk.
Goed om te lezen dat een VPN hiertegen helpt, want ik zit regelmatig in een hotel en dan gebruik ik ook veelal VPN om gebruik te maken van het hotelnetwerk.
Een goede password manager of FIDO2 gaat ook helpen. In beide gevallen wordt bij respectievelijk het invullen van een wachtwoord, danwel het doen van een challenge-response, het TLS domein geverifieerd. In beide gevallen is er geen match zijn, want een aanvaller kan niet zomaar een certificaat krijgen voor (*.)microsoft.com. Een password manager zal dan simpelweg geen opties bieden en een FIDO2 challenge-response zal nergens toe leiden omdat de TLS SNI niet bekend is.

Als je met de hand wachtwoorden gaat kopiëren en plakken is het natuurlijk wel game over.

Bescherming met een VPN zitten overigens wel wat haken en ogen aan, want veel VPNs zijn zo geconfigureerd dat niet al het verkeer via de VPN gaan (bijv. split tunneling) en er zitten regelmatig bugs/gebreken in implementaties.

[Reactie gewijzigd door danieldk op 27 juli 2026 13:54]

Entra global secure acces route eigenlijk 100% van je traffic via azure.

Daar worden dit soort aanvallen direct omgeleid ondat ze er niet komen of gedetecteerd als je er handmatig heen gaat.
Alleen gaat de gemiddelde gebruiker dan dus gewoon zijn wachtwoord kopiëren uit zijn zakelijke password manager. Daarom zetten wij voor Microsoft account in op passwordless met Windows Hello. Gebruiker krijgt zn wachtwoord niet eens.

[Reactie gewijzigd door matroosoft op 28 juli 2026 00:24]

Bescherming met een VPN zitten overigens wel wat haken en ogen aan, want veel VPNs zijn zo geconfigureerd dat niet al het verkeer via de VPN gaan (bijv. split tunneling) en er zitten regelmatig bugs/gebreken in implementaties.
Met een willekeurige consumer-grade VPN tunnel heb je vaak nog wel een risico.

...maar de meeste enterprise VPN oplossingen gebruiken *wel* meestal designated DNS-servers (die nodig zijn om verkeer naar interne resources goed te kunnen routen).

Daarmee los je indirect wel je issue op.
Dus als ik het lees is dit een typische man-in-the-middle attack? nope, het is DNS hijacking en phishing.

Bij MITM proxyen ze het verkeer en doen ze een decrypt en reencrypt naar legitiem endpoint.

In dit geval intercepten ze het DNS request en sturen die door naar een andere host met een fake backend.

[Reactie gewijzigd door Razwer op 27 juli 2026 13:05]

De onderzoekers benadrukken dat het gebruik van publieke DNS-services de aanval niet voorkomt. De gateway vervalst verzoeken al voordat ze bij de bedoelde resolver aankomen.
Maar deze opmerking maakt het vreemd. Want als ik een publieke DNS service hardcoded in mijn verbindingsinstellingen zet, dan gaan ze die verzoeken naar mijn idee niet vervalst krijgen. Immers, mijn laptop gaat gewoon rechtstreeks naar de publieke DNS. De gateway doet daar normaal niets mee.

Mijn laptop staat op wifi en ethernet gewoon hardcoded naar NextDNS. Dit gaat af en toe fout als ik door een portal heen moet voor goedkeuring, maar over algemeen zorgt nextdns ervoor dat ook dat wel goed wordt afgehandeld. Op de telefoon gebeurd eigenlijk hetzelfde omdat ik ook daar een private dns heb ingevuld.
Dat is helemaal afhankelijk van of je DNS over TLS (DoT) of DNS over HTTPS (DoH) gebruikt. Als je dat niet ingesteld hebt, zijn alle dns verzoeken niet versleuteld en verlaten je WAN op poort 53.

Het is dodelijk eenvoudig om alle uitgaande DNS-verzoeken op die poort af te vangen en te redirecten naar een andere DNS-server die de beheerder/hacker van de router instelt. (En alle andere DNS-servers te blokkeren).

DoT is iets moeilijker, maar vertrekt doorgaans alsnog over een vaste poort: 853. Maar dan wel versleuteld.

Het moeilijkst te onderscheppen is DoH. Dat gebruikt poort 443. En is dus niet te blokkeren/lezen/af te vangen. DoT presteert doorgaans met minder latency dan DoH.
Wat ze bedoelen is dat normale DNS (dus als je bijv. geen DoH of DoT gebruikt), requests en antwoorden niet gesigned zijn. Dus een AP of router kan gewoon de pakketen lezen en z'n eigen antwoord teruggeven.
Er staat ook gateway niet dns.

Dus dat suggeseerdt dat ze bijvoorbeeld 8.8.8.8 dus naar de malifide site routeren omdat het pub internet is. De een hard coded route is de gateway
Als ze de gateway overnemen dan hoeven ze de DNS niet aan te passen en is een security probleem op de devices zelfs groter dan dat ze alleen admin credentials hebben en de dns bij de dhcp scope aanpassen.
Grootste nadeel hiervan is dat je apparaten binnen je interne netwerk niet meer bereikbaar zijn via de hostname.
Daar helpt een VPN wel degelijk tegen, maar dan moet die wel al werken voordat je verbinding maakt met het netwerk. Dus al aanzetten voordat je verbinding maakt met de wifi.
ik antwoordde op het stukje: "Dus als ik het lees is dit een typische man-in-the-middle attack?". ik heb het bericht bewerkt en verduidelijkt.
Dit is niet altijd waar. Ook met een VPN verbinding is er nog steeds een kans op zo'n DNS hijack. Ook kun je niet een VPN verbinden voordat je met andere netwerk verbindt: zo werkt het niet.
tenzij de dns requests nooit aankomen bij de dns server die opgegeven is in je dhcp set. als je ál het verkeer forceert over je vpn met static dns settings dan ziet de dns server van de hacker nooit enige requests. wel even zelf aanzetten het vinkje om internetverkeer te blokkeren als er geen vpn actief is.
Als je je VPN-tunnel opzet voordat je naar de betreffende site gaat, en je dns-verzoeken ook door die tunnel gaan. Dan wel natuurlijk.

In dit specifieke geval lijkt het erop dat er alleen een paar Microsoft-domeinen worden omgeleidt. Dus als, al je verkeer door de tunnel gaat (inclusief je DNS vanaf het moment dat de tunnel is geactiveerd), dan kom je niet meer bij de malafide DNS-server uit.
En evil portal op een pineapple kan dat heel goed
een vpn werkt daadwerkelijk alleen als je ál je verkeer via de vpn pusht, dat is in heel veel gevallen niet zo en moet je zelf aanzetten. in die vpn instellingen zet je dan ook welke dns server je vpn tunnel gebruikt waardoor er geen mitm kan plaatsvinden.
Inderdaad, dus geen split-tunneling zoals veel (bedrijfs-) VPN's aanbieden. Dan wordt er alsnog zaken afgevangen.
Probleem met vpn is wel dat veel hotels een inloggen pagina hebben, die krijg je met een VPN niet te zien!
VPN helpt inderdaad, maar dan nog kan het soms gewoon wenselijker zijn om helemaal niet het risico van een vreemd wifi punt te nemen. Gewoon je eigen mobiele hotspot opzetten op je telefoon.
Ik denk dat een custom dns in dit geval ook zou helpen, want je gebruikt dan niet de default dns server van de modem.
Goos Ja een vpn werkt maar de wifi in een hotel is vaak erg langzaam en met een vpn wordt het alleen maar erger.Als je normaal al 10mbps hebt hou je 4 over.
Hoe werkt dat dan? Je surft naar www.microsoft.com en krijgt een malicious IP terug van de geinfecteerde GW. Vervolgens connecteert je laptop daar dan mee, maar deze malicious webserver heeft toch geen geldig SSL certificaat voor microsoft.com? Dan krijg je toch een waarschuwing als gebruiker?
Als ik het juist begrijp is de DNS aangepast om te directen (via een CNAME record bijvoorbeeld) naar een van de malafide domeinen dat ze zelf hosten. Daar kunnen ze dus perfect hun eigen SSL certificat(en) voor hebben en zal de gebruiker dus geen waarschuwing in zijn/haar browser krijgen.

Edit : Dit klopt dus niet. De web browser zal verifiëren of de gevraagde site (bv. microsoft.com) certificaat klopt, ook al heeft de aanvaller een geldig certificaat voor het malafide domein, zal deze niet geldig zijn voor microsoft.com. Excuses voor de foute informatie.

[Reactie gewijzigd door Kepslok op 27 juli 2026 13:06]

Je kan pas een redirect toen na het tot stand komen van de TLS sessie; dat werkt dus al niet.
Exact, je moet eerst langs SSL van Microsoft en dan is er nog HSTS. Dus je verbinding stopt gewoon zodra je die SSL error krijgt, je kunt niet doorklikken of negeren.

Beetje raar verhaal dit. De bron verduidelijkt dit ook niet.
Het is dan ook helemaal de bedoeling niet om de login pages van Microsoft te omzeilen. Ze passen bv. de captive portal aan waardoor je op hun legit maar fake domein met certificaat beland. Ondertussen vraagt de attacker zelf bij Microsoft een code aan om in te loggen.


Attacker forward de code, user vult hem in en klaar is kees.
Precies, de hack is helemaal niet zo ingewikkeld. Waar ik echter niemand over zie praten is hoe Microsoft omgaat met getroffen mensen?

Van wat ik hoor zal Microsoft voornamelijk reageren door Microsoft accounts die hacked zijn te blokkeren. Alles wat aan je Microsoft account hangt ben je dan kwijt: OneDrive, email, al je games en toegang tot je eigen lokale computer.

Mensen die in deze situatie terecht komen hebben vaak enorme moeite om het met Microsoft weer voor elkaar te krijgen om hun account te herstellen, als het ze al lukt. Zie bijvoorbeeld dit artikel:
Microsoft Deletes User's 25-Year-Old Account With Thousands Spent on Games and His Son's Baby Pictures After It Was Hacked
Daarom altijd backuppen. En liefst eigen domein waar je de MX kunt aanpassen.
Idd als ze de captive portal aanpassen is het een stuk makkelijker.
Dat hoeft toch helemaal niet?

Het is zeker niet verstandig, en veel browsers zullen automatisch al HTTPS proberen en helemaal als je recent (als in, afgelopen jaar denk ik) op dat apparaat met die browser al eerder een verbinding met Microsoft website hebt gehad (en dus een HSTS header hebt ontvangen).

Maar, volgens mij kan je prima een 301 (perma redirect) terugsturen via poort 80 (plain-text HTTP) voordat je iemand doorstuurt naar poort 443 (HTTPS). Dat is wel super bad practice, altijd eerst HTTPS redirect doen.

@Noxious fair enough. Dat denk ik ook wel ja. Maar ging mij meer om het principe dat het altijd moet.

[Reactie gewijzigd door keranoz op 27 juli 2026 15:53]

Je mag er wel vanuit gaan dat de Microsoft websites in vrijwel iedere browser zijn preloaded in HSTS lijsten, dus je maakt altijd verbinding op 443.
Een CNAME record doet geen redirect op HTTP niveau, maar is meer een alias voor een andere domeinnaam.
Klopt, verkeerde woordkeuze. Heb het aangepast.
Nee, zo werkt een CNAME dus niet. Een CNAME is geen magische HTTP-redirect waarmee je ineens op een ander domein terechtkomt. De browser blijft gewoon https://office.com bezoeken en verwacht dus óók een certificaat dat geldig is voor office.com.

Dat de aanvaller een geldig certificaat voor super-legitieme-microsoft-login.ru heeft, is daarbij volledig irrelevant. De browser vergelijkt het certificaat namelijk met de hostnaam in de adresbalk, niet met het domein waar DNS uiteindelijk naar verwijst. Anders zou HTTPS ook vrij weinig nut hebben.

Een aanval kan uiteraard wel werken wanneer het slachtoffer daadwerkelijk naar een lookalike-domein wordt doorgestuurd, bijvoorbeeld via een captive portal, een HTTP-pagina of social engineering. Maar “CNAME aanpassen en een eigen certificaat gebruiken” is technisch gewoon onjuist.

Dit is overigens vrij eenvoudig zelf te testen voordat je het met zoveel overtuiging opschrijft.

[Reactie gewijzigd door whiner op 27 juli 2026 12:56]

Wat je zegt klopt inderdaad, ik was fout. De URL blijft hetzelfde in de browser dus de site zal een geldig certificaat voor de gevraagde hostname (microsoft.com, office.com, ..) moeten voorleggen, wat het uiteraard niet kan.

[Reactie gewijzigd door Kepslok op 27 juli 2026 13:46]

Snap inderdaad ook niet hoe dit zou moeten werken, helemaal met HSTS headers (die voor grote domeinen zelfs al preloaded zijn in browsers) zou het niet eens meer mogelijk moeten zijn om zonder TLS er mee te verbinden.

Hoe je dan zonder certificaat een succesvolle redirect kan doen snap ik niet, zit er ergens in de login chain een domein die hijacked kan worden op deze manier die niet HSTS preloaded is en ook niet die header al cached heeft van een vorig bezoek?
als je gaat vissen weet je ook niet welke vis er gaat bijten. Als er vissen zijn die niet beter weten dan dat je worm met haak voedsel is, dan zullen ze bijten als ze honger hebben. :+
Waarschijnlijk kom je op de hotel login pagina voor wifi en staan daar wat hyperlinks naar m365. Met de fake urls.

Kan ok zijn dat de hotel pagina vraag een root cert te instaleren.

Kan ook nog een browser in browser mimic zijn.


Best wel wat oplossingen te bedenken
Is het niet eerder dat de captive portal een knop toont met iets als "log je in met microsoft" en dan een fake ms login pagina toont?
In dit artikel staat het net even iets beter uitgelegd met wat meer technische diepgang over oa de gebruikte domeinen en IOC's.

https://reliaquest.com/blog/threat-spotlight-dns-poisoning-tactics-expand-to-hospitality/
Ik snap alleen niet helemaal hoe dit werkt met SSL? Als je naar office.com gaat om in te loggen moet je toch eerst door een SSL stap heen voor je een redirect kan krijgen, toch?
Ik heb ooit een test gedaan in een gecontroleerde omgeving en met toestemming.

Het gekke is dat je het ssl probleem kunt negeren omdat veel gebruikers gewoon door klikken :-(

Je kunt ook een url rewrite doen om naar een ander domein te gaan waar je wel een geldig certificaat hebt. Zoals de domeinen die in het artikel worden genoemd. Gebruiker merkt dit eigenlijk nooit op. Tools als evilginx tunnelen dan netjes door naar de echte m365 servers zodat alles er netjes uit ziet en de gebruiker ook mfa afhandeling krijgt. Als de authenticatie gelukt is steelt de aanvaller het auth token.

[Reactie gewijzigd door rajackar op 27 juli 2026 12:36]

Het gekke is dat je het ssl probleem kunt negeren omdat veel gebruikers gewoon door klikken
Dit is helemaal niet gek. Zet je adblocker is uit. En ga met een browser in een 'InPrivate' ding is het internet op. Je wordt helemaal krankjorem van alle popups.

Website intikken:
- Cookie popup
- Nieuwsbrief popup
- We willen je pushberichten sturen popup
- Laatste update van de dienst popup
- Aanbieding popup

Ik snap prima dat iedereen klakkeloos meldingen aan het wegklikken is.
Al die dingen zijn natuurlijk prima tegen te gaan, maar voor Jan Doedel die z'n apparaat gewoon wil gebruiken, is dat allicht minder makkelijk weggelegd.
Dit is helemaal niet gek. Zet je adblocker is uit.
No, I don't think I will.
Terecht :D - Het is internet een stuk stommer zonder adblocker.
Pushberichten kan je uitzetten in Firefox als je die tenminste gebruikt:

dom.webnotifications.enabled dubbelclick naar false
Zoals ik al schreef kun je al dingen prima tegengaan. Ook in Chrome/Edge/blablabla kun je het uitzetten. Maar dan moet je dat wel doen. Als iemand dat niet doet om reden xyz ('snapt ie niet?'), dan krijg je dus popup-verzoeken.
Ik snap jouw punt helemaal. Ik word ook stapelgek van het web zonder blockers.

Maar deze melding staat vaak knalrood in beeld en dan moet je twee keer doorklikken om bewust naar een onveilige site te gaan. Ik weet het, gebruikers doen domme dingen maar damn......
Ik vermoed dat ze in DNS een redirect doen via CNAME records naar een domein wat ze wel beheren (zoals de genoemde).

Ah nee dat zou de URL niet aanpassen dus dat werkt niet. Recentelijk was er een soortgelijk bericht waarbij iemand (en ik) dezelfde vraag had. Maar daar kwam ook niet echt een antwoord op.

Gevonden: Prince in 'Russische staatshackers stelen Microsoft-inloggegevens via DNS-hacks van routers'

[Reactie gewijzigd door Noxious op 27 juli 2026 12:24]

Zoals ik het zie, waren dit dan geen https-sites, en lieten de betreffende clients daar geen waarschuwing van zien.
Zoals meerdere mensen al stellen: Hoe komen ze langs SSL?

En dit laat maar weer zien: DNSSEC is ook belangrijk! Heel jammer dat dat niet gemeld wordt. Goed werkende DNSSEC zou dit ook al op hebben gelost.
Nou nee. De client controleert standaard geen DNSSEC. Als de DNS-server die gebruikt werd (dus de malafide DNS-server) geen DNSSEC controles doet, dan houdt het gewoon op.

Wat hier wel had geholpen is DoH/DoT/DoQ. De client verbindt dan niet met de juiste server, en detecteerd dit direct.
Een client kan zeker wel DNSSEC afdwingen en falen als het niet ingesteld staat. Want microsoft.com heeft wel DNSSEC.

Maar goed, security is niet 1 ding, het is meerdere lagen.

Ik vind het alleen het antwoord: VPN nogal simpel. Je hebt geen VPN nodig om je hier tegen te beschermen.
Uiteraard 'kunnen' ze het wel. Alles dat iets met DNS doet kan het. In de praktijk zien we echter dat ze dit meestal delegeren naar de ingestelde DNS-server. Het probleem is alleen dat die nou net malafide bleek. ;)
Ik weet niet hoe je er bij komt dat microsoft.com DNSSEC gebruikt, maar dat is niet zo. Zie: https://dnsviz.net/d/microsoft.com/dnssec/
Er is geen DS-record in .com voor microsoft.com en dus geen DNSSEC.

Overigens heeft office.com wel DNSSEC, maar je noemde specifiek microsoft.com.

[Reactie gewijzigd door alm op 29 juli 2026 14:31]

Daar was ik eigenlijk wel vanuit gegaan. Dat is wel zonde dan van Microsoft
Het domein moet dan wel DNSSEC ingeschakeld hebben, en dat is zeker niet altijd het geval. En je eigen resolver moet geschikt zijn voor DNSSEC-checks. Geen idee of Microsoft-domeinen DNSSEC gebruiken.

[Reactie gewijzigd door ray0755 op 27 juli 2026 12:47]

Ze doen precies hetzelfde als bij de vele phishing campagnes denk ik. Ze zetter een een proxy tussen, vergelijkbaar met deze: https://evilginx.com/. Ook de devicecodeflow aanval is eentje de veelvuldig voorkomt en waar voor wordt gewaarschuwd.

Via phishing komen die aanvallen veelvuldig voor en zijn ze helaas gemeengoed. Ik snap het advies van die VPN dan ook helemaal niet. Ja, dat voorkomt deze specifieke manier van aanvallen. Maar als je iets als Passkeys uitrolt, of hardware tokens, dan voorkom je alle varianten van die aanval. Ook voor het blokkeren van devicecodeflow heb je geen VPN nodig en kun je die veel beter met Conditional Access blokkeren. Dan blokkeer je het voor alle gevallen en niet alleen voor die beperkte uitzondering voor een publiek wifi.

[Reactie gewijzigd door BytePhantomX op 27 juli 2026 12:52]

Bijkomend probleem hier is dat Microsoft zelf ook niet al te consistent is met de domeinen die ze gebruiken voor inlogpagina's. (Bijvoorbeeld microsoftonline.com en nog wel een paar andere.)

Dat kan voor extra verwarring zorgen over wat een legitieme Microsoft-inlogpagina is en wat niet.

[Reactie gewijzigd door Commendatore op 27 juli 2026 12:26]

Ik heb er vrij weinig verstand van, maar is het inderdaad niet zo simpel als forwarden naar een domeinnaam die er heel erg op lijkt? Als de pagina er uit ziet, zoals je verwacht, ga je niet meer checken of de domeinnaam nog hetzelfde is. En daar vul je doodleuk je inlogggegevens in.

[Reactie gewijzigd door pegagus op 27 juli 2026 13:09]

In 2026 gewoon je inloggegevens invullen is dan ook nogal... dom? Dit is al heel erg lang een opgelost probleem, password managers matchen de opgeslagen URL. FIDO2 token/passkey challenge-response werkt niet met een onjuiste TLS SNI.

Heel erg veel leken zullen dit ongetwijfeld doen. Maar als bedrijven nog geen password managers en/of FIDO2 authenticatie gebruiken, dan is het vragen om problemen.
Tsja, ik heb ook een password manager. Maar die is niet altijd gekoppeld aan exact de juiste domeinnaam. Zeker bij Microsoft is dat nog al een ding, als ze te pas en te onpas verschillende domeinnamen gebruiken waarbij je met hetzelfde Office365 account moet inloggen (het artikel noemt er al 4). En het helpt ook niet meer dat mijn Microsoft-account en mijn Office-account twee verschillende accounts zijn. Het ene is een outlook.com adres, het andere is een onmicrosofft.com adres. En ik weet niet of ze het al eens gefixed hebben, maar twee verschillende websites voor office365 prive en office365 zakelijk werkt ook niet mee.

Tweetrapsverificatie kan helpen, al is dat ook wel weer te spoofen, vermoed ik.
Tweetrapsverificatie kan helpen, al is dat ook wel weer te spoofen, vermoed ik.
TOTP e.d., ja. FIDO2, nee (is gekeyed op TLS SNI in het certificaat).

Ik zie het punt van Microsoft's gebruik van domeinen. Maar als dit op een onvertrouwde WiFi gebeurt, zou ik toch twee keer nadenken en gewoon het domein proberen dat in m'n password manager staat.

[Reactie gewijzigd door danieldk op 27 juli 2026 16:00]

Alsof er ook maar iemand is, die daar op let :). Allicht een paar mensen op dit platform, maar verder toch echt niet. Als je goed oplet zie je al snel vele redirects van a naar b terug naar a dan naar c, enz, voordat je inlogt.
Hoe de aanvallers toegang krijgen tot de wifiapparaten, is onduidelijk.
Is dat niet vaak vanwege het feit dat die wifi-apparaten vaak standaard logingegevens gebruiken? En dan met name de wat oudere apparaten.
En als dat al wel veranderd is, zit helaas nog vaak een hardcoded account in. En als dat er niet is, kun je er vast een CVE voor vinden.
Hoe zit dit precies. Ik gebruik onbekende Wifi-netwerken nooit. Is het zo dat mobiele netwerk altijd de veiligste optie zijn?
Ja, gewoon altijd (mits mogelijk) via je mobiele netwerk. Persoonlijk zit ik nooit op een onbekend wifi netwerk, beveiligd of niet.
De kans is groot dat dit via de Captive Portal check gaat van de verschillende besturingsystemen.

Wikipedia: Captive portal

Apple bijvoorbeeld probeert of er internet verbinding is door met HTTP verbinding te maken met http://captive.apple.com/hotspot-detect.html. Als je de DNS server controleert kan je dus deze laten verwijzen naar een webserver waarop je een redirect doet naar welke pagina je maar wilt, dus bijvoorbeeld de phishing pagina's.

Captive Portal mechaniek werkt normaliter om de voorwaarden te accepteren.
Is er een goede reden waarom Apple dit niet over https doet?

Als deze checks inderdaad http only zijn dan is dit de enige plausible verklaring wat mij betreft.

[Reactie gewijzigd door Noxious op 27 juli 2026 12:40]

Is er een goede reden waarom Apple dit niet over https doet?
Zeker! Ook Android en Windows gebruiken http links

http://www.msftconnecttest.com/connecttest.txt / http://connectivitycheck.gstatic.com/generate_204

Publieke hotspots willen jou redirecten naar hun inlog pagina (voorbeeld). Om dat te doen, moeten ze jouw http request onderscheppen. Als je dit onderscheppen probeert met https verkeer, krijg je een flinke waarschuwing om je oren. De browser krijgt namelijk niet het juiste certificaat terug.

Dat is de reden dat je OS eerst een request doet naar een onbeveiligde server. Als deze request een normaal antwoord teruggeeft, heb je (blijkbaar) al vrij toegang tot het internet.

Mocht je een redirect terugkrijgen, dan staat het OS deze redirect expres toe, en zie je het inlogscherm. Dit is gebruiksvriendelijk, maar geeft de hotspot wel de optie om iets te laten zien wat niet de bedoeling is.
Check - dat klinkt logisch, thanks!
Volgens mij voorkom je dit soort aanvallen grotendeels met Conditional Access (o.a. beschikbaar in Microsoft 365 Business Premium). Bijvoorbeeld door af te dwingen dat toegang tot Microsoft 365 alleen mogelijk is vanaf 'compliant devices'. Alleen MFA is tegenwoordig niet meer voldoende; zie bijvoorbeeld ook aanvallen met Evilginx.
Tuurlijk is dit waar en goed om te doen. Maar dan ga je weer naar beleid. Komt die CEO, met z'n privélaptop. Want de bedrijfslaptop heeft ie niet altijd mee, en op privé wil hij ook z'n mail kunnen checken. Of die middelmanagement manager, met hetzelfde verhaal. Nou, dan zien we gewoon vaak dat er bij IT geen ballen bestaan, en zwichten ze onder de druk van managers die IT "lastig" vinden, want het werkt niet zoals zij willen. Met goede redenen, maar hierdoor vinden nog steeds dit soort hacks plaats.

Om te kunnen reageren moet je ingelogd zijn