A $10,000 Phishing Kit Does Not Break Your Passkey. It Enrolls Its Own — In About Six Seconds — And Your Password Reset Does Nothing.
- Patrick Duggan
- 5 hours ago
- 5 min read
The cryptography held. That is the part everybody is going to skip past, and it is the part that makes this worth writing about.
A toolkit called iAuthFlow V2, first seen advertised on a Russian-language cybercrime forum and analysed by Abnormal Security, sells for $10,000 with modules extra. It does not defeat WebAuthn. It does not steal a private key, forge an attestation, or break the origin binding that makes passkeys phishing-resistant in the first place. Every one of those controls works exactly as designed throughout the entire attack.
What it does instead is wait until you have authenticated, take the session you just created, and use it to enroll a second passkey that belongs to the attacker. Reported time to plant: about six seconds after authentication completes.
Then you change your password. Then you revoke all sessions. Then you tell the board it is contained.
It is not contained. The attacker's passkey is still enrolled, and a passkey does not care what your password is.
The mechanics, in order
The relay itself is old technology dressed for the occasion. The victim lands on an attacker-controlled page. The attacker is running a separate browser environment on their own server. Credentials and authentication responses relay from the victim's browser to that remote browser in real time, and the attacker applies the victim's device fingerprint to their own environment so the provider sees a familiar client. Everything the victim types is logged silently.
The new part is what happens in the seconds after success. With a live authenticated session in hand, the toolkit drives the victim's own browser to the account's passkey settings and requests a new credential. Because the request is presented through the phishing page, the victim performs the authentication gesture — the touch, the biometric, the PIN — believing they are completing the login they already started. They are not. They are signing the registration ceremony for a credential the attacker controls.
The provider observes this correctly and permits it, because it is correct: an authenticated user added a passkey to their own account. The analysis focuses on Google accounts.
Why your incident response playbook is now wrong
Reset the password. Revoke active sessions. Force re-authentication. Close the ticket.
That sequence is in essentially every mailbox-compromise runbook in existence, and it was correct for as long as the attacker's persistence lived in something the password governed — the password itself, or a session token derived from it. Both of those get invalidated by the reset.
An enrolled passkey is governed by neither. It is a first-class authentication factor bound to the account, provisioned through a legitimate flow, and it survives every step of that runbook. The attacker does not need your password again. They never needed it after the first six seconds.
So the response has to change shape. Containment is no longer about revoking what the attacker took. It is about auditing what the attacker added. After any suspected credential compromise, the question that matters is not "have we reset it" but "what changed on this account after the authentication event" — newly enrolled passkeys and security keys, new recovery phone numbers and addresses, new OAuth grants to third-party applications, new mailbox forwarding rules and filters, new app passwords, new trusted devices.
Every one of those is a persistence mechanism that outlives a password reset, and enrolled credentials are the one almost nobody currently enumerates, because until recently there was no reason to.
This is the second independent finding on the same hole this month
Here is the part that moves this from a single vendor report to a structural problem, and it is why we are writing it up rather than letting it pass.
In the same window, a Cornell study described passkeys being used to backdoor accounts past password resets in intimate-partner abuse scenarios — an abuser with momentary legitimate access to a device enrolls their own passkey, and the survivor's password reset does not remove it.
Different researchers. Different motive. Different threat model entirely — one is a $10,000 criminal toolkit sold on a forum, the other is somebody who already has physical access to the phone. Same structural gap: enrollment is a privileged action gated only by an authenticated session, and account recovery is not modelled as an attack surface.
When two unrelated lines of research arrive at the same seam within weeks, that is not a coincidence and it is not a product bug. It is a design assumption that was reasonable when the second factor was a code you typed and became unreasonable when it became a credential you provision.
We have a name for this shape because we keep meeting it: the hard perimeter holds perfectly and the bleed goes through the trusted soft middle. It was the Meta AI support bot granting account access in June. It was the OAuth grant in the Vercel breach. Here it is the enrollment ceremony. In every case the strong control did its job and the attacker simply used a different door — one that was left unlocked because it is not a door anybody thought of as a door.
What to do, in the order that helps most
This week, look. For every account you consider high-value — executives, finance, IT administrators, anybody with delegated mailbox access — pull the current list of enrolled passkeys and security keys and confirm each one is accounted for. Most providers expose this in security settings and via API. You are looking for a credential nobody remembers adding, typically registered within seconds of a login the user does remember.
Then instrument it. Credential-enrollment events are logged by the major providers. Alerting on "passkey added" is a cheap, low-noise detection that most organisations have simply never turned on, and it fires on the exact moment this attack succeeds. If you take one thing from this post, take that: the six seconds that defeat your runbook also produce a log entry.
Then rewrite the runbook. Add credential and recovery enumeration to your compromise response, ahead of the password reset rather than after it, so you know what you are dealing with before you tip the attacker off by locking them out of the door they stopped using.
And do not un-deploy passkeys over this. That would be the wrong lesson, badly wrong. Passkeys stopped the credential-phishing problem they were built for, and this toolkit costs $10,000 precisely because the cheap attacks no longer work. The failure is in the enrollment and recovery surface around them, not in the credential. Fix the surface.
Capped where we always cap it: this analysis rests on Abnormal Security's examination of forum posts and vendor demonstrations rather than a captured sample of the toolkit, which is worth saying out loud. The mechanism is coherent and the Cornell work corroborates the underlying gap independently, but "as advertised by the seller" is a weaker evidentiary tier than "as observed in a victim environment," and we are not going to pretend otherwise.
Sources
Abnormal Security's analysis of iAuthFlow V2, reported by SecurityWeek and The Register, 21 August 2026. Cornell University research on passkey enrollment and account backdooring past password resets, reported 15 August 2026. Netcraft's "Phishing After Passkeys" analysis of expected post-passkey attack classes.
Our own related coverage: the Meta AI support-bot account takeovers, the Vercel OAuth supply-chain compromise (20 April 2026), and the Verizon DBIR read on attackers no longer needing the click (2 July 2026).
If you go and audit enrolled passkeys on your high-value accounts this week, tell me what you find — especially if you find nothing, because a clean audit from a real tenant is a data point almost nobody publishes. Rate this post below.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=a-10-000-phishing-kit-does-not-break-your-passkey-it-enrolls-its-own-in-about-six-seconds-and
Comments