• Thread Author
Two German researchers demonstrated at Black Hat that an attacker with local administrative access can inject a malicious biometric template into Windows Hello for Business and sign in as another user with nothing more than their own face — a practical, low-noise bypass that undermines one of Microsoft’s flagship passwordless promises. (notebookcheck.net)

Background​

Windows Hello has been central to Microsoft’s push toward a passwordless future: it uses on-device biometric enrollment (face or fingerprint) and device-bound cryptographic keys to authenticate users to Windows, enterprise resources, and identity providers such as Entra ID (Azure AD). For business deployments, Microsoft introduced Enhanced Sign-in Security (ESS) — a virtualization- and hardware-backed isolation model intended to keep biometric processing and template storage out of reach of OS‑level attackers. (learn.microsoft.com)
Despite those protections, ERNW researchers Dr. Baptiste David and Tillmann Osswald presented a live proof-of-concept (PoC) at Black Hat showing that a local administrator can extract, modify, and inject biometric templates into the Windows Biometric Service store — effectively teaching a victim’s PC to accept the attacker’s face. NotebookCheck, Cybernews and other outlets reported the new attack, called “Faceplant,” and explained that it advances an earlier demonstration (Face Swap) by removing the requirement that both enrollments occur on the same device. (notebookcheck.net, cybernews.com)

Overview of the Faceplant attack​

What the researchers did (high level)​

  • Enroll a biometric (face) on any Windows machine to create a biometric template.
  • Decrypt and extract that biometric template from the enrolling machine.
  • With local admin rights on a target device, replace or inject the extracted template into the target’s Windows biometric database.
  • Present the attacker’s face at sign-in — Windows Hello accepts it as the legitimate user and issues the device-bound authentication operation.
This process doesn’t try to fool the camera with deepfakes or prints; instead it tampers with the stored data that Windows uses to decide whether a presented face matches an enrolled profile. NotebookCheck and Cybernews independently described the same sequence; the researchers’ live Black Hat demo corroborated the technique by enrolling on one laptop, injecting on another, and completing authentication on stage. (notebookcheck.net, cybernews.com)

Why this matters now​

Biometric authentication is widely seen as a phishing‑resistant, convenient second factor and, for many IT teams, an access-first option for endpoint logon. The Faceplant attack shifts the threat model: it shows that if an attacker gains administrative control of a device — a common stage in real-world intrusions or advanced malware campaigns — they can turn biometric authentication into a persistent and stealthy backdoor that does not require stealing passwords or passkeys. Multiple outlets covering the Black Hat presentation stressed that administrative access is a necessary precondition; however, in many breaches that stage is already achieved prior to lateral movement and identity theft. (cybernews.com, wired.com)

Technical anatomy: where the trust chain breaks​

Windows Hello for Business architecture (concise)​

  • Enrollment generates a private/public key pair bound to the device and the biometric profile.
  • The private key is protected by platform mechanisms and used to sign or unlock authentication operations.
  • Biometric templates (face/fingerprint) are stored locally in the Windows Biometric Service (WBS) database and are used to gate access to the private key.
  • CryptProtectData and other Windows APIs are used to encrypt stored artifacts, but those protections rely on secrets and environment properties available on the local system. (learn.microsoft.com)

The precise weakness exploited​

ERNW’s researchers demonstrated that on non-ESS systems the WBS database encryption and key material can be accessed or manipulated by an entity that already controls local administrative privileges. That means an attacker can:
  • Generate a template on a throwaway machine.
  • Extract and convert the template into the format expected by the WBS store.
  • Inject the template (and related identifiers/cryptographic pointers) into the victim device’s biometric database.
  • Trigger the biometric pipeline so that Windows Hello uses the injected template to allow authentication.
Because the attack targets stored templates and cryptographic references rather than the camera or sensor, conventional sensor hardening (e.g., liveness detection) does not mitigate the threat. NotebookCheck and other reports emphasize this is an architectural weakness of template storage when not isolated in hardware or hypervisor-isolated firmware. (notebookcheck.net)

ESS: effective but not universal​

