The Login Was Legitimate. Russia-Linked Operators Turned OAuth and WhatsApp Linking Into Initial Access.
The login pages were real. The QR codes were real. The device-linking requests were real.
That did not make them safe.
Google Threat Intelligence Group has documented three suspected Russian cyber-espionage clusters that repeatedly turn legitimate authentication features into initial-access mechanisms. Their targets include people working in academia, aerospace and defence, government, diplomacy, nonprofit organisations and think tanks across Europe and the United States.
The common technique is not to break authentication. It is to persuade a carefully selected person to complete an authentic workflow that grants the attacker access.
The security control completed the attack
Application passwords, OAuth consent, device codes and linked devices exist for legitimate reasons. They allow older applications to connect, third-party services to receive delegated access, devices with limited keyboards to authenticate and messaging accounts to work across several screens.
Those features also create a dangerous gap between technical validity and human intent.
A user can authenticate on the correct Google or Microsoft domain, scan a genuine WhatsApp code and approve a request generated by the real service. If the request originated with an attacker, the platform can issue exactly the access that its protocol was designed to issue.
This is why conventional phishing advice is insufficient. Checking the domain helps detect a counterfeit login page. It does not explain why an unexpected person is asking the user to authorise an application, copy a verification code or link a new device.
Three clusters, not one campaign
Google tracks the activity as UNC6293, UNC7005 and UNC5976. It assesses with high confidence that all three have a Russian nexus, but it does not present them as one group.
GTIG assesses with moderate confidence that UNC6293 and UNC7005 are linked to an initial-access subcluster of ICE RELIC, the actor formerly known as APT29. UNC5976 remains distinct and may reflect a different strategic mandate or intelligence-service alignment.
The separation matters. Similar targeting and authentication abuse do not prove shared command. Defenders should use the common operational pattern without collapsing three analytical clusters into one attribution claim.
UNC6293 is the most patient of the three. It has impersonated US State Department officials, built rapport with prominent academics and critics of Russia and instructed targets to create application-specific passwords. In June 2026, GTIG also observed the cluster asking targets to share a full redirect URL or verification code after completing a legitimate external login.
UNC7005, also tracked by Microsoft as STORM-2945, combines selective social engineering with device-code phishing, OAuth abuse and malware. Its lures have imitated diplomatic events, conferences, GLOBSEC and the Finnish Operations Center. In August, it sent targets connected to the European defence industry through a genuine Google OAuth login before redirecting them to an attacker-controlled cloud project likely intended to collect authentication tokens.
UNC5976 has used fake file-sharing sites to send targets to legitimate Google OAuth pages. After authentication, malicious scripts in an associated cloud project collected the returned token. Google says the cluster created at least twelve new domains and related infrastructure within roughly three months of the first discovery and disruption, then began moving parts of the operation away from Google infrastructure.
The WhatsApp code was genuine
UNC7005’s WhatsApp operation shows the problem most clearly.
In May and June 2026, attacker-controlled pages invited targets to join a secure WhatsApp call, chat or document share. The page asked for a phone number, which the attacker used to initiate a legitimate linked-device request. It then displayed the real QR code and linking code to the target.
If the target followed the instructions, WhatsApp linked the account to a device controlled by the attacker. The platform was not reported as compromised. The user had been manipulated into approving the attacker’s device.
The operation continued after the link was established. One path presented a fake voice call and requested browser access to the camera and microphone. Malicious JavaScript recorded audio and video while the call appeared to ring, then uploaded the recording when the call appeared to fail. Other paths offered a fake encrypted chat or an unknown file download.
This is a useful distinction for incident response. Removing a malicious email or resetting an account password may not remove an already linked messaging device. The response must examine the platform’s delegated access, sessions and device relationships.
Personal accounts create an organisational blind spot
Many targets are selected because of their work, but the compromised accounts may be personal.
An academic advising a government, an employee in the defence supply chain or a researcher focused on Russia may discuss sensitive work through a personal mailbox or encrypted messenger. Corporate identity logs, endpoint tools and email gateways may never see the initial approach or the resulting account access.
That visibility gap is strategic. A compromised personal account can expose relationships, private correspondence and meeting plans. It can also become a credible channel for approaching the victim’s contacts. The attacker gains both information and a trusted identity from which to continue the operation.
UNC7005 also delivered VIDAR to Windows users and ATOMIC Stealer to macOS users through a fake summit application. Malware remains part of the playbook. The more important lesson is that some of the most consequential access required no malware and no vulnerability.
Defence must validate intent, not only the login
Organisations with staff in the affected sectors should treat unexpected authorisation requests as possible security incidents, even when the browser displays a legitimate service.
- Disable application-specific passwords where they are not operationally required. Google recommends its Advanced Protection Program or security-key-only two-step verification for high-risk users.
- Inventory OAuth applications and delegated permissions. Revoke unfamiliar grants and investigate the messages or events that preceded them.
- Monitor device-code authentication and unusual consent events, especially when they follow invitations, conference registration or file-sharing requests.
- Require staff to confirm unexpected invitations through a separately obtained contact channel. Do not rely on phone numbers, links or identities supplied inside the invitation.
- Establish routine checks of linked devices in WhatsApp and other messaging platforms. Remove unfamiliar sessions immediately.
- Enable registration locks and two-factor authentication for messaging accounts where available. These controls do not neutralise a willingly approved device link, but they reduce other takeover paths.
- Include personal-account compromise in high-risk-user playbooks. Provide a trusted route for reporting suspicious contacts without requiring the event to begin on a corporate device.
- After suspected compromise, revoke tokens, application passwords, sessions and linked devices. A password reset alone may leave alternate access intact.
Detection teams should also use the indicators published by GTIG, while recognising their limits. These campaigns are selective and adaptive. Domain blocklists can disrupt known infrastructure, but they cannot distinguish a legitimate OAuth request initiated for a malicious purpose.
The attacker no longer needs to fake the door
Authentication systems are designed to answer a technical question: did the account holder complete the required steps?
These operations exploit a different question: did the account holder understand whose access those steps would create?
That is the BlackTree angle. Mature identity programmes often measure stronger authentication, fewer passwords and broader adoption of trusted platforms. Those are useful improvements, but they do not eliminate social engineering. They can move the decisive moment from entering a secret into approving a relationship.
The login can be legitimate. The authorisation can be cryptographically valid. The new device can be linked exactly as designed.
The access can still belong to a Russian espionage operator.
Sources and further reading
- Google Threat Intelligence Group: Going with the Flow(s): Distinct Clusters Target Individuals of Interest to Russia, published 20 August 2026
- Google Threat Intelligence Group: What’s in an ASP? Creative Phishing Attack on Prominent Academics and Critics of Russia, published 18 June 2025 and updated 10 July 2025
- Citizen Lab: Same Sea, New Phish, published 18 June 2025
- ReliaQuest: DNS Poisoning Tactics Expand to Hospitality Wi-Fi, published 23 July 2026
- Microsoft Threat Intelligence: CaptiveCrunch: Midnight Blizzard Targets Travelers Worldwide for Malware Delivery and Credential Theft, published 31 July 2026
