Suspected Russian Espionage Clusters UNC6293, UNC7005, UNC5976 Abuse Google OAuth and WhatsApp Device Linking — Detection and Defense Guide

Google's Threat Intelligence Group and partner researchers have exposed three distinct suspected Russian cyber espionage clusters — tracked as UNC6293, UNC7005, and UNC5976 — conducting persistent, adaptive account-hijacking campaigns against high-value individuals: academics, aerospace and defense personnel, government officials, and think tank staff across Europe, plus academia and think tanks inside the United States.

What makes this campaign dangerous is what it doesn't do. There's no zero-day, no credential-phishing page harvesting passwords, no malware dropper in the initial stage. Instead, these actors abuse legitimate authentication flows — Google OAuth consent grants and WhatsApp's device-linking feature — to gain durable, MFA-bypassing access to victim accounts. When an attacker rides a sanctioned authentication path, your perimeter controls, password policies, and even well-deployed MFA can become irrelevant.

If your organization employs people who work on sensitive research, defense programs, policy, or government-adjacent topics, this is a direct threat to your data and your people. Treat it as such.

Technical Analysis

Who Is Being Targeted

This is classic espionage tasking, not opportunistic crime. The victimology across all three clusters centers on:

• Academia (both European and U.S. institutions)
• Aerospace and defense sector personnel
• Government officials (Europe)
• Think tanks and policy organizations (Europe and U.S.)

Target selection of this kind strongly indicates intelligence-collection requirements — the actors want communications, documents, and contact networks, not wire transfers.

Attack Chain: Google OAuth Application Abuse

UNC6293 has been observed crafting phishing lures — often impersonating trusted contacts or institutional figures — that direct victims to authorize a malicious third-party OAuth application against their Google account. The mechanics from a defender's perspective:

1. Lure delivery: Highly personalized messages referencing real relationships or projects (indicating prior reconnaissance or compromised contact lists).
2. Consent redirection: The victim is routed to a legitimate accounts.google.com/o/oauth2 consent screen — the URL is genuinely Google's, which defeats user training focused on "check the domain."
3. Scope grant: The victim approves scopes such as mail.google.com (full Gmail access), https://www.googleapis.com/auth/drive.readonly, or contacts/calendar scopes. Because the grant is user-consented, Google issues valid OAuth tokens to the attacker's application.
4. Persistent access: The actor now holds refresh tokens that survive password changes and, critically, do not require MFA to use. Access persists until the grant is explicitly revoked or the account's tokens are invalidated.

This is MITRE ATT&CK T1528 (Steal Application Access Token) combined with T1566 (Phishing) and T1550.001 (Use Alternate Authentication Material: Web Session Cookie/token replay). The access token becomes the crown jewel — no password needed ever again.

Attack Chain: WhatsApp Device Linking Abuse

A parallel technique — observed across these clusters — abuses WhatsApp's legitimate "Link a Device" feature:

1. The victim is socially engineered (often via a message appearing to come from WhatsApp support, a colleague, or a conference organizer) into scanning a QR code or entering a linking code.
2. The QR code actually belongs to an attacker-controlled WhatsApp Web session.
3. Once scanned, the attacker's browser session is registered as a linked companion device on the victim's account.
4. The actor receives near-real-time access to all messages — past sync and future traffic — without ever touching the victim's phone or SIM. No SIM swap, no spyware implant, no malware detection opportunity.

WhatsApp does display linked devices in the app settings, but high-value espionage targets rarely audit this screen unprompted.

Exploitation Status

• Confirmed active exploitation in the wild, conducted by three named threat clusters with espionage tasking.
• No CVE applies — this is abuse of designed functionality, not a software vulnerability. There is nothing to patch in the traditional sense; the fix is architectural and behavioral.
• Activity is persistent and adaptive — the actors rotate infrastructure, lures, and app registrations when exposed. Assume retooling after any public disclosure.

Detection & Response

The detection surface here is primarily identity telemetry (OAuth grants, sign-in anomalies, audit logs) rather than endpoint malware. Endpoint hunting still has value for establishing whether a compromise has occurred and scoping exposure.

Sigma Rules

These rules target the observable behaviors: OAuth consent events in logged environments, suspicious mail-access patterns from non-standard clients, and process-level artifacts consistent with follow-on collection activity.

---
title: Suspicious Third-Party OAuth Consent Grant to Mail or Drive Scopes
id: 3f8a1c42-7b9d-4e51-a2c8-9d4e6f1a2b3c
status: experimental
description: Detects OAuth authorization grants requesting high-risk Google scopes (full Gmail, Drive, contacts) commonly abused by espionage actors for persistent mailbox access after user-consented phishing.
references:
  - https://attack.mitre.org/techniques/T1528/
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.credential_access
  - attack.t1528
  - attack.persistence