Enhanced Sign-in Security (ESS) moves face matching and template handling into a virtualization-based, higher trust level (VTL1) and uses a TPM-backed secure channel to protect template encryption and key authorization. When ESS is properly enabled and the device includes ESS-capable sensors, template injection and database-level tampering should be effectively blocked. Microsoft’s documentation explains how ESS places the biometric algorithm and template generation into VBS-isolated memory and restricts access to TPM‑authorized keys. (learn.microsoft.com)
However, ESS depends on specific hardware, firmware, and certified sensors. ERNW reported that even relatively recent enterprise laptops lacked ESS‑capable camera modules in some cases; manufacturers and OEM decisions about camera modules and firmware matter. The absence of ESS on a fleet therefore leaves many corporate endpoints exposed. Independent coverage confirms that ESS adoption is uneven and external peripheral support remains limited. (notebookcheck.net, learn.microsoft.com)

Validation: cross-referencing the public record​

To ensure the Black Hat claims align with public reporting and vendor documentation, three independent threads of evidence were checked:
  • The researchers’ live demo and writeups (reported by multiple outlets as Faceplant / Face Swap) describe template extraction and injection as the core technique. NotebookCheck and Cybernews closely match the researchers’ description. (notebookcheck.net, cybernews.com)
  • Microsoft’s technical pages on Enhanced Sign-in Security explicitly describe the VBS-based isolation model that would, by design, prevent arbitrary process access to face templates and matching algorithms. That documentation supports the assertion that ESS blocks database-level tampering when present. (learn.microsoft.com)
  • Historical precedent shows Windows Hello can be bypassed via other vectors (e.g., sensor spoofing) but those attacks targeted the input pipeline rather than the stored templates; previous attacks prompted patches and hardware-driven mitigations, reinforcing why platform isolation is central to defense-in-depth. Wired’s coverage of earlier webcam‑based bypasses provides context for the evolution of defenses. (wired.com)
Where public detail is missing or unverifiable (for example, the precise registry keys and encryption key lifetimes used in the PoC), responsible caution is advised rather than speculative technical claims. The ERNW demonstration and vendor docs are consistent on the high‑level mechanism and mitigation model. (notebookcheck.net, learn.microsoft.com)

Implications for enterprise security teams​

Immediate triage: actions to take this week​

  • Audit Windows Hello usage across your estate and identify which devices have ESS enabled. Systems without ESS are at higher risk. Microsoft’s documentation explains how to verify ESS status via Windows Security and Event Viewer. (learn.microsoft.com)
  • Inventory local administrator privileges and tighten them immediately. Apply principle of least privilege, roll out just-in-time (JIT) elevation tools, and restrict who can perform local admin tasks.
  • For high-risk systems (sensitive data, privileged accounts, domain controllers, remote workers with unmanaged devices), temporarily disable biometric sign-in and require PIN or stronger multi-factor authentication until ESS can be validated or devices replaced. Multiple reports and the researchers recommended disabling biometrics where ESS is not available. (cybernews.com, learn.microsoft.com)
  • Harden endpoint detection and response (EDR) to identify abnormal writes to biometric stores or unexpected service activity related to WBS; implement file integrity monitoring to detect tampering of biometric-related artifacts.
  • Verify remote management channels and third-party vendor access — remote support tools with high privileges are a potential abuse vector for injecting templates at scale. (learn.microsoft.com)

Medium-term measures (3–12 months)​

  • Prioritize device refresh for hardware that supports ESS or otherwise offers proven virtualization isolation for biometric processing.
  • Deploy FIDO2 hardware tokens or passkeys for high-assurance access to critical systems; do not rely solely on local biometrics for privileged account sign-in.
  • Update procurement standards to insist on ESS-capable sensors, TPM 2.0, Secure Boot, and vendor attestation for camera modules.

Long-term architecture shifts​

  • Consider moving sensitive authentication decisions off the endpoint entirely when feasible — for example, requiring a second factor that is remote-asserted or using hardware security modules that cannot be tampered with by local admin.
  • Reassess whether on-device biometrics should be used for access to privileged accounts or whether they should remain a convenience tier for non-sensitive workflows.

Pros, cons, and real-world risk calculus​

Strengths of Windows Hello​

  • Convenience and user acceptance — biometrics reduce helpdesk friction and phishing exposure when properly isolated.
  • Local key-based model ties authentication to a device-bound private key, limiting remote replay of credentials.
  • ESS architecture offers a pathway to a robust, hardware-isolated biometric model where supported. (learn.microsoft.com)

Weaknesses exposed by Faceplant​

  • Dependency on local device integrity — if an attacker attains admin, stored biometric templates and cryptographic gating can be manipulated.
  • Hardware fragmentation — ESS requires specific sensors and firmware; fleets with mixed or older hardware cannot rely on ESS uniformly.
  • Detection gaps — template injection produces minimal user-visible artifacts and may not trigger standard AV or logging without dedicated monitoring. Independent coverage and researcher notes highlight the operation is stealthy once admin access exists. (notebookcheck.net, cybernews.com)

