Key Takeaways
- iAuthFlow v2 is a phishing kit sold on Russian‑language cybercrime forums that uses a browser‑in‑the‑middle (BitM) technique to enroll attacker‑controlled passkeys on compromised accounts.
- The kit costs roughly $10,000 for the base package, with additional modules available for iCloud, LinkedIn, Microsoft, and Google services.
- After the victim completes authentication on a fake login page, the attacker’s infrastructure silently registers a passkey that can persist even if the victim later changes their password.
- Researchers hypothesize the kit may employ a Chromium‑based virtual authenticator that completes WebAuthn registration without storing the private key on the victim’s device, though this has not been independently verified.
- Defenders should look for newly registered passkeys and other post‑compromise artefacts (rogus OAuth grants, recovery methods, mailbox filters, etc.) when responding to an account breach, rather than relying solely on password resets or session revocation.
- Passkeys improve resistance to phishing but are not foolproof; attackers can still exploit fallback authentication methods, active sessions, device‑code phishing, or stolen session cookies.
Introduction
A recently advertised phishing kit called iAuthFlow v2 is being marketed on Russian‑language cybercrime forums for approximately $10,000, with optional add‑ons for iCloud, LinkedIn, Microsoft, and Google services. The seller claims the toolkit can bypass the security benefits of passkeys by enrolling an attacker‑controlled passkey on a victim’s account after the victim has successfully authenticated. This capability allows the attacker to retain access even if the victim later changes their password or invalidates existing session tokens, presenting a notable evolution in credential‑theft tactics.
Browser‑in‑the‑Middle Model
At the core of iAuthFlow v2 is a browser‑in‑the‑middle (BitM) attack architecture. Rather than presenting a static fake login page that harvests credentials for later reuse, the kit creates two parallel browser sessions: one displayed to the victim and another controlled by the attacker on a remote server. The victim believes they are interacting directly with the legitimate service, while the attacker’s browser relays every input and response between the victim and the real authentication endpoint. This relay enables the attacker to complete the full authentication flow in real time, including any multi‑factor challenges that the victim may encounter.
Authentication Relay Process
When the victim navigates to the phishing page impersonating, for example, Google’s login screen, they enter their username and password as usual. iAuthFlow v2 captures these credentials and forwards them to the attacker‑controlled browser, which submits them to the genuine Google authentication service. Google’s subsequent prompts—such as push notifications, SMS codes, or WebAuthn challenges—are relayed back to the victim’s browser, which displays them exactly as they would appear on the legitimate site. The victim completes each step, unaware that their actions are being mirrored and manipulated by the attacker’s infrastructure. This back‑and‑forth continues until the authentication flow is deemed complete by the service.
Passkey Enrollment After Authentication
Once the victim has successfully authenticated, iAuthFlow v2 does not redirect them to their inbox or dashboard. Instead, it shows a brief loading screen labeled “Verification, Processing.” During this interval, the kit operates behind the scenes using the authenticated attacker‑controlled browser to navigate to the target’s passkey settings (e.g., Google’s passkey management page) and initiates the registration of a new passkey tied to an attacker‑chosen device. In the seller’s demonstration video, the passkey was created roughly six seconds after the authentication flow finished. Because the passkey is registered under the attacker’s control, it remains valid for future logins even if the victim later resets their password or invalidates existing session cookies.
Speculated Storage Mechanism
Abnormal Security, which analyzed the kit’s documentation and demos, notes that it is unclear where the private key associated with the attacker‑generated passkey is stored. The researchers hypothesize that iAuthFlow v2 may leverage a Chromium‑based virtual authenticator capable of completing the WebAuthn registration process without ever writing the private key to the victim’s device. Such a virtual authenticator could generate and retain the key entirely within the attacker’s server‑side browser environment, thereby avoiding detection by local security tools that monitor for key‑material writes. However, because the researchers did not purchase or execute the kit, this storage theory remains unverified.
Limitations and Uncertainties
The analysis by Abnormal Security is based solely on publicly available marketing material and demonstration videos; the kit itself has not been acquired or tested in a controlled environment. Consequently, claims about the reliability of the BitM technique, the exact timing of passkey enrollment, and the robustness of the purported virtual authenticator cannot be independently confirmed. There may be additional constraints—such as rate‑limiting by the target service, extra verification steps that could thwart the automated enrollment, or environmental dependencies—that affect the kit’s real‑world efficacy. Nonetheless, the described methodology illustrates a plausible avenue for attackers to undermine passkey‑based defenses.
Defensive Recommendations
Organizations should treat any suspected account compromise as a broader investigation rather than concluding with a password reset or session revocation. Specific actions include:
- Auditing newly registered passkeys or WebAuthn credentials on affected accounts.
- Reviewing OAuth grants, application passwords, and recovery methods (e.g., backup emails, phone numbers) for unauthorized additions.
- Inspecting mailbox settings for malicious filters, forwarding rules, or delegated access that could facilitate data exfiltration.
- Monitoring for anomalies such as logins from unfamiliar devices or locations immediately after a password change.
By extending the scope of incident response to cover these post‑authentication artefacts, defenders can detect and remove the persistence mechanisms that kits like iAuthFlow v2 attempt to establish.
Passkeys Are Not a Panacea
While passkeys are promoted as a phishing‑resistant replacement for passwords and weaker MFA methods, they do not render accounts immune to compromise. Attackers can still target alternative authentication pathways, such as fallback passwords, SMS‑based codes, or email magic links, especially if those methods remain enabled. Additionally, stealing active session cookies via infostealer malware can grant immediate access without triggering a passkey prompt. Device‑code phishing, which abuses the OAuth device flow, remains viable in organizations that permit this flow for legitimate purposes. Consequently, a defense‑in‑depth strategy that secures all authentication vectors and monitors for anomalous post‑login activity is essential.
Conclusion and Outlook
The emergence of iAuthFlow v2 highlights how cybercriminals are adapting to the growing adoption of passports‑style credentials by developing tools that exploit the authentication process itself rather than trying to defeat the cryptographic properties of passkeys. As the kit’s capabilities evolve—potentially incorporating more sophisticated stealth mechanisms or targeting additional services—defenders must shift from reactive credential resets to proactive, comprehensive account‑restoration workflows. Continuous monitoring for newly enrolled authenticators, rigorous review of account recovery configurations, and user education about the limits of any single security control will be crucial in mitigating the threat posed by next‑generation phishing kits.