How attackers bypassed Gmail 2FA with app passwords, and how to protect yourself

Key takeaways

• App-specific passwords let legacy apps sign in without a second factor, so tricking someone into sharing one bypasses 2-step verification.
• Google's threat intelligence team reported the campaign in June 2025; attribution to APT29 was low-confidence overlap, so read the primary report.
• The attack was social engineering, not a flaw in Gmail.
• High-risk users should use Google's Advanced Protection Program.
• Never create or share an app password because someone asks.

What happened?

In June 2025 Google's threat intelligence team described a targeted phishing campaign that they tracked as a separate cluster and linked, with low confidence, to activity associated with Russian state-backed actors, including the group known as APT29. The targets were reported to be prominent academics and critics of Russia. Read the primary report on the Google Cloud threat intelligence blog. Details below follow that reporting. The editor should check them against the report itself.

How did the attack work?

It was patient social engineering, not a software exploit.

1. The attacker contacted the target while posing as an official, building trust over several messages.
2. The message invited the target to a private discussion and included a believable reason to set up a special access step.
3. The target was guided to create an app-specific password in their Google account and send it to the attacker.
4. The attacker then used that password to sign in to the target's mailbox, and could read mail without a one-time code.

What is an app-specific password?

It is a 16-character password that lets an older app or device that cannot handle modern 2-step verification sign in to your account. It works instead of your normal password and does not ask for a second factor. That makes it useful for legacy software and dangerous if a criminal gets it.

Was this a Gmail vulnerability?

No. The service worked as designed. The attacker persuaded the user to hand over a credential that is meant to bypass the second step. This is why technical controls alone do not stop skilled social engineering.

How do you protect yourself?

1. Do not create an app password at anyone's request, especially not to "join a secure meeting" or "view a document".
2. Check whether you need app passwords at all. Most modern apps use sign-in with Google. Revoke unused app passwords in your Google Account security page.
3. Enrol high-risk accounts in Google's Advanced Protection Program, which uses security keys or passkeys and does not allow this kind of access.
4. Use passkeys or hardware keys for important accounts.
5. Verify by another channel when a stranger or an unexpected official asks you to set something up.
6. Review account activity and signed-in devices regularly.

What should organisations do?

• Let Workspace admins restrict app passwords where policy allows.
• Train high-risk staff, such as executives, journalists and researchers, on this specific pattern.
• Alert on new app-password creation and unusual sign-ins.
• Have a clear reporting path. See github device-code phishing for a similar consent-abuse pattern.

What does it teach?

Attackers choose the easiest route to a human. A good second factor can be bypassed if the process offers a side door. The related post on bypassing 2FA through OAuth misconfiguration shows another side door.

Next steps

To study how analysts investigate and respond to account takeover, see our SOC analyst course. For a related consent-abuse case, read GitHub device-code phishing explained.

Related reading

• What Is a Spear Phishing Attack? Examples, Prevention & Detection Guide
• Why are hackers sending PDFs that look like Microsoft or DocuSign emails asking me to call a phone number?
• Malicious Calendly and Google Meet Links Deliver Weaponized Zoom Extension | Cybersecurity Alert 2026