The common tactic: make a dangerous request look legitimate

The operations used persistent, targeted social engineering. Attackers posed as trusted officials or contacts, created plausible invitations and conversations, and then guided victims through real account-security features. Those features included Google OAuth authorization, application-specific passwords and WhatsApp device linking.

That approach can bypass the protection users associate with multifactor authentication. A victim may not be handing over a password at all; they may be approving an OAuth application, creating an app password or linking a new device. In each case, the victim’s action can give an attacker a legitimate-looking path into an account.

What each cluster reportedly did

UNC6293: impersonation, app passwords and OAuth

UNC6293 reportedly impersonated U.S. State Department officials and other trusted contacts. The lures were designed to persuade targets to create and disclose application-specific passwords, which can provide account access outside a normal second-factor prompt. GTIG also described OAuth-consent phishing, in which attackers seek authorized tokens rather than directly stealing a password.

GTIG assessed with moderate confidence that UNC6293 was an initial-access subcluster of ICE RELIC, Google’s name for the actor formerly known as APT29.

UNC7005, also tracked as STORM-2945: WhatsApp and multi-stage lures

UNC7005 used a broader set of evolving techniques, including:

• WhatsApp device-linking scams: victims were induced to link an attacker-controlled device to their WhatsApp account.
• Fake voice calls and encrypted-chat invitations: these interactions helped establish trust before a malicious link or code was delivered.
• Spoofed organizational communications: lures referencing the Finnish Operations Center were used alongside fake Microsoft sign-in portals.
• OAuth and malware delivery: Google OAuth flows were used to seek tokens or account access, while malware including VIDAR and ATOMIC infostealers was also deployed.

The cluster’s techniques and infrastructure differed from UNC6293’s, which is why GTIG tracks them separately despite their overlapping targeting and reliance on legitimate authentication flows.

UNC5976: OAuth phishing aimed at defense-related targets

UNC5976 reportedly focused on military, aerospace and defense-related personnel and organizations, including targets connected to Ukraine and Armenia. Its phishing activity sought authorization through OAuth to access victims’ accounts or data.

What GTIG said about the Russian connection

GTIG assessed with high confidence that the overall activity had a Russian nexus. That is an attribution assessment, not a claim that every operational detail or cluster relationship is proven with equal certainty.

The available reporting also describes possible links between some of the activity and ICE RELIC/APT29. GTIG’s assessment connecting UNC6293 to ICE RELIC was moderate confidence, while the clusters continue to be tracked separately because their tradecraft and infrastructure are not identical.

Why multifactor authentication is not enough by itself

Multifactor authentication can still be defeated when an attacker manipulates a user into approving the wrong action. An unexpected OAuth consent screen, app-password request or WhatsApp linking code may represent account takeover even if no password is stolen.

The practical lesson is to treat authentication prompts as transactions that require verification—not as automatically safe steps simply because they appear inside a familiar service.

Recommended defenses

GTIG’s guidance emphasizes slowing down the workflow attackers are trying to accelerate:

• Check the complete browser URL before signing in or approving OAuth access.
• Verify invitations and requests independently. Use a known contact method for conference invitations, voice calls, encrypted-chat requests and messages claiming to come from government or organizational contacts.
• Never share app passwords, one-time verification codes, QR codes or device-linking codes. Do not approve an unexpected sign-in or OAuth request.
• Review linked messaging devices regularly. Remove unfamiliar devices from WhatsApp and other messaging applications.
• Use phishing-resistant MFA. Organizations should prioritize security keys or passkeys and, where possible, restrict risky OAuth applications and application-specific passwords.

For people working in sensitive sectors, the most important habit is simple: a familiar brand, a real login page or a genuine authentication feature does not prove that the request is legitimate. The request itself—and the person or organization that initiated it—must also be verified.

The common tactic: make a dangerous request look legitimate

The operations used persistent, targeted social engineering. Attackers posed as trusted officials or contacts, created plausible invitations and conversations, and then guided victims through real account-security features. Those features included Google OAuth authorization, application-specific passwords and WhatsApp device linking.

That approach can bypass the protection users associate with multifactor authentication. A victim may not be handing over a password at all; they may be approving an OAuth application, creating an app password or linking a new device. In each case, the victim’s action can give an attacker a legitimate-looking path into an account.

What each cluster reportedly did

UNC6293: impersonation, app passwords and OAuth

UNC6293 reportedly impersonated U.S. State Department officials and other trusted contacts. The lures were designed to persuade targets to create and disclose application-specific passwords, which can provide account access outside a normal second-factor prompt. GTIG also described OAuth-consent phishing, in which attackers seek authorized tokens rather than directly stealing a password.

GTIG assessed with moderate confidence that UNC6293 was an initial-access subcluster of ICE RELIC, Google’s name for the actor formerly known as APT29.

UNC7005, also tracked as STORM-2945: WhatsApp and multi-stage lures

UNC7005 used a broader set of evolving techniques, including:

• WhatsApp device-linking scams: victims were induced to link an attacker-controlled device to their WhatsApp account.
• Fake voice calls and encrypted-chat invitations: these interactions helped establish trust before a malicious link or code was delivered.
• Spoofed organizational communications: lures referencing the Finnish Operations Center were used alongside fake Microsoft sign-in portals.
• OAuth and malware delivery: Google OAuth flows were used to seek tokens or account access, while malware including VIDAR and ATOMIC infostealers was also deployed.

The cluster’s techniques and infrastructure differed from UNC6293’s, which is why GTIG tracks them separately despite their overlapping targeting and reliance on legitimate authentication flows.

UNC5976: OAuth phishing aimed at defense-related targets

UNC5976 reportedly focused on military, aerospace and defense-related personnel and organizations, including targets connected to Ukraine and Armenia. Its phishing activity sought authorization through OAuth to access victims’ accounts or data.

What GTIG said about the Russian connection

GTIG assessed with high confidence that the overall activity had a Russian nexus. That is an attribution assessment, not a claim that every operational detail or cluster relationship is proven with equal certainty.

The available reporting also describes possible links between some of the activity and ICE RELIC/APT29. GTIG’s assessment connecting UNC6293 to ICE RELIC was moderate confidence, while the clusters continue to be tracked separately because their tradecraft and infrastructure are not identical.

Why multifactor authentication is not enough by itself

Multifactor authentication can still be defeated when an attacker manipulates a user into approving the wrong action. An unexpected OAuth consent screen, app-password request or WhatsApp linking code may represent account takeover even if no password is stolen.

The practical lesson is to treat authentication prompts as transactions that require verification—not as automatically safe steps simply because they appear inside a familiar service.

Recommended defenses

GTIG’s guidance emphasizes slowing down the workflow attackers are trying to accelerate:

• Check the complete browser URL before signing in or approving OAuth access.
• Verify invitations and requests independently. Use a known contact method for conference invitations, voice calls, encrypted-chat requests and messages claiming to come from government or organizational contacts.
• Never share app passwords, one-time verification codes, QR codes or device-linking codes. Do not approve an unexpected sign-in or OAuth request.
• Review linked messaging devices regularly. Remove unfamiliar devices from WhatsApp and other messaging applications.
• Use phishing-resistant MFA. Organizations should prioritize security keys or passkeys and, where possible, restrict risky OAuth applications and application-specific passwords.

For people working in sensitive sectors, the most important habit is simple: a familiar brand, a real login page or a genuine authentication feature does not prove that the request is legitimate. The request itself—and the person or organization that initiated it—must also be verified.