Passkey enrollment becomes a persistence trick: $10,000 kit outlives the password reset

Researchers at Abnormal AI have published an analysis of iAuthFlow v2, a phishing toolkit that uses a freshly phished Google session to enroll a passkey the attacker controls ^[1]. That single step inverts the usual containment logic: in the seller's recorded demonstration, the account owner changes their password and invalidates the live session, and the operator simply authenticates with the new passkey and returns to the mailbox ^[2].

The kit sells for a $10,000 base price with capability modules priced separately, and Abnormal has tracked it since it surfaced on a Russian-language cybercrime forum ^[3][5]. The build examined targets Google; the seller also advertises versions for Microsoft, iCloud and LinkedIn ^[7], four identity providers in total ^[22]. Abnormal is explicit that the work draws on the seller's forum posts, Telegram channel and demonstration videos plus Google's own documentation, and that researchers did not run the toolkit or sign into an account through it ^[8].

The mechanics are browser-in-the-middle. The target types into a Google-styled page in their own browser while a second browser on the attacker's server does the actual talking to Google, with credentials and prompts relayed in both directions ^[10]. In the recorded run, the target's unique link resolved to a subdomain of trycloudflare[.]com, Cloudflare's free tunneling service ^[12]. The toolkit applies a device fingerprint to its own browser before the target types anything ^[20], writes a timestamped system log of each stage ^[15], and records the email address, the password, and an authenticator code 40 seconds later ^[13]. Notably, the test account already had a passkey enrolled and Google offered it alongside the code; the target chose the code, which the relay passed through ^[18]. Google's SID and SSID cookies landing in the attacker-controlled browser are the kit's success signal ^[19]. Rather than forwarding the victim onward, the toolkit parks them on a "Verification, Processing" page served from the lure domain while it operates inside the account ^[14]. SecurityWeek's account of the analysis describes the passkey as added silently and authenticated by the target during the flow, without the target knowing what they are approving ^[11].

The remediation problem is structural, not incidental. Abnormal notes that changing the password and revoking sessions are the standard responses to a compromised mailbox, and that when access is limited to captured session cookies those actions normally end it ^[16]. Google's documentation says a password change revokes app passwords and OAuth tokens with Gmail scopes, though some authorized devices and third-party connections may remain signed in ^[17]. A passkey is neither: it is a credential registered to the account rather than a token derived from the password ^[4]. Recovery for the operator is a matter of choosing "try another way" at login and using the passkey, with no need to know the current password ^[6].

Worth keeping in proportion: SecurityWeek stresses that very little is publicly known about iAuthFlow V2 beyond the seller's own posts, and notes that Gemini describes it as a commercial phishing-as-a-service framework sold on forums such as Exploit while making no mention of passkeys at all ^[21].

What to watch: whether your incident playbook enumerates registered passkeys and security keys as a containment step, not just sessions and passwords. Abnormal's write-up ships IOCs and remediation guidance, and its central conclusion is that a password reset is no longer sufficient to close out a phishing compromise ^[9]. Watch also for the advertised Microsoft, iCloud and LinkedIn builds appearing in the wild ^[7], and for any second, independent confirmation that the passkey module works as demonstrated rather than as advertised ^[8].