Goodbye? Attackers Can Bypass 'Windows Hello' Strong Authentication

­Microsoft's Windows Hello for Business (WHfB) default phishing-resistant authentication model recently was found susceptible to downgrade attacks, allowing threat actors to crack into even biometrically protected PCs and laptops.

WHfB authentication, which uses cryptographic keys embedded in a computer's Trusted Platform Module (TPM) and enabled by biometric or PIN-based verification, can be bypassed by altering the parameters within an authentication request.

Accenture red-team security researcher Yehuda Smirnov, who made the discovery late last year, reported it to Microsoft, which has made a fix available. Smirnov will demonstrate the attack and how to mitigate that loophole during a session at Black Hat USA 2024 in Las Vegas on Aug. 8.

Authentication Downgrades With Adversary-in-the-Middle

WHfB, an option for commercial and enterprise versions of Windows 10, has been available since 2016. It is designed to protect against phishing attacks using Windows Hello's device-based biometric or PIN authentication, an inherently more secure verification mode than passwords or SMS-based, one-time passwords (OTPs).

Smirnov is not the first to uncover a vulnerability in WHfB's secure authentication model. In 2019, researchers explored attack vectors in WHfB, notably a persistent Active Directory backdoor that evaded security tools. And last month, researchers demonstrated how passkey redaction attacks can force downgraded authentication for Microsoft and other services.

In this case, Smirnov found that an attacker can intercept and alter POST requests to Microsoft's authentication services, defaulting WHfB to less secure passwords or OTP methods. Specifically, Smirnov tells Dark Reading that he was able to downgrade WHfB's default authentication using the open-source Evilginx adversary-in-the-middle (AitM) reverse-proxy attack framework. Attackers are known to use Evilginx to phish credentials and session cookies, allowing them to bypass multifactor authentication to a phishable method.

Using Evilginx, Smirnov was able to downgrade WHfB to a phishable form of authentication at scale by intercepting the POST request to  "/common/GetCredentialType" and changing either the user-agent or the parameter "isFidoSupported." "The Evilginx code was modified, and a phishlet was created to facilitate automation of the attack," he noted when first documenting his discovery.

WHfB's Phishing-Resistant Model

Smirnov says his discovery does not indicate that WHfB is insecure. "The insecure part here is not regarding the protocol itself, but rather how the organization forces or does not force strong authentication," he says. "Because what's the point of phishing-resistant authentication if you can just downgrade it to something that is not phishing-resistant?"

Smirnov maintains that because of how the WHfB protocol is designed, the entire architecture is phishing resistant. "But since Microsoft, back at the time, had no way to allow organizations to enforce sign-in using this phishing-resistant authentication method, you could always downgrade to a lesser secure authentication method like password and SMS-OTP," Smirnov says.

When a user initially registers Windows Hello on their device, the WHiB's authentication mechanism creates a private key credential stored in the computer's TPM. The private key is inaccessible to an attacker because it is sandboxed on the TPM, therefore requiring an authentication challenge using a Windows Hello-compatible biometric key or PIN as a sign-in challenge.

To authenticate with cloud applications using WHiB, Microsoft generates a challenge sent to the client using the WebAuthn API implemented in a browser, which interacts with Windows Hello on the device to request the verification challenge using the private key. WebAuthn, a World Wide Web Consortium (W3C) standard, is the underlying component of FIDO2 or passkeys-based authentication.

Microsoft's Remediation: New Conditional Access Policy

Microsoft's fix quietly arrived in March with the addition of a new Conditional Access capability called "authentication strength," which administrators can now activate in the Azure portal. "Basically, they can force the employees to authenticate using only phishing-resistant authentication," Smirnov says. "It is now possible for them to do that, which was not possible beforehand."

According to Microsoft, the authentication strength parameter can require exclusively phishing-resistant authentication to access sensitive information. Microsoft says authentication strength is based on its authentication methods policy, which lets administrators seek authentication methods for specific users and groups.

The new authentication strength capability is now available with Microsoft's Entra ID federated applications, which were updated earlier this month with the release of its Entra Suite. Microsoft says organizations can adjust authentication strength based on various conditions, such as resource sensitivity, user risk, compliance requirements, and location.

Microsoft did not respond to a Dark Reading request for additional comment on the vulnerability and its fix.

The bottom line, Smirnov emphasizes, is administrators who configure these new conditional access policies can ensure that users can only authenticate with phishing-resistant methods.

"This way, an attacker cannot downgrade the authentication method because the credential will not work," he says. "Because the conditional access policy does not allow signing in using any authentication policy other than the phishing-resistant one."