Security researchers from ERNW, Dr. Baptiste David and Tillmann Osswald, took the stage at Black Hat to demonstrate a practical, low-noise attack against Windows Hello for Business. Dubbed "Faceplant," the technique lets an attacker with local administrative privileges inject a malicious biometric template into the Windows Biometric Service (WBS) database, essentially teaching the system to accept the attacker's face as any enrolled user. The demo proved that an attacker can enroll a face on one laptop, extract the template, and inject it onto a fully independent target device – all without triggering standard defenses or leaving obvious forensic traces.
This isn't a sensor spoof or a deepfake trick. Faceplant strikes at the storage and cryptographic gating layer that decides whether a presented face matches an enrolled profile. By compromising the template store, an attacker bypasses the camera's liveness checks and the entire front-end biometric pipeline. The implications are severe for organizations that have placed biometric sign-in at the heart of their passwordless strategy, expecting it to resist phishing and credential theft. With admin rights already in hand – a common stage in real-world intrusions – an adversary can transform a compromised endpoint into a persistent identity backdoor, impersonating any user without ever stealing a password or token.
Windows Hello's Trust Model and Where It Breaks
Windows Hello for Business ties authentication to device-bound cryptographic keys. During enrollment, a private/public key pair is generated, and the private key is sealed to the device's TPM. Access to that key is gated by biometric verification: the system matches a live face or fingerprint against a locally stored template before unlocking the key for sign-in, authorization, or access to services like Entra ID (formerly Azure AD). The biometric templates are encrypted and stored in the WBS database, with protections such as CryptProtectData APIs.
However, these protections rely on secrets and environment properties available to a process running with local administrative rights. On systems that lack Enhanced Sign-in Security (ESS), an admin-level attacker can decrypt, modify, and re-inject templates. ERNW demonstrated precisely this:
- Enroll a face on any Windows machine (attacker-controlled throwaway device).
- Decrypt and extract the biometric template from that machine's WBS store.
- On the target device, with local admin access, replace or insert the extracted template into the victim's biometric database.
- Present the attacker's face at sign-in – Windows Hello matches it to the injected template and releases the victim's private key.
Because the attack targets the stored template and the trust that the biometric match is genuine, hardware-level protections like liveness detection on the camera are irrelevant. The system isn't being fooled into accepting a fake face; it's being reprogrammed to accept a deliberately planted face as authentic.
Enhanced Sign-in Security: A Shield with a Narrow Deployment
Microsoft anticipated such template-tampering threats and designed Enhanced Sign-in Security (ESS) to isolate biometric processing in a higher trust level. ESS leverages Virtualization-based Security (VBS) and TPM-backed secure channels. Face matching and template handling move to VTL1, a hypervisor-protected enclave, where the OS – and therefore a local admin – cannot directly touch the data or algorithms. In an ESS-compliant configuration, template injection and database-level tampering should be effectively blocked.
Yet ESS adoption is far from universal. The researchers noted that even recent enterprise laptops often ship without ESS-capable camera modules. ESS requires specific hardware, firmware, and sensor drivers certified by Microsoft. External USB cameras, widely used in work-from-home setups and shared workstations, rarely support ESS. This fragmentation means many corporate fleets have at best partial protection. Microsoft's own documentation makes clear that ESS is the designed mitigation, but it is a hardware-dependent feature that cannot be retrofitted to existing non-ESS devices.
Beyond the Hype: Validating the Claims
Independent reports from NotebookCheck and Cybernews corroborate the Black Hat demo and technical walkthrough. The researchers themselves documented the attack as an evolution of earlier work (Face Swap) that required both enrollments on the same device; Faceplant removes that constraint, broadening the threat model. Microsoft's technical pages on ESS describe exactly the isolation model that would prevent the attack, which aligns with the researchers' assertion that ESS-protected devices are not vulnerable. Historical context also supports the findings: prior Windows Hello bypasses targeted sensor spoofing (e.g., crafted infrared images), while Faceplant exploits a storage-layer weakness that demands architectural isolation rather than a simple firmware patch.
Where specific cryptographic details (registry paths, key lifetimes) haven't been publicly disclosed, the high-level mechanism is consistent and credible. The researchers responsibly reported their findings to Microsoft before the conference, and the company acknowledged the work.
What This Means for Enterprise Security Teams
The attack requires local administrative access – a high bar but one routinely met in sophisticated breaches, ransomware campaigns, and insider threat scenarios. Once an attacker has admin, they can disable logging, tamper with EDR, and now implant a persistent biometric backdoor that survives password changes and token revocations. The operation is stealthy, generating minimal user-visible alerts or standard AV triggers. This shifts the calculus for any organization that has adopted Windows Hello for Business as a primary sign-in method.
Immediate Triage (This Week)
- Audit ESS coverage: Identify every device using Windows Hello for Business and check ESS status via Windows Security or Event Viewer. Systems without ESS should be flagged as high-risk.
- Lock down local admin: Enforce least privilege, deploy just-in-time (JIT) elevation solutions, and remove standing admin rights wherever possible.
- Temporarily disable biometrics on non-ESS devices: For high-risk endpoints (sensitive data, privileged accounts, domain controllers, remote workers), switch to PIN-based sign-in or hardware MFA until ESS status is confirmed or hardware upgrades are made.
- Harden monitoring: Implement file integrity monitoring on WBS artifacts and configure EDR to detect abnormal writes to the biometric store or unexpected
svchost.exe -k WbioSrvcactivity. - Scrutinize remote access tools: Remote management software with elevated privileges is a prime vector for template injection at scale. Tighten controls and logging.
Medium-Term Measures (3–12 Months)
- Refresh hardware: Prioritize devices that support ESS or other proven isolation mechanisms. Include ESS-capable sensors, TPM 2.0, and Secure Boot as mandatory procurement criteria.
- Decouple high-assurance access: Use FIDO2 hardware tokens or passkeys for privileged account sign-in instead of relying solely on local biometrics.
- Redesign authentication architecture: Consider moving sensitive authentication decisions off the endpoint entirely – for example, requiring a remote-attested second factor that cannot be compromised by a local admin.
Risk Calculus: Biometrics as Convenience vs. Strong Authentication
Windows Hello's strengths are real: it reduces helpdesk friction, resists phishing, and binds authentication to a device-bound key. When ESS is properly deployed, biometric processing is hardware-isolated, making the attack vector moot. Yet the weaknesses are equally stark. Local device integrity is paramount; if an admin is compromised, the biometric store becomes mutable. Hardware fragmentation means many organizations cannot achieve uniform ESS coverage, leaving pockets of exposure. And detection is hard – template injection is quiet, lacking the noisy artifacts of traditional credential theft.
For organizations with mature security posture – strictly controlled admin rights, robust EDR, and continual ESS validation – the real-world risk is tempered but not zero. For those with lax admin controls or older hardware, the risk is unacceptably high. The pragmatic takeaway: assume endpoints can be compromised, and design authentication so that local compromise does not trivially grant domain-level or identity-layer access.
Why a Quick Patch Won't Fix This
Both researchers and independent analysts agree that this isn't a bug to be patched with a single update. The fundamental issue is that on non-ESS systems, the WBS database encryption relies on locally accessible secrets. Redesigning the trust model would require either moving template generation and matching entirely into certified secure hardware or hypervisor-protected domains for all devices, or changing the key-binding such that private keys cannot be unlocked without hardware-backed attestations invisible to the OS. Both paths impose hardware, firmware, and supply-chain constraints that cannot be retrofitted quickly across the millions of existing Windows machines.
Thus, the immediate operational mitigations – disable biometrics where ESS is absent, enforce strict admin controls, and deploy hardware tokens – become the practical path forward for most organizations.
Microsoft's Response and the Path Ahead
Microsoft acknowledged the research, reiterating that the attack requires prior administrative access and that ESS is the designed mitigation. The company pointed to its documentation on ESS as the correct defensive posture. However, this acknowledgment implicitly highlights a deployment gap: Microsoft cannot force OEMs to include ESS-capable sensors on all devices, nor can it retroactively add virtualization-based security features to legacy hardware.
Enterprises are left with a transitional problem that demands operational discipline. The silver lining is that ESS adoption is likely to accelerate as the pressure to protect biometric authentication intensifies. For now, the burden falls on IT leaders to inventory, mitigate, and transition.
The Sobering Reality: Biometrics Are Only as Secure as Their Isolation
Faceplant does not render Windows Hello useless. It reframes where trust must be placed. When biometric processing and template storage are isolated in firmware, TPMs, and VBS-protected enclaves, Windows Hello remains a compelling phishing-resistant, user-friendly authentication method. When those protections are absent, biometric convenience becomes a liability that a privileged attacker can exploit with surgical precision.
For enterprises that have gone all-in on passwordless, the demo is a call to action: verify ESS readiness, remove local admin where possible, and segment high-value access from endpoint authentication that hinges on local integrity. The architectural lesson is clear – security that depends solely on OS-level defenses is only as strong as the hardware isolation beneath it.