# The Phishing Tool That Survives Your Password Reset
Passkeys were supposed to be the thing that finally killed phishing. The pitch was elegant: no password to steal, no credential to replay, cryptographic proof of device ownership that an attacker sitting on the other side of a proxy couldn't intercept. Billions of dollars of industry marketing have gone into that story over the past three years.
A toolkit called iAuthFlow V2 just put a hole in it.
Researchers have identified a phishing framework capable of registering an attacker-controlled passkey during a compromised session — meaning that even after the victim discovers the breach, resets their password, and revokes every active session, the attacker still has a valid key to the front door. The passkey they registered doesn't disappear when you change your password. It just sits there, waiting.
## The Persistence Trick Nobody Prepared For
To understand why this is nasty, you need to understand what passkeys actually are at the protocol level. A passkey is a FIDO2 credential — a public/private key pair where the private key lives on your device and the public key is registered with the service. When you authenticate, your device signs a challenge with the private key and the server verifies it against the stored public key. No password travels over the wire.
The attack iAuthFlow V2 performs isn't breaking that cryptography. It's exploiting the *enrollment* moment. During a live adversary-in-the-middle (AiTM) phishing session — where the victim authenticates through an attacker-controlled reverse proxy, handing over their session cookie in real time — the toolkit uses that live, authenticated session to register a new passkey. The private key for that passkey lives on attacker infrastructure, not the victim's device.
Now the attacker has a passkey registered to the account. The victim gets suspicious, changes their password, revokes sessions. Standard incident response. The problem: none of that touches the registered passkey. Password resets don't delete FIDO2 credentials. Session revocation doesn't delete FIDO2 credentials. Most identity platforms treat passkey registration as a device-trust event, not a session-derived one — so revoking the session that *enabled* the registration doesn't retroactively undo it.
The attacker comes back hours, days, or weeks later, authenticates with their registered passkey, and walks right in. The account looks clean. No suspicious session, no unusual login from a known-bad IP. Just a valid passkey authentication.
## Your IR Playbook Has a Gap
This breaks the standard corporate incident response script in a specific and serious way.
When a credential compromise is detected — phishing report, suspicious login alert, helpdesk ticket — the playbook typically goes: reset the password, force MFA re-enrollment, revoke active sessions. Done. Account secured. iAuthFlow V2 makes that incomplete. If a passkey was registered during the compromised session, the account is not secured. It's an open door with a combination lock on it.
Security teams need to add a step they didn't have before: audit and purge registered passkeys and FIDO2 credentials on any account suspected of compromise. This is not something every enterprise identity team has built into their runbooks. Many SOC analysts may not even know where to look — passkey management UIs are still relatively new in most enterprise identity platforms, and some don't surface registered credentials in the same admin panels used for MFA management.
It's also worth noting what this implies for detection. Passkey authentication events are typically low-noise, high-trust signals. If your SIEM is set up to treat a successful passkey authentication as inherently lower-risk than a password+MFA event, an attacker using a fraudulently registered passkey may fly completely under the radar.
## AiTM Grows Up
iAuthFlow V2 isn't an isolated curiosity. It's the next generation of a family of tools — Evilginx, Modlishka, Muraena — that pioneered AiTM phishing as a systematic technique for bypassing MFA. Those earlier tools focused primarily on session cookie theft: intercept the authenticated session, replay the cookie, get access. Most enterprise defenses have gradually caught up: token binding, device fingerprinting, conditional access policies that evaluate device posture.
Each time defenders built a better mousetrap, the toolkits adapted. The passkey persistence technique is that adaptation. If session cookies are increasingly scrutinized and can be revoked, register a credential that *isn't* session-derived. It's the same strategic logic — find the gap in the revocation model — executed at a new layer.
There's a grimly appropriate irony here. The FIDO Alliance and major platform vendors have spent years arguing that passkeys are "phishing-resistant" by design. That's technically accurate for the authentication step: you can't phish a passkey out of a victim the way you can phish a password. But iAuthFlow V2 demonstrates that you can phish the *registration* of a new passkey. The authentication credential is phishing-resistant. The enrollment ceremony, apparently, is not — at least not in the way it's currently implemented across most platforms.
This will force a hard conversation about whether passkey registration should require additional friction: step-up authentication, push notifications to existing trusted devices, administrator approval flows for new device registrations. Some platforms already have elements of this. Many don't.
## What Defenders Should Do Right Now
The practical response isn't to retreat from passkeys — they're still a meaningful improvement over passwords plus TOTP. But the security model around them needs adjustment:
---
## HackWire Analysis
The timing of iAuthFlow V2 landing in the wild is not a coincidence. Major platforms — Microsoft, Google, Apple — have spent 2024 and 2025 aggressively pushing passkey adoption, and enterprise rollouts are now reaching meaningful scale. Attackers build tools for the defenses that actually exist, not theoretical ones. The fact that someone wrote a toolkit specifically to weaponize passkey registration tells you that passkeys are now widespread enough to be worth targeting.
What's being underreported in most coverage of this tool is the asymmetry it creates in incident response. Password resets are a muscle memory response at this point — helpdesks do them thousands of times a day, SOC runbooks assume they close the breach. The passkey persistence technique silently invalidates that assumption for any account that had a passkey registered during the compromised window. Security teams won't know they have a problem until the attacker walks back in with a credential that looks completely legitimate.
There's also a vendor responsibility angle here that nobody is pushing hard enough. Identity providers that support passkeys should be building anomaly detection into the registration flow itself: does this new passkey registration match the device posture we'd expect? Is the user's current session elevated in any unusual way? Is this the first passkey for the account? These are signals worth acting on. Some providers do this; many don't, because passkey registration has been treated as a UX simplification exercise rather than a security-critical event. That framing needs to change.
The broader lesson is one the industry keeps relearning: moving the authentication layer doesn't eliminate the attack surface. It relocates it. The next phishing toolkit will find the next seam. The only durable answer is defense in depth — and right now, most enterprise environments have a passkey-shaped hole in their incident response.
— HackWire Editorial
---
## Related Coverage