logsource:
  product: google_workspace
  service: token
detection:
  selection_scopes:
    scope|contains:
      - 'mail.google.com'
      - 'gmail.readonly'
      - 'gmail.modify'
      - 'drive.readonly'
      - 'drive'
      - 'contacts'
  filter_known_apps:
    client_id|contains:
      - 'apps.googleusercontent.com'
  condition: selection_scopes and not filter_known_apps
falsepositives:
  - Legitimate third-party integrations (CRM sync, backup tools) - maintain an allowlist of approved OAuth client IDs
level: high
---
title: OAuth Token Usage From Anomalous ASN or Geography
id: 8c2d5e91-4a6b-4f38-b1d7-5e9a3c7d2f4e
status: experimental
description: Detects Google API access (Gmail/Drive) using OAuth tokens from IP ranges or geographies inconsistent with the user's baseline, consistent with actor-held refresh tokens being replayed from foreign infrastructure.
references:
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/08/10
tags:
  - attack.initial_access
  - attack.t1550.001
logsource:
  product: google_workspace
  service: login
detection:
  selection:
    event_name:
      - 'authorize'
      - 'access_token_grant'
  condition: selection
falsepositives:
  - Users traveling internationally - correlate with HR travel records and user confirmation
  - Corporate VPN egress points
level: medium

KQL Hunt — Microsoft Sentinel

If your targets use Microsoft 365 alongside personal Google accounts (very common in academia and think tanks), hunt for analogous OAuth abuse in Entra ID, and hunt Defender data for evidence of QR-code phishing content and anomalous browser sessions.

// Hunt for high-risk OAuth consent grants in Entra ID (parallel technique exposure)
AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName in ("Consent to application", "Add OAuth2PermissionGrant")
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| where tostring(TargetResources_modifiedProperties.displayName) =~ "ConsentType"
| extend ConsentScopes = tostring(TargetResources_modifiedProperties.newValue)
| where ConsentScopes has_any ("Mail.Read", "Mail.ReadWrite", "full_access_as_app", "Files.Read.All", "offline_access")
| project TimeGenerated, InitiatedBy = tostring(parse_json(InitiatedBy).user.userPrincipalName),
    AppName = tostring(TargetResources.displayName), ConsentScopes, CorrelationId
| order by TimeGenerated desc
;
// Hunt for WhatsApp Web session artifacts and QR-phish landing patterns in email
EmailEvents
| where TimeGenerated > ago(30d)
| where EmailDirection == "Inbound"
| where Subject has_any ("whatsapp", "link a device", "verify your account", "paired device")
   or SenderDisplayName has_any ("whatsapp", "whats app", "wa-support")
| where SenderFromDomain !in ("whatsapp.com", "facebook.com", "meta.com")
| project TimeGenerated, RecipientEmailAddress, SenderFromAddress, SenderFromDomain, Subject, UrlCount
| order by TimeGenerated desc
;
// Browser visits to OAuth consent endpoints immediately followed by new app token usage
DeviceNetworkEvents
| where TimeGenerated > ago(14d)
| where RemoteUrl has_any ("accounts.google.com/o/oauth2", "oauth2/auth")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, RemoteUrl, RemoteIP
| order by TimeGenerated desc

Velociraptor VQL — Endpoint Forensics

Use this to scope whether a suspected victim's endpoint shows artifacts of the phishing lure and subsequent session activity (browser history to OAuth consent flows and WhatsApp Web pairing pages).

-- Hunt browser history for OAuth consent screens and WhatsApp pairing lures
SELECT url, title, visit_time, visit_count
FROM Artifact.Windows.Forensics.Timeline()
WHERE url =~ 'accounts.google.com/o/oauth2'
   OR url =~ 'web.whatsapp.com'
   OR url =~ 'whatsapp.com/link'
ORDER BY visit_time DESC

-- Enumerate active processes and network connections for unknown WhatsApp Web / messaging bridges
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ 'whatsapp'
   OR CommandLine =~ 'web.whatsapp'
   OR CommandLine =~ 'oauth'

Remediation / Verification Script

Audit Entra ID for risky OAuth grants (the same technique applied against Microsoft accounts), and enumerate users' connected app posture.

# Audit OAuth consent grants with high-risk scopes across Entra ID
# Requires: Microsoft.Graph PowerShell SDK, signed in with Cloud Application Administrator or higher
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All","AuditLog.Read.All"

