Microsoft’s Windows Hello for Business Flaw Let Attackers Bypass Authentication

Researchers have uncovered a vulnerability in Microsoft’s Windows Hello for Business (WHfB) that allows attackers to bypass its robust authentication mechanism.

This flaw, which downgrades the authentication process to a less secure method, has raised concerns about the security of enterprise environments relying on WHfB for phishing-resistant authentication.

What is Windows Hello for Business?

According to the Medium blog report, Windows Hello for Business is a sophisticated authentication mechanism that enhances security using a cryptographic key pair stored on the user’s device.

It leverages the Trusted Platform Module (TPM) to store the private key securely while the public key is sent to the authentication server. The process involves two main phases:

1. Registration: Users register for WHfB, creating a cryptographic key pair. The private key is stored in the TPM, and the public key is sent to the server.
2. Authentication: When users authenticate, they use their Windows Hello PIN or fingerprint, which triggers the encryption of a nonce (unique challenge) issued by Microsoft. This encrypted nonce, along with the origin field, is sent back to the server for validation.

The Flaw: Bypassing WHfB Authentication

The vulnerability in WHfB allows attackers to intercept and alter the authentication requests, coercing users into using a less secure, phishable authentication method.

Join our free webinar to learn about combating slow DDoS attacks, a major threat today.

This can be achieved by manipulating the POST request values, specifically the isFidoSupported parameter and the User-Agent header.

Exploitation Process

1. Intercepting Requests: Attackers use tools like Burp Suite to intercept the outgoing authentication request.
2. Modifying Parameters: They change the isFidoSupported parameter to false or alter the User-Agent header to an unsupported value.
3. Downgrading Authentication: This manipulation downgrades the authentication method from WHfB to a standard, less secure method, which can be easily phished using frameworks like EvilGinx.

A proof of concept (PoC) video demonstrates how this attack can be executed.

The authentication method is downgraded by intercepting the POST request to /common/GetCredentialType and changing the isFidoSupported parameter, allowing attackers to bypass WHfB.

Automated Exploitation with EvilGinx

Researchers have modified the EvilGinx framework to automate this attack. EvilGinx is a tool used for phishing attacks, and the customizations include:

• Modifying the core/http_proxy.go file: This allows manipulation of POST requests with JSON bodies.
• Creating a Phishlet: A phishlet is a customizable template for creating phishing pages.
• The phishlet for this attack alters the POST request to /common/GetCredentialType to set isFidoSupported to false and hides the “Sign-in options” button.

Snippet from BurpSuite’s intercept proxy (/common/GetCredentialType) showing the value “isFidoSupported”

/ set the value of the specified key in the JSON body
func SetJSONVariable(body []byte, key string, value interface{}) ([]byte, error) {
    var data map[string]interface{}
    if err := json.Unmarshal(body, &data); err != nil {
        return nil, err
    }
    data[key] = value
    newBody, err := json.Marshal(data)
    if err != nil {
        return nil, err
    }
    return newBody, nil
}

lp() function

Firstly, find the document element by class (table), which belongs to the box containing the various sign-in methods — such as Fido/WHfB authentication:

Recommendations for Mitigation

Microsoft recommends creating conditional access policies using authentication strength to mitigate this attack vector.

This involves:

1. Implementing Strong Authentication for Cloud Apps: Enforce phishing-resistant authentication methods across all cloud applications.
2. Creating Custom Authentication Strengths: Define custom authentication strengths that include phishing-resistant methods like Temporary Access Pass (TAP).
3. Secondary Policy for Registering Phishing-Resistant Methods: Implement a secondary Conditional Access (CA) policy for users registering new methods via compliant devices.

The discovery of this vulnerability in Windows Hello for Business highlights the need for continuous vigilance and robust security practices.

By implementing strong authentication policies and staying informed about potential threats, organizations can better protect their sensitive data and maintain the integrity of their authentication processes.

Windows Hello for BusinessCaption: Windows Hello for Business aims to provide a secure and phishing-resistant authentication mechanism.

Organizations must adopt advanced security measures as cyber threats evolve and stay ahead of potential vulnerabilities.

The flaw in Windows Hello for Business serves as a reminder of the importance of layered security and proactive risk management. 

This comprehensive news article provides an in-depth look at the vulnerability in Microsoft’s Windows Hello for Business, detailing the exploitation process, proof of concept, and recommendations for mitigation.

By understanding the mechanics of this flaw and implementing the suggested security measures, organizations can enhance their defense against sophisticated phishing attacks.

Protect Your Business Emails From Spoofing, Phishing & BEC with AI-Powered Security | Free Demo