A live Google MFA prompt is not safety if an operator is watching it through a reverse proxy. According to Cisco Talos, UAT-11985 steered affiliates of Taiwan research and policy organizations into an adversary-in-the-middle kit that impersonated Google sign-in, relayed passwords and MFA challenge responses in real time, and harvested full authenticated session tokens for account takeover. Closing that phishable login stops this path. Malware after a legitimate login is a harder, separate problem, and that is not what Talos documented for initial access here.
Why UAT-11985's Google proxy still finished MFA
Cisco Talos published its analysis of UAT-11985 on 8 October 2026, describing mid-2026 spear-phishing and quishing aimed at Taiwan research and policy organization affiliates. Lures borrowed real public event detail and familiar regional brands, then dropped victims onto a proxied Google authentication page rather than 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 live. Talos described a hybrid HTTP and WebSocket design that synchronized the full authentication workflow so an operator could drive MFA screens in lockstep with the victim. Joey Chen's write-up for Cisco Talos framed the goal plainly: interception of credentials and multi-factor authentication challenges through that synchronized flow.
Unlike fully automated phishing kits, this framework appears optimized for operator-driven authentication orchestration, according to Cisco Talos. Initial access was credential theft at the proxied Google login. Passwords and live MFA responses (OTP, push, and similar transferable factors) moved through the kit before authentication finished on the attacker side. The reverse proxy did not need to break cryptography. It needed the user to finish a familiar ceremony on the wrong origin while the operator stayed synchronized over WebSocket.
Standard Google MFA factors are phishable in real time against that design. A one-time code the user can type can be typed again on the attacker path. A push the user can approve can be approved while the proxy holds the session open. UI fidelity across zh-CN, zh-TW, and en locales, plus browser language detection, reduced the friction that usually breaks clumsy clones. Victims stayed inside one continuous fake Google flow that mirrored the real one.
After the victim finished MFA on the proxied path, the kit captured complete Google session tokens. Persistence was session-cookie replay after authentication had already finished. Those bearer sessions unlocked account takeover with no further MFA until expiry or revocation. Possession replaced re-authentication. No second factor stood between the attacker and mail, Drive, Docs, or shared research material reachable under that identity. SSO federation is not required for blast radius when the stolen object is already the authenticated Google session.
| Phase | What the kit took | What MFA could still demand |
|---|---|---|
| Proxied Google login | Password plus live MFA response | Nothing useful; factors were relayed |
| After successful proxied MFA | Full Google session token | No fresh MFA for bearer replay |
| Later account use | Ongoing session access | Only revoke or expiry |
Public reporting does not establish named victim organization counts, confirmed data exfiltration volumes, or affected record counts. Public reporting also does not establish helpdesk resets, SIM swap, device-code OAuth, or a household-name enterprise IdP workforce as the primary target. The documented failure is classic AiTM against Google authentication for research-org affiliates: phishable factors at login, then bearer cookies after login.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: UAT-11985 operator-driven Google AiTM and session cookie theft.
How phishing-proof device-bound login stops this kit
The prevention claim sits at the login the kit completed, not at revoke theater after the cookie exists. Phishing-proof MFA 2.0 uses device-bound public-key credentials. The private key never leaves hardware, never crosses the network as a typed secret, and signs only for the legitimate origin. A coached fake Google page is the wrong origin. There is no OTP to read aloud, no push to approve for a stranger, and no password the proxy can copy into the real path.
Against UAT-11985's operator-driven relay, that means the ceremony the kit was built to finish never finishes. The attacker does not obtain a valid password-plus-MFA completion, so the proxy never mints a replayable Google session on the attacker path. Closing the phishable login stops this attack. That is prevention, not detection.
How each control fares against UAT-11985’s relay:
| Control | Against UAT-11985 AiTM login | Against later cookie replay |
|---|---|---|
| Password plus OTP or push | Fails; live relay works | N/A; session already issued |
| Phishing-resistant passkeys at login | Hardens origin-bound sign-in | Does not un-issue a stolen cookie |
| Phishing-proof full-lifecycle MFA | Blocks transferable factors end to end | Still does not reverse a cookie already held |
| Token revoke / forced re-auth | Hygiene after compromise | Containment, not prevention of the kit |
Device-bound keys do not stop malware on a machine that already holds a legitimate session. That leftover path is endpoint compromise, not another login-factor failure. Fooling a user into a proxied login is easy. Planting malware is not. For this campaign, Talos documented the easy path: AiTM completion of Google authentication. The prevention-focused architecture is built so that remote kits never receive a transferable factor or a signature they can complete off-origin.
Session lifetime limits do not equal prevention either. Shortening cookie life only forces the attacker to re-use or re-steal sooner. If the attacker already holds a full authenticated Google session from a successful proxied login, lifetime is a clock, not a lock. Revoke remains hygiene for any cookie that somehow exists. It is not the product story for an AiTM-class breach that should never have completed authentication.
Within Google itself, one stolen session still reaches mail and files without a fresh proof at each app boundary. Classic SSO multi-app federation was not the reported vector here, yet the same skeleton-key problem appears whenever one bearer proof unlocks a wide identity surface. Prefer per-app, device-bound proof with no shared replayable federation cookie when you redesign workforce access. The device-bound architecture keeps each proof local to hardware and origin instead of minting a single transferable session the proxy can steal.
Passkeys harden login; proof closes the lifecycle
Passkeys and FIDO2 register a key pair on the user's device. The private key stays in hardware. The public key alone lives at the identity provider. At sign-in, the device creates an origin-bound signature for the real relying party. Industry language correctly calls that phishing-resistant at the login act: a lookalike domain does not receive a usable signature the way a typed OTP does. On a generic enterprise IdP that issues only hardware-bound signatures, the user taps once on an already-enrolled device; nothing secret is typed into a proxy. That is the mechanical reason UAT-11985-style Google clones lose when the only accepted factor is an origin-bound key.
FIDO2 and passkeys remain phishing-resistant at authentication only. They harden the login ceremony. They do not automatically harden how a user is registered or how a new device is added. If enrollment or recovery still accepts email OTP, SMS, or push, an attacker who controls that channel can enroll their own authenticator and later produce signatures that look legitimate. MFA 2.0 is phishing-proof because no phishable factor appears at registration, device onboarding, authorisation, authentication, or decommissioning. UAT-11985 did not need a helpdesk reset or a recovery secret; the live Google login was enough. The lifecycle lesson still matters for defenders who deploy passkeys for sign-in while leaving phishable onboarding beside them. Resistant hardens login. Proof closes the lifecycle.
Key Takeaways for Defenders
- Treat operator-driven Google AiTM as a credential-phase failure: block transferable OTP and push at workforce Google sign-in, not only after cookies appear.
- Prefer origin-bound, device-bound factors so a reverse-proxy clone cannot complete authentication on the attacker path.
- Plan explicit Google session revoke and forced re-authentication as containment hygiene when any cookie may already be stolen.
- Scrutinize event-invitation and quishing paths into research communities; the first click needed a believable work reason, not malware.
- Audit enrollment and recovery separately from login cryptography so passkey deployments do not reintroduce phishable device add flows.
The forward path is simple to state and hard to fake: stop minting sessions for anyone who can type a secret or approve a prompt on a stranger's page. When the only proof that works is a hardware-bound signature for the real origin, UAT-11985's WebSocket theater has nothing left to relay.
FAQ
Would phishing-proof MFA have stopped UAT-11985 from minting stolen Google sessions?
Phishing-proof MFA would have stopped UAT-11985 from completing the proxied Google login that minted the session, so the kit would not have harvested that token through AiTM. According to Cisco Talos, UAT-11985 relied on live relay of passwords and standard Google MFA responses before capturing authenticated session cookies. Device-bound, origin-bound authentication does not yield a transferable factor the proxy can finish. MFA does not reverse a cookie already stolen after a completed login; prevention is blocking the ceremony that issued it.
Why did standard Google MFA still complete for UAT-11985?
Standard Google MFA still completed for UAT-11985 because OTP and push-style factors are transferable in real time through a reverse proxy. Cisco Talos described an operator-driven framework using HTTP POST and WebSocket to synchronize the fake Google UI with the real authentication path, intercept MFA challenges, and complete login for the attacker. The MFA step ran; the operator collected it. That is a credential-phase failure at the proxied login, not evidence that MFA was disabled.
Are passkeys enough to prevent Google AiTM phishing like UAT-11985?
Passkeys are phishing-resistant at login and would block a fake Google origin from receiving a usable signature the way UAT-11985 collected typed OTP or push approvals. They are not automatically phishing-proof across enrollment and recovery if those stages still use email codes, SMS, or push. MFA 2.0 is phishing-proof across the full identity lifecycle, which closes the gap passkeys leave when onboarding remains phishable. For this breach, the documented win is stopping the AiTM login itself.
What should defenders do about Google session tokens after an AiTM incident?
Defenders should revoke affected Google sessions and force fresh authentication on every account that may have completed a proxied login, then eliminate phishable factors so the next kit cannot mint a new cookie. In the UAT-11985 campaign, post-MFA session tokens enabled account takeover with no further MFA until expiry or revocation. Shortening token lifetime alone does not prevent AiTM; it only shortens the abuse window. Closing the phishable login is the prevention claim. Revoke remains hygiene.
Did UAT-11985 use helpdesk resets or device-code phishing?
No. Public reporting does not establish helpdesk resets, Temporary Access Pass abuse, SIM swap, or device-code OAuth elements in the UAT-11985 Google AiTM campaign. Cisco Talos documented spear-phishing and quishing into a real-time Google authentication proxy that stole passwords, MFA challenge responses, and full session tokens from Taiwan research and policy organization affiliates.