How to weigh the risk​

The attack requires local administrative access — a substantial but realistic precondition in many breach scenarios. For low-privilege endpoints with strict EDR and monitored admin elevation, the risk is reduced but not eliminated. For enterprise environments with unmanaged or poorly controlled admin access, the risk is materially higher. The pragmatic defense is to assume endpoints can be compromised and to design authentication so that local compromise cannot trivially grant domain or identity-level access.

Why fixing this is non-trivial​

Researchers and reporting converge on a hard truth: patching a single API call or service is unlikely to solve an architectural flaw that stems from how and where templates and keys are generated, stored, and authorized. ERNW suggested the full mitigation path could be:
  • moving template generation and matching into certified secure hardware or hypervisor-protected domains for all devices, or
  • redesigning the key‑binding model so private keys cannot be authorized without hardware-backed attestations that are inaccessible to local admin.
Both options impose hardware, firmware, and supply‑chain constraints and, realistically, cannot be retrofitted across millions of existing devices quickly. That’s why the immediate operational mitigations (ESS where available, disable biometrics where not) remain the practical path for many organizations. (notebookcheck.net, learn.microsoft.com)

Practical checklist for IT leaders​


  • Inventory: List all devices using Windows Hello for Business and mark ESS status.
  • Privilege control: Restrict local admin rights and deploy JIT admin tools.
  • Temporary policy: Disable biometrics on non-ESS devices; require PINs or hardware MFA for privileged accounts.
  • Monitoring: Add file integrity monitors and EDR rules focused on Windows Biometric Service artifacts and unusual service restarts.
  • Procurement: Only approve future devices that meet ESS and sensor attestation requirements.
  • Test: Simulate privilege escalation scenarios and validate that biometric data cannot be modified from an admin session in your environment.
  • Communication: Notify helpdesk and support teams to expect and handle biometric-related incidents.
  • -

Broader security context and precedent​

This isn’t the first time Windows Hello has been scrutinized. Earlier research showed sensor-level bypasses (for example, crafted IR imagery) prompting Microsoft to improve sensor checks and recommend ESS-style isolation. Those historical incidents led to vendor and platform hardening; Faceplant differs because it strikes at the storage and gating layer rather than the input pipeline, which means hardware-based isolation is the correct architectural remedy rather than a firmware tweak. Wired’s reporting on older webcam bypasses and Microsoft’s ESS documentation together show the industry progression toward isolation as the primary defense. (wired.com, learn.microsoft.com)

What Microsoft has said (and what remains open)​

Microsoft acknowledged the research, emphasized that the attack requires prior administrative access, and pointed to Enhanced Sign-in Security as the designed mitigation for tampering and database-level threats. ESS operates at a virtualized trust level above the OS and is intended to prevent the exact class of database tampering demonstrated at Black Hat. That said, Microsoft’s stance also implicitly acknowledges the deployment gap: ESS is not universally present across enterprise fleets, and enabling ESS depends on hardware, firmware, and OEM choices. This leaves organizations with a transitional problem that must be managed operationally. (learn.microsoft.com, theverge.com)

Conclusion: a sober recalibration of trust​

Faceplant is a significant wake-up call for organizations that have moved to biometric-centric, passwordless strategies without accounting for endpoint compromise and hardware diversity. The attack does not render Windows Hello useless — rather, it reframes where and how trust must be placed. When biometric processing and template storage are isolated in firmware, TPMs, and virtualization-protected enclaves, Hello’s convenience and phishing-resistant benefits remain compelling. When those protections are absent, however, biometric convenience becomes a liability in the hands of a privileged attacker.
Enterprises must act decisively: inventory devices, lock down administrative privileges, and favor hardware that supports Enhanced Sign-in Security or rely on alternative high‑assurance factors until platform-level isolation is guaranteed. The research shows that biometrics are only as secure as the environment that stores and protects them — an engineering and procurement challenge as much as a software one. (notebookcheck.net, learn.microsoft.com)

(Reports from the Black Hat demonstration, follow-up analysis, and vendor documentation were consulted in preparing this feature to ensure technical accuracy and practical guidance.) (cybernews.com, learn.microsoft.com, wired.com)

Source: TechSpot New Faceplant attack exposes serious flaw in Windows Hello at Black Hat