UAT-11985 Uses Event Lures for Real-Time Google Phishing

Cisco Talos has analyzed a targeted spear-phishing operation that combines credible event invitations, institutional impersonation, malicious QR codes, and a real-time adversary-in-the-middle (AitM) phishing framework aimed at Google accounts. The campaign targeted individuals affiliated with research organizations in Taiwan and used a level of authentication-page interaction that goes beyond a conventional fake login form.

Talos tracks the activity as UAT-11985. Its analysis describes a campaign designed to make recipients trust the initial invitation, guide them toward an apparently familiar registration service, and then relay the victim’s authentication process between a counterfeit Google interface and the legitimate Google service. The result is a phishing workflow capable of collecting credentials and interacting with multi-factor authentication (MFA) challenges while maintaining a convincing user experience.

Trust was established before the phishing page appeared

The observed emails impersonated organizations including the Taiwan European Union Centre, NCCU Institute of International Relations, and Taiwan Research Institute. The purported senders could not be verified by the organizations named in the messages, according to Talos. The campaign nevertheless used genuine or plausible public event information, including subjects, dates, venues, and policy themes, to make the invitations appear authentic.

Talos identified a consistent three-part message structure. The opening sections used formal geopolitical and policy language, followed by personalized praise directed at the recipient. The final section supplied event logistics and registration instructions. The personalization appears to have been based on publicly available professional information, while references to exclusive participation, VIP seating, or the recipient’s expertise were used to encourage engagement.

Talos assesses that the emails show strong evidence of AI-assisted content production and personalization. The organization points to repeated sentence structures, interchangeable praise, fluent but formulaic prose, and rapid adaptation across different institutions and topics. However, the researchers explicitly note that these linguistic characteristics do not prove that a large language model generated the messages in full. The confirmed finding is that the lures share a reusable structure and consistent personalization patterns; the role of generative AI remains an assessment rather than a directly established fact.

The registration links added another layer of deception. In one example described by Talos, the visible text resembled a legitimate Google Forms address, while the underlying hyperlink redirected the recipient to a phishing site hosted on third-party infrastructure. This mismatch is important because link text, branding, and the apparent use of a familiar service can create false confidence even when the destination is controlled by an attacker.

Malicious QR codes extended the campaign beyond email

The operation also used event posters as delivery mechanisms. Talos observed posters copied from legitimate websites but modified to contain malicious QR codes. The apparent objective was to exploit the physical environment of the targeted organizations: a recipient might print and display the poster, allowing other people who never received the original email to scan the altered code.

This is a form of QR-code phishing, or quishing. It changes the audience and inspection model. A recipient scanning a poster may not have access to the original email headers, sender context, or visible hyperlink destination. Mobile devices can also make it more difficult to inspect a URL before opening it. The research does not establish how widely the posters were distributed or how many people scanned them. It does show that the campaign incorporated a physical-world propagation opportunity into an otherwise email-led operation.

The phishing kit imitated Google and adapted to the authentication flow

After a victim followed the malicious link, the phishing page presented a close visual imitation of a Google sign-in experience. The page first collected an account identifier, such as an email address or phone number, and then presented the next stage based on the authentication process associated with that account.

Talos found that the interface supported Simplified Chinese, Traditional Chinese, and English. The page selected a locale using the browser’s navigator.languages value, which the researchers say is consistent with targeting Chinese-speaking users. The kit also contained a hidden HTML section intended to simulate a successful authentication event, including a locally hosted success-page asset in an iframe.

The client-side JavaScript was obfuscated using a large array of Base64-encoded strings, runtime array rotation, and control-flow obfuscation. The code was placed at the end of the HTML document. These features can make automated inspection and static deobfuscation more difficult, although they do not make the page invisible to network, browser, or identity telemetry.

HTTP and WebSocket channels supported operator-driven phishing

The most significant technical feature was the division of the phishing kit’s communications into two channels. HTTP POST requests carried event data from the browser to the operator’s server. Talos observed these requests being used for browser information, account identifiers, password submissions, authentication challenge data, and periodic heartbeat activity.

A persistent WebSocket connection handled near-real-time instructions in the opposite direction. The server could use the connection to tell the phishing page which authentication screen to display. This allowed the counterfeit interface to follow the state of the legitimate Google authentication process rather than presenting a fixed sequence of static pages.

