Passkey Attacks Can Expose Synced FIDO2 Keys and Bypass Phishing-Resistant MFA: Detection and Hardening Guide

Security researchers are describing a new class of attacks against passkeys that undermine two assumptions many organizations made when migrating away from passwords: that a synced passkey private key cannot be recovered from the cloud credential fabric, and that phishing-resistant MFA cannot be bypassed once WebAuthn/FIDO2 is enabled. The source item does not publish a CVE identifier, CVSS score, vendor-specific affected version list, or CISA KEV entry, so defenders should treat this as an active technique class rather than a single patched bug.

The defensive concern is straightforward. If an attacker can recover a synced private key, coerce enrollment of an attacker-controlled authenticator, replay or steal an already-authenticated session token, or force an authentication-policy downgrade away from passkeys, then MFA is no longer the control boundary. The identity control plane, browser/OS credential store, mobile cloud account recovery process, and relying-party WebAuthn policy become the real perimeter.

Organizations using passkeys for workforce SSO, consumer identity, privileged admin access, or high-risk transaction approval should immediately validate that passkey-only authentication cannot be silently weakened, that new authenticator registration is strongly governed, and that SOC analytics can see credential-store access, token-theft behavior, and anomalous WebAuthn ceremonies.

What Is at Risk

The affected surface is not one product. It is the passkey ecosystem: FIDO2/WebAuthn relying parties, identity providers, browser credential managers, OS platform authenticators such as Windows Hello, iCloud Keychain-style sync fabrics, Android/Google credential sync, password managers that sync passkeys, and any IdP flow that permits fallback from passkeys to weaker factors.

High-impact scenarios include:

Recovery or extraction of a synced passkey private key through compromise of the cloud account that synchronizes credentials.
Enrollment of an attacker-controlled passkey after account recovery, help-desk reset, or weak step-up authentication.
Bypass of phishing-resistant MFA by stealing session cookies, OAuth refresh tokens, or IdP artifacts after a legitimate passkey assertion.
Downgrade paths where a relying party accepts TOTP, SMS, push approval, or password-plus-risk-score when passkey verification fails or is unavailable.
Cross-device or hybrid WebAuthn flows abused from an attacker-controlled browser session.

No CVE is named in the provided source. Do not invent one. Treat exploitation status as researcher-demonstrated or emerging until your vendors confirm otherwise, but act now because the preconditions — token theft, help-desk social engineering, sync-account compromise, and permissive fallback — are already common in real intrusions.

Technical Analysis

Passkeys are built on WebAuthn/FIDO2: the relying party issues a challenge, the client platform uses an authenticator to produce an assertion, and the server validates the signature, user presence/verification flags, origin, RP ID, attestation where required, and credential metadata. Security depends on more than cryptography. It depends on authenticator provenance, enrollment governance, session binding, and the absence of weaker fallback.

The attacks described by the news item map to four defender-observable failure modes.

First is synced-key recovery. Many users store passkeys in a cloud-backed credential manager so credentials follow the user across devices. If the sync account is compromised through password reuse, infostealer capture, OAuth consent abuse, malicious browser extension, weak recovery, or session hijack, the attacker may be able to restore credentials to a new device or access protected local state. The private key is intended to remain non-exportable, but the operational trust chain includes DPAPI/Keychain/Keystore protection, device unlock, cloud account recovery, and vendor-specific sync metadata.

Second is authenticator substitution. If an IdP or application allows a user to add a passkey after only password reset, email verification, push approval, or help-desk assertion, then the attacker does not need to steal an existing private key. They register a new one. Weak AAGUID attestation policy makes this worse because the relying party cannot distinguish a vetted hardware key from an arbitrary software authenticator.

Third is post-authentication bypass. Phishing-resistant MFA protects the ceremony, not every artifact created afterward. If refresh tokens, session cookies, device code flow tokens, or desktop SSO artifacts are stolen and replayed from another host, the attacker may not need to repeat WebAuthn. This is why passkey rollout without token-theft detection creates false confidence.

Fourth is policy downgrade. Many enterprises support mixed authentication during migration. An attacker who can induce a failure — claim no phone, no security key, broken Bluetooth, unsupported browser — may be routed to SMS, voice, TOTP, push, or password. Unless the relying party requires authentication strength, the strongest factor becomes optional.

From a detection perspective, do not hunt for a single exploit binary. Hunt for the chain: credential-store access, suspicious process trees around browsers, new sign-ins from unfamiliar device posture immediately before passkey registration, WebAuthn ceremony anomalies, token issuance from unexpected clients, and session reuse inconsistent with device or network history.

Detection and Hunting

The following controls are behavioral and must be tuned to your IdP, browser standard builds, EDR telemetry, and approved password-manager inventory. They are intentionally focused on high-value identity events rather than broad FIDO chatter.

YAML

---
title: Non-Browser Process Access to Browser Credential Stores
id: 4d7f0f4d-4b90-4e9c-9f62-7ac9f64d2a21
status: experimental
description: Detects processes outside approved browsers/password managers accessing browser Login Data, Cookies, Web Data, or Local State artifacts used for sessions and credential sync. Relevant to passkey/MFA bypass via token theft and synced credential abuse.
references:
  - https://attack.mitre.org/techniques/T1555/003/
  - https://attack.mitre.org/techniques/T1539/
