Researchers have disclosed an APT spear-social-engineering campaign tracked as UAT-11985 that targets individuals affiliated with Taiwan research organizations. The lure is operational rather than technical: fake event invites that route victims to an adversary-in-the-middle (AitM) phishing framework impersonating Google authentication. The objective is to harvest Google account credentials and multi-factor authentication codes in real time, then replay them through the proxy to establish a valid Google session.
No CVE is identified in the reporting, and this should not be treated as a vulnerability-management issue. The risk is identity compromise: once an AitM relay captures a password plus an OTP or push approval, the attacker can often bypass conventional MFA, create a durable session, access Gmail/Drive, reset recovery options, add OAuth grants, and use the mailbox for downstream spear-phishing. For research institutes, universities, think tanks, defense-adjacent collaborators, and MSSPs protecting them, this is an active credential-theft operation, not a hypothetical phishing trend.
Technical Analysis
Affected products and platforms: Google Account authentication flows, Gmail/Google Workspace identities, Chrome/Edge/Firefox/Safari sessions on any OS, and the identity perimeter of organizations whose staff use personal or Workspace Google accounts for collaboration. The campaign is socially scoped to Taiwan research affiliates, but the technique generalizes to any organization with high-value Gmail or Workspace identities.
CVEs / CVSS: None disclosed in the source item. Do not map this activity to an invented identifier. Track it as TTP-based activity aligned to phishing and session theft techniques rather than patchable software exposure.
Attack chain from a defender's perspective:
- Target selection and lure fabrication: Operators identify researchers, assistants, administrators, or event coordinators and send credible fake invitations. Calendar and event lures are effective because they create urgency, imply professional context, and normalize clicking a login link from email.
- Redirect to AitM infrastructure: The invite link points to attacker-controlled infrastructure that presents a pixel-accurate Google sign-in flow. The domain is the tell: it may contain
accounts,google,login,verify, or event-related wording, but it is not a legitimate Google-controlled domain. - Real-time credential and MFA relay: The victim enters username/password. The AitM framework replays those credentials to Google. If challenged for MFA, the victim is prompted for an OTP, push approval, or other second factor, which is relayed immediately. This defeats TOTP/SMS/voice and can defeat some push flows when the user approves a prompt they believe is legitimate.
- Session material capture: Modern AitM kits prize session cookies and tokens more than passwords. If the framework captures post-authentication cookies, the operator can import them into an attacker browser and bypass repeated MFA until revocation/expiry.
- Post-compromise persistence: Expect mailbox rule creation, recovery email/phone changes, OAuth consent grants, forwarding, Drive sharing, contact harvesting, and use of the compromised mailbox to invite additional targets.
Exploitation status: Confirmed active campaign per reporting. No public PoC is required because this is deployed social engineering. Not applicable for CISA KEV because no CVE is named.
The most important defensive point: MFA presence is not MFA resilience. AitM turns one-time codes and many push approvals into relayed secrets. FIDO2/passkeys and Google Advanced Protection materially raise the bar because cryptographic origin binding prevents replay to a lookalike domain.
Detection & Response
Prioritize identity telemetry over endpoint malware telemetry. In pure AitM credential theft there may be no malicious process, no payload, and no endpoint IOC. Hunt the authentication and the post-login changes.
---
title: Proxy Access to Google Account Lookalike Hostname
id: 9d2a41b7-6f30-4c8e-9c11-7f0f2c6a8d41
status: experimental
description: Detects HTTP/S proxy requests where the Host/SNI contains Google-account themed strings but is not an allowlisted Google domain, consistent with AitM phishing relays.
references:
- https://attack.mitre.org/techniques/T1566/002/
- https://attack.mitre.org/techniques/T1557/
author: Security Arsenal
date: 2026/10/01
tags:
- attack.initial_access
- attack.t1566.002
- attack.credential_access
- attack.t1557
logsource:
category: proxy
detection:
selection:
c-uri-host|contains:
- 'accounts.google'
- 'accounts-google'
- 'google-accounts'
- 'google.login'
- 'login.google'
- 'google.verify'
- 'workspace.google'
filter_google:
c-uri-host|endswith:
- '.google.com'
- '.googleusercontent.com'
- '.gstatic.com'
- '.googleapis.com'
- '.youtube.com'
- '.google-analytics.com'
condition: selection and not filter_google
falsepositives:
- Squid or TLS inspection fields that capture only SNI may require normalization
- Internal training phishing platforms should be explicitly allowlisted by domain and campaign ID
level: high
---
title: Browser Launched With Remote Debugging or Automation Flags
id: 3a8e0d54-52a1-4b3a-b9ef-41d2f6c91a70
status: experimental
description: Detects Chrome/Edge/Firefox started with remote debugging or automation switches. Not the phishing relay itself, but useful for post-compromise triage where stolen session material or browser automation is used to validate access.
references:
- https://attack.mitre.org/techniques/T1185/
- https://attack.mitre.org/techniques/T1539/
author: Security Arsenal
date: 2026/10/01
tags:
- attack.collection
- attack.t1539
- attack.t1185
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
selection_cli:
CommandLine|contains:
- '--remote-debugging-port='
- '--remote-debugging-pipe'
- '--headless'
- '--disable-extensions'
- '--user-data-dir='
condition: selection_img and selection_cli
falsepositives:
- QA automation, Selenium/Playwright, accessibility tooling, and developer workstations
- Tune by parent process, user role, and approved automation host list
level: medium
// Sentinel/Defender: hunt for Google-auth lookalike destinations observed by endpoint network events
let GoogleAuthLookalikes = dynamic(["accounts.google","accounts-google","google-accounts","login.google","google.login","workspace.google","google.verify"]);
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where RemoteUrl has_any (GoogleAuthLookalikes) or RemoteIP in (GoogleAuthLookalikes)
| where not(RemoteUrl endswith "google.com" or RemoteUrl endswith "googleusercontent.com" or RemoteUrl endswith "googleapis.com" or RemoteUrl endswith "gstatic.com")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, ActionType
| order by TimeGenerated desc;
// Sentinel via CEF/Syslog ingestion of Google Workspace audit or IdP-equivalent sign-in logs
// Normalize field names to your connector. Focus: first-seen source/ASN, success after MFA, then rapid recovery/OAuth changes.
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DeviceVendor has_any ("Google","Google Workspace") or DeviceProduct has_any ("Workspace","Google","Identity")
| where Activity has_any ("login","signin","oauth","2sv","mfa","recovery","forwarding","filter","grant")
| extend User = coalesce(DestinationUserName, SourceUserName)
| extend Msg = tostring(Message)
| where Msg has_any ("challenge","success","2sv","oauth","recovery email","recovery phone","filter created","forwarding enabled","granted")
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Sources=make_set(SourceIP, 20), Activities=make_set(Activity, 30), Sample=any(Msg) by User, bin(TimeGenerated, 1h)
| order by LastSeen desc;
-- Triage endpoints for browser automation/debugging and suspicious access to browser credential stores
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(remote-debugging-port|remote-debugging-pipe|headless|user-data-dir)'
OR Name =~ '(?i)(chrome|msedge|firefox)'
-- List browser credential/profile artifacts touched recently for users implicated by sign-in alerts
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs='C:/Users/*/AppData/Local/{Google/Chrome,Microsoft/Edge}/User Data/**/{Login Data,Cookies,Network/Cookies,Web Data,History}', accessor='ntfs')
WHERE Mtime > now() - 86400*7
ORDER BY Mtime DESC
# Squid explicit-proxy hardening: allow only exact Google auth domains and deny Google-themed lookalikes
# Test in a staging proxy first. Requires TLS/SNI visibility or CONNECT host inspection; use only where lawful and disclosed.
set -euo pipefail
CONF=/etc/squid/conf.d/40-google-auth-allowlist.conf
sudo tee "$CONF" >/dev/null <<'EOF'
acl google_auth_exact dstdomain accounts.google.com
acl google_auth_exact dstdomain myaccount.google.com
acl google_auth_exact dstdomain gstatic.com
acl google_auth_exact dstdomain ssl.gstatic.com
acl google_auth_exact dstdomain googleapis.com
acl google_theme regex -i (accounts|login|signin|verify|workspace).*google|google.*(accounts|login|signin|verify|workspace)
http_access allow google_auth_exact
http_access deny google_theme !google_auth_exact
deny_info TCP_RESET google_theme
EOF
sudo squid -k parse
sudo systemctl reload squid
sudo grep -n "google_theme" /var/log/squid/access.log | tail -50 || true
Remediation
- Immediately contain suspected compromises: revoke Google sessions, reset passwords, remove attacker-added recovery email/phone, delete unknown OAuth grants, disable forwarding/filters, and rotate app passwords. Reissue hardware-backed MFA where available and treat captured OTPs as burned.
- Move high-risk users to phishing-resistant MFA now: enroll researchers, executives, admins, finance, and external-collaboration-heavy staff in FIDO2 security keys/passkeys. For the highest-risk cohorts, evaluate Google Advanced Protection Program for Workspace/consumer Google identities.
- Harden Workspace: enforce 2-Step Verification with security keys for privileged and targeted groups; restrict less-secure app access; alert on recovery option changes, new filters/forwarding, OAuth grants to unverified apps, unusual IMAP/POP enablement, and sign-ins from new ASN/country plus rapid MFA events.
- Email and web controls: banner external event invites, rewrite and detonate URLs, block newly registered domains impersonating Google-account language, and add proxy allow/deny logic similar to the Squid example. Train users to navigate to Google accounts via known bookmarks or password managers, never invite links.
- Operational hunt: for every suspected click, search 14 days before/after for sign-in anomalies, mailbox rule creation, OAuth consent, Drive sharing externally, and downstream messages sent from the account. Assume credential replay occurred even if the user reports “I only entered my password.”
- Useful official references: Google Account security guidance (https://support.google.com/accounts/answer/46526), Google Workspace admin security center/2SV controls (https://support.google.com/a/), Google Advanced Protection Program (https://landing.google.com/advancedprotection/), CISA phishing guidance (https://www.cisa.gov/secure-our-world/recognize-and-report-phishing).
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.