Three Russian Spy Crews Hijacked Accounts Without Stealing a Single Password

Google’s Threat Intelligence Group published a report this week on three Russian-linked hacking clusters, tracked as UNC6293, UNC7005, and UNC5976, that have spent the better part of two years breaking into the accounts of diplomats, academics, and defense researchers across Europe and the US. None of them cracked a password. None of them exploited a CVE. They asked their targets to log in normally, and the targets did.

The techniques read like a menu of features every major platform ships on purpose. App-specific passwords that Google built so power users could authorize a mail client. OAuth consent screens that ask “sign in with Google” and mean it. WhatsApp’s device-linking flow, the same QR code you’d scan to open WhatsApp Web on your laptop. One cluster spoofed a Finnish defense-industry portal, sent a phishing link, and walked victims through a completely legitimate Google login before harvesting the resulting token from a cloud project URL. Another impersonated a “secure WhatsApp call” and had victims link their own account to an attacker’s device, no malware required.

I spent years pushing passkeys and FIDO2 as the fix for phishing. I told my team, correctly at the time, that once we killed reusable passwords and SMS codes, most of our account-takeover risk went away. I was right about credential phishing and wrong about how narrow that fix actually was. None of what Google described touches a password field. None of it needs to beat a hardware key. The attacker isn’t defeating your authentication, they’re getting you to authorize a second device or a second app, a feature your MFA was never built to see.

That’s the part every vendor pitch skips. Ask an identity or SSO vendor how they detect a new device linking to an existing account and most will describe classic signals: impossible travel, new IP, unrecognized browser fingerprint. Ask them specifically whether they monitor device-authorization grants and device-linking events as a distinct threat class, separate from login events, and the conversation slows down. It’s not that they’re lying. The product roadmap was built against the last generation of attack, credential stuffing and adversary-in-the-middle proxies, and device-linking abuse is a different shape of problem that happens to route through the exact same “successful login” event their dashboards were designed to celebrate.

The GTIG report is useful precisely because it names the gap without meaning to. UNC5976 registered a dozen file-sharing lookalike domains since March, all disrupted by Google, and simply moved its infrastructure elsewhere. UNC7005 ran wine-and-diplomacy lures going back to 2023 under different names, kept working, and only got caught because a single research team happened to be watching closely. These aren’t zero-days. They’re identical social engineering plays running for years against the same universities, defense contractors, and NGOs, because the defensive tooling those organizations bought was never asked to look for this.

For a startup pitching identity security to a VC, the diligence question is not “do you stop phishing.” Every vendor in the category will say yes, and most of them mean AiTM-resistant, passkey-compatible, FIDO2-everywhere yes. The question that actually separates a real product from a marketing deck is whether they can show a live alert on an OAuth consent grant to an unfamiliar third-party client, or a device-linking request from an ASN the account has never touched, within minutes of it happening. If the answer is a roadmap slide, the product is defending last year’s attack.

There’s a reason this keeps recurring specifically in identity, and not, say, endpoint. Endpoint vendors got forced years ago to treat “legitimate binary, malicious behavior” as their entire job, that’s what EDR is. Identity and access tooling largely still treats a successful login, correctly completed MFA challenge and all, as the finish line. Google’s own researchers said the quiet part out loud: these clusters’ “creative abuse of legitimate features” makes tracking legitimate and malicious access “more challenging,” which is a polite way of saying most of the industry isn’t tracking it at all.

None of this means passkeys were a bad bet. Credential phishing and SIM-swap-driven MFA bypass are both meaningfully harder than they were three years ago, and that’s real progress worth having shipped. But a security leader who reports “MFA adoption at 98%” to their board as a phishing metric is reporting a number this specific attack path doesn’t touch. The metric that matters now is closer to this: what percentage of your account-linking and consent-grant events get reviewed by anything other than the end user in the moment, half-asleep, tapping “allow” on their phone at 11pm because a calendar invite told them to.

I’d bet that within the next year, at least one company outside of government and defense, probably in finance or healthcare given how attractive those targets are, discloses a breach that traces back to device-linking or OAuth-grant abuse rather than a stolen credential, and its initial incident report calls it “phishing” before anyone corrects the record to “authorization abuse.” The distinction matters because it changes what you’d have needed to buy to stop it. Ask your own vendor which one they actually detect. Most haven’t been asked the question yet.

Amit Spitzer is CTO and CISO at Glilot Capital, an early-stage VC investing in cybersecurity, AI, and enterprise infrastructure.