What’s most surprising about iAuthFlow V2 is that it can keep an attacker inside a Gmail account even after the victim changes the password. The toolkit, first spotted on a Russian‑language cybercrime forum, sells for a $10,000 base price and adds a separate passkey module that lets the operator log in again without needing the new password.
Key Takeaways
- iAuthFlow V2 uses a browser‑in‑the‑middle architecture to hijack a Google sign‑in flow.
- After a successful phishing page, the toolkit enrolls a new passkey that remains valid after password resets.
- Standard remediation—changing the password and revoking sessions—doesn’t remove the attacker’s foothold.
- The toolkit costs $10,000 and offers additional modules for Microsoft, iCloud, and LinkedIn.
- Abnormal’s analysis is based on seller posts and demo videos; the malware hasn’t been run by the researchers.
passkey phishing: How iAuthFlow V2 Subverts Google’s Password Reset
The attack starts with a classic phishing link, but the page isn’t a static form. It relays every keystroke to a second browser that lives on the attacker’s server. Because the victim sees a Google‑styled login, they don’t suspect anything. The remote browser completes the authentication, and Google hands it a valid session.
That remote session is the attacker’s launchpad. Once it’s live, iAuthFlow V2 writes its own system log, timestamps each step, and applies a device fingerprint before the victim even types. The log records the email, password, and a 2FA code that arrives about 40 seconds later. The victim thinks they’ve just logged in normally. They haven’t.
Two‑Browser Relay Explained
In the demo, the phishing URL resolved to a subdomain of trycloudflare[.]com, a free tunneling service. The victim’s browser displayed a Google sign‑in page, but behind the scenes iAuthFlow V2 fed every input to the attacker‑controlled browser. Google’s prompts and error messages traveled back through the same tunnel, so the user never saw a mismatch.
When the victim finally entered the authenticator code, the relay passed it straight to the remote browser, which presented it to Google. Google accepted the code, created SID and SSID cookies, and handed them to the attacker’s browser. At that point the toolkit had a fully authenticated Google session.
Why a Password Reset No Longer Cuts the Cord
Abnormal notes that “Changing the password and revoking active sessions are standard responses to a compromised mailbox. When an attacker’s access is limited to captured session cookies, those actions normally end that access,” and adds that Google says a password change revokes app passwords and OAuth tokens. The crucial detail is that a passkey isn’t a token derived from the password; it’s a separate credential registered to the account.
“Google also states that changing a password revokes app passwords and OAuth tokens with Gmail scopes, although some authorized devices and third‑party connections may remain signed in.”
Because iAuthFlow V2 enrolls a fresh passkey during the compromised session, the attacker ends up with a credential that survives any password change. When the victim later resets the password, Google invalidates the old session cookies, but the newly minted passkey stays active. The attacker can simply select the passkey at the next login and walk back into the mailbox.
What the Toolkit Actually Does
- Writes its own log with timestamps for each stage.
- Applies a device fingerprint before any user input.
- Relays credentials to a remote browser via a BitM (browser‑in‑the‑middle) relay.
- Uses the authenticated remote browser to enroll a new passkey under the victim’s account.
- Provides additional modules for Microsoft, iCloud, and LinkedIn.
Historical Context: The Rise of Passkey‑Based Attacks
Passkeys arrived as a response to the endless cycle of password leaks and phishing lures. By moving the secret into a cryptographic key stored on a device, they promised a frictionless login experience. The industry quickly embraced the standard, and major providers rolled it out across consumer and enterprise accounts.
Attackers, however, adapt fast. Early password‑only phishing kits focused on stealing the static secret. Once passkeys became mainstream, threat actors began probing ways to capture or forge those credentials. The first public demos of passkey‑theft emerged months after the feature’s debut, showing that the attack surface had simply shifted.
iAuthFlow V2 is a direct evolution of that trend. The original iAuthFlow version targeted only password‑based flows, relying on stolen cookies to maintain access. The new version adds a module that hijacks the enrollment step itself, turning the very mechanism meant to improve security into a backdoor.
That progression mirrors a broader pattern: every time a platform introduces a stronger authentication factor, a subset of malicious tools re‑engineers the flow to bypass it. The result is a cat‑and‑mouse game where defenders must treat new conveniences as potential liabilities.
Competitive Landscape
While iAuthFlow V2 focuses on Google, its marketing material highlights modules for Microsoft, iCloud, and LinkedIn. Those offerings suggest a toolbox approach, where a single codebase can be repurposed for multiple identity providers. The presence of these extra modules indicates that the underlying browser‑in‑the‑middle technique is not limited to a single ecosystem.
Other underground vendors have posted similar “passkey phishing” prototypes, though none have been priced as high as $10,000. The price point positions iAuthFlow V2 as a premium product, likely bundled with support or regular updates through the seller’s Telegram channel. Buyers therefore expect a ready‑to‑use solution rather than a DIY script.
From a defender’s perspective, the shared architecture means that detection rules built around Google’s flow can often be repurposed for Microsoft or iCloud attempts. Observables such as unusual tunneling subdomains, rapid creation of new credentials, or the appearance of unknown passkeys are cross‑platform indicators.
What This Means For You (Expanded)
Developers building authentication flows need to remember that passkeys are now a high‑value target. If your product integrates with Google’s passkey API, you should implement monitoring for sudden additions to a user’s credential list. An alert that a new passkey appears without user confirmation could be an early warning sign.
Founders should ask their security teams whether they’ve added passkey inventory checks to their breach‑response playbooks. It’s not enough to tell employees to change passwords after a phishing email; you have to verify that no rogue passkeys linger. Ignoring that step could let a cheap $10,000 toolkit keep a foothold in your SaaS customers’ accounts for months.
Scenario one: a SaaS platform that offers single‑sign‑on via Google. A user reports a suspicious login email. The ops team forces a password reset, but the account is still accessed the next day because a hidden passkey was silently added. Without a routine audit of the passkey list, the breach goes unnoticed.
Scenario two: an internal tooling team builds a custom admin console that relies on Google OAuth. An attacker compromises a low‑privilege employee, runs the iAuthFlow relay, and enrolls a passkey tied to the admin account. When the admin later changes their password, the attacker still walks in with the stored key, bypassing the new credentials.
Scenario three: a startup adopts passkey‑only MFA to simplify onboarding. During a simulated phishing test, the red team uses a public demo of iAuthFlow V2 to enroll a passkey. The exercise reveals that the “password‑less” policy alone does not prevent credential theft if enrollment can be hijacked.
In each case, the missing piece is visibility. A quick glance at the “Security” tab in the account UI can expose an unfamiliar device or key. Automating that check removes the reliance on manual inspection.
Going forward, the security community will have to treat passkeys as both a convenience and a new attack surface. If attackers can enroll them silently, the promise of password‑less login could turn into a double‑edged sword.
Cost, Distribution, and the Unknowns
The base price of $10,000 makes iAuthFlow V2 a premium offering on underground markets. The seller advertises the toolkit on the Exploit forum and pushes updates through a Telegram channel. No independent researcher has run the code; the analysis relies entirely on the seller’s demo videos and forum posts.
Because the researchers didn’t execute the malware, some details remain speculative. The description of the passkey module comes from the seller’s own demonstration, not from a captured real‑world infection. That said, the steps shown in the demo line up with Google’s documented passkey enrollment flow, which lends the claim credibility.
Implications for Incident Response
If you’ve been hit by a phishing attack that led to a password reset, you can’t assume you’ve cleared the threat. The presence of an unauthorized passkey means the attacker can bypass password‑based defenses entirely. Traditional remediation—changing passwords, revoking sessions, and resetting OAuth tokens—won’t touch the rogue passkey.
Security teams need to start looking for unknown passkeys in account settings. Google’s UI shows a list of registered passkeys, but many admins don’t routinely audit that list. Adding a regular check for unfamiliar passkeys could catch a lingering foothold before it’s used.
Remediation Guidance from Abnormal
Abnormal’s report includes Indicators of Compromise (IOCs) such as the unique Cloudflare tunnel subdomains and the specific log entries the toolkit writes. They also advise revoking all registered passkeys and re‑enrolling only trusted ones. That step, combined with a full device security audit, is the only way to guarantee the attacker’s credentials are gone.
Organizations should also consider enforcing stricter MFA policies that require hardware‑based keys rather than software tokens, because a compromised passkey can be removed only by the account owner. In environments where passkeys are mandatory, a policy to rotate them after any suspected breach becomes essential.
Key Questions Remaining
- How often do real‑world threat actors deploy iAuthFlow V2 versus proof‑of‑concept demos?
- What detection signatures can be built into SIEMs to flag the two‑browser relay pattern?
- Will Google introduce automatic passkey revocation on password changes, or is manual review the only mitigation?
- How effective are existing endpoint protection products at spotting the BitM relay component?
- What impact will broader adoption of hardware security keys have on the profitability of this toolkit?
Answers to those questions will shape the next wave of defenses. Until then, vigilance around passkey enrollment remains the most practical safeguard.
Sources: SecurityWeek, Abnormal AI
Primary sources: abnormal.ai (Primary source linked by the report).