The sequence began with collection of device and browser characteristics, including locale, user-agent string, screen dimensions, and mobile-device status. The phishing page sent this information through a session-start request. After the server created a session, the browser opened the WebSocket connection and received the current state.

When the victim entered an identifier, the phishing infrastructure relayed it to the legitimate authentication service. According to Talos, the response was used to determine whether the account existed and whether a passkey-related flow was available. The server then instructed the phishing page to show a password prompt or passkey prompt.

When the victim submitted a password, the page sent the password, account identifier, and user-agent information to the operator’s server. The server forwarded the credentials to the legitimate service. If additional authentication was required, the returned MFA challenge type and layout were used to advance the victim through the appropriate counterfeit screen.

Talos characterizes this as an operator-driven AitM framework rather than a fully automated credential collector. The relay architecture was designed to keep the attacker synchronized with the authentication process and, in Talos’s assessment, to obtain authenticated session access after MFA interaction. Organizations should treat this as a material limitation of relying on passwords plus conventional MFA alone for high-value accounts.

Attribution remains limited

Talos assesses with moderate confidence that the phishing interface was originally developed in Simplified Chinese and later adapted for Traditional Chinese and English. The assessment is based on the localization structure, the Simplified Chinese default branch, and lexical choices associated by the researchers with mainland Chinese software terminology.

This is a language and development-environment assessment, not a conclusive identification of the operator or sponsoring organization. The supplied research does not establish a named threat actor, government affiliation, or definitive geographic origin. Organizations should therefore use the technical characteristics of the campaign for detection rather than treating the language assessment as attribution.

What organizations should do now

• Inspect links at the destination level. Train users that visible link text and familiar branding do not establish where a link leads. Email security controls should analyze the final destination and redirects, including links presented as event-registration forms.
• Establish a separate verification path for invitations. Confirm unusual event invitations with the named institution through a known, independently sourced contact method. Do not use contact details or links supplied in the suspicious message.
• Apply QR-code controls. Treat QR codes in posters and email attachments as links requiring the same scrutiny as hyperlinks. Organizations can prohibit unapproved event posters in sensitive areas and provide a reporting process for altered or unexpected materials.
• Monitor identity telemetry. Review sign-ins involving unusual browser characteristics, unfamiliar devices, unexpected locales, and sessions that follow suspicious link clicks. Correlate identity events with email, web-proxy, DNS, and endpoint records.
• Look for phishing-page behavior. Web controls and browser telemetry should investigate pages that imitate Google authentication, collect account identifiers and passwords, maintain WebSocket connections, or submit authentication data to an unrelated host.
• Prefer phishing-resistant authentication where possible. Passkeys and other phishing-resistant methods can reduce exposure to credential replay, but deployment should be validated carefully because the campaign specifically attempted to adapt its interface to account authentication states.
• Protect high-value accounts with layered controls. Enforce strong identity policies, conditional access, session-risk evaluation, and rapid session revocation procedures. Users should report suspected credential entry promptly so administrators can reset credentials and invalidate active sessions.
• Use available vendor detections. Cisco Talos reports coverage through a ClamAV signature identified as Html.Phishing.UAT11985-10060614-0 and Snort identifiers 1:67198 and 7:31. Administrators should verify applicability and deployment status in their own environments.

Threat hunters should search for email messages containing event invitations with mismatched displayed and actual destinations, poster attachments with QR codes, and links that redirect from apparently legitimate registration services to unrelated infrastructure. Browser and proxy logs can be examined for authentication-like pages followed by repeated HTTP POST activity and persistent WebSocket connections. These checks should be performed using the organization’s approved security tooling and existing telemetry; the research does not provide a complete set of infrastructure indicators in the supplied material.

Conclusion

UAT-11985 demonstrates how a focused phishing campaign can combine social credibility, physical-world delivery, and technically sophisticated authentication relaying. The event details and institutional identities made the initial messages plausible, while the AitM kit supplied the real-time behavior needed to imitate a changing Google login process.

The central defensive lesson is that a successful MFA prompt does not necessarily prove that the user is interacting with a legitimate service. Organizations should combine link and QR-code scrutiny with identity monitoring, phishing-resistant authentication, session controls, and rapid response procedures. Talos’s language-based assessment may inform further research, but the campaign’s observable delivery and browser behaviors provide the more actionable basis for detection.

Sources

Cisco Talos: UAT-11985: AI-assisted event lures delivering real-time Google AitM phishing