iAuthFlow v2 & Pass-the-Passkey (CVE-2026-34348): The $10,000 Attack Turning Your Passkeys Against You

Your organisation just rolled out passkeys. Your CISO announced it in the all-hands: “We’ve finally eliminated phishing.” A week later, a threat actor on a Russian-language forum is selling a toolkit that plants their own passkey into your users’ accounts in under six seconds — and your password reset does nothing to stop them.

Welcome to the post-passkey era. In the past fortnight, three independent research teams and one criminal marketplace have shattered the comfortable myth that passkeys are inherently phishing-resistant. The identity security assumptions you built your zero-trust architecture on need an urgent audit.

Three Research Bombs and One Criminal Marketplace

August 2026 will be remembered as the month that brought passkey security back to earth. The convergence started at Black Hat USA 2026 (August 5), where SpecterOps presented Pass-the-Passkey, demonstrating how Windows Event Logging stored WebAuthn assertion signatures from hardware security keys in readable plaintext. Within days, Unit 42 published its Golden Pass-ta-Key research targeting Google Password Manager’s synced credential infrastructure. Researcher Dirk-jan Mollema added a third vector exploiting Windows Hello in already-compromised sessions.

Then, on August 20, 2026, Abnormal Security found something chilling on a criminal forum: iAuthFlow v2, a polished, commercially sold phishing toolkit specifically engineered to weaponise the passkey enrollment process itself — no CVE required.

How iAuthFlow v2 Works: A Six-Second Backdoor

iAuthFlow v2 operates through a four-stage browser-in-the-middle (BitM) architecture that exploits the passkey enrollment flow rather than any cryptographic weakness:

1. Phishing Relay: The victim receives a unique link to a fake Google (or Microsoft, iCloud, LinkedIn) sign-in page hosted via Cloudflare Tunnels. The page is indistinguishable from the legitimate login experience; it proxies every interaction in real time to an attacker-controlled remote browser.
2. Session Hijack: Once the victim completes authentication — including any MFA challenge — the attacker’s server-side browser obtains authenticated SID/SSID session cookies with full account access.
3. Stealth Passkey Enrollment: While displaying a “Verification, Processing…” hold screen to the victim, iAuthFlow v2 uses the authenticated session to silently register an attacker-controlled WebAuthn credential. The entire enrollment takes approximately 6 seconds. A software-based virtual authenticator retains the credential’s private key on the attacker’s infrastructure.
4. Persistent Re-entry: When the victim notices suspicious activity, changes their password, and revokes all active sessions — the standard incident-response playbook — the attacker simply authenticates again using their enrolled passkey. Password resets do not remove attacker-enrolled passkeys.

The toolkit is priced at $10,000 for the base package, with additional modules sold separately for Microsoft, iCloud, and LinkedIn targets. It was discovered listed on Russian-language cybercrime forums by Abnormal Security researchers, who analysed seller demonstrations rather than executing the malware itself.

Detection fingerprints published by Abnormal Security include a Shodan MMH3 favicon hash of 1987889572, a stylesheet SHA-256 of 9dd237a185b6c2ff26a10cb9d1f670a59c1a0b4b, and session cookies using access_key=<32 hex characters>. These indicators should be immediately loaded into your threat intelligence platforms and SIEM rules.

CVE-2026-34348: When Your YubiKey Becomes the Attacker’s YubiKey

SpecterOps researchers Karl Fosaaen and Ethan Robish discovered that the Windows Event Logging Service was writing WebAuthn assertion signatures — the cryptographic proof produced by a hardware security key like a YubiKey during authentication — to event log files in cleartext. Any low-privilege domain user with read access to those logs could extract a valid, unexpired signature and replay it against Microsoft Entra ID, successfully impersonating a privileged account and bypassing phishing-resistant MFA entirely.

CVE	CVSS	Attack Type	Target	Status
CVE-2026-34348	6.5	Signature replay from Event Log	Windows / Entra ID	Patched July 2026
Golden Pass-ta-Key	N/A	Synced private-key extraction	Google Password Manager	No revocation mechanism
Windows Hello Abuse	N/A	TPM assertion without re-auth	Windows Hello / Entra ID	Mitigations in progress
iAuthFlow v2	No CVE	BitM passkey enrollment	Google, Microsoft, iCloud, LinkedIn	Actively sold ($10K)

Microsoft patched CVE-2026-34348 in the July 2026 Patch Tuesday cycle — Windows updates now make WebAuthn assertions written to event logs unusable for replay. However, SpecterOps noted as of August 10 that Entra ID itself had not yet received corresponding hardening on challenge validation. If you haven’t applied July 2026 Windows updates across your domain controllers and endpoints, this is a priority-one gap.

The Zero-Trust Blind Spot: Why This Changes the Calculus

Zero-trust architectures rest on a foundational assumption: “verify every access, every time, regardless of network location.” Passkeys became the verification mechanism of choice precisely because they were categorised as phishing-resistant. The discoveries of this month reveal that the verification layer itself can be compromised without breaking cryptography.

Consider what this means for a typical enterprise in India’s BFSI, IT, or pharma sector deploying hybrid Microsoft 365 environments:

