Living Off the Legitimate: How Russian APTs Weaponize Google OAuth and WhatsApp Linking

For years, the playbook for state-sponsored cyber espionage relied heavily on custom malware, zero-day exploits, and infrastructure built from scratch to breach high-value networks. But building custom implants that bypass modern endpoint detection and response (EDR) solutions is expensive and noisy. Why bother writing a complex kernel-level rootkit when you can just log in using the front door?

Recent findings from the Google Threat Intelligence Group (GTIG) highlight a profound paradigm shift in how advanced persistent threat (APT) groups operate. Instead of breaking security controls, attackers are increasingly “Living Off the Legitimate”—weaponizing native cloud features, identity providers, and everyday communication platforms to blend in with normal administrative traffic. By co-opting trusted ecosystems like Google OAuth, Microsoft Entra ID, and WhatsApp, Russian state-sponsored actors are gaining stealthy, persistent access to diplomatic, defense, and academic targets with minimal risk of setting off traditional alarm bells.

Anatomy of the Threat Clusters: UNC6293, UNC7005, and UNC5976

The campaign mapped by GTIG involves three distinct suspected Russian threat clusters—UNC6293, UNC7005, and UNC5976—each operating with a high degree of operational security and focus. These actors are not casting wide nets; their targets are meticulously chosen high-value entities, including government ministries, international think tanks, defense contractors, and academic institutions.

The attribution of UNC6293 as a sub-cluster of Ice Relic (widely tracked as APT29 or Cozy Bear) is particularly telling. APT29 is known for its patience, stealth, and operational adaptability. Their pivot toward cloud-native identity abuse demonstrates that even the most sophisticated actors view credential and session hijacking via legitimate channels as a superior return on investment compared to deploying custom malware binaries.

Deep Dive into Authentication Vector 1: Google OAuth & Application-Specific Passwords

One of the most insidious techniques observed in these campaigns involves the manipulation of Google OAuth and application-specific passwords. Modern cloud environments are designed to be extensible, allowing third-party applications to integrate seamlessly via OAuth 2.0 consent screens. Threat actors are exploiting this architectural openness.

Adversary-in-the-Middle (AitM) and Consent Phishing

Attackers frequently deploy Adversary-in-the-Middle (AitM) phishing frameworks that sit between the target user and the legitimate identity provider. Unlike traditional credential harvesters that merely grab a password, AitM proxies capture session cookies and OAuth tokens in real-time.

Furthermore, UNC6293 and associated actors have been observed registering unverified cloud-hosted OAuth projects. When a target is tricked into authenticating through these malicious applications, they are presented with a consent screen requesting broad scopes of access to their mailbox, contacts, or cloud storage. Because many organizations allow users to grant third-party applications access to their accounts by default, the malicious app is successfully provisioned without alerting IT administrators.

[Target User] ---> (AitM Phishing Proxy) ---> [Google OAuth Provider]
      |                                              |
      +--- [Captures Session Tokens & OAuth Grants] -+

Bypassing MFA with Application-Specific Passwords

Multi-factor authentication (MFA) is often heralded as the silver bullet against credential theft, but application-specific passwords provide a convenient bypass. Many legacy or specialized workflows allow users to generate unique passwords for third-party clients that do not support standard MFA flows. Attackers who compromise a primary account or manipulate security settings can generate and abuse these application-specific passwords, granting them long-term, programmatic access to email and file repositories completely bypassing subsequent MFA prompts.

Deep Dive into Authentication Vector 2: WhatsApp Device Linking & Device Code Flows

While cloud identity providers remain prime real estate, attackers are also targeting the communication tools organizations rely on daily. UNC7005 introduced novel social engineering vectors by weaponizing messaging app linking mechanisms and enterprise device code authentication flows.

WhatsApp Device Linking Hijacking

WhatsApp allows users to link companion devices (such as desktop apps or web browsers) to their primary mobile account by scanning a QR code. UNC7005 operationalized this feature by engineering sophisticated spoofed interfaces that mimic WhatsApp authentication flows.

When a target is lured into scanning a malicious QR code presented by the attacker, they are not logging into a legitimate companion client. Instead, they are authorizing an attacker-controlled device to mirror their WhatsApp account. This grants the threat actor real-time access to encrypted messaging threads, tactical communications, and contact lists—all without triggering any alerts on the victim’s mobile device, as the platform views the linked session as entirely legitimate.

Exploiting Microsoft Entra ID Device Code Flows

In parallel with messaging app exploits, these clusters have leveraged the Microsoft Entra ID Device Code Flow. This feature is designed for devices with limited input capabilities (like Smart TVs or IoT devices), allowing a user to authenticate on a secondary device by visiting a URL (e.g., microsoft.com/devicelogin) and entering a short alphanumeric code.

Threat actors abuse this by tricking users into authenticating via phishing lures that initiate a device code flow. Once the user enters the code provided by the attacker, the attacker’s CLI tool or script receives the access token. This vector completely bypasses conditional access policies that might otherwise restrict traditional browser-based sign-ins.

Infrastructure and Tooling: From HTML Applications to FruitStone C2

The execution chains backing these campaigns combine classic staging techniques with modern, modular command-and-control (C2) frameworks.

Initial staging often begins with malicious HTML Applications (HTA) or booby-trapped documents delivered via targeted phishing emails. When executed, these HTA files invoke native Windows utilities like PowerShell to execute obfuscated scripts designed to survey the local environment and establish persistence.

Rather than relying on off-the-shelf C2 platforms that carry well-known signatures, these clusters utilize custom Go-based tooling. Go is a favorite among modern threat actors due to its cross-platform compilation capabilities, native concurrency, and the relative difficulty of static reverse engineering when symbols are stripped.

At the center of their network infrastructure is FruitStone, a centralized web-based C2 panel used to manage compromised sessions, ingest stolen tokens, and coordinate downstream actions. In certain operational phases, actors have even leveraged network-level artifacts, such as deploying captive Wi-Fi gateways to perform DNS poisoning against targets in physical proximity, intercepting local traffic and forcing redirection to AitM credential harvesting pages.

Defensive Strategies: Hardening and Detection Engineering

Because these attacks utilize legitimate features, traditional signature-based detection is largely ineffective. Securing an organization against OAuth abuse and device linking requires a shift toward identity posture management and behavioral analytics.

1. Restricting and Auditing Third-Party OAuth Apps

Organizations must enforce strict governance over OAuth consent grants.

• Disable the ability for end-users to grant unverified third-party applications access to corporate data.
• Maintain an allowlist of trusted enterprise applications.
• Regularly audit existing OAuth grants in Google Workspace and Microsoft Entra ID for anomalous API permissions (e.g., https://mail.google.com/ or Files.ReadWrite.All).

2. Monitoring Device Code Flow Anomalies

Enterprise logging must track authentication requests initiated via device code flows, especially when they originate from unexpected geographies or atypical user agents.

• Configure alerting for high-risk sign-in logs in Entra ID and Google Cloud.
• Correlate device code flow initiations with user activity to ensure the user actually owns a device requiring that authentication method.

3. Hardening Mobile and Messaging Platforms

• Implement Mobile Device Management (MDM) policies that restrict unauthorized device linking for enterprise messaging tools like WhatsApp Business.
• Educate high-risk personnel (executives, diplomats, researchers) on the risks of scanning unverified QR codes or interacting with unexpected device-linking prompts.

Hunting Query Example

Security engineers can use hunting queries in their SIEM to detect anomalous OAuth token creation or unusual application registrations. For example, hunting for newly created service principals or enterprise applications with high-privilege API permissions in Microsoft 365:

AuditLogs
| where OperationName == "Add service principal"
| mv-expand TargetResources
| extend AppName = tostring(TargetResources.displayName)
| extend ModifiedProperties = TargetResources.modifiedProperties
| project TimeGenerated, InitiatedBy, AppName, ModifiedProperties
| sort by TimeGenerated desc

Future Outlook: The Next Frontier of Ecosystem Abuse

The campaigns orchestrated by UNC6293, UNC7005, and UNC5976 signal a permanent evolution in state-sponsored espionage. As organizations harden their network perimeters and deploy robust endpoint detection, threat actors will continue to abstract their operations further up the stack—moving away from disk-resident malware and deeper into cloud identity layers and communication platforms.

We can anticipate a future where zero-click exploits and the abuse of native platform features (such as collaborative document sharing, webhook integrations, and developer APIs) become the primary vectors for initial access and persistence. Furthermore, the convergence of cloud identity attacks with supply chain vectors—such as compromising Managed Service Providers (MSPs) to inherit trusted authentication trust relationships—presents a compounding risk.

For security architects and incident responders, building a resilient zero-trust posture no longer stops at the device boundary. Identity is the new perimeter, and securing how applications, devices, and users authenticate is the single most critical investment an organization can make.