APT29 Ghost Login: Russian Spies Bypass MFA Using Google OAuth and WhatsApp — GTIG Reveals Three Active Espionage Clusters

It begins with an email — a polished invitation to a NATO security forum, a PDF from someone who appears to be a U.S. State Department official, or a WhatsApp message with a conference QR code. The victim visits a legitimate Google login page, enters real credentials, and passes multi-factor authentication. No alarm fires. Yet somewhere in Moscow or St. Petersburg, a Russian intelligence officer now owns that account. No password was stolen. No malware was needed to get in. This is the new face of APT29.

The Ghost Login: How Russia’s Spies Walk Through Your MFA

Traditional credential theft is a blunt instrument: phish the password, crack the hash, buy it on a dark-web market. Multi-factor authentication was supposed to render that playbook obsolete. Russia’s APT29 — operating today under Google’s designation ICE RELIC — has spent the last fourteen months engineering a more surgical approach: make the victim hand over authenticated access using only legitimate authentication flows.

On 21 August 2026, Google’s Threat Intelligence Group (GTIG) published a detailed breakdown of three distinct sub-clusters executing this strategy at scale. The report is chilling not because of exotic zero-day exploits, but because of the mundane legitimacy of every step the victim sees. From a user’s perspective, they clicked a real Google login page and entered real credentials. From an attacker’s perspective, the resulting OAuth token is as valid as one produced by the account owner — because it was.

Three Clusters, One Russian Hand

GTIG tracks the activity across three operationally distinct but tactically overlapping clusters:

Cluster	Also Known As	Attribution	Primary Technique	Active Since
UNC6293	—	ICE RELIC sub-cluster (moderate confidence)	App-Specific Password & OAuth device-code phishing	June 2025
UNC7005	STORM-2945	ICE RELIC sub-cluster (moderate confidence)	OAuth device-code, WhatsApp linking, DNS poisoning	February 2026
UNC5976	—	Russian nexus (high confidence; separate service)	Fake file-sharing OAuth & HEADRUSH malware	March 2026

All three are assessed with high confidence to have a Russian intelligence nexus. UNC6293 and UNC7005 are linked — with moderate confidence — to APT29, the FSB-affiliated group historically known as Cozy Bear and Midnight Blizzard. UNC5976’s heavier malware footprint and focus on Ukrainian military and Armenian aerospace suggests potential alignment with GRU, though GTIG stops short of a firm attribution.

Technical Breakdown: Four Attack Vectors That MFA Cannot Stop

1. App-Specific Password (ASP) Phishing

UNC6293 impersonates senior U.S. State Department officials, sending highly targeted PDF lures — in some cases reaching fewer than five individuals per campaign. The PDFs contain fabricated instructions for setting up an app password labelled ms.state.gov. Once created, app-specific passwords bypass all MFA: they authenticate directly to legacy protocols (IMAP, SMTP) that Google still supports for backward compatibility. The attacker doesn’t break MFA — they use a legitimate bypass built into the platform itself.

2. OAuth Device-Code Phishing

This is the campaign’s workhorse technique. The attacker registers a convincing domain (for example my-invite[.]org spoofing GLOBSEC, or finishoperations[.]com spoofing Finland’s Operations Centre for defence exporters). The victim visits the page, is invited to register for a conference or download a document, and sees a legitimate Google OAuth consent screen. After authenticating normally — including passing MFA — the victim’s token is silently redirected to an attacker-controlled Google Cloud project in testing mode, which Google flags with a warning most users dismiss. The token grants full account access, typically to Gmail, Drive, and Calendar. UNC7005 went further, embedding browser fingerprinting scripts to detect sandbox analysis before rendering the phishing page.

3. WhatsApp Device-Linking Hijack

Perhaps the most brazen vector: UNC7005 operates domains like wa-connect[.]eu and wa-invite[.]com that walk the victim through a genuine WhatsApp device-linking flow. The victim enters their phone number, receives a real WhatsApp QR code and six-digit linking code — served by the legitimate WhatsApp backend — and scans or enters it. The attacker’s device is now linked as a secondary WhatsApp session. Post-linking, the phishing page offers “voice call”, “encrypted chat”, or “file download” options — each triggering JavaScript that activates the device camera and microphone to record audio-video and exfiltrate it to the attacker’s server.