• A phishing email targets a finance director. The iAuthFlow v2 page captures credentials AND enrolls a rogue passkey — all while the user thinks they just completed a routine verification.
• The SOC’s next-morning alert fires on the initial credential capture. The analyst resets the password and revokes sessions. Incident closed.
• Six weeks later, the attacker silently re-enters via the enrolled passkey, accesses the SharePoint environment, and begins exfiltrating financial documents — all from a clean authentication event that shows a valid passkey login.

This is not hypothetical. It is the precise persistence mechanism that iAuthFlow v2 is designed and sold to enable. The fact that this attack mirrors APT29’s documented OAuth persistence playbook should concern every CISO — nation-state techniques are now available to any criminal with $10,000.

The Microsoft Entra ID vulnerabilities we have seen exploited this month reinforce a clear pattern: identity infrastructure is the new perimeter, and it is under sustained, sophisticated assault.

What You Should Do Right Now

As a cybersecurity consultant who works with enterprises across Delhi NCR on zero-trust architecture and identity security, my recommendations are specific and sequenced:

1. Apply July 2026 Windows patches immediately. CVE-2026-34348 is patched — but only if your endpoints and domain controllers are current. Run a vulnerability scan today and close this gap before exploitation tooling proliferates.
2. Audit enrolled passkeys and security keys across all user accounts. For Microsoft environments: review Azure AD > Users > Authentication Methods and flag any FIDO2 credentials enrolled from unfamiliar devices or registered outside business hours. For Google Workspace: check Admin Console > Users > Security > 2-Step Verification and revoke unrecognised passkeys.
3. Hunt for iAuthFlow v2 infrastructure. Load the Shodan favicon hash (1987889572) and the stylesheet SHA-256 into your threat intelligence feeds. Block the session cookie pattern access_key=<32hex> at your web proxy. Flag unusual Cloudflare Tunnel domains in DNS logs.
4. Treat passkey enrollment as a high-risk event requiring approval. Implement manager-approval workflows or step-up authentication (including a separate hardware token) before any new passkey or FIDO2 credential can be registered on privileged accounts.
5. Implement Continuous Access Evaluation (CAE) for Microsoft 365. CAE enforces near-real-time session revocation and can significantly reduce the persistence window of compromised passkey sessions.
6. Require device attestation in WebAuthn policies. Platform authenticators (Touch ID, Windows Hello) tied to hardware TPMs are dramatically harder to spoof than software-based virtual authenticators like those used by iAuthFlow v2. Enforce attestation verification in your WebAuthn Relying Party configuration.
7. Brief your SOC on the updated incident-response checklist. When a phishing incident is detected: password reset + session revocation is no longer sufficient. Add a mandatory step: enumerate and revoke ALL passkeys and FIDO2 credentials on the compromised account. Document this in your IR playbooks today.

For organisations using Google Workspace: enable the “Only security key” restriction in 2-Step Verification settings and consider enrolling high-risk users in the Advanced Protection Program, which restricts which applications can access account data and adds friction to new device/key enrollment.

Frequently Asked Questions

Does this mean passkeys are broken and we should stop using them?

No — passkeys remain far superior to passwords and SMS-based OTP, which are trivially phishable. The vulnerabilities uncovered this month exploit implementation flaws in surrounding systems (event logging, sync mechanisms, enrollment controls) rather than the underlying WebAuthn/FIDO2 cryptography. The answer is hardened passkey deployment with proper enrollment controls, attestation enforcement, and proactive credential auditing — not abandonment.

Are FIDO2 hardware security keys (YubiKey, Titan) still the gold standard?

Hardware security keys remain the strongest available authenticator for high-privilege accounts, but CVE-2026-34348 demonstrates that the surrounding OS infrastructure can undermine them if not patched. Apply July 2026 Windows updates, enforce hardware attestation, and treat signature logging as a security-sensitive data plane requiring protection equivalent to credential storage.

How does iAuthFlow v2 get around Google’s or Microsoft’s device-binding protections?

iAuthFlow v2 exploits a window during active, authenticated sessions — before any device-binding verification is anchored. It uses a software-based virtual authenticator (leveraging Chromium’s WebAuthn API) to enroll a credential that is technically valid under the platform’s enrollment policy. The platform authenticates the session, not the physical device, at enrollment time. This is why enforcement of hardware attestation at the Relying Party level is the critical control — it would reject a software-based virtual authenticator credential at enrollment.

How should India-based enterprises using Microsoft 365 and hybrid Active Directory respond specifically?

Prioritise three actions: (1) apply July 2026 Windows patches to all AD CS and domain controller infrastructure — CVE-2026-34348 is especially dangerous in environments with on-premises AD federated to Entra ID; (2) enable Phishing-Resistant MFA policy in Entra Conditional Access and set it to require hardware attestation for all FIDO2 credentials; (3) run the Entra ID Sign-In Logs query for passkey-based authentications over the past 90 days and validate each enrolled credential against your authorised device inventory. If you find unrecognised entries, assume compromise and escalate.

---

The identity layer is your new perimeter. Three Black Hat presentations and one criminal marketplace listing in a single week prove that attackers are obsessively focused on breaking the “phishing-resistant” label — and succeeding through implementation gaps rather than mathematical breaks. Your passkey deployment is only as secure as the enrollment controls, patch cadence, and incident-response procedures around it.

If you are unsure whether your organisation’s identity security posture is ready for this threat landscape, let’s talk. Sanjay Seth and the P J Networks team specialise in zero-trust architecture design, identity security reviews, and SOC advisory for enterprises across India. Request a security assessment →