UAT-11985 phishing uses event invitations to steal Google account sessions
News
On October 8, Cisco Talos published new research on UAT-11985, a spear-phishing campaign that used credible event invitations to steal Google account credentials and authenticated session tokens. The publication is fresh, but the observed campaign dates to mid-2026. It targeted people affiliated with Taiwan research organizations rather than the public at random.
The operation reused real public event details, impersonated known institutions and sent personalized invitations. A visible Google Forms address concealed an attacker-controlled destination. Some attached posters copied legitimate designs but replaced their QR codes. Once a recipient reached the fake registration flow, an operator-driven adversary-in-the-middle (AitM) kit imitated Google sign-in screens, relayed authentication challenges and captured a completed session.
What Talos found
The Talos report attributes the activity to the tracking name UAT-11985. This is independent threat research into spear-phishing and impersonation infrastructure, not a product announcement. Talos says the emails impersonated the Taiwan European Union Centre, the NCCU Institute of International Relations and the Taiwan Research Institute. An email recipient checked with the named organizations and learned that the purported senders could not be confirmed as employees or representatives.
The messages combined accurate event topics, dates, venues and registration details with fabricated sender identities. They also added tailored praise and claims of exclusive access. That mixture matters because every visible event fact could be correct while the invitation itself remains malicious. Authentic public information proves that an event exists. It does not prove that the person sending the invitation is authorized to represent the organizer.
What the evidence does not establish
Talos did not report a Google service breach, a compromised impersonated institution, a victim count or confirmed victims who scanned printed posters. The report also does not publish domain-authentication results for the lure messages. Nothing in the research supports calling this a DMARC bypass.
UAT-11985 is separate from the older UAT-11587 activity involving the Antino backdoor and from prior mortgage-themed phishing coverage. Investigators should not transfer actor identity, infrastructure, tactics or objectives between those cases without case-specific evidence.
How the invitation led to account access
The social engineering path began with a familiar professional action: register for an event. The email displayed a benign-looking Google Forms URL, but the underlying hyperlink opened infrastructure controlled by the operator. Posters attached to some messages used the same trust mechanism. Their design came from real institutions, while the QR destination had been changed. Talos suggested the actor anticipated that a poster might be printed or shared, but it did not confirm that this happened or produced victims.
UAT-11985 path from an event invitation to a stolen Google account session.
The destination first imitated Google Forms and then forced a transition to a copied Google sign-in experience. Talos found Simplified Chinese, Traditional Chinese and English interfaces. Browser language settings helped select what the recipient saw. The visual continuity reduced the obvious break between event registration and account authentication, even though the browser had left the legitimate service.
What the recipient saw
- Trusted context: Real event details and recognizable institution names.
- Familiar label: Visible text that appeared to reference Google Forms.
- Expected action: A registration form followed by a sign-in request.
- Polished language: Personalized professional praise and plausible logistics.
What actually happened
- False identity: The named institutions could not verify the senders.
- Changed route: The actual hyperlink led to attacker infrastructure.
- Copied interface: A fake form handed the user to a fake sign-in flow.
- Live relay: An operator synchronized challenges and captured the session.
Why the AitM kit could steal a live session
The phishing kit used two communication paths. HTTP POST requests sent captured input and browser details to the operator's infrastructure. A persistent WebSocket connection let the operator update the screen as the real authentication service changed state. This allowed the fake page to show the next relevant challenge instead of relying on one static password form.
HTTP POST and WebSocket channels supporting a live adversary-in-the-middle sign-in relay.
Talos reports that the operator relayed MFA challenges and obtained authenticated session tokens. That finding should not be expanded into a claim that every MFA method can be bypassed. The analyzed code includes handling for a passkey-related flow, but the research does not establish that UAT-11985 defeated origin-bound passkeys or hardware security keys. Origin binding matters because a credential created for the legitimate site should not authenticate an unrelated phishing origin when properly supported and deployed.
Careful interpretation
The report strongly suggests AI-assisted lure creation based on repeated structure, formulaic wording, personalized flattery and consistent customization patterns. It does not prove full AI generation. Talos also assesses with moderate confidence that the interface was originally developed in Simplified Chinese. That technical language assessment does not prove the operator's nationality, employer, state sponsorship or any specific government connection.
Where DMARC helps and where it stops
Domain authentication answers a narrow but important question: whether a message is authorized for the domain it claims to use and whether relevant identifiers match. It cannot decide whether the sender's story is honest, whether copied event details are being abused, whether displayed link text matches its destination or whether a QR code was altered. It also cannot protect a Google session after a user completes authentication on an attacker-controlled site.
That limitation is not a reason to skip authentication. Strong DMARC monitoring reduces direct domain spoofing and gives operators evidence about legitimate and unauthorized sending sources. It belongs beside invitation verification, link analysis, account controls and incident response. Teams should also run periodic domain health checks and validate policy syntax with a DMARC record checker.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is our DMARC and email authentication platform. It is the best overall fit for teams that need automated issue detection, guided fixes, real-time alerts, hosted policy management and unified DMARC, SPF, DKIM, reputation and deliverability visibility. Those controls help establish and monitor the sending baseline. They do not detect a stolen Google session or stop an AitM page, so account telemetry and phishing-resistant sign-in controls still need separate ownership.
Authentication reports can reveal unauthorized domain use and configuration drift, while invitation and identity controls answer different questions. Keeping those signals in their proper scope prevents a passing authentication result from becoming a false safety verdict on message intent.
Operational checks for invitations and QR codes
The useful response is a repeatable verification routine that treats accurate event details as context, not proof. Apply it to invitations aimed at researchers, policy teams and executives, especially when the message creates status pressure through reserved seating or personal recognition.
- Verify independently: Find the event through the institution's official website or a previously trusted contact channel. Do not use contact details supplied only in the invitation.
- Inspect destinations: Compare displayed link text with the actual destination using safe inspection controls. Do not open a suspected link to test it.
- Treat QR codes carefully: Preview and inspect the decoded destination in an approved analysis process before navigation. A copied poster design does not validate its QR code.
- Check the sign-in origin: Stop when event registration unexpectedly requests an account login on a different domain. Open the expected service separately instead.
- Improve authentication: Evaluate phishing-resistant, origin-bound sign-in methods with supported identity providers. Confirm recovery paths before broad deployment.
- Train for borrowed trust: Teach staff that a real event, accurate venue and professional language do not prove the sender or registration route is genuine.
Mail teams should preserve the original message and headers when escalating a suspected invitation. Security teams can then examine sender infrastructure, redirect chains, attachment hashes and decoded QR destinations without requiring the recipient to revisit the content. Keep suspicious indicators defanged in tickets and internal communications.
Hunting and session response
Organizations can use the indicators published with the Talos research to search historical email, web, DNS and proxy records. Hunting should look for the complete sequence, not only one domain. Relevant evidence includes delivery of the invitation, navigation to a changed destination, a Google sign-in event near that time and subsequent account activity that differs from the user's normal pattern.
|
|
|
|---|---|---|
Email | Headers, links, attachments | Confirm delivery path |
Web | Redirect and QR targets | Map navigation |
Identity | Sign-ins and sessions | Find account misuse |
Endpoint | Browser history and time | Correlate user action |
Evidence to preserve before containment actions change account state.
If evidence indicates that a user entered credentials or completed a challenge on the fake flow, coordinate incident response before making broad changes. Preserve available identity and browser evidence, review suspicious logins and active sessions, then revoke affected sessions. Reset exposed credentials, inspect account recovery settings and check for persistence such as unfamiliar forwarding behavior or delegated access. The exact order should follow the organization's evidence-preservation requirements.
Do not investigate by revisiting the lure
Do not click the email link, scan the QR code on a personal device or enter test credentials into the page. Use approved isolated analysis processes, preserve the original evidence and coordinate containment through the incident response team.
The control gap UAT-11985 exposed
UAT-11985 succeeded at the boundary between trustworthy facts and an untrustworthy route. The event could be real, its topic current, the venue correct and the institution familiar, while the sender identity, hyperlink, QR destination and sign-in flow were false. The live sign-in relay then moved the risk beyond simple credential collection to an authenticated session.
Operators should keep the controls separate and connected. Email authentication limits domain impersonation. Independent invitation checks expose borrowed trust. Origin-bound authentication can resist phishing sites when supported. Identity monitoring and session revocation address activity after sign-in. No single control validates all parts of that chain, which is why a clean DMARC result must never be treated as proof that an invitation, displayed link, QR code or login page is safe.
