Turning on two-factor authentication used to feel like the end of the phishing conversation. It is not. A recent Google threat-intelligence report on three espionage clusters made one thing very clear, and it has nothing to do with who the attackers were: modern phishing has moved past stealing passwords. The most effective operators now bypass 2FA outright, by abusing the legitimate features of the very services meant to protect you. They never need your password, and that is exactly why so many defences miss them. Here is how the techniques work, and what actually stops them.
“We have 2FA” is not a security posture
The comfort of a checkbox is the problem. Two-factor authentication is not one thing; it is a spectrum, from SMS codes that can be intercepted or socially engineered, through app-generated codes that can be phished in real time, up to hardware keys that are genuinely resistant. Attackers know this spectrum better than most defenders, and they aim squarely at the weak end of it.
What the report documents is a set of techniques that do not break authentication so much as walk around it. Each one turns a feature a service offers for convenience into an entry point. None of them requires cracking a password or defeating cryptography. They require a person to click “allow,” share a code, or set up a credential they were talked into creating. That shift, from attacking systems to attacking legitimate workflows, is the whole story.
The three ways attackers skip your second factor
Three methods showed up again and again across the clusters. They are worth recognising on sight.
| Technique | How it works | Why 2FA doesn’t help |
|---|---|---|
| App-specific passwords | victim is talked into creating an app password and entering it on a fake form | app passwords exist precisely to bypass 2FA |
| Device-code / OAuth consent | victim shares a code or clicks “allow,” linking the account to the attacker | a live session or token is granted, no second factor asked |
| Messenger device linking | victim confirms a legitimate QR/linking code under a pretext | the account is simply added to the attacker’s device |
App-specific passwords: the back door around 2FA
Many email and cloud services still issue app-specific passwords for older software that cannot handle a second factor. By design, these passwords skip 2FA entirely — that is their whole purpose. The attack is simply to convince a target to generate one. Under a plausible pretext, a fake “conference access setup” or a “confirm your participation” prompt, the victim is walked through creating an app password and typing it into a lookalike form.
From there the operator logs straight into the mailbox, and no second factor is ever requested, because the credential they now hold was built to avoid asking. It is a clean, quiet takeover that leaves normal login alerts untouched. The uncomfortable part for defenders is that everything the victim did was a supported feature working as intended.
Device codes and OAuth consent: stealing the session, not the password
The second family is subtler and, if anything, more dangerous. Here the victim is guided through a genuine Microsoft or Google login, and then asked to “share a verification code” or to press “allow” on a consent screen that links their account to the attacker’s application or device. The password stays with its owner. What leaves is a working session or an access token, which is all the attacker actually needs.
One cluster in the report ran victims through a real Google login that then redirected to an unpublished, testing-mode cloud project under the attacker’s control, which silently collected the access tokens. Because the login itself is legitimate and the malicious step is a consent the user grants, this class of attack sails past filters that only look for fake login pages. Misconfigured and over-permissive OAuth consent is its own exposure, and reviewing what apps can be granted access to is part of a cloud configuration review.
Messenger device linking: a takeover with a camera
The third technique targets the “link a new device” feature in messengers such as WhatsApp. The victim is shown a legitimate QR or linking code and, under some pretext, asked to confirm it — after which the account is quietly attached to the attacker’s device, exposing chats, calls and files.
Researchers found a nastier twist on one fake “call” page: a hidden script asked the browser for camera and microphone access and recorded the victim’s audio and video, shipping it off to the attacker. So under the cover of an ordinary video call, someone was quietly capturing both. Email security controls do not see any of this, because the target is never the password — it is trust, and the reflex to approve a prompt that looks routine.
Why this hits businesses, not just high-value targets
It is tempting to file this under espionage and move on. That would be a mistake, because the techniques are not tied to any particular kind of victim. An app password opens a corporate mailbox exactly as easily as a diplomat’s. A malicious OAuth consent links a work account to an attacker’s app just as cleanly. Messenger linking works on anyone. Only the lure on the email changes.
If anything, ordinary organisations are softer targets. A company has dozens of staff, each with mail, cloud and messaging, and many still believe that having 2FA switched on settles the matter. These operations show that switched-on is not the same as resistant: what matters is which second factor you use and whether it can be walked around through a legitimate path. A single employee who creates an app password because an email asked nicely can undo an entire authentication programme.
What actually stops it
- Move to phishing-resistant authentication. Hardware security keys (FIDO2) and passkeys cannot be relayed or talked out of a user the way SMS and app codes can. For high-risk staff, enrol them in the strongest account-protection tier available.
- Kill app-specific passwords. Disable them where you can, revoke old ones, and train people never to create one because a message told them to.
- Treat “share this code” and unexpected consent prompts as attacks. Teach staff to read what an OAuth screen is actually granting, and to never relay a verification code to anyone.
- Audit linked devices and app grants regularly, across email, cloud and messengers, and enable registration locks and 2FA on messaging accounts.
- Test your people, not just your firewalls. Targeted, feature-abuse phishing is exactly what a phishing simulation, a social-engineering assessment and full red team operations are built to rehearse, while an assumed-breach assessment shows how far one linked account lets an intruder travel.
The bottom line
Strip away the threat-group labels, and the lesson is simple and universal: phishing has outgrown password theft. The strongest attackers now go after sessions, tokens and account features, walking around two-factor authentication through the very conveniences vendors built in. Believing you are safe because 2FA is enabled is precisely the assumption these operators rely on. Move your critical accounts to phishing-resistant keys, shut off the legitimate back doors like app passwords and stray OAuth grants, and pressure-test the human layer where these attacks actually land. If you are not sure your team would spot a “share your code” message or a rogue consent screen, talk to our team and find out on your terms.