The Passkey Pwned Attack: Breaking the “Unbreakable”

Passkeys are marketed as the beginning of the passwordless era, a modern authentication strategy that will supposedly end phishing, neutralize credential stuffing, and render brute-force attacks obsolete. Security vendors package passkeys as a silver bullet — a cure for every authentication ailment. As red teams, we know better. Every new security control creates a new attack surface, a new blind spot, and a new place to push a pry bar.

Passkeys are not exempt. In fact, they introduce entire categories of weaknesses that are invisible to organizations who believe “passwordless” means “invulnerable.” The truth is more nuanced. Passkeys eliminate the low-hanging fruit, but they also create high-value weaknesses that can be exploited through misbinding, malware-driven origin tampering, cloud sync compromise, malicious enrollment workflows, and strategic endpoint abuse.

This blog lays out a red-team view of how modern attackers approach passkey-centric environments, how the threat surface shifts, and where offensive tradecraft can bend the system into producing authentication assertions that benefit the adversary instead of the defender.

Part I — Understanding the Terrain: What Passkeys Actually Are

Before breaking something, it’s essential to understand how it works.

A passkey is a WebAuthn credential composed of:

A private key (stored on a device or synced across multiple devices)
A public key registered with a website or identity provider
A binding to a specific origin (or Relying Party ID)
Metadata about the authenticator and client environment

The private key should never leave the user’s device. When a user “logs in,” the authenticator produces a signed assertion proving possession of the private key.

The security industry often repeats the mantra:

“Passkeys can’t be phished.”

But the red-team reality is:

“Passkeys can’t be traditional phished — but they can be misused, misbound, relayed, subverted, or replayed under the right conditions.”

Phishing isn’t dead. It’s just evolving.

Part II — The Red-Team Threat Model: Where Passkeys Bend

Passkey attacks do not resemble classic password theft. Instead, they revolve around:

Manipulating the origin
Exploiting sync mechanisms
Hijacking the endpoint
Abusing recovery flows
Force-enrolling attacker-controlled passkeys
Leveraging sloppy enterprise implementations

The strength of passkeys is their origin binding, but anything that bends the origin or tricks the client into signing for the wrong RP becomes a powerful exploit.

We break down the major categories below.

Part III — Attack Vector #1: The Misbinding Exploit

The most potent attack against passkeys is the misbinding attack, a scenario where the user believes they are creating or using a passkey for one domain, but the system actually binds (or uses) it for another.

This occurs when:

A mobile application uses embedded WebViews
An enterprise identity provider exposes inconsistent redirect origins
A reverse proxy rewrites host headers improperly
A browser extension manipulates the URL bar or DOM
A malicious app triggers the passkey prompt with its own RPID

From a red-team standpoint, the misbinding attack is elegant because it occurs inside the normal protocol. Nothing is “broken” in FIDO2—you’re simply redirecting trust.

Attack Flow

Target is directed to a login prompt through an attacker-controlled app or script.
The attacker controls the WebView or browser origin.
The client generates an authentication assertion for the attacker’s RPID.
The attacker forwards that assertion to the legitimate site, completing the login.

This turns WebAuthn into a silent, cryptographically validated proxy.

Users rarely see the true origin inside mobile applications, so the entire phishing barrier collapses when there is no visible URL bar.

Part IV — Attack Vector #2: Cloud Sync Compromise

Syncable passkeys are the convenience trade-off of modern authentication. Apple, Microsoft, and Google allow passkeys to be shared across user devices. This introduces an overlooked but devastating reality:

If the attacker compromises the sync cloud account, they compromise every synced passkey within it.

From a red-team perspective, this opens several pathways:

Compromise of the user’s iCloud, Google, or Microsoft account
Hijacking OAuth refresh tokens stored on an endpoint
Session hijacking through browser token theft
Abuse of device-based encryption keys cached in memory
Extraction of synced passkeys from rooted or jailbroken systems

The user’s device login effectively becomes the encryption key. If attackers take the cloud account plus one enrolled device (or a valid token), the encryption model collapses.

Red Team Play

Gain initial access.
Dump browser profiles and token stores.
Access the user’s cloud identity account.
Extract synced passkey material.
Replay authentication assertions.

The victim’s passkeys become adversary credentials.

Part V — Attack Vector #3: Local Authenticator Hijacking

If the attacker compromises the endpoint, passkey protections evaporate. The attacker can:

Trigger WebAuthn requests silently
Modify the origin field
Use accessibility APIs to auto-approve prompt dialogs
Inject scripts that manipulate clientDataJSON
Replay signed assertions captured from memory

Passkey prompts can be generated by local processes, not just user-initiated browser actions. Malware can call the WebAuthn API silently, collect the signed response, and exfiltrate it.

Example Scenario

Malware executes locally.
It spawns a headless browser instance.
It initiates a WebAuthn signing request.
The authenticator signs the challenge.
Malware exfiltrates the assertion.
The red team replays it against the identity provider.

The user sees nothing unusual. Their device simply signed something they didn’t know about.

Passkeys protect servers from remote credential theft; they do not protect victims from their own compromised endpoints.

Part VI — Attack Vector #4: Real-Time Relay Against Fragile Implementations

Relay attacks against passkeys require controlling:

The challenge
The origin
The RPID
The clientDataJSON
The authenticatorData

