DEV Community

CaraComp
CaraComp

Posted on Originally published at go.caracomp.com

Biometrics: Fake Passkey Texts Hijack Microsoft 365

Why fake passkey rollouts are breaking authentication pipelines highlights an uncomfortable reality in modern application security: cryptographic protocols are only as secure as the onboarding workflow that bootstraps them.

Reports indicate threat actors are actively leveraging "passkey registration" social engineering scripts to hijack Microsoft 365 environments. Rather than attempting to break WebAuthn or client-side biometric cryptography, attackers are deploying Adversary-in-the-Middle (AiTM) reverse-proxy architectures to intercept session tokens and legacy credentials during fake enrollment flows.

For engineers designing auth systems, identity verification pipelines, and biometric workflows, this campaign exposes a critical vulnerability window in zero-trust architectures.

The Attack Vector: Exploiting the Enrollment Gap

The cryptographic foundation of WebAuthn and FIDO2 relies on public-key cryptography bound to a specific origin (domain). A properly registered passkey cannot be phished by a reverse proxy because the browser client will refuse to sign a challenge from an untrusted origin.

However, attackers are targeting the pre-enrollment state:

  1. Proxying the Handshake: Attackers deploy an AiTM proxy that mirrors legitimate corporate identity providers (IdPs).
  2. Harvesting the Primary Session: The user enters their primary credentials and completes an out-of-band MFA challenge (such as push notifications or SMS OTP).
  3. Session Hijacking & Token Extraction: The proxy captures the resulting session cookie or bearer token, bypassing multi-factor checks entirely.
  4. Persistence Injection: Using the authenticated session, attackers query identity APIs (like Microsoft Graph) to quietly register their own FIDO2 security keys, authenticator apps, or burner phone numbers.

The issue isn't biometric verification or cryptographic signatures; it is the bootstrapping phase where trust is established.

What This Means for Identity and Verification Architecture

If you are building or maintaining identity and access management (IAM) pipelines or biometric workflows, reliance on self-serve, unverified user onboarding creates systemic risk.

Here is how engineering teams need to adapt their architectural approach:

  • Strict Origin Validation and Passkey Bootstrapping: Never allow passkey or biometric enrollment over untrusted networks or from unmanaged devices without cryptographic attestation. Use client certificates or TPM-bound device health checks before exposing registration endpoints.
  • Continuous Access Evaluation (CAE): Expire and invalidate tokens dynamically based on IP or device telemetry anomalies rather than relying solely on static token expiration windows.
  • Separating Authentication from Verification: Authentication (proving you have a registered key) is fundamentally different from Identity Verification (proving who you are). When bootstrapping access or resetting credentials, secure systems rely on 1:1 facial comparison against a trusted reference image using high-precision Euclidean distance analysis rather than vulnerable out-of-band SMS or email tokens.
  • Restricting Secondary Credential Registration: Enforce step-up identity verification before allowing any account to register new FIDO2 authenticators or update backup MFA channels.

As developers, we cannot treat passkeys as a silver bullet if the enrollment pipeline leaves the front door open to AiTM proxies. Securing the perimeter requires verifying the human at the other end before granting cryptographic persistence.

How is your engineering team hardening the enrollment and bootstrapping phase of WebAuthn and passkeys against AiTM proxy attacks?

Top comments (0)