No password, no MFA bypass: this OAuth attack takes one click, and Russian state hackers are already running it in the wild.
A few months ago I built a malicious OAuth app and showed it being used to break into a Google Workspace account. The victim clicks through a standard OAuth consent flow and ends up giving the attacker access to their entire mailbox and Drive. The attack didn't rely on credential theft or MFA bypass. The token created also outlives a password reset and session revocations, so even a textbook incident response can leave the attacker with a live session.
I built the demo to make a specific point: OAuth consent is a powerful path into files and email, allowing the attacker to fully interact with an account, and the controls most teams rely on to prevent account takeovers (MFA, endpoint tooling, password resets) don't address it. This makes OAuth token hijacking and malicious OAuth apps very attractive to attackers.
A campaign in the wild
Last month, Google's Threat Intelligence Group published research on suspected Russian espionage clusters doing exactly that — fake file-sharing pages, a legitimate "Sign in with Google" flow, tokens harvested on the other side. Suspected Russian actors, tracked by Google as UNC5976, used this technique against the military, aerospace, and defense industrial base, along with NGOs and think tanks, with geographic focus on Ukraine and Armenia. GTIG began tracking the cluster's OAuth activity in March 2026 and assesses it with high confidence to have a Russian nexus.
How the attack works
UNC5976 automated token theft by abusing cloud infrastructure. The chain is short and, notably, never asks the victim for a password:
- Register a themed domain and stand up a cloud project. The domains were usually file-sharing themed (for example, verify-drive[.]com) with a Google Cloud project tied to each one.
- Serve a fake file-sharing page. After the target lingers on the page for a few seconds, it pops a login dialog.
- Send the victim through a real Google login. Clicking "Continue with Google" redirects the target to a genuine Google OAuth page and asks them to sign in. This is the part that defeats user intuition: the login screen is authentic.
- Redirect to attacker-controlled infrastructure. After authenticating, the victim lands on a Google Cloud project URL. Scripts hosted in that project pull the authentication token out of the redirect URL and store it for the operator to collect later.
- Retrieve the token and access the account. Post-compromise, UNC5976 used dedicated hosting rather than residential proxies.
UNC5976 iterated fast: within roughly three months of GTIG's initial discovery and disruption, the cluster stood up at least twelve new domains, and it has since begun migrating off Google infrastructure onto other providers.
This wasn't a one-cluster idea, either. GTIG documented a separate cluster, UNC7005, running its own cloud-project OAuth operation in August 2026, spoofing the Finnish Operations Center to target the European defense industry with the same "Sign in with Google" redirect into an attacker-controlled, unverified cloud project. Two distinct Russian clusters landed on the same design independently. That convergence is the point I keep coming back to below.
Why the resemblance matters
I didn't invent anything in the demo, and that's the point. Two nation-state teams and I arrived at the same design independently because OAuth is so compelling as an attack vector. When an attack is that convergent, it’s time to reexamine our controls.
What to do about it
If your security controls treat traditional account takeover methods as the only way into an account, this attack is hidden from you.
The controls that address this govern consent and monitor the account after login:
- OAuth app allowlisting. Treat third-party app grants as privileged access. Default-deny and approve deliberately.
- Account detection and response. A successful authentication is the start of the investigation, not the end. Watch what the token does next.
- Consent governance. You should be able to answer "which apps can read our mail, and who approved them?" on demand.
This is a lot of what we work on over at Material, across both Google Workspace and M365. The takeaway holds regardless of tooling: authentication context matters as much as authentication success.
You can read more about the disclosure in Google's writeup, and see my original demo of the attack flow here.
Appendix
Indicators of compromise
GTIG published a full IOC set and a GTI Collection. The UNC5976 indicators most relevant to the OAuth activity:
- Indicator:
drive.google.verify-drive.com- Type: Domain - Notes: phishing domain (OAuth flow) - Indicator:
mail.kiis.co.uk- Type: Domain - Notes: malware distribution - Indicator:
2c7f4165967d6f7737b3fef87959846920b57a5368b531ad1427c7214d4c41a2- Type: SHA256 - Notes: HEADRUSH — malicious Excel plugin leading to an HTA downloader
For the parallel UNC7005 cloud-project OAuth operation, GTIG lists the Finnish Operations Center phishing domains — finishoperations[.]com, finishoperations[.]org, foc-share[.]com, share-foc[.]com, foc-share[.]org, internal-share[.]com — and the landing-page hash a06a8fd1b6fa1924199a4540cf16d089217ce8f78c617739946f145fd1fc88c1. The full list, including the UNC6293 and UNC7005 malware families, is in GTIG's writeup.
IOCs age out quickly here — UNC5976 was cycling infrastructure on a roughly weekly basis. Treat the domains and hashes as a starting point for retro-hunting, not as a durable detection.