4. CaptiveCrunch — DNS Poisoning at Hotels and Conferences

Between April and July 2026, UNC7005 infrastructure was linked to captive-portal DNS poisoning at hotel Wi-Fi gateways and conference-centre networks. Travellers connecting to what appears to be an ordinary hotel portal were silently redirected through attacker-controlled Microsoft OWA-spoofing pages (owa-ms365[.]com, m365-owa[.]com). This campaign aligns with Microsoft’s independent “CaptiveCrunch / Midnight Blizzard” reporting from 31 July 2026 and Reliaquest’s threat spotlight from 23 July 2026.

Post-Compromise Malware Arsenal

Once initial access is achieved, the clusters drop purpose-built tools:

• VIDAR (Windows infostealer, Go binary, SHA256: 1d9299799…): Exfiltrates browser credentials, saved payments, cookies, and addresses. C2: 107.189.18[.]7.
• ATOMIC / AtomicStealer (macOS, MaaS-operated): Targets Safari and Chrome credential stores, crypto wallets.
• ENGINELIGHT (Go-based, C2: statistic-ms[.]live): Lightweight persistent implant for long-haul espionage access.
• CHERRYPIE / ChocoShell (PowerShell): LLM-assisted artifacts — meaning AI was used to generate evasion-ready code — harvesting credentials and clipboard data.
• HEADRUSH (malicious Excel plugin, SHA256: 2c7f4165…): Distributed via spoofed Ukrainian institute file-sharing pages, drops an HTA downloader for secondary payload staging.

The use of AI-generated malware code in CHERRYPIE marks a tactical shift worth noting: AI is now a force-multiplier for state actors producing evasion-tuned malware at speed. Defenders’ signature databases will perpetually lag.

Why This Matters for Indian Enterprises and Government Bodies

While today’s confirmed victims are primarily in Europe, the United States, Ukraine, and Armenia, the Indian threat landscape is directly implicated for three reasons. First, the same OAuth-abuse TTPs are deployed across multiple threat actor clusters, not just Russian-nexus groups — China-nexus actors (notably APT41) and criminal ransomware operators have been observed using device-code phishing against Indian IT service providers and their global clients. Second, India’s defence and aerospace sector — DRDO, HAL, BEL, and their supply chains — are high-value targets for multiple state-sponsored actors who study ICE RELIC’s techniques as a template. Third, Indian IT and consulting firms manage the digital infrastructure of European and American defence clients, making them an indirect vector into these primary targets.

The previous post on this blog about The Gentlemen Ransomware campaign targeting India through FortiGate backdoors illustrates how threat actors pivot through Indian infrastructure. OAuth-based initial access provides an even quieter entry point — no exploit, no firewall alert, no AV detection.

What You Should Do: Sanjay’s Zero-Trust Defensive Playbook

These attacks succeed precisely because they look legitimate. A perimeter firewall, a SIEM rule tuned for “suspicious login”, and even FIDO2-based MFA can be bypassed or circumvented depending on configuration. The response must be architectural, not just tactical.

