The Login Screen Was Real. The Hacker Was Russian.

What did Google's threat researchers actually find?

Google's Threat Intelligence Group published a report this month naming three distinct hacker clusters, tracked as UNC6293, UNC7005 (also called Storm-2945), and UNC5976, that it assesses with high confidence share a Russian nexus. The report is explicit about what makes these campaigns unusual: none of the three groups relies on a software vulnerability. Instead, each abuses a legitimate authentication workflow, the same app-password screens, OAuth consent prompts, and device-linking flows that a normal employee uses every day to sign into Google, Microsoft, or WhatsApp.

UNC6293 has been active since at least June 2025, when Google and the Citizen Lab first detailed it as a probable sub-cluster of Ice Relic, the group more widely known as APT29 or Cozy Bear. UNC7005 was identified separately in February 2026 and UNC5976 has been tracked since March 2026; Google treats all three as related but operationally distinct, each with its own infrastructure and target list.

How does a real login screen become a trap?

The mechanism varies by cluster but the pattern is consistent: get the target to complete a genuine login, then capture what comes out of it. UNC6293 tricks targets into generating an application-specific password, a legitimate Google feature meant for older devices, and then relays that password back to the attacker either directly or through a fake verification-code request. UNC7005 runs a parallel version against Microsoft accounts using device-code phishing, where a victim is talked into entering a real Microsoft device code on the attacker's behalf, handing over a valid session token without ever typing a password onto a fake page.

UNC7005's most distinctive technique targets WhatsApp directly. Since May 2026, the group has lured victims into linking their WhatsApp account to an attacker-controlled device using WhatsApp's own device-linking feature, the same one used to run WhatsApp on a second phone or a laptop. Once linked, the attacker can read messages, place calls, and, through malicious JavaScript served during a faked voice call, record the target's own audio and video without installing a single file on their device.

Who is actually on the target list?

Google names the sectors directly: academia, aerospace and defense, governments, think tanks, and diplomatic staff, concentrated in Europe with a secondary footprint in the United States. The clearest single data point in the report is a dated one: between August 6 and August 13, 2026, UNC7005 sent phishing emails to people in or connected to the European defense industry, using a domain spoofing a Finnish operations center. UNC5976 skews more military and industrial, with its geographic targeting centered on Ukraine and Armenia.

Why can't your security software catch this?

Because there is nothing for it to catch at the point of compromise. An intrusion-detection system looks for exploit code, a known malicious file hash, or traffic to a flagged address; none of that exists when the entire attack consists of a real person clicking through a real login screen and handing over a token that Google or Microsoft itself considers valid. The infostealer malware Google does document further down the chain, VIDAR on Windows and ATOMIC on macOS, only arrives after the account is already compromised, which means antivirus catches the second half of the attack at best.

This is the genuinely new part for a business that has spent its security budget on endpoint tools and patch management: the entry point here is a permissions and awareness gap, not a technical one. A fully patched laptop with current antivirus offers no resistance to a colleague who approves a device-link request they did not initiate.

What should an owner actually do about it this week?

Start with the admin console, not the help desk. In Google Workspace and Microsoft 365, review which third-party apps and OAuth grants your highest-risk staff, anyone in government-facing, defense-adjacent, or academic-research roles, have approved, and revoke anything unrecognized. Where your organization does not need Microsoft's device-code sign-in flow for legitimate use, such as signing into a smart-TV app, disable it outright; it is the exact mechanism UNC7005 abuses.

Separately, tell the specific people in those roles, by name, never to approve a WhatsApp device-linking prompt or share a verification code they did not generate themselves, and to check their own WhatsApp linked-devices list this week for anything unfamiliar. None of this costs money. All of it closes the actual door these three groups are using.

Read next: Binance Left Russia. Its Compliance Inbox Didn't.  |  MCP Dropped Sessions and Moved Your Model Bill