Google’s Threat Intelligence Group (GTIG) has published details on three distinct, Russia-nexus espionage clusters running concurrent phishing operations against individuals of interest to the Russian state — academics, diplomats, aerospace and defense researchers, and think-tank staff across Europe, the US, and Ukraine. None of the three techniques exploits a software vulnerability. Instead, each abuses a legitimate authentication feature — application-specific passwords, OAuth consent screens, and WhatsApp’s linked-device flow — to walk around multi-factor authentication rather than break it, which is exactly why they are largely invisible to standard credential-phishing detections.

What Happened

GTIG tracks the activity as three clusters: UNC6293 and UNC7005, assessed with moderate confidence as initial-access clusters tied to Ice Relic (Google’s name for the actor also tracked as APT29 / Cozy Bear / Midnight Blizzard), and UNC5976, a separate cluster active since at least March 2026 focused heavily on Ukraine and Armenia.

UNC6293 impersonates U.S. State Department officials and sends tailored, low-volume lures — conference invitations, diplomatic-themed documents — to high-value targets critical of the Kremlin. Its signature technique is app-password phishing: the lure walks the victim through generating a Google application-specific password “to join a secure call” or “access a shared document.” Because app passwords bypass standard second-factor prompts by design, a victim who generates one and hands it over gives the attacker durable account access that survives password rotation and doesn’t trigger the MFA challenge a normal login would.

UNC7005 runs a parallel OAuth-abuse track. Victims land on a fake file-sharing page and click a “Continue with Google” button that opens a legitimate Google OAuth consent screen — the domain and TLS certificate are real, so URL-based training and browser warnings don’t fire. After the victim authenticates, the flow redirects through an attacker-controlled Google Cloud project that captures and persists the resulting OAuth token, giving the attacker durable API access to the victim’s mail and files without ever touching a password. UNC7005 separately lures targets into linking their WhatsApp account to an attacker-controlled device via WhatsApp’s own multi-device linking feature, then triggers JavaScript during a normal-looking voice call to silently record audio and video, uploading the capture to attacker infrastructure — turning a legitimate WhatsApp feature into a persistent wiretap that requires no malware on the victim’s device.

UNC5976 takes a more infrastructure-heavy approach, abusing Supabase and Cloudflare Workers-style edge/serverless platforms to host token-theft pages and relay stolen sessions, and has deployed the HEADRUSH malicious Excel add-in against at least one Ukrainian aerospace and imaging company. Payloads observed across the three clusters include VIDAR, ATOMIC, ENGINELIGHT, and CHERRYPIE, alongside the credential- and session-harvesting infrastructure described above.

Impact

The shared thread across all three clusters is that each abused mechanism is a legitimate, vendor-supported feature — app passwords, OAuth consent, device linking — not a bug. That means signature-based phishing detection, URL reputation filters, and even most MFA deployments provide little protection: the victim is authenticating through a real identity provider’s real login page. Standard MFA is not a durable defense against any of these techniques, because none of them requires stealing or replaying a session cookie or defeating a second factor directly — the victim voluntarily mints a durable credential (an app password) or grants a durable authorization (an OAuth token or a linked device) and hands it over as part of what looks like normal onboarding for a call or document.

Organizations with staff in academia, government-adjacent research, aerospace/defense, or NGO/think-tank work — Russia’s stated targeting priorities here — should treat this as an active, ongoing collection effort rather than a one-off campaign.

Mitigation

  • Disable application-specific password generation at the tenant/organization level where it isn’t operationally required; app passwords bypass conditional access and MFA by design and have no legitimate use case for most knowledge workers.
  • Move from OTP/push MFA to phishing-resistant, hardware-bound authentication (FIDO2 security keys or platform passkeys) for any account with access to sensitive research, diplomatic, or defense-adjacent data — phishing-resistant MFA doesn’t stop app-password or OAuth-token abuse by itself, but it closes the credential-phishing leg attackers fall back to.
  • Audit and restrict third-party OAuth app grants tenant-wide; alert on new OAuth consent grants from unfamiliar or newly registered Google Cloud/Workspace projects, and require admin approval for non-published apps requesting mail or file scopes.
  • Review WhatsApp linked-device lists on corporate and high-risk personal devices; WhatsApp shows linked devices under Settings > Linked Devices, and any unrecognized entry should be treated as an active compromise, not a stale session.
  • Brief high-risk personnel (public critics of Russia, diplomatic staff, defense researchers) specifically on app-password and OAuth-consent social engineering, since this bypasses the “check the URL / watch for a fake login page” training most phishing awareness programs rely on.
  • Hunt for outbound traffic to Supabase and Cloudflare Workers subdomains that don’t correspond to known internal usage, and for VIDAR/ATOMIC/ENGINELIGHT/CHERRYPIE indicators from recent threat-intel feeds.

Sources