Pass-the-Passkey Attack Bypasses Phishing-Resistant MFA and Impersonates Privileged Users

A newly disclosed “Pass-the-Passkey” attack family demonstrates how implementation weaknesses in WebAuthn can undermine passkey protections, even when private keys remain within hardware security keys or trusted device enclaves.

SpecterOps researchers identified more than 20 attack techniques affecting Windows 11, Microsoft Entra ID, web browsers, password managers, and enterprise authentication workflows.

The techniques do not break FIDO2 cryptography or extract private keys. Instead, they exploit the ecosystem around passkeys, including endpoint logging, server-side assertion validation, authentication prompts, and application interfaces.

Pass-the-Passkey Attack

The most serious attack chain combines a Windows event logging flaw with insufficient WebAuthn validation in Microsoft Entra ID. Prior to Microsoft’s remediation, Windows recorded complete WebAuthn assertion responses in the Microsoft-Windows-WebAuthN/Operational event log.

A WebAuthn assertion is a signed authentication response generated after a user approves a passkey request. It may contain the credential identifier, authenticator data, challenge-related information, user handle, and a cryptographic signature.

Although an assertion is not the private passkey itself, it remains sensitive authentication material that should not be reusable outside its original login transaction.

SpecterOps found that users with local access to an affected system could retrieve historical assertions from Windows Event Viewer. This becomes particularly dangerous when privileged cloud administrators use a shared, remotely accessible, or compromised endpoint.

An attacker could collect logged assertion data and attempt to submit it again to an authentication endpoint.

Normally, WebAuthn relying parties should prevent this by generating one-time challenges, binding every challenge to a specific login session, rejecting reused requests, and validating authenticator signature-counter behavior where available.

SpecterOps reported that Microsoft Entra ID did not consistently enforce these controls in the affected scenario. The weaknesses enabled replay of captured assertion data and impersonation of a user while satisfying phishing-resistant MFA requirements.

Microsoft addressed the Windows logging weakness as CVE-2026-34348 in its July 14, 2026 security updates. The issue affected the Windows Event Logging Service, exposing WebAuthn assertion data in event logs.

Patched systems truncate the signature component stored in the log to six bytes, preserving limited troubleshooting capability while preventing an event entry from being used as a full replayable assertion.

The remediation removes a critical component of the replay chain, but the findings reinforce that phishing resistance is not guaranteed solely by using passkeys.

Authentication security also depends on how endpoints handle WebAuthn artifacts and whether relying parties rigorously validate every authentication response.

Beyond replay, the research documents local techniques that abuse legitimate WebAuthn interfaces without stealing cryptographic key material.

Malware running on a compromised endpoint can invoke passkey APIs to present authentication requests, repeatedly trigger prompts to create user fatigue, or manipulate calling-application details to make a request appear trustworthy.

One technique involves the Windows Credential UI window handle behavior. A malicious process may attempt to cause a passkey dialog to appear to be connected to a legitimate application window, such as a browser or an enterprise productivity tool.

This can make an unauthorized prompt more convincing and increase the possibility that a user approves it. Microsoft reportedly assessed the window-handle spoofing technique as a low-severity defense-in-depth concern.

Mitigation

Organizations should rapidly deploy Windows updates that address CVE-2026-34348 and verify that privileged endpoints receive the July 2026 security release.

Server-side WebAuthn implementations must generate unique, single-use challenges, bind them to an active session, and reject assertions that do not meet replay and counter-validation requirements.

Security teams should also monitor access to WebAuthn event logs, investigate unexpected WebAuthn API calls from untrusted processes, and limit privileged administration to hardened, segregated workstations.

Detect, investigate, and respond faster with in-browser data inspection from ANY.RUN. Gain complete phishing visibility to strengthen your SOC and reduce MTTR