Three Russian Espionage Clusters Are Turning Your Own Login Screen Into Their Best Weapon, and Google Just Open-Sourced the AI System That Finds 100 Critical Bugs in Two Days

Start with the story that should change how you think about phishing training, because it's not about fooling anyone into typing a password on a fake page anymore. Google's Threat Intelligence Group disclosed that it's now tracking three distinct suspected Russia-linked cyber-espionage clusters — UNC6293, UNC7005, and UNC5976 — running campaigns against academics, diplomats, defense personnel, government staff, and think-tank researchers across Europe and the United States. What ties the three together isn't shared malware or shared infrastructure. It's a shared philosophy: none of them are trying to steal a password. All three are getting targets to willingly complete completely legitimate authentication flows — the same OAuth consent screens, app-password generation steps, and device-linking prompts that Google, Microsoft, and WhatsApp built to make account security easier — and handing the resulting access straight to the attacker.

UNC6293, assessed with moderate confidence to be a sub-cluster of Ice Relic — the group more widely known as APT29, Cozy Bear, or Midnight Blizzard — has repeatedly impersonated U.S. State Department officials to approach prominent critics of the Russian government, building on tactics first documented publicly in June 2025 involving abused Google application-specific passwords. Its targeting isn't abstract: in June, the group went after Keir Giles, a prominent British expert on Russian information operations, using a phishing page hosted at a domain impersonating a foreign-relations think tank to request a "verification code" — the kind of request that looks routine enough that a careful, security-conscious target can still be talked into completing it. That's the pattern across all three clusters, and it's worth sitting with: these aren't campaigns succeeding against careless targets. They're succeeding against people whose job is to be skeptical, because the request itself is genuinely indistinguishable from a legitimate one at the moment it's made.

UNC7005, also tracked as STORM-2945 and first identified in February 2026, spoofs real organizations people in the defense and security space would recognize and trust — the GLOBSEC forum, the Finnish Operations Center that supports Finnish defense firms within NATO — to lure targets into device-code and app-password phishing. Its WhatsApp operation is the one worth remembering by name: victims are told they need to link their account to join a secure call or document-sharing session, and the moment they approve it, the attacker has an authorized companion device attached to a real account. Google's researchers found the technique goes further than simple access — pages tied to this campaign attempt to record audio and video through a fake voice-call interface immediately after the WhatsApp link completes, uploading the recording to an attacker server timed to look like the call simply failed to connect, so the victim never suspects anything happened. The same cluster distributed the VIDAR infostealer to Windows targets and AtomicStealer to macOS targets through a fake Ukraine-support summit site in a broader May campaign, and researchers traced roughly 30 unique IP addresses communicating with the cluster's adversary-in-the-middle infrastructure to harvest tokens, with at least one IP also observed talking to a ChocoShell command-and-control server — concrete evidence this isn't a one-off operation but sustained infrastructure built for repeat use.

UNC5976 works differently and, in some ways, more patiently. Active since at least March 2026 and focused heavily on Ukraine and Armenia, it buys domains styled to look like file-sharing services, stands up a matching cloud project behind each one, and waits for a target to click "Continue with Google" on a fake file-sharing popup — which correctly redirects to a real, legitimate Google OAuth login page hosted at Google's actual domain. A victim who signs in there is doing exactly what the login page asks; the token that results just doesn't go where they think it does. This cluster also deployed a malicious Excel plugin called HEADRUSH against a Ukrainian aerospace and imaging company specifically, using automation to collect and exfiltrate tokens from the cloud infrastructure it stood up rather than manually harvesting each session. After Google disrupted its infrastructure — adding attacker domains to Safe Browsing and disabling the malicious cloud projects — UNC5976 didn't fold. It registered at least a dozen new domains within roughly three months and now appears to be actively migrating away from Google-hosted infrastructure entirely, a direct, measurable response to being caught, and a reminder that disrupting one wave of infrastructure buys time, not an ending.

Microsoft confirmed a related piece independently: a portion of this broader activity uses doppelganger domains mimicking Microsoft's own online services to run adversary-in-the-middle phishing that specifically abuses the device-code authentication flow in Entra ID — the same identity platform that had its own maximum-severity flaw disclosed and then walked back on exploitation status just days ago. The throughline across every technique here — OAuth, app passwords, device codes, WhatsApp linking — is that none of it is a software bug. Multi-factor authentication doesn't stop a victim from correctly authenticating on a genuine page and then approving access for a device or application they were tricked into trusting. If your organization includes people in academia, government, defense, or think-tank work — the exact population these clusters are targeting — the practical takeaway isn't "train harder against phishing links." It's specifically about auditing what third-party apps, linked devices, and app passwords are attached to high-value accounts on a recurring basis, since that's the access path that survives good password hygiene and MFA alike, and it's an access path most organizations have never built a review process for at all.

