Google's Threat Intelligence Group (GTIG) has disclosed tracking of three separate suspected Russia-linked cyber espionage clusters that share a common playbook: abusing legitimate authentication mechanisms — specifically OAuth device authorization flows and WhatsApp's linked-devices feature — to compromise accounts belonging to researchers, diplomats, and defense personnel.
This is not a vulnerability story. There is no CVE to patch, no vulnerable binary to update. The adversary is weaponizing authentication features working exactly as designed. That is precisely what makes this campaign class dangerous: your MFA prompts, your OAuth consent screens, and your messaging apps are the attack surface. Defenders who rely solely on vulnerability management will miss this entirely.
The targeting profile — academics, think tanks, foreign ministry staff, defense sector employees — is consistent with long-running Russian intelligence collection priorities (historically associated with clusters like COLDRIVER/Star Blizzard and related FSB/GRU-nexus operations). The tradecraft centers on:
- Fake conference and event invitations delivered via highly personalized spear-phishing emails, establishing rapport before delivering the payload.
- OAuth device code phishing — tricking victims into entering attacker-supplied codes on Microsoft's legitimate device login page (
microsoft.com/devicelogin), granting the attacker OAuth tokens without ever touching the victim's password or MFA. - WhatsApp device-linking abuse — luring victims into scanning attacker-controlled QR codes or entering linking codes, silently pairing the attacker's client to the victim's WhatsApp account and exposing all message traffic.
Every organization with personnel of intelligence interest — government, defense industrial base, NGOs, academia, journalism — should treat this as an active threat requiring immediate detection engineering and policy hardening.
Technical Analysis
Attack Chain 1: OAuth Device Code Grant Phishing
The OAuth 2.0 Device Authorization Grant (RFC 8628) exists so input-constrained devices (smart TVs, IoT, CLI tools) can authenticate. The attacker initiates a device code request against a legitimate identity provider (typically Microsoft Entra ID), receives a short user code, and delivers it to the victim via email, Signal, or WhatsApp — framed as a "secure document portal," "conference registration," or "mail migration" step. The victim navigates to the genuine microsoft.com/devicelogin page — on the real Microsoft domain, passing every URL filter — enters the code, and approves the sign-in. The attacker's polling client then receives valid access and refresh tokens, often with Mail.Read/offline_access scopes, bypassing password and MFA entirely.
Key characteristics defenders must understand:
- No credential theft occurs. Password spray, MFA fatigue, and phishing-resistant auth detections will not fire.
- Tokens are minted for first-party or attacker-registered application client IDs. The device code flow client is frequently the Azure CLI (
04b07795-8ddb-461a-bbee-02f9e1bf7b46) or similar first-party clients that often bypass Conditional Access policies scoped narrowly to browser flows. - Sign-ins originate from attacker infrastructure — frequently VPS providers, Tor exit nodes, or residential proxies — with device code flow marked as the authentication protocol.
- Refresh tokens persist after password resets unless explicitly revoked.
Attack Chain 2: WhatsApp Linked-Device Abuse
The adversary impersonates a trusted contact or organizational security team and directs the victim to scan a QR code or enter an 8-character linking code — presented as joining a secure group, verifying identity, or accessing a document. In reality, the victim completes the WhatsApp linked-device pairing flow, enrolling an attacker-controlled WhatsApp Web session or a WhatsApp-linked phishing kit (e.g., browser-in-the-middle proxies relaying the genuine QR code). Once paired, the attacker reads messages, harvests contacts for downstream social engineering, and monitors conversations in real time.
Attack Chain 3: Fake Conference Lures
These campaigns invest heavily in pretext: spoofed or typosquatted domains mimicking real conferences, PDF invitations referencing the victim's actual research, and multi-message rapport building before any malicious action. The lure's job is to get the victim to perform one of the two authentication abuses above. Expect sender infrastructure using lookalike domains, compromised legitimate accounts, and free webmail.
Exploitation Status
- Active, in-the-wild exploitation confirmed by Google GTIG across three distinct clusters.
- No CVE is associated; this is abuse of intended functionality (MITRE ATT&CK T1566 Phishing, T1528 Steal Application Access Token, T1550.001 Use Alternate Authentication Material: Web Session Cookie / token replay).
Detection & Response
The highest-fidelity detection points are in your identity provider logs — Entra ID sign-in and audit logs — not on the endpoint. Device code flow sign-ins are rare in most environments; baselining them yields an extremely high-signal hunt.
---
title: OAuth Device Code Flow Sign-In from Non-Standard Application
description: Detects Microsoft Entra ID sign-ins using the OAuth 2.0 device authorization grant (RFC 8628), a technique abused by Russia-nexus espionage clusters to phish tokens without credentials or MFA. Device code flow is rare in most enterprises outside legitimate CLI/IoT use.
references:
- https://securityaffairs.com/197630/apt/fake-conferences-oauth-and-whatsapp-inside-russias-new-espionage-tactics.html
- https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.credential_access
- attack.t1528
logsource:
product: azure
service: signinlogs
detection:
selection:
authentication_protocol|contains:
- 'deviceCode'
- 'Device Code'
filter_known_apps:
app_id:
- '04b07795-8ddb-461a-bbee-02f9e1bf7b46' # Azure CLI - tune per your baseline
condition: selection and not filter_known_apps
falsepositives:
- Legitimate Azure CLI, Azure PowerShell, or VS Code sign-ins on unmanaged devices
- IoT/smart display enrollment
level: high
---
title: Suspicious OAuth Consent Grant for Mail or Offline Access Scopes
description: Detects user or admin consent grants for high-risk OAuth scopes (Mail.Read, offline_access, full_access_as_app) to newly registered or rare service principals, consistent with consent-phishing tradecraft used in espionage campaigns targeting mailboxes.
references:
- https://securityaffairs.com/197630/apt/fake-conferences-oauth-and-whatsapp-inside-russias-new-espionage-tactics.html
- https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.persistence
- attack.t1550.001
logsource:
product: azure
service: auditlogs
detection:
selection_operation:
operation_name:
- 'Consent to application'
- 'Add service principal'
- 'Add delegated permission grant'
selection_scopes:
target_resources|contains:
- 'Mail.Read'
- 'Mail.ReadWrite'
- 'offline_access'
- 'full_access_as'
- 'EWS.AccessAsUser.All'
condition: all of selection_*
falsepositives:
- Legitimate third-party mail client or CRM onboarding (maintain an allowlist of approved enterprise apps)
level: high
---
title: Spear-Phishing Lure Referencing Device Login or Secure Document Verification
description: Detects inbound email content characteristic of device-code phishing lures, including references to microsoft.com/devicelogin, device codes, QR-based verification, and WhatsApp pairing instructions. Apply via email security gateway or M365 content search.
references:
- https://securityaffairs.com/197630/apt/fake-conferences-oauth-and-whatsapp-inside-russias-new-espionage-tactics.html
- https://attack.mitre.org/techniques/T1566/002/
author: Security Arsenal
date: 2026/02/14
tags:
- attack.initial_access
- attack.t1566.002
logsource:
category: email
detection:
selection_body:
MessageBody|contains:
- 'microsoft.com/devicelogin'
- 'enter the code'
- 'device code'
- 'link a device'
- 'scan the QR code'
- 'secure document portal'
filter_internal:
SenderDomain|contains:
- 'microsoft.com'
condition: selection_body and not filter_internal
falsepositives:
- IT helpdesk communications; legitimate service enrollment emails
level: medium
// Hunt: Device code flow sign-ins with token issuance anomalies
// Tables: AADSignInEventsBeta / SigninLogs (Sentinel), AuditLog (consent), EmailEvents (lures)
// Sentinel: SigninLogs | Defender XDR: AADSignInEventsBeta
// 1) Device code flow sign-ins, enriched with rare-app and risky-IP context
let KnownDeviceCodeApps = dynamic(["04b07795-8ddb-461a-bbee-02f9e1bf7b46"]); // Azure CLI baseline — tune to your environment
AADSignInEventsBeta
| where Timestamp > ago(30d)
| where AuthenticationRequirement == "singleFactorAuthentication" or IsInteractive == false
| extend Raw = todynamic(RawEventData)
| where tostring(Raw.authenticationProtocol) has "deviceCode"
or tostring(Raw.originalTransferMethod) has "deviceCode"
| extend AppId = tostring(Raw.appId),
AppDisplayName = tostring(Raw.appDisplayName),
DeviceCodeClient = tostring(Raw.clientAppUsed)
| where AppId !in~ (KnownDeviceCodeApps)
| project Timestamp, AccountUpn, IPAddress, AppId, AppDisplayName, DeviceCodeClient, Country, SessionId, RequestId
| sort by Timestamp desc;
// 2) Consent grants to applications requesting mail scopes in the last 30 days
AuditLog
| where TimeGenerated > ago(30d)
| where OperationName in ("Consent to application", "Add delegated permission grant", "Add app role assignment to service principal")
| mv-expand TargetResources
| extend ModifiedProps = tostring(TargetResources.modifiedProperties)
| where ModifiedProps has_any ("Mail.Read", "Mail.ReadWrite", "offline_access", "EWS.AccessAsUser.All", "full_access_as")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result
| sort by TimeGenerated desc;
// 3) Email lures referencing device login or QR pairing sent to targeted staff
EmailEvents
| where Timestamp > ago(14d)
| join kind=inner (EmailUrlInfo | where Url has_any ("devicelogin", "devicecode")) on NetworkMessageId
| project Timestamp, NetworkMessageId, SenderFromAddress, Subject, RecipientEmailAddress, Url, DeliveryAction
| sort by Timestamp desc;
// 4) Post-compromise: mailbox activity from IPs that never authenticated interactively
// (token replay often shows MailItemsAccessed from infrastructure disjoint from user's normal sign-in geography)
CloudAppEvents
| where Timestamp > ago(14d)
| where ActionType == "MailItemsAccessed"
| extend ClientIP = tostring(RawEventData.ClientIP)
| summarize AccessCount = count(), DistinctIPs = dcount(ClientIP) by AccountObjectId, ClientIP, bin(Timestamp, 1h)
| where DistinctIPs >= 1 and AccessCount > 50
| sort by AccessCount desc;
-- Hunt endpoints for browser access to the device login page and
-- WhatsApp Web/Desktop artifacts consistent with linked-device abuse.
-- Deploy as a Velociraptor hunt across user endpoints.
-- Artifact 1: Chrome/Edge history hits on device login or WhatsApp pairing pages
SELECT Key.LastVisitTime AS VisitTime,
Key.Name AS HistoryPath,
Data.value.url AS URL,
Data.value.title AS PageTitle
FROM foreach(row={
SELECT FullPath FROM glob(globs='C:/Users/*/AppData/Local/*/User Data/*/History')
}, query={
SELECT * FROM sqlite(file=FullPath, query="SELECT url, title FROM urls WHERE url LIKE '%devicelogin%' OR url LIKE '%web.whatsapp.com%' OR url LIKE '%devicecode%'")
})
ORDER BY VisitTime DESC
-- Artifact 2: WhatsApp Desktop local state (presence of linked multi-device session data)
SELECT FullPath, Mtime, Size
FROM glob(globs=[
'C:/Users/*/AppData/Local/Packages/5319275A.WhatsAppDesktop_*/LocalState/**',
'C:/Users/*/AppData/Roaming/WhatsApp/**'
])
WHERE FullPath =~ 'log|session|db'
ORDER BY Mtime DESC
-- Artifact 3: Processes running WhatsApp Web bridge or suspicious electron-based clients
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'whatsapp|electron|node'
OR CommandLine =~ 'web.whatsapp|wa.me|devicelogin'
# Entra ID / M365 hunting + hardening script
# Run in the SOC: detects device-code sign-ins, risky consent grants,
# and revokes refresh tokens for confirmed compromised users.
# Requires: Microsoft.Graph PowerShell SDK, ExchangeOnlineManagement
# Connect-MgGraph -Scopes "AuditLog.Read.All","Policy.Read.All","User.ReadWrite.All","Directory.ReadWrite.All"
# 1) Hunt: device code flow sign-ins in the last 30 days
$start = (Get-Date).AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
$signIns = Get-MgAuditLogSignIn -All -Filter "createdDateTime ge $start"
$deviceCodeHits = $signIns | Where-Object {
$_.AuthenticationProtocol -match 'deviceCode' -or
$_.ClientAppUsed -match 'device'
}
$deviceCodeHits | Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName,
AppId, IPAddress, @{n='Country';e={$_.Location.CountryOrRegion}}, Status |
Sort-Object CreatedDateTime -Descending | Format-Table -AutoSize
# 2) Hunt: recent consent grants requesting mail or offline scopes
$grants = Get-MgAuditLogDirectoryAudit -All -Filter "activityDisplayName eq 'Consent to application'"
$grants | Where-Object {
($_.TargetResources.ModifiedProperties | Out-String) -match 'Mail.Read|offline_access|full_access_as|EWS.AccessAsUser'
} | Select-Object ActivityDateTime, ActivityDisplayName, Result,
@{n='InitiatedBy';e={$_.InitiatedBy.User.UserPrincipalName}} | Format-List
# 3) CONTAINMENT: For a confirmed compromised user — revoke ALL refresh tokens
# (password reset alone does NOT kill stolen OAuth refresh tokens)
$upn = "compromised.user@yourdomain.com"
Revoke-MgUserSignInSession -UserId $upn
# 4) CONTAINMENT: Remove malicious OAuth consent grants
# Enumerate grants for the user, then remove the offending one
Get-MgUserOauth2PermissionGrant -UserId $upn | Format-Table Id, ClientId, Scope
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <GrantId>
# 5) HARDENING: Verify Conditional Access blocks device code flow (recommended policy)
$ca = Get-MgIdentityConditionalAccessPolicy
$ca | Where-Object {
$_.Conditions.AuthenticationFlows.TransferMethods -match 'deviceCodeFlow'
} | Select-Object DisplayName, State | Format-Table -AutoSize
# If nothing returns, you do NOT have a device-code CA policy — create one:
# Entra Portal > Conditional Access > New Policy > Target: All users >
# Condition: Authentication flows = Device code flow > Grant: Block
# 6) HARDENING: Verify user consent is restricted (no self-service consent to unverified apps)
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions |
Format-List *
# Recommended: PermissionGrantPoliciesAssigned should be EMPTY or limited to
# 'ManagePermissionGrantsForOwnedResource' with Admin Consent Workflow enabled.
Remediation and Hardening Recommendations
Because there is no patch, remediation is a combination of identity policy, detection coverage, and targeted user hardening:
- Block or tightly scope the device code flow in Entra ID. Create a Conditional Access policy targeting the "Device code flow" authentication flow with a Block control. If legitimate use exists (Azure CLI on unmanaged devices), scope it to a break-glass group or require compliant devices. This single control kills the OAuth leg of this campaign class.
- Restrict user consent. Set Entra user consent to "Do not allow user consent" or permit consent only for verified publishers on low-risk scopes. Enable the Admin Consent Workflow so requests route through review.
- Deploy phishing-resistant MFA (FIDO2/passkeys) for high-value targets. While device code phishing can still mint tokens post-authentication, phishing-resistant auth eliminates the majority of session-hijack paths and raises the cost of the lure step. Apply Conditional Access token protection and sign-in frequency policies to limit refresh token lifetime.
- Revoke tokens on suspicion. For any suspected compromise, use
Revoke-MgUserSignInSession(or the portal's "Revoke sessions") in addition to password reset — refresh tokens survive credential resets otherwise. - Continuous Access Evaluation (CAE): ensure CAE is enabled so revoked tokens die near-instantly rather than living out their 60–90 minute lifetime.
- WhatsApp hygiene for targeted populations: Brief at-risk staff (diplomats, researchers, executives) that no legitimate party will ever ask them to scan a QR code or enter a linking code. Enable two-step verification (PIN) in WhatsApp, and periodically audit Settings > Linked Devices for unknown sessions. Treat unsolicited "security verification" or "group invite" QR requests as hostile by default.
- Email controls: Detonate and banner-flag external emails containing
devicelogin, QR-code images, or urgent pairing/verification language. Lookalike-domain detection (DNSTwist-style permutation monitoring) should cover your conference and event brands. - Monitor KQL detections above as scheduled analytics rules, and baseline your tenant's normal device-code usage before enabling blocking — otherwise you will blindside legitimate CLI workflows and the policy gets rolled back.
- Threat-informed user briefings: The most effective control against rapport-building lures is a workforce that recognizes the pretext pattern — conference invitations from slightly-wrong domains, requests to "verify" via code entry, pressure to move conversations to WhatsApp/Signal.
Conclusion
The three clusters Google is tracking demonstrate a mature evolution in Russian espionage tradecraft: when defenders harden the front door, adversaries walk through the side door the vendor built for convenience. Device code phishing and WhatsApp device linking defeat password policies, MFA fatigue protections, and URL filtering in one move. The defensive answer is identity-centric: block the abused flows, restrict consent, hunt your sign-in telemetry, and train the small population these actors actually target. Do those four things this week and this campaign class loses most of its bite.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.