# 1. List all OAuth2 permission grants and flag high-risk scopes
$highRisk = @("Mail.Read","Mail.ReadWrite","Mail.Send","Files.Read.All","full_access_as_app","offline_access","Contacts.Read")
Get-MgOauth2PermissionGrant -All | ForEach-Object {
    $sp = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId
    $granted = $_.Scope -split ' '
    $hits = $granted | Where-Object { $highRisk -contains $_ }
    if ($hits) {
        [PSCustomObject]@{
            AppDisplayName = $sp.DisplayName
            AppId          = $sp.AppId
            Publisher      = $sp.PublisherName
            Verified       = ($sp.VerifiedPublisher.VerifiedPublisherId -ne $null)
            ConsentType    = $_.ConsentType
            RiskyScopes    = ($hits -join ',')
        }
    }
} | Format-Table -AutoSize | Out-String -Width 300 | Tee-Object -FilePath ".\oauth-grant-audit-$(Get-Date -Format yyyyMMdd).txt"

# 2. Review recent consent audit events (last 30 days)
$start = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $start and activityDisplayName eq 'Consent to application'" -All |
  Select-Object ActivityDateTime, @{n='Initiator';e={$_.InitiatedBy.User.UserPrincipalName}},
    @{n='TargetApp';e={$_.TargetResources[0].DisplayName}}, Result |
  Format-Table -AutoSize

# 3. To revoke a malicious grant (replace with the grant ID from step 1):
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<GrantId>"
# Then force sign-out / token revocation for affected users:
# Revoke-MgUserSignInSession -UserId "user@domain.com"

# Google Workspace: audit third-party OAuth grants via GAM (Google Apps Manager)
# Run as a super admin. Flags grants of sensitive scopes to unvetted apps.
gam all users show token scopes | grep -Ei 'mail.google.com|gmail|drive|contacts' > oauth-sensitive-grants.txt

# Revoke a specific malicious app's token for a specific user:
# gam user user@domain.com deauthorize clientid <MALICIOUS_CLIENT_ID>

# Force global sign-out (invalidates sessions, NOT OAuth grants — revoke grants first)
# gam user user@domain.com signout

# Export admin console token audit events for the last 30 days for IR review
gam report token start -30d > token-audit-30d.csv

Remediation

There is no patch — the fix is configuration, policy, and people.

Google Workspace / Gmail (priority actions):

1. Restrict third-party app access: In Admin console → Security → API controls → App access control, move from "unrestricted" to "Trust only verified apps" or explicit per-app allowlisting. This single control neutralizes the UNC6293-style consent lure for Workspace-managed accounts.
2. Enable Google Advanced Protection Program for high-risk individuals (executives, researchers, defense program staff). Advanced Protection blocks third-party OAuth access to Gmail/Drive entirely and requires hardware security keys.
3. Mandate hardware-backed phishing-resistant MFA (FIDO2/passkeys) for targeted populations. While it doesn't stop post-consent token use, it raises the bar on account takeover and enables stronger session policies.
4. Revoke grants at scale: Use the GAM commands above to enumerate and deauthorize any suspicious client_id grants for targeted users, then force sign-out.

WhatsApp / messaging hygiene for targeted staff: 5. Instruct high-risk personnel to audit WhatsApp → Settings → Linked Devices weekly and terminate any session they don't recognize. Make this a documented, recurring checklist item — not a one-time email. 6. Establish a verbal/secondary-channel verification policy: any request to scan a QR code, enter a pairing code, or click an account-verification link must be confirmed out-of-band before action. 7. Brief targeted staff explicitly on this campaign: the lure impersonates trusted contacts and leverages real relationship context. Generic phishing training will not catch it.

Identity and monitoring (Microsoft side — these actors abuse the same technique against Entra ID): 8. Disable user consent or move to admin consent workflow in Entra ID (Enterprise Applications → Consent and permissions). Require admin approval for any app requesting mail/files scopes. 9. Alert on Consent to application audit events and on token use from anomalous ASNs/geographies (see KQL above). 10. On confirmed compromise: revoke the OAuth grant, revoke all refresh tokens (Revoke-MgUserSignInSession / Google sign-out), rotate the password, review mailbox rules and forwarding for persistence, and scope sent/received mail during the exposure window for follow-on spear-phishing of the victim's contacts.

Watch for follow-on activity: Compromised mailboxes in these campaigns are used to phish the victim's contact network. If you confirm a compromise, proactively warn the victim's key external contacts — that's how these clusters propagate.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub