Russian clusters bypass two step verification by asking for app passwords

Google Threat Intelligence Group published an account on 20 August 2026 of three clusters linked to Russian intelligence, tracked as UNC6293, UNC7005 and UNC5976. The targets are academics, the aerospace and defence industry, governments, diplomats and think tanks across Europe, Ukraine and the United States. What they have in common is not malware, but authentication. The clusters get their targets to create app passwords, approve device codes or complete genuine OAuth sign ins that end up with the attacker. Google stresses that the campaigns largely go after personal accounts, which makes them hard for an employer to detect and respond to.

What happens technically

An app password is a separate code a service can issue to older programs that cannot handle two step verification. That is precisely why it interests an attacker. A sign in with an app password bypasses two step verification, and it triggers no approval on the phone. Google describes how UNC6293 has impersonated US government bodies and asked the target to create an app password with a specific name, and how from October 2025 the cluster directed targets to fake authentication forms rather than asking for the code in plain text. UNC7005 uses the same approach with a distinct password name per target.

The second route is device code phishing. The flow exists for devices without a keyboard, where the user types a code on a genuine sign in page to approve the device. The attacker starts the sign in themselves, sends the code to the target in a fake conference invitation or registration form, and obtains a valid session once the target approves. Google also describes how UNC7005 has applied the same principle to messaging services by displaying genuine linking codes, so that the attacker's device is linked to the target's account. The third route is token collection through genuine OAuth flows. From 31 July 2026 UNC7005 registered domains spoofing a Finnish defence sector organisation, and between 6 and 13 August the campaign targeted the European defence industry. The target was sent through Google's own sign in flow and onwards to a cloud project the attacker controlled, where the token was collected. UNC5976 has used the same technique with fake file sharing pages, and in April 2026 also a malicious Excel add in that Google calls HEADRUSH. Google recommends removing app passwords, auditing linked devices and verifying unexpected invitations through an independent channel.

What this means for you if you manage sign-in

This case is uncomfortable because it moves the attack outside the organisation's field of view. When the attacker goes after an employee's private account, the incident appears neither in company logs nor in security monitoring, and the first indication may be a document surfacing somewhere it should not. The target group is also recognisable for organisations in defence, research and foreign policy, and for their suppliers. These are exactly the people who get invited to conferences, who receive approaches from unfamiliar institutes, and who have good reasons to reply.

The second point is that two step verification is not one measure but several, and the weakest variants are the ones exploited here. App passwords are an old back route that many organisations still leave open without knowing, and the device code flow is enabled by default in several services. Our assessment is that this is among the cheapest sets of measures available, because it amounts to closing functions you probably do not use. For the most exposed roles, security keys are what actually stops this entire category, since a key cannot be handed over in a form.

Berigo recommends

• Disable app specific passwords in Google Workspace and Microsoft 365, and revoke the ones that already exist.
• Restrict or disable device code sign in with conditional access, and log the attempts.
• Require security keys for executives, researchers and other exposed roles, and consider enhanced protection programmes for individuals.
• Review linked devices in messaging services, and enable registration locks where the service offers them.
• Introduce a simple rule that unexpected invitations and sign in requests are verified through a channel the recipient finds independently.