Three Russian Clusters Are Phishing Auth Flows, Not Passwords: OAuth, App Passwords, and WhatsApp Device Linking

Three Russian espionage clusters are targeting authentication flows, not just passwords, according to Google Threat Intelligence Group's research. The affected groups are UNC6293, UNC7005, and UNC5976, which have been active since at least March 2026. These clusters focus on academia, aerospace and defense, government, and think tank personnel in Europe, Ukraine, and the United States.

All three clusters manipulate the authentication flow itself, including OAuth consent, application-specific passwords, device code grants, and WhatsApp device linking. They persistently adapt their tactics, targeting personal accounts across multiple platforms. The clusters use OAuth consent, device code grants, and WhatsApp device linking, but a complete multi-factor authentication (MFA) rollout does not prevent these attacks.

UNC6293, a sub-cluster of Ice Relic, is assessed as a persistent and adaptive threat, focusing on personal accounts. UNC7005, also known as Storm-2945, has been linked to WhatsApp device linking. UNC5976, which centers on military, aerospace, defense industrial base, and NGOs, has automated OAuth token harvesting using legitimate cloud services. The groups use commercial residential proxies and purchase domains with file-sharing themed names to create a cloud project tied to each domain.

After successful authentication, the victims are redirected to a Google Cloud project URL, where scripts strip the authentication token and stage it for the operator. The response from Google disrupted most of these domains, but UNC5976 continued to pivot to other providers. Additionally, the groups run malware, such as the rogue Excel plugin "HEADRUSH" targeting Ukrainian aerospace companies.

In the UNC5976 flow, users authenticate on the genuine Google login page, satisfy MFA, and do not see a credential prompt on an attacker domain. The theft occurs after authentication, in the redirect. User awareness training does not catch this, as the victim authenticates on the real Google login page, satisfies MFA, and does not see a credential prompt on an attacker domain.