A phishing kit for sale on Russian-language cybercrime forums claims it can enroll attacker-controlled passkeys on compromised accounts, providing persistent access after passwords are changed. Advertised at around $10,000 for the base package, with additional modules sold separately, iAuthFlow v2 aims to solve a common problem for attackers: being locked out after the victim detects the compromise. Defenders would ordinarily revoke session tokens and rotate credentials. Those measures remain necessary, but may not be sufficient if the attacker has enrolled a passkey on the compromised account. According to Abnormal Security, which examined the kit's documentation and demonstration videos, the technique uses a browser-in-the-middle (BitM) model involving two separate browser environments. In a BitM attack, the victim appears to complete the login on their own device, while the attacker's infrastructure relays the interaction through a separate browser session. The victim sees a phishing page impersonating the targeted service. The iAuthFlow v2 demos focused on Google, but the seller advertises packages for iCloud, LinkedIn, and Microsoft too. The victim enters their account details into the phishing page, while iAuthFlow v2 operates a separate browser on the attacker's server. It sends the victim's input to Google and relays Google's prompts back to the victim. The process repeats until the authentication flow is complete. Once authentication is complete, iAuthFlow v2 controls an authenticated browser session and uses it to enroll an attacker-controlled passkey, Abnormal says. That credential can remain valid after the victim changes their password. Rather than sending the victim to their Gmail inbox after authentication, iAuthFlow v2 displays a brief loading screen reading: "Verification, Processing." Meanwhile, the toolkit works behind the scenes to register a passkey to an attacker-controlled device. "During that pause, the seller's demonstration shows the passkey module opening the target's Google passkey settings through the authenticated browser and requesting a new credential," Abnormal said. "Google may require further identity verification before allowing the change. In the recorded run, the toolkit log indicates that the passkey was created six seconds after authentication." It is unclear where the private key associated with the attacker's passkey is stored. Abnormal hypothesized that the kit may use a Chromium-based virtual authenticator capable of completing WebAuthn registration without storing the private key on the victim's device. However, because the researchers did not buy and test the kit, they could not confirm its storage mechanism – or independently verify the seller's broader claims. Whatever the storage mechanism, organizations should look for newly registered passkeys when investigating an account compromise. Responders should also hunt for other post-compromise changes, including rogue passkeys, OAuth grants, recovery methods, Gmail filters, and forwarding rules. "Response and recovery cannot end with a password reset or session revocation," said Abnormal. "Organizations must also examine what changed after authentication – especially newly enrolled credentials, recovery methods, OAuth grants, and mailbox settings – and remove anything the attacker left behind. "As toolkits like iAuthFlow v2 expand their post-authentication capabilities, effective response increasingly depends on treating account restoration as a comprehensive investigation, not a simple reset." Passkeys are routinely heralded as the future of account security. Designed to resist phishing, they can replace passwords and more vulnerable forms of MFA. Registering a passkey does not make an account bulletproof. Attackers can instead target fallback login methods, active sessions, account recovery processes, and other weaknesses surrounding the credential. Stealing session cookies, often through infostealer malware, can grant access to an authenticated session without triggering a passkey prompt. Another route is device code phishing, although it depends on the organization permitting the underlying OAuth device flow – something generally discouraged unless operationally necessary. ®
/s3/static.nrc.nl/wp-content/uploads/2026/08/19151020/210826CUL_2035660553_CD_FI_CD-Montage3.jpg)
