Security News Hackers hijack hotel Wi-Fi DNS to steal Microsoft 365 accounts

[Parkinsond]

Content source

https://www.bleepingcomputer.com/news/security/hackers-hijack-hotel-wi-fi-dns-to-steal-microsoft-365-accounts/

It is unclear how initial access to the Wi-Fi appliances was gained, but ReliaQuest says the threat actor could have exploited weakly protected, exposed management interfaces (e.g., SSH, SNMP, web admin dashboards) or vulnerabilities.

The researchers also emphasized that using public DNS servers such as Google’s 8.8.8.8 does not prevent this attack, as the gateway forges the plain-text requests before they reach the intended resolver.

Hackers hijack hotel Wi-Fi DNS to steal Microsoft 365 accounts

Hackers are changing the DNS settings on Wi-Fi devices at hotels and conference centers to redirect users to fake Microsoft 365 login pages.

www.bleepingcomputer.com

 

[Marko :)]

This is great example why you shouldn't use DNS servers provided by network and instead use third-party DNS service (or your own).

Using DNS servers that support DNSSEC standard and through DoH, DoT or DoQ would prevent this kind of attack. And as a bonus, it would unblock websites blocked on DNS-level.

 

[Parkinsond]

Using DNS servers that support DNSSEC standard and through DoH, DoT or DoQ would prevent this kind of attack

You mean if he/she was using for example ControlD DoH instead of Google dns, they would not be vulnerable?

 

[Wrecker4923]

Using DNS servers that support DNSSEC standard and through DoH, DoT or DoQ would prevent this kind of attack.

The source research article also mentions not configuring plain-text fallbacks for the DNS resolutions.

The source article doesn't mention how the redirection manages to defeat the HTTPS certificate (for the authentication landing page). But perhaps configuring the browser with strict HTTPS connection would have defeated this redirection as well.

Overall, checking the domain you are about to provide credentials for would have worked too. So does usage of a password manager extension that you don't override, or a passkey authentication that you get careful about when the site claims it needs to drop back to passwords and such.

 

[Parkinsond]

The source research article also mentions not configuring plain-text fallbacks for the DNS resolutions.

The source article doesn't mention how the redirection manages to defeat the HTTPS certificate (for the authentication landing page). But perhaps configuring the browser with strict HTTPS connection would have defeated this redirection as well.

Overall, checking the domain you are about to provide credentials for would have worked too. So does usage of a password manager extension that you don't override, or a passkey authentication that you get careful about when the site claims it needs to drop back to passwords and such.

Generally, I do not recommend log in using any public wifi; only at home.

 

[Marko :)]

You mean if he/she was using for example ControlD DoH instead of Google dns, they would not be vulnerable?

Actually, Google Public DNS would prevent this attack if it was used through DoH, DoT or DoQ protocol because it supports DNSSEC standard. Unfortunately, only small number of people use secure DNS protocols which makes attacks like this possible.

Even if the person used Control D, over regular DNS port 53, attack would still be successful as the hackers would have ability to see and modify your network requests because they aren't encrypted.

DoH, DoT and DoQ encrypt DNS requests so instead of seeing domain names of the websites you visit, they'd only see hostname of DNS you're use.

For example, when you're using regular DNS over port 53, hackers and anyone who monitors network sees following:

Date and time       |         IP address           |         Domain            |        Port
25/07/2026 12:02    |        xxx.xxx.xx.xxx        |         bbc.com           |        53
25/07/2026 12:03    |        xxx.xxx.xx.xxx        |         facebook.com      |        53
25/07/2026 12:05    |        xxx.xxx.xx.xxx        |         instagram.com     |        53
25/07/2026 12:08    |        xxx.xxx.xx.xxx        |         x.com             |        53

If, let's Control D Free DNS was used over DoH, hacker would see following:

Date and time       |         IP address           |         Domain                         |        Port
25/07/2026 12:02    |        xxx.xxx.xx.xxx        |         freedns.controld.com           |        443
25/07/2026 12:03    |        xxx.xxx.xx.xxx        |         freedns.controld.com           |        443
25/07/2026 12:05    |        xxx.xxx.xx.xxx        |         freedns.controld.com           |        443
25/07/2026 12:08    |        xxx.xxx.xx.xxx        |         freedns.controld.com           |        443

The source research article also mentions not configuring plain-text fallbacks for the DNS resolutions.

This is exact reason why I use YogaDNS with Control D. If DoQ fails for some reason, there won't be any traffic to plain-text DNS and I basically lose internet access. If I used DoH built into Windows, it would automatically fall back to plain-text port 53. For me, it's either surfing securely, or no surfing at all.

The source article doesn't mention how the redirection manages to defeat the HTTPS certificate (for the authentication landing page). But perhaps configuring the browser with strict HTTPS connection would have defeated this redirection as well.

They had to pass authentication page in order to access the internet. So I think attack likely happened after the authentication.

Overall, checking the domain you are about to provide credentials for would have worked too. So does usage of a password manager extension that you don't override, or a passkey authentication that you get careful about when the site claims it needs to drop back to passwords and such.

This wouldn't help.

DNS poisoning is fancy name for DNS records manipulation. When hackers manipulate DNS records, they change the IP addresses where that domain leads to. In other words, you can type microsoft.com in the browser and believe you're on authentic Microsoft website. What you won't see is the IP address behind domain not leading to Microsoft's server rather than an IP address used by hackers.

So even if you used a password manager, it will also think you're on legit Microsoft site because it reads what it says in the address bar.

Generally, I do not recommend log in using any public wifi; only at home.

Public Wi-Fi isn't an issue as long as you know how to protect yourself. That means using DNS resolver with DNSSEC support over secure protocol (DoH, DoT, DoQ). This is usually enough, but you can always opt for even better protection and use free Cloudflare WARP to encrypt your whole traffic.

 

[Wrecker4923]

If I used DoH built into Windows, it would automatically fall back to plain-text port 53.

It's configurable nowadays:



Also, some members appear to block port 53 at the firewall altogether.

This wouldn't help.

DNS poisoning is fancy name for DNS records manipulation. When hackers manipulate DNS records, they change the IP addresses where that domain leads to. In other words, you can type microsoft.com in the browser

And the browser's certificate check fails the TLS/HTTPS connection, showing it in the browser. That's exactly what the TLS/HTTPS certificates and trusted certificates on the devices are used for.

So even if you used a password manager,

Password manager extension and FIDO2 authenticator rely on the browser's (with the OS) capability in verifying the authenticity of the service via the TLS/HTTPS connection. It wouldn't fail this for sure, unless the computer is compromised or the user overrides the negative match.

ps: Sorry @Marko :), I added the 2nd and 3rd parts in after you reacted to my post. This PS is another post-edit.

 

[Marko :)]

It's configurable nowadays:

View attachment 299032

Also, some members appear to block port 53 at the firewall altogether.

Didn't know they added this. Though I still prefer YogaDNS because DNS-over-QUIC is waaay faster than regular DoH.