Russian Hackers Abuse OAuth, WhatsApp to Hijack High-Value Accounts

Cyber-espionage groups weaponize OAuth and WhatsApp features to bypass traditional security measures in targeted attacks.

By Central
Google Cloud analysts detail three clusters of Russian cyber-espionage activity exploiting authentication features.
Highlights
  • Attackers use legitimate OAuth workflows to gain account access without password theft.
  • WhatsApp device-linking scams trick victims into granting attacker access to messages and contacts.
  • Three clusters—UNC6293, UNC7005, and UNC5976—are linked to Russian cyber-espionage operations.

Suspected Russian cyber-espionage groups are turning the very features designed for convenience—OAuth sign-ins and WhatsApp device linking—into stealthy tools for account takeover, targeting high-value individuals across Europe and the United States in a series of sophisticated campaigns that bypass traditional password theft entirely. This latest wave of activity, documented by Google Cloud’s Threat Intelligence Group, marks a significant evolution in cyber-espionage tactics, where attackers no longer rely on breaking passwords or exploiting software flaws. Instead, they expertly manipulate legitimate authentication workflows, persuading targets to approve actions that look perfectly normal but hand over complete account access.

The New Frontier of Account Hijacking: Weaponizing Trusted Authentication Features

The attack methodology represents a dangerous shift in the threat landscape. These operations do not depend on tricking a user into typing their password on a fake login page—a classic phishing technique that is increasingly detectable by security tools and user awareness training. Instead, the victim often interacts with a real authentication page or a genuine account feature, making the scam appear significantly safer than a traditional fake login page. This creates a critical blind spot for organizations that primarily monitor corporate accounts and may overlook suspicious activity on personal accounts, which are frequently the initial target.

Google Cloud analysts identified three distinct clusters of malicious activity, tracked as UNC6293, UNC7005 (also known as STORM-2945), and UNC5976. These groups use a combination of highly targeted phishing, OAuth abuse, app-password theft, device-code lures, and malware to compromise accounts belonging to individuals in academia, aerospace, defense, government, nonprofit organizations, and think tanks. Google assesses with high confidence that these clusters have a Russian nexus, based on their targeting patterns, the geopolitical themes of their phishing lures, and their operational methods.

Understanding the Core Techniques: How Russian Hackers Abuse OAuth and WhatsApp Device Linking

WhatsApp Device-Linking: The GhostPairing Threat

The campaign conducted by UNC7005 offers a stark illustration of this new approach. In a WhatsApp-focused operation observed during May and June 2026, attackers used tailored lures impersonating events, embassies, conferences, or trusted organizations. Victims were directed to a convincing fake page and asked to enter their phone number. The page then generated a legitimate WhatsApp device-linking request for an attacker-controlled device and displayed the real QR code or linking code to the target. If the target unwittingly approved the request in WhatsApp, the attacker instantly gained a linked session capable of accessing all the victim’s messages, contact lists, and media.

This technique mirrors the wider risk documented in what security researchers call WhatsApp GhostPairing account hijacks, where social engineering turns a normal companion-device feature into unauthorized account access. After successful device linking, UNC7005’s pages could present a fake voice call, encrypted chat, or file-transfer option to the victim. The false call page used malicious browser code to record audio and video, while the chat path displayed credentials for a secondary login page. Google Cloud could not determine what file was staged in the file-transfer scenario, but the potential for data theft is clear.

OAuth Abuse: Signing In With Google to Hand Over Your Account

The same cluster also abused OAuth flows against Google and Microsoft accounts. In August 2026, it used domains impersonating the Finnish Operations Center to target people connected to Europe’s defense sector. Victims who selected “Sign in With Google” were taken to a real Google login page before being redirected to an attacker-controlled, unverified cloud project designed to collect authentication tokens. This tactic is fundamentally different from password theft because a victim can enter their correct credentials only on a legitimate provider page and still give an attacker full access. The victim sees a familiar interface, and no red flags are raised, while the attacker silently captures the token that allows them to access the account without ever knowing the password.

Earlier reporting on Google services phishing abuse has illustrated how trusted infrastructure can make malicious requests appear unusually convincing. Similar attacks leveraging Microsoft Teams meeting invite abuse have demonstrated how valid device-code workflows can be weaponized to obtain durable access tokens without stealing passwords.

Beyond Authentication Abuse: Malware Distribution in Targeted Campaigns

UNC7005’s activities extend well beyond authentication abuse. In a broader campaign in late May 2026, attackers used a fake Ukraine-related summit website to distribute browser-information stealers to both Windows and macOS users. Windows visitors received VIDAR, while macOS users received ATOMIC—two malware families built specifically to collect saved browser data such as credentials, cookies, addresses, and payment details. This dual-platform approach highlights the sophistication and resource availability of these threat actors, who are prepared to compromise victims regardless of their operating system.

The distribution of malware through seemingly legitimate conference sites represents a multi-stage attack. The first stage uses social engineering to convince the target to visit a site and download a file. The second stage involves the silent theft of all browser-stored credentials, which can then be used for further account takeovers, lateral movement within a network, or long-term espionage. This layered approach ensures that even if one attack vector fails, another may succeed.