1. Kill App-Specific Passwords entirely. In Google Workspace Admin Console, navigate to Security → 2-Step Verification and disable app-specific passwords for all users. There is no legitimate use case that requires them in a modern, managed environment.
2. Restrict 2FA to hardware security keys only. TOTP, SMS, and app-push MFA all remain susceptible to real-time phishing. FIDO2/WebAuthn hardware tokens (YubiKey, Google Titan) are origin-bound and cannot be relayed. Enforce this for all privileged accounts immediately, and for all users within 90 days.
3. Enrol high-risk users in Google’s Advanced Protection Programme (APP). APP prevents app-password creation and restricts which apps can access account data, neutralising both the ASP and OAuth vectors simultaneously.
4. Audit OAuth consent grants monthly. In Workspace Admin → Security → API Controls → Domain-wide delegation, review all connected apps. Any OAuth grant from an unverified or testing-mode application should be immediately revoked. Third-party tools like Google Security Command Center and Microsoft Defender for Cloud Apps can surface shadow OAuth grants automatically.
5. Implement WhatsApp Device Audit policies. For any organisation where WhatsApp is used for business communication (common in India’s MSME sector and even in enterprise sales teams), mandate quarterly linked-device audits under WhatsApp → Settings → Linked Devices. Consider migrating sensitive communications to platforms with richer enterprise audit controls.
6. Treat conference-centre and hotel Wi-Fi as hostile networks. All remote-working and travelling employees should connect via corporate VPN (ideally with zero-trust network access, where the device is continuously verified rather than granted blanket tunnel access) before opening any cloud authentication flow. The CaptiveCrunch campaign is a direct warning against portal-authenticated Wi-Fi.
7. Integrate threat intelligence feeds. The IOC table from GTIG — including domains like wa-connect[.]eu, foreignrelations[.]us, my-invite[.]org, and IPs 104.194.159[.]150 and 107.189.18[.]7 — should be immediately loaded into your firewall and NGFW threat intelligence feeds. FortiGate’s FortiGuard Threat Intelligence service will distribute these IOCs automatically for customers using the premium threat-intelligence subscription.

Frequently Asked Questions

Does hardware MFA (FIDO2/WebAuthn) protect against OAuth device-code phishing?

Mostly yes, with a critical caveat. Hardware security keys are origin-bound: the key will refuse to sign a challenge for a domain that does not match the registered origin. This blocks real-time phishing of MFA codes. However, OAuth device-code phishing operates differently — the victim authenticates to the genuine Google domain, so the hardware key signs correctly. The attack hijacks the resulting token, not the authentication event. Combining hardware keys with OAuth app whitelisting and unverified-app consent blocking is required for full protection.

We use Microsoft 365, not Google Workspace. Are we affected?

Yes. UNC7005 and Midnight Blizzard both operate device-code phishing campaigns against Microsoft 365 accounts, as confirmed by Microsoft’s own CaptiveCrunch reporting from July 2026. The attack flow is nearly identical: a spoofed Microsoft login page, a real device-code prompt, and a stolen access token. Microsoft’s Conditional Access policies with compliant-device enforcement and the blockDeviceCodeFlow authentication context provide the equivalent mitigation.

How do I tell if my Google or WhatsApp account has already been compromised this way?

For Google: check Security → Recent Security Activity and Third-party apps with account access. Look for apps you don’t recognise, especially those granted sensitive scopes (Gmail read, Drive full access) within the last six months. For WhatsApp: Settings → Linked Devices shows all active secondary sessions with approximate location — any unfamiliar device should be immediately unlinked. Neither indicator is infallible; a sophisticated attacker will have already exfiltrated what they need and may have unlinked. SIEM correlation of authentication tokens from unusual IPs or user-agents against normal baseline behaviour is more reliable at the enterprise level.

Is this APT29 campaign specifically targeting Indian organisations?

Current GTIG reporting does not name Indian victims. However, the techniques — particularly OAuth phishing and WhatsApp device-linking — are platform-agnostic and are being replicated by multiple threat actor families beyond APT29. Indian defence subcontractors, IT service providers managing European defence accounts, and diplomatic missions in Delhi are plausible targets under a supply-chain or indirect-access strategy. The Indian Computer Emergency Response Team (CERT-In) has not yet issued a specific advisory, but organisations in the defence, government, and critical-infrastructure sectors should treat this as an active risk.

The Bottom Line: Legitimate Flows Are the New Attack Surface

The most significant insight from the GTIG report is architectural: perimeter security and traditional MFA were built to defend against illegitimate access — but these attacks use entirely legitimate flows. The token is real. The login page is real. The QR code is real. The only thing that is manufactured is the context in which the victim uses them.

Zero-trust — which demands continuous verification of identity, device health, and access context at every step, not just at the perimeter — is the only framework that structurally addresses this class of attack. App whitelisting, OAuth consent monitoring, and hardware-bound authentication are not optional hardening steps for high-security environments. They are baseline hygiene for any organisation whose people use cloud platforms — which, in 2026, means everyone.

The sources for this article are the Google Threat Intelligence Group primary report, The Hacker News coverage, The Register’s technical analysis, and Security Affairs.