iAuthFlow V2 represents a significant evolution in phishing toolkit capability, moving beyond credential theft and session hijacking to persistent authentication method registration. The toolkit employs a browser-in-the-middle (BitM) architecture using two separate browser environments: the victim's browser displays a convincing Google-styled phishing page delivered via a Cloudflare tunnel (trycloudflare.com subdomain), while the attacker operates a separate authenticated browser session on their own server. Credentials and authentication responses are relayed between the two environments in real time, enabling the toolkit to defeat most forms of multi-factor authentication including TOTP, SMS codes, and push notifications.

Once the victim completes authentication, iAuthFlow V2 does not immediately forward them to their inbox. Instead, it displays a fake 'Verification, Processing' loading screen while simultaneously navigating the authenticated attacker-controlled browser session to the victim's Google passkey settings. The toolkit then requests and registers a new WebAuthn passkey bound to an attacker-controlled device or software-based virtual authenticator. According to Abnormal Security's analysis of the seller's demonstration, the passkey was created approximately six seconds after the initial login. The session log recorded 'Passkey created and saved' at 21:37:24, six seconds after the login at 21:37:18.

Google's passkey architecture is the critical enabler: a passkey is a credential registered to the account, not a token derived from the password. As Google's own documentation states, 'changing the password does not remove it.' When the legitimate account owner changes their password and revokes active sessions — normally the definitive response to a compromise — the attacker-enrolled passkey remains valid. The attacker can regain access by selecting 'Try another way' at the login prompt and authenticating with the passkey, bypassing the new password entirely.

The exact storage mechanism for the attacker's passkey private key remains unconfirmed, as Abnormal Security analyzed the kit through seller documentation and demonstration videos rather than independent acquisition. The most plausible mechanism is a Chromium-based software virtual authenticator for WebAuthn, which can perform registration and retain the private key without requiring the victim's physical device. The phishing frontend itself does not handle WebAuthn, keeping the technical complexity isolated to the attacker's infrastructure.

The base toolkit is priced at $10,000 with additional modules sold separately. The seller, operating under the handle PHISHLETS, has been active on a Russian-language cybercrime forum since June 2024 and maintains a Telegram channel for customer support. The analyzed demonstration targeted Google accounts, but the seller also advertises versions for Microsoft (Microsoft 365), Apple iCloud, and LinkedIn. A test instance was hosted at nax4q7m9[.]org, and phishing pages are delivered through Cloudflare tunnel subdomains of trycloudflare[.]com.

Detection is challenging because the toolkit operates through legitimate infrastructure. The Cloudflare tunnel subdomains are dynamically generated and require no account creation, making them difficult to block at the network level. In Google Workspace, the attack leaves detectable signals in three audit streams: login events showing compressed ~1-second logins from VPS hosting ASNs (Clouvider, Host Telecom), OAuth token grants showing consistent client ID 77185425430.apps.googleusercontent.com with NATIVE_DESKTOP client type, and DEVICE_REGISTER_UNREGISTER_EVENTs from new device registrations. The Google Workspace passkey_enrolled audit event is the most direct indicator of compromise.

Remediation requires a comprehensive approach beyond password reset. The affected account must be investigated for newly registered passkeys, unauthorized OAuth grants, modified recovery methods, malicious Gmail filters and forwarding rules, and unauthorized application access. Password reset and session revocation alone are insufficient. Organizations should consider Google Workspace Advanced Protection Program enrollment for high-risk users, which enforces passkey or security key requirements for sign-in, and the 'Only security key' setting in 2-Step Verification to restrict phishable fallback methods.