Google AitM Phishing Kit Uses WebSockets to Bypass MFA in Real Time

A Google account phishing kit uses live WebSocket connections to guide victims through fake sign-in screens, relay authentication requests, and steal authenticated sessions.

The campaign shows how attackers can get past MFA by forwarding login steps in real time rather than breaking the security checks themselves.

The operation targets people linked to research organizations in Taiwan. Its emails pose as invitations to academic and policy events, using real event details, false sender identities, and hidden registration links to make a credential theft attempt look like routine professional correspondence.

Researchers from Cisco Talos identified the campaign, tracked as UAT-11985, during mid-2026 and detailed its phishing kit in an October threat research report published on October 8.

Their analysis describes an operator-driven system that combines HTTP requests with WebSocket updates to mirror Google’s authentication process.

Google AitM Phishing Kit

The emails impersonated the Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute.

When a recipient checked the supposed senders with those institutions, none could confirm the individuals were employees or representatives. Accurate event information helped the attackers build trust around fabricated identities.

Each message followed a similar pattern: a policy-themed opening, praise tailored to the recipient, and registration instructions.

The approach draws victims toward the same session theft risk seen in Tycoon 2FA phishing attacks, where a convincing login page sits between users and a real authentication service.

Talos noted signs of AI-assisted writing, including repeated sentence patterns, broad compliments, and quick changes for different topics and recipients.

However, the researchers could not prove that a large language model wrote the complete emails. The finding supports likely AI assistance, not confirmed fully automated content generation.

The attackers also copied legitimate event posters and replaced their QR codes with malicious ones. Talos suggested that printed posters could expose additional people who never received the original email. A familiar design therefore offered no assurance that its registration code led to a safe destination.

How the WebSocket MFA Relay Works

Victims first encounter a fake Google Form that redirects them to a copied Google sign-in page. Unlike a basic password collection form, the kit lets an operator control each authentication stage.

Similar JWR WebSocket phishing techniques show how persistent connections can support live interaction, although that framework targets banking and payment information.

The kit separates data uploads from screen updates. HTTP POST requests send browser details, account identifiers, passwords, and challenge submissions to attacker-controlled infrastructure.

A persistent WebSocket connection carries instructions back to the page, telling it which authentication screen to display next. This split keeps uploads separate while allowing rapid changes during login.

The first request, google_login_start, collects language settings, user-agent information, screen size, and mobile-device status. After creating a session, the script opens its WebSocket connection.

The google_input_identifier event then sends the victim’s email address or phone number for checking against Google’s real authentication service.

When a password is entered, google_login_check forwards it with the account identifier and browser information. If Google requests another verification step, the attacker updates the fake interface through WebSocket messages.

Talos reports that this coordinated relay enables the theft of authenticated session tokens, allowing account takeover after the victim completes the requested checks.

The page also hides its JavaScript through Base64 strings and repeated array rotation. Its interface supports Simplified Chinese, Traditional Chinese, and English.

Talos assessed with moderate confidence that Simplified Chinese was the developer’s main working language; that finding alone does not establish nationality or state sponsorship.

The important distinction is that a completed MFA prompt does not guarantee a safe session. As documented in Mirage2FA session cookie theft, attackers can reuse authentication material captured during a relayed login.

Organizations should favor phishing-resistant authentication, verify unexpected invitations independently, and investigate suspected session theft rather than relying only on password changes.

Indicators of compromise (IoCs):-

Type	Source-published indicator
URL	https[:]//google.morelessty[.]com
URL	https[:]//jmlh.morelessty[.]com/
URL	https[:]//google.centerhoti[.]com/
URL	https[:]//google.natrlyi[.]com/
URL	https[:]//accounts.natrlyi[.]com/
Email	hoangthikieuanh254@gmail[.]com
Email	chenzhengyu1989@gmail[.]com
Email	tonn9127@gmail[.]com

Talos also lists detection coverage below. These are defensive signatures, not additional infrastructure indicators.

Detection system	Signature or rule
ClamAV	Html.Phishing.UAT11985-10060614-0
Snort 2	1:67198
Snort 3	7:31

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stops threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC