> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# UAT-11985: AI-assisted event lures delivering real-time Google AitM phishing
- URL: https://f4n6.co.uk/security-feed/uat-11985-ai-assisted-event-lures-delivering-real-time-google-aitm-phishing/
- Published: 2026-10-08T14:45:15.000Z
- Updated: 2026-10-08T14:45:15.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

Cisco Talos has documented a spear-phishing campaign, tracked as UAT-11985, against individuals affiliated with Taiwan-based research organisations. The actor impersonated three named Taiwanese academic and policy institutions, reused genuine public event details as cover, and delivered links to an adversary-in-the-middle (AitM) phishing kit that replicates the Google sign-in interface and relays authentication in real time over a hybrid HTTP POST and WebSocket channel. The kit captures credentials and MFA challenges and returns authenticated session tokens, which defeats MFA without exploiting a software vulnerability. No CVE is involved and no CISA KEV entry applies. The direct targeting is Taiwan-focused and the spoofed login panels support only zh-CN, zh-TW and en locales, so EMEA financial services exposure is indirect: the same kit architecture, the same Google Workspace and Microsoft 365 account-takeover outcome, and the same quishing technique are transferable to any organisation whose staff authenticate to cloud identity providers through a browser. The operational risk to a bank is account takeover of a federated identity, not malware on an endpoint.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item.

The item is a threat-intelligence report on an actor's tradecraft, not a reportable incident at any client. DORA Art. 17, 18 and 19 are triggered by an ICT-related incident affecting the institution itself; none is described here. DORA Art. 24, 28, 29 and 30 concern testing and third-party arrangements; the phishing kit is hosted on a third-party platform but that platform is not an ICT third-party provider to a client, and the source does not name it. NIS2 Art. 21(2)(d) and Art. 23 and the UK NIS 2018 duties attach to the client's own supply chain and incident reporting, and no client incident is in scope. Clients should treat this advisory as input to their existing phishing and identity-control programme rather than as a regulatory trigger.

## 3\. Technical analysis & attack chain

The campaign is a credential-phishing operation against Google accounts. There is no exploited software vulnerability, no malware implant and no CVE. The attack chain below reflects the steps Talos describes; the atomic indicators are not present in the material supplied to us and are held in Talos' GitHub repository, which we have not retrieved.

1. The actor sends an invitation email that impersonates a legitimate Taiwanese institution (Taiwan European Union Centre, NCCU Institute of International Relations, or Taiwan Research Institute) and reuses real event topics, dates and venues scraped from public announcements.
2. The email body carries a hyperlink whose visible text is a legitimate-looking Google Forms URL but whose underlying href points to actor-controlled infrastructure hosted on a third-party platform.
3. Some emails carry an attached event poster. The poster artwork is scraped from legitimate sites but the embedded QR code has been replaced with one pointing to the actor's infrastructure, extending the lure to anyone who prints or displays the poster.
4. The victim clicks the link and is served a replica of the Google sign-in page. The page loads obfuscated JavaScript that runs the AitM relay.
5. On load, the page collects browser and device data (locale, user agent, screen dimensions, mobile-device status) and posts it to the actor's HTTP command-and-control server as a `google_login_start` request. The server creates a session and the page opens a WebSocket to the same infrastructure, receiving a snapshot of current session state.
6. The victim submits an email address or phone number. The page posts it as a `google_input_identifier` event. The actor's server relays the identifier to Google to test whether the account exists and whether a passkey flow is enabled, then instructs the page over WebSocket to render either the password page or a passkey prompt.
7. The victim submits a password. The page posts the password, account identifier and user agent as a `google_login_check` request. The actor's server forwards the credentials to Google. If Google accepts them and demands a second factor, the server returns the MFA challenge type and layout and the actor advances the victim's interface to the matching MFA step over WebSocket.
8. The relay continues until Google issues an authenticated session. The actor holds the resulting session token and has full account access without the victim seeing anything anomalous.

The kit's architecture is the part that matters to a defender. It splits traffic into two channels by design: stateless HTTP POST for one-shot uploads (fingerprints, identifier, credentials, and periodic heartbeat polls) and a persistent WebSocket for low-latency server-to-page instructions that dictate which MFA screen the victim sees. That split is what lets the operator mirror Google's dynamic authentication state in real time rather than replaying a static page. The client-side JavaScript is embedded at the end of the HTML document and obfuscated with a large static array of Base64-encoded strings plus control-flow obfuscation, using a `while(!![]) { push/shift }` array-rotation loop resolved at runtime to defeat static deobfuscation tools. The page also contains a hidden HTML `<section>` that simulates a successful Google authentication event, holding an iframe with ID `google-success-frame` that loads a locally hosted asset at `/google-login-assets/operation-success.html`; the iframe carries the `sandbox="allow-scripts"` attribute.

Two targeting details are worth recording. The spoofed login panels support only Simplified Chinese (zh-CN), Traditional Chinese (zh-TW) and English, with region selection driven by the browser's `navigator.languages` value, which points at Chinese-speaking users. Talos assesses with moderate confidence that the kit's user interface was authored by a native Simplified Chinese speaker, citing the localization architecture and mainland-Chinese lexical usage; that is a language-inference judgement, not an attribution to a named group.

Confidence caveats. The entire technical picture above is single-sourced to Cisco Talos; we have not independently validated the kit or retrieved the IOC set. Talos states it cannot conclusively determine whether the lure emails were fully generated by a large language model, only that the consistent three-part structure, interchangeable flattery, repetitive sentence patterns and rapid customisation across recipients and topics are consistent with AI-assisted template generation. Treat the AI-generation claim as an assessed likelihood, not a confirmed fact. Talos also notes a separate, earlier report on a different phishing kit using similar WebSocket techniques, attributed to a Chinese-speaking actor, but states the strategies differ from this case; do not merge the two. The actor name UAT-11985 is Talos' tracking designation. No MITRE ATT&CK group profile is available for it in our reference data, so any attribution beyond "the actor Talos tracks as UAT-11985" is unconfirmed.

## 4\. Mitigation & containment

The controls that defeat this kit are identity and browser controls, not endpoint signatures. The AitM relay depends on the victim typing credentials into a page the actor controls, so anything that stops credentials being typed into a non-Google origin breaks the chain.

P1 (within 24 hours)

- Enforce phishing-resistant authentication (FIDO2 security keys or passkeys) for all Google Workspace and Microsoft 365 accounts, starting with finance, treasury, payments and any role with payment initiation or approval rights. The kit explicitly probes for passkey support and falls back to password plus MFA relay when it is absent; passkeys bound to the legitimate origin do not relay.
- Where passkeys are not yet deployed, restrict MFA to number-matching push or hardware tokens. The relay works by rendering whatever MFA challenge Google returns and forwarding the victim's response, so any factor the victim can be induced to complete on a lookalike page is relayable.
- Block the WebSocket egress pattern at the proxy for unmanaged destinations: alert on browser sessions opening a WebSocket to a host that is not on the corporate allowlist while a Google authentication flow is in progress. The kit cannot function without the persistent channel.
- Push a user advisory naming the lure pattern: invitation emails from academic or policy institutions, visible Google Forms link text that does not match the destination on hover, and event posters with QR codes. Instruct staff to reach registration pages by typing the institution's domain directly, never via the emailed link or the poster QR code.

P2 (within 72 hours)

- Add conditional access or Workspace policy that blocks authentication from the third-party hosting platforms commonly used for these kits where your organisation has no business need for them, and require managed-device and compliant-network posture for Google and Microsoft 365 sign-in.
- Enable and alert on Google Workspace and Entra ID logs for the AitM signature: a successful sign-in preceded by an authentication attempt from a hosting-provider IP range, a session token issued to a browser whose user agent does not match the enrolled device, or a sign-in where the MFA method recorded differs from the user's enrolled default.
- Review mail gateway rules for inbound messages whose visible link text is a Google Forms or Google Docs URL but whose href resolves elsewhere. Most secure email gateways can rewrite or flag display-text/href mismatch; enable it if it is off.
- If your organisation runs public events, audit your own event pages and downloadable posters for QR codes and confirm the registration links resolve to your own domains. The actor scrapes legitimate posters and swaps the QR code, so a poster circulating with your branding may not be yours.

P3 (within 7 days)

- Add the AitM relay behaviour to detection engineering: correlate a browser process opening a WebSocket to a non-allowlisted host with a subsequent POST sequence containing `google_login_start`, `google_input_identifier` or `google_login_check` in the request body. These event names are the kit's own protocol strings and are stable across the three lures Talos analysed.
- Tabletop the account-takeover path: if a finance user's Google session token were stolen today, what stops a payment instruction being sent from that mailbox, and how quickly would you detect it? The kit's output is a valid session, so mailbox rules, forwarding, OAuth grant and payment-callback changes made after takeover are the events to hunt.
- Retrieve the IOC set from Talos' GitHub repository (linked from the source report) and load it into your mail and web proxy controls. We have not reproduced those indicators here because they were not in the material supplied to us; do not treat this advisory as an IOC source.

## 5\. Indicators of compromise

No atomic indicators of compromise are available in the source material supplied to us. Talos states its IOC set is published in a GitHub repository linked from the report; we have not retrieved it. The table below records the behavioural indicators the source does describe, which are observable in proxy, browser and identity logs.

| behaviour                                                                                                                                    | where to observe                                           | confidence                                               |
| -------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------------------------------------- |
| HTTP POST to actor C2 with body containing google\_login\_start, google\_input\_identifier or google\_login\_check                           | web proxy / TLS inspection logs, browser network telemetry | high (named in source)                                   |
| Persistent WebSocket opened from a browser session to a non-allowlisted host during a Google authentication flow                             | web proxy, firewall, EDR network telemetry                 | high (named in source)                                   |
| Google sign-in page served from a non-Google origin, with iframe ID google-success-frame loading /google-login-assets/operation-success.html | browser DOM telemetry, web content inspection              | high (named in source)                                   |
| Spoofed login panel rendering only zh-CN, zh-TW or en based on navigator.languages                                                           | browser telemetry, user reports                            | medium (source describes kit behaviour, not a log field) |
| Inbound email whose visible link text is a Google Forms URL but whose href resolves to a third-party hosting platform                        | secure email gateway, mail header analysis                 | high (named in source)                                   |
| Event poster attachment whose embedded QR code resolves to a non-institutional domain                                                        | mail gateway attachment scanning, QR decode at the proxy   | high (named in source)                                   |

No copyable atomic indicator block is provided because the source material contains no hashes, domains, IP addresses or URLs.

## 6\. Detection

The source gives usable artefacts: the kit's own protocol strings, the iframe ID and asset path, and the obfuscation pattern. The YARA rule below targets the client-side JavaScript and HTML of the phishing page. It will not match the emails, which contain none of these strings.

```yara
rule Phishing_Google_AitM_Kit_UAT11985
{
    meta:
        author = "Adverse Trace"
        date = "2026-10-08"
        reference = "https://blog.talosintelligence.com/uat-11985/"
        description = "Detects the Google AitM phishing kit client-side page described by Cisco Talos (UAT-11985). Matches the kit's own relay protocol strings and the hidden success-frame asset path."
        confidence = "medium"
    strings:
        $ev1 = "google_login_start" ascii
        $ev2 = "google_input_identifier" ascii
        $ev3 = "google_login_check" ascii
        $frame = "google-success-frame" ascii
        $asset = "/google-login-assets/operation-success.html" ascii
        $sandbox = "sandbox=\"allow-scripts\"" ascii
        $rot = "while(!![])" ascii
    condition:
        uint16(0) == 0x3C3F or uint16(0) == 0x3C21 or uint16(0) == 0x6874 or filesize < 2MB
        and 2 of ($ev*) or any of ($frame, $asset) and $rot
}

```

The Sigma rule below targets the network and identity side, where the relay is observable without content inspection. It assumes proxy or EDR telemetry that records HTTP request bodies and WebSocket destinations.

```yaml
title: Google AitM Phishing Relay Protocol Strings in Web Traffic
id: 8f2c1a44-6b7e-4d19-9c02-uat11985a
status: experimental
description: Detects the UAT-11985 Google AitM phishing kit relay protocol strings in HTTP POST bodies, and browser WebSocket connections to non-allowlisted hosts during authentication.
author: Adverse Trace
date: 2026-10-08
references:

    - https://blog.talosintelligence.com/uat-11985/
logsource:
    category: proxy
detection:
    selection_events:
        cs-method: 'POST'
        body|contains:

            - 'google_login_start'
            - 'google_input_identifier'
            - 'google_login_check'
    selection_ws:
        cs-method: 'GET'
        cs-uri-scheme: 'wss'
        cs-host|endswith:

            - '.google.com'
    condition: selection_events
fields:

    - c-ip
    - cs-host
    - cs-uri
    - cs-user-agent
falsepositives:

    - Legitimate Google authentication traffic does not carry these parameter names; validate any hit against the destination host before blocking.
level: high

```

Both rules key on strings the kit itself emits. They will not fire on the lure emails, on the poster attachments, or on the actor's infrastructure before the victim clicks. Detection of the lure stage has to come from mail gateway display-text/href mismatch checks and QR-code decoding, which are configuration rather than signature work.

## 7\. Sources

- Cisco Talos, "UAT-11985: AI-assisted event lures delivering real-time Google AitM phishing", https://blog.talosintelligence.com/uat-11985/, published 2026-10-08.

## 8\. Adverse Trace position

We assess this as a moderate-priority advisory for EMEA financial services clients: no CVE, no CISA KEV entry, no ransomware, and no confirmed targeting of the sector, but a phishing kit whose output is a fully authenticated cloud session, which is the credential class that matters most to a bank. The technical detail is single-sourced to Cisco Talos and we have not independently validated the kit or retrieved its IOC set, so treat the protocol strings and asset paths as reliable for detection engineering but verify before enforcement, and do not treat the AI-generation assessment as confirmed. The actor designation UAT-11985 has no MITRE ATT&CK group profile in our reference data, so we make no attribution beyond Talos' own tracking name. We will retrieve and validate the Talos IOC set and issue a follow-up if it contains indicators that change the detection guidance, and we will monitor for the same kit architecture appearing against financial-sector identity providers, which is the development that would raise this to a sector-specific alert.

---

[Read the original source →](https://blog.talosintelligence.com/uat-11985/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*