> ## Content Index
> Fetch the complete content index at: https://www.thecybersignal.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# iAuthFlow V2 Phishing Kit Plants Attacker Passkeys to Survive Password Resets
- URL: https://www.thecybersignal.com/iauthflow-v2-phishing-toolkit-passkey-persistence-2026/
- Published: 2026-08-22T16:02:00.000Z
- Updated: 2026-08-22T16:01:59.000Z
- Description: Researchers at Abnormal documented iAuthFlow V2, a $10,000 phishing toolkit that registers an attacker-controlled passkey on a compromised account. Because a passkey is a credential, not a password token, it survives the reset and session revocation that normally evict a phisher.
- Author: Nicholas Robert
- Tags: Phishing, Identity Security, Passkey / FIDO2

The two moves at the top of nearly every phishing-response playbook are reset the password and revoke the active sessions. A phishing toolkit now on sale is built so that neither one locks the attacker out.

Researchers at [Abnormal](https://abnormal.ai/blog/iauthflow-v2-phishing-google-passkeys?ref=thecybersignal.com) documented **iAuthFlow V2**, a phishing toolkit advertised for $10,000 on a Russian-language cybercrime forum that silently registers an attacker-controlled passkey (a FIDO2 / WebAuthn credential) on the account it compromises. Because a passkey is a credential registered to the account rather than a token derived from the password, it survives the password reset and session revocation that normally end a phisher's access. [SecurityWeek reported](https://www.securityweek.com/new-phishing-toolkit-uses-passkeys-to-maintain-access-after-password-resets/?ref=thecybersignal.com) the analysis on August 21, 2026.

One caveat sits under all of this, and it matters for how much weight to put on the toolkit. Abnormal built its analysis from the seller's forum posts and demonstration material, not from acquiring or running the malware, and the demonstrated target was a single Gmail account. So the mechanism is documented from the vendor's own sales pitch rather than from an infection observed in the wild. The defensive lesson, though, does not depend on the toolkit being real: any account-recovery process that stops at the password has the same blind spot.

## What Abnormal Documented

The core claim is narrow and specific. During a successful phishing session, iAuthFlow V2 registers a passkey that the attacker controls onto the victim's account. That credential is the payload. Everything defenders usually reach for after a phishing hit is aimed at password-derived access, and this credential is not password-derived.

Abnormal frames the gap in plain terms. "Changing the password and revoking active sessions are standard responses to a compromised mailbox. When an attacker's access is limited to captured session cookies, those actions normally end that access," the company writes in its analysis. The problem is that the attacker's access here is not limited to session cookies. It is anchored in a registered authenticator.

This is a different failure than the adversary-in-the-middle phishing kits that have dominated the past year, where the prize is a live session cookie that a reset can still kill. We covered that pattern when [Microsoft traced an AiTM campaign](https://www.thecybersignal.com/microsoft-aitm-phishing-code-of-conduct-35000-users-13000-orgs-may-2026/) across tens of thousands of users. iAuthFlow V2's twist is that it converts a one-time phishing success into a standing credential, and standing credentials are exactly what passkeys were meant to make trustworthy.

The price tag is part of the story. At $10,000 for the base kit with modules sold separately, iAuthFlow V2 sits at the premium end of the phishing-as-a-service market, which is one reason so little about it is public. Abnormal is candid that its picture comes from the seller's marketing, and it notes that even AI assistants queried about the toolkit return thin or contradictory descriptions. That uncertainty cuts both ways. The exact capabilities are unverified, but the technique it advertises, turning a phishing hit into a registered credential, is well within what the WebAuthn model allows for anyone who can complete a login as the victim.

The timing matters because passkeys are finally mainstream. Google, Microsoft, and Apple have spent two years pushing users onto passkeys as the phishing-resistant default, and adoption has climbed with them. A technique that abuses passkey enrollment therefore lands on a far larger installed base than it would have a year ago, and it targets exactly the accounts security teams were most confident about.

## Why a Password Reset Does Not Evict It

A password reset invalidates the things that hang off the password. Google, for the Gmail case Abnormal examined, revokes app passwords and OAuth tokens with Gmail scopes when the password changes, though it notes some authorized devices and third-party connections may stay signed in. Session revocation kills the browser cookies that keep an attacker logged in. Between them, those two steps clear the usual residue of a phishing compromise.

A passkey answers to none of that. As Abnormal puts it, the reset "does nothing to the new passkey which is a credential registered to the account rather than a token derived from the password." The attacker does not need to know the current password to come back. At the login screen, they select the alternate sign-in option and authenticate with the passkey they registered. The account looks recovered to the user and to the help desk, and the attacker still holds a key to the front door.

Incident responders have been here before, in a smaller way. The mature phishing playbook already reaches past passwords and sessions: it hunts for rogue OAuth app grants, attacker-created mail-forwarding rules, and app passwords, because each is a foothold that a password change leaves untouched. An attacker-registered passkey belongs on that same list. The difference is that a passkey is not a side channel or a leftover token. It is a first-class login credential, so leaving one behind is closer to handing over a spare key than to forgetting to kill a session.

For the targeted organization, the practical effect is dwell time. A phisher who would otherwise be evicted within hours of detection can quietly keep account access for as long as the rogue passkey goes unnoticed, which is exactly the window that business email compromise and slow data theft depend on. The reset closes the incident on paper while the access stays open.

The diagram below lays out where the standard playbook lands and what it misses.

| ● The Remediation Gap Why the standard post-phishing playbook does not evict an attacker-registered passkey.                                                                                                                                                            |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Standard Response Reset the password and revoke active sessions. This clears stolen passwords, session cookies, and OAuth tokens scoped to the mailbox.                                                                                                                 |
| ↓                                                                                                                                                                                                                                                                       |
| What Survives The attacker-controlled passkey. It is a FIDO2 / WebAuthn credential registered to the account, not a token derived from the password, so a reset does not touch it. The attacker returns by choosing the alternate sign-in option and using the passkey. |
| ↓                                                                                                                                                                                                                                                                       |
| Close The Gap Make credential review part of account recovery: enumerate every registered passkey, remove any the user does not recognize, and alert on new WebAuthn registrations.                                                                                     |
| Source: Abnormal analysis of iAuthFlow V2, via SecurityWeek (Aug. 21, 2026). Diagram by The CyberSignal. Defender view; no exploitation detail.                                                                                                                         |

## What IAM Teams Should Add

The fix is not a new product. It is treating registered credentials as part of the compromise, the same way you already treat passwords and sessions. Four additions turn a standard recovery into one that actually evicts this class of attacker.

- **Audit passkey and WebAuthn enrollments after any account-recovery event.** The moment an account is reset for suspected phishing, enumerate every passkey and security key on it and confirm each one with the user. A credential the user cannot place is the whole game here.
- **Review WebAuthn attestation logs.** Registration events carry attestation data and timing. A passkey enrolled minutes after a suspicious sign-in, from an unfamiliar device, is the signal that a reset alone would have buried.
- **Force passkey re-enrollment on account recovery.** For high-value accounts, treat recovery as a reason to invalidate existing authenticators and have the real user register fresh ones. That closes the door even if the review misses a rogue credential.
- **Alert on new credential registration.** A new passkey on an executive, admin, or finance account should page someone, not sit silently in an audit trail. New-authenticator registration deserves the same monitoring weight as an impossible-travel login.

For teams that want to operationalize this, the signal lives in the identity provider's audit trail. Google Workspace records security-key and passkey enrollment under its account security events, and Microsoft Entra ID logs authentication-method registration in its audit logs. Pull those events, correlate them with the sign-ins around a suspected compromise, and a passkey that appeared during the incident window stops being invisible. The goal is not to distrust every new credential. It is to make new-authenticator registration a reviewable event rather than a silent one.

Practically, this is a runbook change more than a tooling purchase. Add a credential-review step to the account-recovery checklist, write the passkey-enumeration query for your identity provider before you need it, and put attacker-registered authenticators into the next tabletop exercise so the muscle memory exists when a real compromise lands.

None of this is Gmail-specific. Any identity provider that supports passkeys, from Okta to Microsoft Entra ID, has the same structural property: a registered authenticator outlives a password change. The remediation gap belongs to the account model, not to one vendor's implementation.

**My read:** passkeys close the phishing hole they were built to close, and in doing so they move the soft spot to enrollment. Once "sign in" is a cryptographic credential instead of a shared secret, "register a new credential" becomes the persistence primitive an attacker wants, and most account-recovery runbooks still do not look there. This is the same lesson from a separate strand of research we covered when [Unit 42 showed passkeys are not one uniformly safe category](https://www.thecybersignal.com/unit-42-pass-ta-key-google-password-manager-passkey-2026/). The defensive work is not to distrust passkeys. It is to start auditing the enrollment surface with the same rigor we spent a decade building around passwords and sessions.

## What Is Not Confirmed

Several details are worth flagging rather than asserting. Abnormal's write-up rests on the seller's own posts and a demonstration, not on a captured sample, and Abnormal says so plainly. The demonstrated target was Gmail; other outlets have reported the broader toolkit pitches Google, Microsoft, iCloud, and LinkedIn as targets, but I have not confirmed the passkey module against any identity provider other than the Google case Abnormal examined. I have seen no named real-world victims, no independent confirmation of the phishing-page templates it ships, and no statement from Google, Microsoft, or Okta that they have deployed detections specific to this technique. Treat the toolkit's exact capabilities as vendor-described until a sample or an incident confirms them, and treat the defensive gap as real regardless, because it follows from how passkeys work.

### Primary Documents

- [Abnormal, "iAuthFlow V2: Phishing Google Passkeys" analysis (IOCs and remediation guidance)](https://abnormal.ai/blog/iauthflow-v2-phishing-google-passkeys?ref=thecybersignal.com)
- [SecurityWeek, "New Phishing Toolkit Uses Passkeys to Maintain Access After Password Resets" (Aug. 21, 2026)](https://www.securityweek.com/new-phishing-toolkit-uses-passkeys-to-maintain-access-after-password-resets/?ref=thecybersignal.com)