author: Security Arsenal
date: 2026/08/07
tags:
  - attack.credential_access
  - attack.t1555.003
  - attack.t1539
logsource:
  category: file_access
  product: windows
detection:
  selection_paths:
    ObjectName|contains:
      - '\AppData\Local\Google\Chrome\User Data\'
      - '\AppData\Local\Microsoft\Edge\User Data\'
      - '\AppData\Roaming\Mozilla\Firefox\Profiles\'
      - '\AppData\Local\BraveSoftware\Brave-Browser\User Data\'
  selection_objects:
    ObjectName|endswith:
      - '\Login Data'
      - '\Cookies'
      - '\Web Data'
      - '\Local State'
      - '\Network\Cookies'
      - '\cookies.sqlite'
      - '\logins.json'
      - '\key4.db'
  approved_images:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\MsMpEng.exe'
      - '\MonitoringHost.exe'
      - '\OneDrive.exe'
  condition: selection_paths and selection_objects and not approved_images
falsepositives:
  - EDR/AV scanners, backup agents, DLP, forensics collection, enterprise password managers, browser updaters
level: high
---
title: Suspicious Child Process From Browser Followed by Credential-Store Access
id: 8bd5b3f1-6a2e-42e2-9a4e-c7f6fd6f11c2
status: experimental
description: Detects browsers spawning scripting, archive, cloud-sync, or remote access tooling that may stage session/cookie theft before synced passkey or IdP token abuse.
references:
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1555/003/
author: Security Arsenal
date: 2026/08/07
tags:
  - attack.execution
  - attack.credential_access
  - attack.t1059
  - attack.t1555.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\7z.exe'
      - '\rar.exe'
      - '\winrar.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Enterprise browser extensions, managed software deployment, SSO troubleshooting, developer workstations
level: medium

KQL — Microsoft Sentinel / Defender

