A fake Google sign-in page is not interesting because it looks real. It is interesting because an operator sat behind it, watched MFA prompts land, and kept the victim on the line until the full session cookie was theirs. According to Cisco Talos, UAT-11985 ran an adversary-in-the-middle campaign against affiliates of Taiwan research and policy organizations, using spear-phishing and quishing to feed victims into a live Google authentication proxy that stole passwords, MFA challenge responses, and complete authenticated session tokens. Public reporting does not establish named victim organization counts or confirmed data exfiltration volumes.
How event lures and quishing fed the Google proxy
UAT-11985 did not open with a generic "your mailbox is full" note. According to Cisco Talos, mid-2026 activity used invitation-style lures that impersonated familiar Taiwan research brands, including the Taiwan European Union Centre, the NCCU Institute of International Relations, and the Taiwan Research Institute. The bait leaned on real public event details, which is the difference between a message that looks like spam and a message that looks like work.
Quishing sat beside the email path. Attackers altered event-poster QR codes so a scan still felt like conference logistics, then dropped the reader onto the same authentication trap. That dual delivery matters for research and policy communities that live on shared calendars, posters, and hybrid events. The first click did not need malware. It needed a believable reason to sign into Google.
The landing page was not a static HTML clone. An adversary-in-the-middle attack is a reverse proxy that sits between the victim and the real identity provider, presenting a login UI while copying every credential and challenge response in real time. Talos described UAT-11985's framework as impersonating Google authentication pages and using a hybrid HTTP and WebSocket architecture to synchronize authentication workflows live. Joey Chen's write-up for Cisco Talos put the design goal in plain language: interception of credentials and multi-factor authentication challenges through that synchronized flow.
Locale handling was deliberate. The spoofed Google login supported zh-CN, zh-TW, and en, with browser language detection steering the UI. Talos assesses with moderate confidence that the interface was originally developed in Simplified Chinese and later adapted for Traditional Chinese and English. That is not a mass-spray kit tuned only for English enterprise tenants. It is a regional operator kit built for the people it was hunting.
Operator-driven MFA relay, then the session cookie
Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration, according to Cisco Talos. That single sentence is the mechanical heart of the breach.
HTTP POST carried the form traffic. WebSocket kept the operator in lockstep with the victim's MFA screen. When the user typed a password, the proxy forwarded it. When Google issued an OTP, push, or similar challenge on the real path, the kit presented the matching prompt on the fake path and relayed the victim's response. Standard Google MFA factors completed successfully for the attacker path because they are transferable secrets and approvals. The reverse proxy does not need to crack cryptography. It only needs the user to finish the ceremony on the wrong origin while the operator watches.
Initial access was credential theft at the proxied Google login. Passwords and live MFA responses moved through the kit before authentication finished on the attacker side. That is why "we had MFA on Google" is not a comforting sentence here. The MFA step happened. The operator collected it.
After victims completed MFA on the proxied flow, the kit harvested full authenticated Google session tokens. Those bearer sessions are the second half of the story. Possession of the post-login cookie replaced any need for another MFA prompt until expiry or revocation. Persistence was session-cookie replay after authentication had already finished. Account takeover no longer required the password or the second factor. It required the cookie the proxy had already minted by completing the login.
| Control in play | What UAT-11985 did | Why it failed |
|---|---|---|
| Password at Google sign-in | Relayed through reverse proxy | Typed secret is copyable |
| OTP / push-style Google MFA | Live WebSocket-assisted relay | Challenge response is transferable |
| Post-MFA Google session cookie | Captured after successful proxied login | Bearer token needs no re-auth |
Public reporting does not establish a household-name enterprise IdP workforce as the primary target, helpdesk resets, SIM swap, or device-code OAuth elements. The documented path is classic AiTM against Google authentication for research-org affiliates, not a recovery-desk story and not an endpoint infostealer opening the door.
The business consequence is straightforward even without published record counts. A full Google session is mail, Drive, Docs, shared research material, and whatever else that identity can reach. SSO is not required for blast radius when the stolen object is already the authenticated Google session. One successful operator-assisted login becomes ongoing access until someone revokes tokens and forces fresh authentication on every affected account.
Why the MFA step still handed over the keys
Security teams often treat "MFA was enabled" as the end of the authentication conversation. UAT-11985 shows the opposite. The kit's job was to make MFA succeed on the attacker path, not to avoid MFA.
Phishable factors lose in real time against a synchronized proxy. A one-time code the user can type can be typed again by the operator's tooling. A push the user can approve can be approved while the proxy holds the session open. The UI fidelity and WebSocket control reduced the friction that usually breaks clumsy clones. Victims were not asked to paste a code into a second channel the attacker could not see. They were kept inside one continuous fake Google flow that mirrored the real one.
The session cookie is a separate problem from the login. No MFA product reverses a cookie that already exists after a completed login. Revocation, short lifetimes, and forced re-authentication are containment after the fact. They are not the same as stopping the proxied ceremony that issued the cookie. Closing the phishable login stops this path. Malware after a legitimate login is a harder, separate problem, and that is not what Talos documented for UAT-11985's initial access.
Related workforce AiTM patterns keep showing the same split. Campaigns that proxy cloud logins win at the credential phase by collecting password plus live MFA, then live on the stolen session. The Taiwan research campaign is that pattern aimed at Google authentication with operator-in-the-loop MFA screen control and regional lure craft, including quishing on event posters.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how phishing-proof login blocks Google AiTM credential relay.
FAQ
How did UAT-11985 break into Taiwan research affiliates' Google accounts?
UAT-11985 broke in by steering affiliates of Taiwan research and policy organizations to a real-time adversary-in-the-middle proxy that impersonated Google sign-in. According to Cisco Talos, spear-phishing and quishing lures fed victims into that kit, which relayed passwords and live MFA challenge responses, completed authentication on the attacker path, and harvested full Google session tokens for account takeover.
Did Google MFA actually run during the UAT-11985 attack?
Yes. Google MFA ran on the proxied flow, and that is how the attack worked. UAT-11985's operator-driven kit synchronized the login UI over HTTP POST and WebSocket, intercepted OTP, push, and similar challenge responses in real time, and only then captured the authenticated session tokens issued after MFA completed.
What could attackers do with the stolen Google session tokens?
Attackers could use the stolen Google session tokens as bearer access to the victim's authenticated Google account without another MFA prompt until expiry or revocation. In the UAT-11985 campaign, Cisco Talos described the primary objective as credential theft leading to full authenticated session takeover of Google accounts. Public reporting does not establish confirmed exfiltration volumes or affected record counts.
Was this automated Evilginx-style spray or a live operator kit?
Cisco Talos assessed the UAT-11985 framework as optimized for operator-driven authentication orchestration rather than a fully automated phishing kit. WebSocket support for live MFA screen control let operators stay synchronized with victims during the Google authentication ceremony instead of relying only on fire-and-forget page clones.
Does public reporting name how many organizations or records were hit?
No. Public reporting does not establish named victim organization counts, confirmed data exfiltration volumes, or affected record counts for the UAT-11985 Google AiTM campaign. Cisco Talos documented the targeting of Taiwan research and policy organization affiliates, the lure brands, the proxy mechanics, and the session-token outcome without publishing those scale figures.
