I would like to know more about how this bypassed server certificate validation. microsoft.com might resolve to a malicious IP address, but your web browser will break as soon as the server certificate check fails. One would need to ignore a fat warning page and click the “Accept risk and continue” button.
Also, if the attackers have hijacked DNS, why do they have these fake domains (m365-owa., etc.)? They can be microsoft.com; they don’t need a copycat domain. This suggests a fair amount of victim participation:
Web browser contacts the malicious web server and receives a TLS certificate that cannot be verified because it was not signed by a global root authority (in this case, DigiCert).
Victim sees “This connection isn’t secure.”
Victim ignores warning and clicks “continue”
Victim either provides their credentials at the fake microsoft.com site, ignoring the red flags all over the browser, or
Victim is quickly redirected to another domain which has a valid certificate and provides their login credentials there
If certificate validation didn’t stop this kind of attack, then a VPN is useless. The attacker can simply redirect your initial handshake with your VPN provider and impersonate your VPN gateway. But because you most likely have some kind of prearranged trust (shared keys or a stored certificate), you can authenticate the VPN provider and establish an encrypted tunnel through all of the untrusted networks between your laptop and the VPN host.
So, while spoofing microsoft.com is the big trick here, there are other failures the operator must commit to allow the attack to succeed.
In many cases, a VPN is redundant to any TLS-encrypted HTTP session. The benefits of a VPN in these cases are to obscure your origin (location, IP address, etc.) from the web sites you are visiting, and to prevent the hotel/coffee Wi-Fi/ISP from tracking or potentially intercepting which sites or services you are accessing. The only time a VPN is not redundant encryption is if you are visiting unencrypted web sites (i.e. a URL starting with http:// and not https://), which by and large have not existed in nearly a decade.
I would like to know more about how this bypassed server certificate validation. microsoft.com might resolve to a malicious IP address, but your web browser will break as soon as the server certificate check fails. One would need to ignore a fat warning page and click the “Accept risk and continue” button.
Also, if the attackers have hijacked DNS, why do they have these fake domains (m365-owa., etc.)? They can be microsoft.com; they don’t need a copycat domain. This suggests a fair amount of victim participation:
If certificate validation didn’t stop this kind of attack, then a VPN is useless. The attacker can simply redirect your initial handshake with your VPN provider and impersonate your VPN gateway. But because you most likely have some kind of prearranged trust (shared keys or a stored certificate), you can authenticate the VPN provider and establish an encrypted tunnel through all of the untrusted networks between your laptop and the VPN host.
So, while spoofing microsoft.com is the big trick here, there are other failures the operator must commit to allow the attack to succeed.
In many cases, a VPN is redundant to any TLS-encrypted HTTP session. The benefits of a VPN in these cases are to obscure your origin (location, IP address, etc.) from the web sites you are visiting, and to prevent the hotel/coffee Wi-Fi/ISP from tracking or potentially intercepting which sites or services you are accessing. The only time a VPN is not redundant encryption is if you are visiting unencrypted web sites (i.e. a URL starting with http:// and not https://), which by and large have not existed in nearly a decade.