let Browsers = dynamic(["chrome.exe","msedge.exe","firefox.exe","brave.exe"]);
let ApprovedPasswordManagers = dynamic(["1password.exe","bitwarden.exe","keepassxc.exe","dashlane.exe"]);
let SuspectChildren = dynamic(["powershell.exe","pwsh.exe","mshta.exe","wscript.exe","cscript.exe","rundll32.exe","curl.exe","wget.exe","7z.exe","rar.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| extend Parent = tolower(InitiatingProcessFileName), Child = tolower(FileName)
| where Parent in~ (Browsers) and Child in~ (SuspectChildren)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Count=count(), Commands=make_set(ProcessCommandLine, 20) by DeviceName, AccountName, Parent, Child, ReportId
| extend Reason = "Browser spawned scripting/archive/network tool; investigate for cookie/session theft preceding passkey sync or IdP token abuse"
| sort by LastSeen desc;

KQL — Microsoft Sentinel / Defender

let IdPHosts = dynamic(["login.microsoftonline.com","login.windows.net","accounts.google.com","idp.example.com","sso.example.com","okta.example.com","auth0.example.com"]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl has_any (IdPHosts) or RemoteIP in (iot_list_optional)
| extend Proc = tolower(InitiatingProcessFileName)
| where not (Proc in~ (dynamic(["chrome.exe","msedge.exe","firefox.exe","brave.exe","microsoftedgecp.exe","officeclicktorun.exe","teams.exe","outlook.exe"]))) 
| summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), URLs=make_set(RemoteUrl, 30), Ports=make_set(RemotePort, 10) by DeviceName, InitiatingProcessAccountName, Proc, RemoteIP
| where Connections > 5 or URLs contains "token" or URLs contains "oauth" or URLs contains "device"
| sort by Connections desc;

VQL — Velociraptor

-- Identify processes with command lines consistent with credential/session theft staging and enumerate endpoint network connections to IdP endpoints
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(login data|cookies|local state|web data|dpapi|refresh[_-]?token|session|oauth|device code|webauthn|fido|passkey)'
   OR Name =~ '(?i)(powershell|pwsh|mshta|rundll32|curl|wget|7z|rar|winrar)'

VQL — Velociraptor

-- Correlate suspicious processes with live outbound connections that may indicate token/session exfiltration
SELECT proc.Pid, proc.Name, proc.Exe, proc.CommandLine, proc.Username,
       net.LocalAddr, net.LocalPort, net.RemoteAddr, net.RemotePort, net.State
FROM pslist() AS proc
JOIN netstat() AS net ON proc.Pid = net.Pid
WHERE net.State =~ 'ESTABLISHED'
  AND proc.CommandLine =~ '(?i)(token|cookie|credential|dpapi|passkey|webauthn|fido|login data|local state)'

PowerShell

# Passkey/FIDO posture spot-check for Windows endpoints. Run read-only first; review before enforcing.
$Report = [ordered]@{}
$Report.Computer = $env:COMPUTERNAME
$Report.Timestamp = (Get-Date).ToUniversalTime().ToString('s') + 'Z'

# Credential Guard and VBS reduce theft of secrets used around Windows Hello and SSO.
$cg = Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard -ErrorAction SilentlyContinue
$Report.CredentialGuardRunning = if ($cg) { $cg.SecurityServicesRunning -contains 1 } else { 'Unknown' }
$Report.VBSRunning = if ($cg) { $cg.VirtualizationBasedSecurityStatus -eq 2 } else { 'Unknown' }

# Consumer passkey sync should be evaluated against policy. Presence is not proof of compromise; use for inventory.
$HelloKeys = @('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication','HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication')
$Report.HelloPolicyValues = foreach ($k in $HelloKeys) { if (Test-Path $k) { Get-ItemProperty $k | Select-Object * } }

# Browser credential-store files accessed recently are weak signals alone; correlate with EDR file-access events and approved processes.
$stores = @(
  "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Login Data",
  "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cookies",
  "$env:LOCALAPPDATA\Microsoft\Edge\User Data\Default\Login Data",
  "$env:LOCALAPPDATA\Microsoft\Edge\User Data\Default\Cookies"
)
$Report.BrowserStoreFiles = foreach ($p in $stores) { if (Test-Path $p) { Get-Item $p | Select-Object FullName,Length,LastWriteTime,LastAccessTime } }

# Recent unusual processes touching network-heavy IdP paths should be triaged with EDR, not blocked from this output alone.
$Report.RecentScriptingChildren = Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1; StartTime=(Get-Date).AddDays(-3)} -ErrorAction SilentlyContinue |
  Where-Object { $_.Message -match 'ParentImage.*(chrome|msedge|firefox|brave)' -and $_.Message -match 'Image.*(powershell|pwsh|mshta|rundll32|curl|wget|7z|rar)' } |
  Select-Object TimeCreated, Id, Message -First 50

[pscustomobject]$Report | ConvertTo-Json -Depth 6

Immediate Defensive Actions

Enforce authentication strength, not MFA presence. Require phishing-resistant methods for privileged roles, financial approval, IdP administration, and recovery flows. In Entra ID, use authentication strengths and Conditional Access so passkey/FIDO2 cannot be replaced by SMS, voice, push, or TOTP for sensitive apps. In Okta, Google Workspace, Ping, Auth0, and similar platforms, require authenticator assurance and block fallback for high-assurance apps.
Govern new passkey registration as a high-risk change. Alert on any credential registration that follows password reset, email change, device enrollment, help-desk interaction, new country/ASN, impossible travel, or sign-in from unmanaged posture. Require step-up with an existing strong authenticator, hardware attestation, and manager/help-desk out-of-band verification for admins.
Constrain authenticators. Prefer attested hardware security keys for admins. Maintain an allowlist of AAGUIDs where the platform supports it. Reject or flag software authenticators and unknown attestation for high-assurance applications.
Protect sync fabrics. Treat Apple, Google, Microsoft, and password-manager accounts that sync passkeys as crown jewels. Require strong MFA and hardware-backed passkeys for those accounts, review recovery emails/phone numbers, disable legacy protocols, and alert on new device restore events.
Reduce token replay value. Shorten session lifetimes for sensitive apps, bind tokens to device where possible, enable continuous access evaluation, revoke refresh tokens on passkey registration changes, and monitor for impossible travel plus ASN/user-agent mismatch after successful WebAuthn.
Lock down browsers and extensions. Use enterprise browser management to limit extensions, block unapproved password managers, disable credential export where policy allows, and collect file-access telemetry for Login Data, Cookies, Web Data, Local State, cookies.sqlite, logins.json, and key4.db.
Prepare IR playbooks for passkey compromise. Steps should include revoking sessions and refresh tokens, removing newly registered authenticators, rotating sync-account credentials, forcing re-enrollment from managed devices, reviewing relying-party logs for assertion anomalies, and preserving WebAuthn attestation/assertion metadata.
Validate with adversary simulation. Test whether a reset flow, help-desk path, unmanaged device, or stolen cookie can bypass passkeys. Confirm SOC alerts fire before an attacker can register a new authenticator.

Remediation and Verification

Because the source names no CVE, remediation is configuration and telemetry driven rather than patch-only. Ask each IdP, browser, OS, and password-manager vendor these exact questions:

Can passkey private keys be restored to a newly signed-in sync account, and what additional verification gates restore?
Are new passkey registrations logged with credential ID hash, AAGUID, attestation format, user verification flags, client IP/ASN, device posture, session ID, and administrator/actor context?
Can fallback to SMS, voice, email, TOTP, or push be disabled per application and per role?
Are sessions revoked automatically when an authenticator is added, removed, reset, or used from an impossible-travel pattern?
Do APIs support allowlisting authenticator attestation and rejecting unknown AAGUIDs for high-assurance apps?

Verification should include a controlled test: attempt account recovery, add a passkey from an unmanaged VM, sign in from a new ASN with a copied session artifact, and intentionally fail WebAuthn to see whether downgrade is offered. If any path succeeds for privileged users, the rollout is not complete.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub