Researchers described iAuthFlow v2, a phishing toolkit that steals a live Google login session and then uses that access to enroll an attacker-controlled passkey. Because passkeys are separate login methods, the attacker can often get back into the account even after the victim changes their password and sessions are revoked. The kit uses a browser-in-the-middle setup to relay credentials and 2FA codes to the attacker in real time.
The toolkit known as iAuthFlow v2 targets Google account logins with a browser-in-the-middle relay. The victim receives a message about unusual sign-in activity and is directed to a realistic login page. What the victim sees is genuine-looking, but behind the scenes the toolkit runs a separate browser on the attacker's server, relaying the entered password and 2FA code in real time. Once the attacker's browser holds an authenticated Google session, it uses that access to enroll a new passkey that the attacker controls, all while the victim is held on a generic "Verification, Processing" screen.
The attack works because a passkey is treated as a legitimate, separate sign-in method rather than a temporary session artifact. A password reset or session revocation cuts off the attacker's active session, but it does not remove a passkey that was already added to the account. That means the attacker can later select "Try another way" and log back in using the passkey, even after the victim believes the account has been secured. The demo also used a trycloudflare.com subdomain, which provided a valid TLS certificate and made the fake login page appear more trustworthy at a glance.
Organizations should treat a password reset as only one step in recovery, not the full remediation. Responders need to check for and remove any authentication methods the account owner did not add, along with other forms of persistence such as mail forwarding rules, OAuth application grants, and recovery settings, before considering an account restored. Employees should be encouraged to pause and verify the actual domain of any login page before entering credentials, since a padlock icon alone does not confirm legitimacy. For higher-risk users, enforcing phishing-resistant authentication such as hardware security keys or a "security key only" policy for verification reduces exposure to relay-based phishing like this. Reporting unusual login stalls or verification delays through normal security channels also helps catch this pattern early, since the pause during account takeover is a deliberate part of the toolkit's behavior rather than a normal loading delay.
Mirage safely runs attacks like this one against your own team, so you find out what happens before a real adversary does.
It uses a stolen, authenticated Google session to enroll a new passkey controlled by the attacker. A password reset ends the session but does not remove that passkey, so the attacker can still sign back in with it.
The victim sees what looks like a real Google login page while the toolkit runs a second browser on the attacker's server, relaying the credentials and 2FA in real time to log in as the victim.
Watch for a login link on an unexpected domain such as a trycloudflare.com subdomain, and an unusual waiting screen like a generic 'Verification, Processing' page after entering your password and 2FA.
They should review and remove any unauthorized authentication methods, such as attacker-added passkeys, along with other persistence like mail rules, OAuth grants, or recovery settings, before considering the account restored.
Imagine you change your Google password… but the intruder still walks right back in. You get an email: “Google Account Verification Required.” The link goes to a page that looks exactly like Google, padlock and all, but the address is something like login-secure.trycloudflare.com. You enter your password and 2-step code. Then you’re stuck on a plain “Verification, Processing” screen. While you wait, their toolkit quietly adds a new passkey to your Google account that survives your password reset. If any Google login feels off, odd URL or a weird “processing” stall, close the browser and report it, then check your account’s passkeys and remove anything you didn’t add.
Google says the BlackFile extortion group (UNC6671) rebranded to “Redact” while keeping the same core scam: phone calls that impersonate IT helpdesk staff and push “urgent security migrations.” Victims are directed to spoofed login pages that steal passwords and MFA codes, enabling attackers to…
This bulletin describes multiple real-world social engineering campaigns where attackers trick people into trusting a familiar screen, like a search result “install guide,” a recruiter outreach, or a helpdesk phone call. The lures push victims to paste commands, install fake software, or reset MFA,…
Check Point reports that scammers are now impersonating ChatGPT/OpenAI in phishing campaigns, reflecting how mainstream the service has become. One documented example used a fake “ChatGPT Plus payment failure” notice that sent victims to a fraudulent payment page designed to capture full credit…
Attackers are taking over hotel and conference Wi‑Fi gateways and changing DNS settings so travelers are silently redirected to fake Microsoft 365 sign-in pages. Victims are then tricked into completing a device-code login that grants attackers a legitimate session token, often bypassing MFA. This…
Check Point reports that OpenAI’s ChatGPT became a top-10 most impersonated brand in Q2 2026 phishing. One observed example used a fake “ChatGPT Plus payment failed” billing email to drive victims to a credit-card theft page. The report also notes other brand-impersonation scams using cloned stores…
Google tracked three suspected Russia-linked groups running targeted phishing that abuses real login and authentication features (app passwords, OAuth, and device codes) to get into accounts. The lures often look like legitimate conference or diplomatic invitations, and some campaigns spoof…