The second story of the day is a genuinely useful counterweight, and it comes from the same company. Google's Mandiant unit published the full architecture behind its Agentic Vulnerability Discovery Harness, an internal multi-agent AI system it's been running for ten months across incident response, penetration testing, red-team work, and proactive code review, analyzing tens of millions of lines of code and generating tens of thousands of individual findings along the way. The headline result: during a real incident response investigation into stolen corporate source-code repositories, the harness found more than 100 true-positive critical vulnerabilities in two days — a pace no manual review process comes close to matching, and precisely the scenario where speed matters most, since an attacker who already has the stolen code has exactly the same head start the harness is racing against.

AVDH doesn't work as a single model scanning for known patterns. It runs a genuine pipeline: a Threat Modeling stage that establishes what's actually worth protecting in a given codebase, parallel Discovery agents that scan for entry points like HTTP routes and IPC listeners and trace which of those accept user-controlled input, an Enrichment agent that follows code across files and nested calls to catch exploitable conditions that only emerge across distributed paths — precisely the kind of bug that both manual review and conventional static-analysis scanners consistently miss, since the vulnerable condition never sits in one place — then dedicated Access Control agents handling control-flow analysis and Data Flow Analysis agents handling data-flow tracking, followed by hypothesis validation where multiple agents, deliberately run at a higher reasoning "temperature" to widen the range of thinking they produce, independently weigh in on each candidate finding before a synthesis agent sorts each one into confirmed, disproven, or rejected.

The detail that matters most for anyone evaluating whether to trust output like this: every single confirmed finding still goes to a human before it counts for anything. Mandiant consultants manually reproduce the exploit and run proof-of-concept code to verify the flaw is real and isn't already blocked by a control the agents missed. Findings that fail that check get thrown out entirely, not flagged as "lower confidence" and left for someone else to sort through later. Mandiant's own researchers were explicit about why that step isn't optional: "We encourage network defenders considering implementing similar vulnerability discovery harnesses to manually validate findings." Google is sharing the architecture publicly, not the tool itself, specifically so other security teams and open-source maintainers can build their own version suited to their own codebase — built on Google's Agent Development Kit, evaluated against internal synthetic codebases with manually injected flaws rather than public vulnerability datasets that may already be baked into model training data, precisely to avoid the harness looking smarter than it is by having simply memorized the answer during training. Mandiant also positioned AVDH as complementary to, not a replacement for, its ongoing CodeMender scanning work, describing the pairing explicitly as a two-layered defense strategy — continuous lighter-weight scanning plus deep, point-in-time agentic review when the stakes justify it.

Set this next to the Google espionage story above and you get a clean, honest picture of where AI actually sits in security right now: it's compressing timelines for attackers finding ways into accounts and for defenders finding bugs in code, at close to the same rate, on both sides at once. Neither side has a durable structural advantage from AI alone — the advantage goes to whichever side pairs the speed with the discipline to actually validate what the speed produces, which is exactly the human-in-the-loop step Mandiant refused to skip.

The third story is smaller in scope but worth flagging for anyone in the Rust ecosystem specifically, since supply-chain compromises keep proving that "smaller in scope" is a matter of how fast someone notices, not how contained the initial exposure is. The Rust Project removed malicious versions of three widely used crates from crates.io — arrayref 0.3.10, internment 0.8.7, and append-only-vec 0.1.9 — after a compromised maintainer account published all three from the same owner in quick succession on August 20. The payload sat in the build script of a typosquatted dependency the malicious releases pulled in, which means the malicious code didn't need to be called by anything in the crate itself; simply building a project that resolved that dependency was enough to execute the payload during compilation, before a single line of the actual application ran. The Rust Project caught and pulled all three releases within 86 to 107 minutes of publication — a genuinely fast response that limited real-world exposure significantly, and a useful benchmark for what "fast" actually looks like in registry-level incident response: under two hours from a compromised maintainer account publishing to the packages being gone. If your build pipeline touches any of these three packages, the response is the same one that's applied to every supply-chain incident this year: check your lockfiles for the affected versions specifically, and don't assume "the malicious version is gone from the registry now" means anything was gone from systems that already built against it during that window — a build script payload executes the moment `cargo build` resolves it, with or without the registry still hosting it afterward.

Three stories, one week continuing to teach the same lesson from a slightly different angle each day: the login screen, the code review, and the build pipeline are all places where something legitimate — a real OAuth page, a real registry, a real maintainer account — got used exactly as designed, just by the wrong party at the wrong moment. Nothing here required a novel vulnerability class. It required attackers patient enough to wait for a victim to click "allow," a defender fast enough to notice within two hours that something legitimate had gone briefly wrong, and — in Mandiant's case — a genuinely disciplined choice not to let AI's speed outrun the human verification step that actually makes the speed trustworthy.