Google's Threat Intelligence Group is tracking three Russian cyber-espionage groups that have added OAuth token theft to their phishing strategies. These campaigns, active as of this month, target fewer than 100 individuals per operation, with under 10 victims each. The significance of these attacks lies not in their scale but in their method. By exploiting legitimate authentication flows, these groups bypass traditional phishing indicators and gain persistent access to personal accounts across multiple platforms.
If your team is implementing ISO/IEC 27001 Clause 6.1.2 risk assessment or designing SOC 2 Trust Services Criteria controls for authentication, this shift demands immediate attention.
What Changed
OAuth abuse has shifted from a theoretical risk to an operational threat. UNC6293, tracked by Google for nearly two years and linked to APT29, began requesting verification codes from targets in June 2026 after they completed legitimate logins to external providers. By providing the code, victims unknowingly granted attackers access to their accounts.
UNC7005, a separate group with lower operational security, used device-code phishing for Microsoft and WhatsApp accounts. Their May and June campaigns spoofed WhatsApp prompts to join voice calls, triggering malicious JavaScript that recorded audio and video, then uploaded it to command-and-control servers.
UNC5976 took a different approach: purchasing domains related to file sharing, creating cloud projects, and hosting fake sharing pages that prompted "Continue with Google" authentication. After victims signed in through a legitimate Google OAuth page, they were redirected to a Google Cloud project URL that captured their authentication token.
Key Findings
OAuth flows now look identical to legitimate authentication. When UNC5976 redirects victims to an actual Google OAuth login page, there's no spoofed domain or fake certificate to flag. The authentication is real; the authorization grant is what's being stolen. Your users can't spot the difference because there isn't one at the protocol level.
Calendar invites and conference registrations are the new phishing vector. UNC7005 spoofed the GLOBSEC forum and created registration processes complete with wine selections, a theme seen in previous APT29-linked campaigns. The registration was thorough enough that targets believed they were confirming attendance at a real diplomatic event.
Post-compromise audio and video collection enables deeper social engineering. The JavaScript deployed through WhatsApp voice call prompts didn't just steal credentials. It captured recordings that attackers can use to impersonate targets in future operations or to gather intelligence on their networks and contacts.
Residential proxies aren't universal. UNC5976 uses dedicated infrastructure for post-compromise activity instead of residential proxies, which changes detection patterns. If your threat detection rules assume all sophisticated actors use residential IPs, you're missing a subset of these campaigns.
What This Means for Your Team
Your user awareness training is addressing the wrong threat model. If you're still teaching people to "hover over links" and "check the sender domain," you're not preparing them for OAuth abuse. When the authentication page is legitimately Google's or Microsoft's, those heuristics fail.
ISO/IEC 27001 Clause 5.1 leadership responsibility and Clause 7.2 competence requirements now extend to understanding OAuth grant types. Your security team needs to know the difference between authorization code flow, device code flow, and implicit flow, and which ones your organization permits.
SOC 2 CC6.1 (logical and physical access controls) must account for token-based authentication as a distinct category. If your control description says "users authenticate with username and password," but your environment uses OAuth, you've got a gap between your documented controls and your actual implementation.
Your incident response plan probably doesn't cover OAuth token compromise. When an attacker holds a valid token, they're not triggering failed login alerts or impossible travel flags. They're accessing resources as if they were the legitimate user. Your CC7.3 detection controls need to look for unusual OAuth scopes granted, new applications authorized, or token usage patterns that don't match user behavior.
Action Items by Priority
Immediate: Audit OAuth application permissions across your organization. Use Google Workspace's security investigation tool or Microsoft Entra ID's enterprise applications blade to identify which third-party apps have been granted access to user accounts. Look for applications authorized within the past 90 days that request broad scopes like "read and write all mail" or "access all files." Document this as evidence for SOC 2 CC6.2 (prior to issuing system credentials).
This week: Update your security awareness content to include OAuth-specific scenarios. Show users what a device code phishing attempt looks like. Explain that seeing "accounts.google.com" in the address bar doesn't guarantee the request is legitimate. Train them to ask: "Did I initiate this authentication request, or did I click a link first?" This supports ISO/IEC 27001 Clause 7.3 awareness requirements.
This month: Implement conditional access policies that restrict OAuth grants. Configure policies that require admin approval for applications requesting sensitive scopes. Block device code flow entirely if your organization doesn't use it. These are technological controls under ISO/IEC 27001 Clause 8.1 operational planning and control.
This quarter: Build detection rules for anomalous OAuth activity. Alert on tokens used from IP addresses or geolocations inconsistent with the user's normal pattern. Flag new OAuth applications authorized outside business hours. Monitor for tokens accessing resources the user hasn't touched in months. This maps to SOC 2 CC7.2 (system monitoring).
Before your next audit: Document your OAuth governance process. Auditors will ask how you manage third-party application access. You need a policy that defines who can authorize applications, what scopes require approval, and how often you review granted permissions. This is evidence for both SOC 2 CC6.1 and ISO/IEC 27001 Clause 9.2 internal audit.
