Google’s Threat Intelligence Group published a report this week tracking three suspected Russian-nexus hacking clusters running espionage campaigns against academics, diplomats, defense industry professionals, and think tank staff across Europe, Ukraine, and the United States. The report is worth reading in full, but the detail that stands out for anyone running a DMARC program is not the attribution. It is how little email authentication has to do with any of it.
Three Clusters, One Shared Insight
Google tracks the clusters as UNC6293 (a suspected sub-cluster of the group known as APT29 or ICE RELIC), UNC7005 (also tracked by Microsoft as Storm-2945), and UNC5976. Each targets a slightly different population, from US and European academics and diplomats to Ukrainian and Armenian defense and aerospace organizations, but they share a common operating principle: rather than fighting through DMARC, SPF, and DKIM to spoof a target’s own domain, they route the entire attack through authentication flows that are completely genuine on the receiving end.
UNC6293 asks targets to generate an app password, a legacy Google feature meant for older devices that cannot use full sign-in, and hand it over. An app password bypasses two-factor authentication entirely by design, so once an attacker has one, MFA is no longer part of the equation. Later versions of the campaign asked targets to enter an OAuth “verification code” on a phishing site instead, skipping the password-sharing step but landing at the same result: a stolen token issued through a completely legitimate authentication exchange.
UNC7005 runs the widest range of techniques. It registered domains spoofing the Finnish Operations Center, a defense-industry support organization tied to NATO-adjacent work, and sent phishing emails from those domains to European defense contractors between August 6 and August 13. Victims who clicked were routed to an attacker-controlled Google Cloud project sitting in “testing mode,” which is enough to complete an OAuth consent flow and steal the resulting token without ever presenting a fake login page. The same cluster runs Microsoft device code phishing against event attendees, using a landing page that fingerprints the visitor’s screen size, timezone, CPU core count, and browser characteristics specifically to detect and evade automated security analysis before showing a real Microsoft device code.
The WhatsApp Detail
The most striking technique in the report targets WhatsApp. UNC7005 built phishing pages themed around secure calls and document sharing, then used them to initiate a genuine WhatsApp device-linking request and display the real QR code or linking code on the page. A target who scans it has authorized an attacker-controlled device to their own WhatsApp account, using WhatsApp’s actual linking feature exactly as designed.
From there, victims are shown a fake incoming call screen. Accepting it triggers JavaScript that calls the browser’s camera and microphone APIs directly, records the feed, and uploads it to attacker infrastructure. Nothing about this touches a mail server, a DNS record, or an authentication tag. It is a phishing page abusing a browser API and a messaging app’s own linking feature, chained together after an email got someone to click a link.
Why This Sits Outside DMARC’s Job
DMARC exists to answer one question: did this message actually come from a mail server the domain owner authorized. It does that job well, and enforcing it stops a huge share of domain spoofing. But none of these three clusters need to spoof the target’s own domain to succeed. UNC7005’s Finnish Operations Center emails come from freshly registered lookalike domains that the attacker controls outright, so of course they pass their own SPF, DKIM, and DMARC checks. Passing DMARC on a domain the attacker registered a week ago tells a receiver nothing about trustworthiness.
More importantly, once the target clicks through, the rest of the attack never touches email again. An OAuth consent screen, a Microsoft device code prompt, and a WhatsApp linking request are all authenticated interactions between the victim and the real platform, exactly as those platforms designed them to work for legitimate use. Google’s report puts it plainly: these operations “abuse legitimate authentication flows which may not immediately seem like phishing attempts to users,” and the accounts under attack are typically personal, not corporate domain-joined accounts, which leaves security teams with no organizational visibility into the compromise at all.
What This Means for Your Program
Enforcing DMARC on your own domain does nothing to stop your people from being phished by someone else’s lookalike domain. These campaigns spoof third-party organizations, conference hosts, and support agencies, not the target’s employer. Your DMARC policy protects your brand’s mail channel. It has no jurisdiction over a domain registered last week to impersonate a defense forum.
Treat unsolicited app password requests as an incident, not a support ticket. App passwords bypass MFA by design. Google’s own guidance is that most users never need to create one. If a message asks a user to generate and share an app password, block distribution of that guidance immediately and investigate.
Extend your out-of-band verification habit past email into every linking and consent flow. A genuine OAuth screen, a genuine device code, and a genuine WhatsApp QR code all look genuine because they are. The only reliable check is confirming, through a separate channel, that the person or organization requesting the link actually sent that request.
Audit linked devices on messaging apps the same way you audit OAuth app grants. Most users have never opened WhatsApp’s linked-devices screen. A periodic reminder to check it, alongside routine OAuth consent audits in your identity provider, closes a gap that email filtering was never built to cover.
The Takeaway
DMARC, SPF, and DKIM remain essential, and none of that changes here. What changes is the reminder that a well-funded, patient attacker will simply go around the parts of your defense that work. These three clusters do not fail DMARC checks because they never put themselves in a position where DMARC gets a vote. The email is just the door. Once it opens, the rest of the operation runs entirely on legitimate infrastructure that authentication protocols were never designed to police.
Excello Mail helps you enforce DMARC, SPF, and DKIM correctly on the domains you control, so the mail channel attackers can actually forge is locked down while your team learns to spot the authentication flows that live outside it. Sign up for free to Excello Mail and get full visibility into who is sending as your domain.