As reported by SecurityAffairs, Abnormal Security has published analysis of iAuthFlow v2, a browser-in-the-middle phishing toolkit that does something genuinely novel: it uses a stolen authenticated session to enroll an attacker-controlled passkey on the victim's Google account. That passkey persists even after the victim resets their password. This is not an incremental phishing evolution — it is a structural challenge to how defenders think about session persistence and incident response.

Threat Alert: As reported by SecurityAffairs, Abnormal Security has published analysis of iAuthFlow v2, a browser-in-the-middle phishing toolkit that does something genuinely novel: it uses a stolen authenticated session to enroll an attacker-controlled passkey on the victim's Google account.

The Real Threat Is Post-Authentication, Not the Phishing Itself

Defenders have spent years optimizing for phishing-resistant MFA, and passkeys are the current gold standard. iAuthFlow v2 doesn't break passkeys — it enrolls them. The attack chain is straightforward: browser-in-the-middle captures credentials and MFA, the attacker obtains a valid session, and within seconds that session is used to register a new passkey under attacker control. The original phishing becomes almost irrelevant; the enrolled passkey is the actual compromise.

The six-second window between login and passkey enrollment means detection must happen at authentication velocity, not human review velocity.

This reframes the problem. The session cookie is temporary. The passkey is permanent. Traditional advice — reset your password, revoke sessions — addresses the temporary artifact while leaving the permanent one untouched.

Who Is Affected and Why It Matters Broadly

Who Is Affected and Why It Matters Broadly
Google Workspace admins: Directly exposed today. Enrolled passkeys appear in the account's security settings but may not trigger alerts unless admin logging is specifically tuned for credential enrollment events.
Enterprises relying on password reset as incident response: The standard playbook for suspected phishing — force password reset, revoke active sessions — is now insufficient. The persistence layer sits above the credential layer.
Any identity provider supporting passkey enrollment via authenticated sessions: While this demo targets Google, the architecture is portable. Microsoft, Apple, and other FIDO2-supporting IdPs that allow in-session credential enrollment face the same conceptual risk.
Cloudflare TryCloudflare users: The use of trycloudflare.com subdomains with valid TLS is notable. Free tunneling services are being abused for legitimacy, and allowlist-based URL filtering will not catch dynamically generated subdomains.

The Commoditization Signal

A $10,000 base price with modular upsells positions this as a premium crimeware product, not a hobbyist tool. The pricing suggests the author expects a market of operators who can monetize persistent mailbox access — business email compromise, financial fraud, internal communications theft. The modular architecture also implies the passkey enrollment capability could be licensed or integrated into other phishing frameworks, spreading the technique beyond a single toolkit.

Shield53 Recommendations

Immediate Actions

  • Audit enrolled passkeys across your Google Workspace tenant. Use the Admin SDK API to enumerate registered security keys and passkeys per user. Establish a baseline and alert on new enrollments, especially outside normal working hours or from anomalous IPs.
  • Restrict passkey enrollment where feasible. Evaluate whether consumer-side passkey enrollment can be disabled or gated behind additional admin approval for sensitive accounts.
  • Revise phishing incident response procedures. Password reset and session revocation are no longer sufficient. Add a mandatory step: review and remove all enrolled FIDO2 credentials, then re-enroll only verified devices.
  • Deploy session anomaly detection. Flag sessions that perform passkey enrollment within the first 60 seconds of authentication — this is a strong behavioral indicator of automated toolkit activity.
  • Block or monitor trycloudflare.com and similar free tunneling services at the DNS or proxy layer for corporate-managed devices.

Strategic Actions

  • Push identity providers for enrollment policy controls. The ability to require step-up verification or admin pre-approval before new passkey enrollment should be a vendor selection criterion.
  • Educate users that passkeys are not self-auditing. Users should periodically review their own enrolled credentials, just as they review active sessions.
  • Assume persistence outlives credentials. Treat any confirmed phishing event as a potential persistent compromise until enrolled credentials are explicitly verified and cleaned.

The defensive community has been correct that passkeys resist phishing. iAuthFlow v2 demonstrates that passkeys can also become the persistence mechanism when the enrollment process is abused. The response is not to abandon passkeys — it is to treat credential enrollment as a privileged, monitored action deserving the same scrutiny as authentication itself.