Nation-state actors are exploiting OAuth flows that your team uses frequently. Russia-linked groups, including those tied to the Foreign Intelligence Service (UNC6293 and UNC7005), have led targets through legitimate Google and Microsoft sign-in pages, only to steal authentication tokens through attacker-controlled redirects. These targets include academia, aerospace, defense, government agencies, and think tanks across Europe and the United States.
This situation raises a pressing question for security teams: should you restrict third-party OAuth integrations entirely, or does that solution create more problems than it solves?
The Case for Locking Down OAuth
Restricting OAuth integrations is about visibility and control. When users authenticate to third-party applications through OAuth, you're placing trust in an external party's cloud project. If adversaries control that project, you've compromised your security.
Google's documented attacks illustrate this risk. UNC7005 used unverified cloud projects in testing mode, presenting victims with a genuine Google sign-in page, then capturing authentication tokens after the redirect. UNC6293 asked targets to share verification codes after legitimate logins to external providers. In both cases, the OAuth flow itself was genuine; the compromise occurred afterward.
Blocking third-party OAuth integrations creates a clear perimeter. You can enforce Role-Based Access Control within your identity provider, require Privileged Access Management for sensitive accounts, and prevent users from authorizing malicious applications. This aligns with the Principle of Least Privilege: if a user doesn't need to grant access to an external app, don't allow it.
You also gain auditability. When all authentication flows terminate within your infrastructure, you can log every access attempt, correlate it with user behavior analytics, and detect anomalies without relying on third-party telemetry. For organizations subject to NIST SP 800-53 control AC-17 or ISO/IEC 27001 Annex A.9.4, this centralized visibility simplifies compliance.
The operational security failures observed in UNC7005's campaigns reinforce this point. The group reused infrastructure across multiple operations, registered domains with the same attacker email, and linked malware command-and-control servers to earlier phishing activity. A mature threat intelligence program could block those indicators, but only if you're monitoring OAuth grants. Without this, you're flying blind.
The Case for Controlled OAuth Access
The counterargument is practical: users will find ways around restrictions, and you'll lose visibility entirely.
OAuth solves a real problem. Users need to integrate productivity tools, share documents with external partners, and access services outside your corporate directory. If you block OAuth, they'll use personal accounts, share credentials insecurely, or set up shadow IT that bypasses your security stack. You won't eliminate risk; you'll just push it out of sight.
The campaigns Google described targeted personal accounts, not corporate ones. UNC6293 and UNC7005 targeted individuals in high-value roles because those accounts are outside organizational monitoring. If your policy forces users to conduct business through personal accounts, you're creating the same visibility gap attackers exploit.
A more defensible approach is to allow OAuth but control it tightly. Maintain an approved application allowlist, require admin review for new integrations, and enforce conditional access policies that block OAuth grants from unmanaged devices or suspicious locations. This gives users flexibility while preserving your ability to detect abuse.
Implement OAuth-specific detection rules. Look for authorization grants to new cloud projects, apps in testing mode, or projects without a published privacy policy. Monitor users who authorize multiple apps rapidly or grant access to apps requesting broad scopes. UNC7005's malicious projects would have triggered these signals if victim organizations had visibility into OAuth activity.
The NIST Cybersecurity Framework (CSF) 2.0 function Detect emphasizes continuous monitoring of identity and access events. Blocking OAuth outright doesn't enhance detection capability; it narrows the attack surface while potentially degrading operational effectiveness.
Where Practitioners Actually Land
Most organizations find a middle ground, segmented by user role and data sensitivity. High-risk populations face stricter OAuth policies or outright blocks. General users get access to a curated app catalog with automatic revocation after inactivity.
The key control is admin-managed OAuth consent, not user-initiated grants. When UNC6293 asked targets to share verification codes after logging in to an external provider, it only worked because users could complete the OAuth flow independently. If admin approval was required, the attack would have failed.
You also need logging that correlates OAuth grants with post-authentication behavior. If a user authorizes an app and then experiences unusual account activity, that's your signal. The attack involving device code phishing against the hospitality industry would have generated this pattern.
Our Take
Block third-party OAuth for privileged accounts and high-risk users. For others, maintain a strict allowlist with admin-controlled consent and real-time monitoring of OAuth grants.
The attacks documented by Google succeeded because they combined legitimate authentication flows with attacker-controlled infrastructure. You can't eliminate that risk by blocking OAuth entirely, as users will route around restrictions using personal accounts you can't monitor. But you can make attacks harder by requiring admin review for new integrations, logging every OAuth grant, and alerting on suspicious patterns.
The tradeoff isn't between security and usability. It's between visible, controlled risk and invisible, uncontrolled risk. OAuth gives you the visibility. The question is whether you're using it.
