UAT-11985: QR Phishing and Google AitM Relay

Cisco Talos's campaign analysis says the threat cluster tracked as UAT-11985 targeted people affiliated with Taiwan-based research organizations in a spear-phishing campaign observed during 2026. The lures borrowed real public event topics and institutional names, then routed recipients to credential-harvesting pages. The activity combined email with modified event posters containing malicious QR codes, widening exposure beyond the original inbox recipient.

The most consequential technical feature was an adversary-in-the-middle (AitM) relay impersonating Google sign-in. It could forward the victim's authentication interaction to the real service while synchronizing the page through HTTP requests and a WebSocket channel. This makes a copied password or one-time MFA code insufficient protection if an attacker can relay the live challenge and capture an authenticated session. Talos says its analysis indicates MFA challenges and session tokens could be intercepted. This is a campaign-specific capability, not proof that every MFA method is bypassable.

How the lure established trust

Talos observed messages impersonating or referencing the Taiwan European Union Centre, National Chengchi University's Institute of International Relations, and Taiwan Research Institute. The messages used plausible public event information, recipient-focused flattery, and a reusable invitation structure. The visible registration text could look legitimate while its actual link led elsewhere. A poster's genuine appearance was not reliable evidence that its QR destination was genuine because the code itself had been changed.

Talos assesses that the messages were likely AI-assisted based on repeated structure, formulaic language, and rapid customization. It does not claim to have proven that a generative model wrote them. Treat AI attribution as an analyst assessment, not an observed fact.

AitM relay, at a high level

1. A target follows an event registration link or scans a modified QR code.
2. A counterfeit form directs the target to a look-alike Google sign-in page.
3. The phishing infrastructure relays the interaction to the real sign-in service. HTTP carries submitted events while a persistent WebSocket synchronizes the challenge shown to the victim.
4. If authentication succeeds, the attacker may obtain a session artifact that can outlast the password submission. Talos describes interception capability; organizations still need tenant logs and evidence to determine whether a particular account was accessed.

This architecture matters because the user can see a plausible, functioning authentication flow. A valid-looking event, correct institutional branding, HTTPS, or a familiar identity-provider logo does not establish that the browser is on the provider's origin. Traditional MFA can reduce risk, but phishing-resistant authentication such as origin-bound FIDO2/WebAuthn is the stronger control against credential relay. Deploy it where supported and pair it with session and sign-in monitoring.

Response checklist for identity and security teams

• Verify event invitations through the institution's independently located website or a known contact. Do not use the email's reply address or registration link as the verification channel.
• Treat QR codes as URLs. Preview the destination with a managed scanner, compare the domain with the institution's official domain, and avoid scanning codes on reprinted or altered posters.
• For suspected credential submission, revoke sessions and refresh tokens using the identity provider's incident procedure, reset credentials from a clean device, and review recent sign-ins, consent grants, recovery methods, and account changes. Password reset alone may not invalidate an already issued session.
• Look for unfamiliar sign-in locations and devices, newly added authentication factors, unexpected OAuth grants, and mailbox forwarding or delegated access. Preserve logs before retention windows expire.
• Prefer FIDO2/WebAuthn or passkeys with origin binding for high-risk accounts. Train users to reject unexpected authentication prompts rather than approve them to complete an event registration.
• Share confirmed indicators only from a trusted threat-intelligence source. Cisco Talos publishes campaign IOCs and detection coverage separately; do not copy unverified infrastructure into block lists.

What is known and unknown

This summary reflects Talos's October 8, 2026 analysis. Attribution, victim scope, and incident impact should be revisited if new primary evidence changes the assessment.

Separate a phishing attempt from a confirmed account incident

An AitM page can relay a live login, but campaign capability alone does not show that a particular person submitted credentials or that an account was accessed. Triage each report against the user's activity and the identity provider's records. Preserve the original invitation, QR image, destination URL, message headers, device details, and the time the user interacted. Avoid opening the lure from a normal corporate workstation.

For affected accounts, inspect new MFA methods, recovery changes, OAuth consent, mailbox forwarding, delegated access, and file activity. Scope the investigation to the user's permissions and the systems they could reach. If the account belongs to an administrator or a researcher with sensitive data, widen review to related identities and shared workspaces. Do not claim data exfiltration unless activity evidence supports it.

Reduce QR and AitM exposure at the control layer

Security awareness should tell users to verify the organizer and destination independently, but training cannot verify a QR code after someone scans it. Managed mobile devices can route unknown links through a protected browser or URL-analysis service. Email and endpoint controls can flag newly registered or look-alike domains, while an identity provider can require phishing-resistant authentication for sensitive accounts and alert on unusual session behavior.

NIST's SP 800-63B verifier-impersonation requirements provide a reference for evaluating phishing-resistant authentication. Check the authenticator and identity-provider configuration rather than relying on a “MFA enabled” label. A phishing-resistant method reduces credential-relay risk, but it does not prevent an attacker from using an already stolen session or exploiting a compromised endpoint.

Questions about event-invitation AitM phishing

Does MFA stop an AitM attack? Not necessarily. A relay can capture a live challenge or session when the chosen method is phishable. Prefer correctly configured origin-bound authentication and still monitor sessions.

Does a QR code make an event invitation safer than email? No. A QR code hides the destination until scanned. Verify the final domain through a separate trusted channel.

Related reading: OAuth and OIDC security testing for SaaS and SAML SSO security testing.