Abnormal has analysed iAuthFlow V2, a phishing-as-a-service kit sold on Russian-language cybercrime forums for $10,000, with modules priced separately.

It does what adversary-in-the-middle kits have done for years — relays a victim's login through a browser the attacker controls — and then does one thing more. During the flow, it silently registers an attacker-controlled passkey on the victim's account.

Why that one step changes the incident

Every mailbox compromise runbook says the same thing: reset the password, revoke the active sessions. Abnormal's framing is exact — when an attacker's access is limited to captured session cookies, those two actions normally end it.

A passkey is not a session and not derived from the password. It is a separate credential on the account. So the victim resets the password, kills every session, tells everyone it is handled, and the attacker signs back in with a credential the reset never touched.

The remediation is not weak here. It is aimed at the wrong object.

How the enrolment happens

The victim never approves anything they understand as approving.

  • The victim lands on the attacker's phishing page
  • The attacker's server runs a parallel browser session against the real service
  • Credentials and authentication responses relay between the two
  • The kit applies a device fingerprint and logs everything typed
  • An attacker-controlled passkey is added to the account
  • The victim completes what looks like an ordinary login, and in doing so authorises it

Gmail is the service in Abnormal's analysis.

This is not an argument against passkeys

Worth being clear, because the headline invites the wrong conclusion.

Passkeys defeat credential phishing properly — the private key never leaves the device and cannot be relayed. Nothing here breaks that. What is being attacked is the enrolment step, which is a different problem: the strength of a credential says nothing about the strength of the process that adds one.

We saw the manual version of this in UNC6671 talking targets through enrolling an attacker's passkey by phone. What is new is that it is now productised, automated, and on sale at a fixed price.

The pattern to carry forward: as authentication gets harder to defeat, attackers move to the surrounding processes — enrolment, recovery, and the help desk. Those are usually the least monitored parts of an identity system.

What to do

  • Add passkey enrolment to the compromise checklist. After a reset, list the account's registered credentials and remove anything not recognised. This is the single change that matters.
  • Alert on new passkey registration, particularly within hours of a suspicious sign-in. It is a rare event, so the alert is cheap.
  • Tell users what enrolment looks like, so an unexpected prompt during a normal login registers as wrong rather than as friction.
  • Treat "we reset the password" as an incomplete report. The follow-up question is which credentials were enumerated afterwards.
  • Review recovery paths at the same time. An attacker who could not add a passkey will try to add a phone number.

What is not established

  • How widely it is deployed. Abnormal describes the kit, not a victim count.
  • Which services beyond Gmail work. The analysis covers Gmail; the technique is not Gmail-specific.
  • Who is buying it. Phishing-as-a-service has many customers by design.
  • Whether the providers can detect the enrolment pattern. No vendor has said so publicly.