Why Personal Accounts Are the Primary Target

A key strategic element of these campaigns is the targeting of personal accounts. High-value individuals—researchers, policymakers, defense contractors, and government officials—often use personal email addresses and messaging apps for sensitive communications, believing them to be outside the reach of corporate security teams. These personal accounts frequently fall outside an employer’s normal monitoring coverage, creating a blind spot that attackers are eager to exploit. Once a personal account is compromised, it can serve as a pivot point for gathering intelligence on professional networks, ongoing projects, and internal organizational dynamics.

The abuse of legitimate features and infrastructure makes malicious activity harder to distinguish from normal account use. A familiar-looking invitation, a valid QR code, or a genuine sign-in page does not prove the request is safe. This reality demands a fundamental shift in how both individuals and organizations approach account security.

Defensive Strategies: Protecting Against Device-Code and OAuth Phishing

For defenders, the message is clear: the tactics used by UNC6293, UNC7005, and UNC5976 require a proactive and layered defense. Organizations cannot rely solely on monitoring corporate accounts. They must extend their threat detection to include personal accounts used by high-risk personnel, especially if those accounts have any connection to business-critical communications or data access.

Users should follow several key practices to protect themselves. First, always inspect the browser URL before signing in. A legitimate login page will always have the correct, official domain name. Second, avoid proceeding past browser warnings that indicate a suspicious or insecure website. Third, independently verify any invitation or request through contact details obtained outside the message itself—for example, by calling the person who supposedly sent the invite using a known phone number. Finally, never share app passwords, verification codes, or a full authentication URL with another person. Legitimate services will never ask for these details.

Organizations should routinely review linked devices on both personal and work messaging accounts. Enforcing two-factor authentication and registration locks where available provides an essential additional layer of defense. Validating contacts through a separate channel before approving any sensitive request can prevent many of these attacks. High-risk users should remove any unfamiliar linked devices immediately and treat unexpected requests to join “secure” chats or calls as potential phishing attempts until proven otherwise.

Indicators of Compromise and the Ongoing Threat

Google Cloud provided a substantial list of indicators of compromise (IoCs) to help security teams identify and block these threats. These include domains, IP addresses, and file hashes associated with the three clusters.

UNC6293 Indicators

  • Domains: atribudosportal[.]app, foreignrelations[.]us, fewfwfwfwfwf[.]info, miov2iaiaoubqosiqoiajwowiwjso[.]online, mioisiskwowiwjowuwjwolab[.]club
  • IP Addresses: 196.251.107.171

UNC7005 (STORM-2945) Indicators

  • WhatsApp-Themed Infrastructure: wa-connect[.]eu, wa-connect[.]net, wa-invite[.]com, wa-device[.]com, wa-meeting[.]com
  • Other Phishing Domains: chamber-ua[.]org, shopinvite[.]org, my-invite[.]org, globsec[.]net, owa-ms365[.]com, m365-owa[.]com, ms365-device[.]com, ms365-live[.]com, finishoperations[.]com, finishoperations[.]org, foc-share[.]com, share-foc[.]com, internal-share[.]com, foc-share[.]org
  • Command-and-Control: statistic-ms[.]live (ENGINELIGHT C2)
  • IP Addresses: 31.57.243.154, 38.146.28.75, 104.194.159.150
  • File Hashes (SHA-256): 5b8d50c2e8cc3038b7c6e6dbf1219f6e814930a1e3c005a06a8fd1b6fa1924, 199a4540cf16d089217ce8f78c6177, 1d9299799a7b8da67c44ebec064d64542c27645f8e84de4a22ca3f6cbc843e3c (VIDAR), c5826032207d623a7f6caec8465af7364eccc355f9a488125752ad7c20d715920 (ATOMIC), a3b2fb0fdde660f07b3f2b05366403b624e35777cbc07dbe66398b21bba70396, a20b859c828f622028e690c943f7fa9aca426c07cab52b5aaba757ebe99857449, d2856dd5a84e21c8a3d5e0e01456adb440621e3ee845fde739fcd3ca9ce62c7f, 142a7c501d11db4c4f6f7090895c1c3dee30de6b3f098ca3a788dc198646e529, 20e20b074967ed6f6e04d609ccec5ff7492665ef25f894ca3be5885afb3eb3bb, 19341e2653212200c568f3f900e02c7f4165967d6f7737b3fef87959846920b57 (HEADRUSH)

UNC5976 Indicators

  • Domains: drive[.]google[.]verify-drive[.]com, mail[.]kiis[.]co[.]uk
  • File Hash (SHA-256): a5368b531ad1427c7214d4c41a2

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Security teams should re-fang these indicators only within controlled threat intelligence platforms such as MISP, VirusTotal, or a SIEM.

The exploitation of OAuth and WhatsApp device-linking represents a mature and dangerous evolution in cyber-espionage. As attackers continue to refine their methods, the cybersecurity community must adapt by treating any unexpected request for authentication—even one that uses a real platform—with deep skepticism. The line between legitimate and malicious has become dangerously blurry, and only a heightened, consistent vigilance can protect the individuals and organizations most at risk.

Share This Article