Standards-based passkey implementations resist relays, but enterprise environments often degrade the protections through:

Reverse proxies rewriting hostnames
Identity providers accepting mismatched RPIDs
Load balancers mishandling WebAuthn headers
Legacy U2F fallback modes
Mobile apps ignoring URL origins entirely

In these situations, a red team can position itself in the middle, let the browser sign the attacker-origin challenge, and forward the signed assertion to the real service.

If the backend accepts it, the attacker logs in without ever touching the legitimate client.

The exploit hinges on enterprise misconfiguration, which is far more common than defenders realize.

Part VII — Attack Vector #5: The Fake Enrollment Attack

The most overlooked passkey attack vector is not stealing an existing passkey — it’s registering a new one under the attacker’s control.

Many identity providers allow the addition of new passkeys with minimal friction:

Only username + password required
No out-of-band verification
Recovery flows that skip MFA
“Add device” prompts with vague messaging

From a red-team standpoint, the attack resembles MFA fatigue or push fraud.

Attack Sequence

Attacker logs in with compromised credentials.
Provider requests MFA.
Attacker selects “Add a new passkey.”
Victim receives a generic approval prompt.
Attacker spoofs a pretext: “Approve to keep your account active.”
Victim accepts.
Attacker registers their own hardware or synced authenticator.

Once enrolled, the attacker’s passkey becomes indistinguishable from a legitimate device.

Part VIII — Attack Vector #6: Device Cloning & Hardware-Level Extraction

Hardware-bound FIDO2 authenticators resist extraction. Mobile device implementations often do not. Red teams frequently encounter:

ADB-enabled Android devices
Bootloaders unlocked
Rooted or jailbroken OS-level access
Insecure keystore management
Full-device backups

In those scenarios, an attacker can:

Dump keystore material
Extract platform-bound passkeys
Clone device images into emulators
Re-register cloned identifiers as new passkeys

Even if the private key never leaves the secure element, the surrounding metadata, challenge data, and intermediate values often do. With sufficient endpoint control, these become accessible.

When the endpoint is compromised, “hardware-backed” becomes a marketing term rather than a security boundary.

Part IX — Offensive Strategy: Turning Passkeys into Tools

The red team objective is not to break the underlying cryptography. It’s to subvert the trust relationships passkeys rely on.

Passkeys can be weaponized to:

Validate forged SSO sessions
Persist attacker access through rogue enrollment
Defeat MFA enforcement
Bypass password requirements entirely
Escalate privileges through SSO session cloning
Maintain near-undetectable persistence

To the defender, an attacker-controlled passkey appears as a legitimate device. There is no suspicious password reset, no authentication anomaly, no brute-force noise. A passkey compromise is stealthy by nature.

Once the attacker controls a passkey — by misbinding, synchronization hijack, or direct endpoint access — the account effectively belongs to them until the defender manually revokes the credential.

Part X — Defensive Blind Spots Red Teams Rely On

Most organizations adopting passkeys have:

No alerting for new passkey registrations
No SIEM ingestion for WebAuthn logs
No requirement for hardware-only authenticators
No RPID pinning
No monitoring of passkey sync activity
No auditing of WebAuthn device metadata
Poor client-side origin controls
Inconsistent mobile login flows

These blind spots create the perfect environment for undetected red-team persistence.

Common findings include:

SOCs that cannot identify which passkeys belong to which users
IAM teams unaware of how to list registered authenticators
Identity providers displaying ambiguous entries like “Authenticator #2”
Lack of revocation workflows
Reliance on insecure fallback authentication

The absence of visibility is the attacker’s biggest advantage.

Part XI — Future Offensive Trends

As passkeys continue to permeate enterprise environments, offensive tactics will expand.

1. Browser Extension-Based Origin Manipulation

Extensions will evolve to intercept, alter, or forge:

URL origins
clientDataJSON values
WebAuthn ceremony data

This will enable new misbinding variations.

2. Automated Enrollment Social Engineering

AI-assisted pretexting will make enrollment attacks far more convincing:

Deepfake help desk calls
Automated scripts prompting victims to approve enrollments
Coordinated fake alerts from cloned identity portals

3. Assertion Replay via Encrypted Channels

If attackers obtain assertions, real-time replay using automated frameworks becomes trivial.

4. Downgrade Chains Against Hybrid Authentication

Most enterprises still support:

Password fallback
SMS or email MFA
Backup recovery codes
Legacy WebAuthn U2F flows

Red teams will exploit the downgrade path to bypass passkeys entirely.

Part XII — Conclusion: Passkeys Shift the Battlefield, They Don’t Secure It

Passkeys represent a significant advancement, but they are not impervious. They eliminate certain classes of attacks while exposing new ones. For offensive operators, they open doors to:

More subtle misbinding opportunities
More impactful endpoint compromises
More valuable cloud-account takeover vectors
More persistent identity-level footholds

Defenders who believe passkeys equal immunity will remain vulnerable. Those who recognize the new threat landscape — one rooted in client-side trust, identity sprawl, and silent authentication flows — will build the necessary controls to defend against a new generation of attacks.

Passkeys change how attackers operate; they don’t eliminate the adversary. They simply redefine the rules of engagement, and in that transition, a skilled red team can often find more room to maneuver than before.

ITInnovationStation