Hi, this is an adversary-in-the-middle phishing technique: the victim sees content relayed from Google, but interacts through an attacker-controlled site. That distinction matters because a genuine-looking login page—and even valid Google responses—does not make the address bar genuine.
How the theft works
The relay passes the victim’s entries to Google and returns Google’s responses in real time. This can let the attacker capture:
- the password;
- a one-time 2FA code or approval;
- the authenticated session token created after successful login.
Stealing the session is the nasty part. It may allow account access without repeatedly supplying the password or 2FA code, at least until that session is revoked or expires. Two-factor authentication still helps against many attacks, but ordinary OTP codes and push approvals are not inherently resistant to a live relay.
The quoted report does not identify the exact relay software or establish the campaign’s present scale, so those details should not be inferred from the headline alone.
What users should check
The reliable check is the
site origin in the address bar, not how convincing the page looks. A padlock only means the connection to that particular site is encrypted; phishing sites can have HTTPS too.
Practical precautions:
- Do not sign in through a voicemail-alert link. Open Google Voice or the relevant Google service directly from a bookmark or by typing its known address.
- Treat an unexpected Google sign-in after clicking an email as a warning, even when the page looks flawless.
- Prefer phishing-resistant authentication such as passkeys or FIDO2 security keys where available. These bind authentication to the legitimate site and are designed to defeat this sort of relay.
- Do not trust an email merely because it passed SPF, DKIM or DMARC. A message sent through a compromised legitimate account can authenticate correctly and still be malicious.
If someone entered credentials
From a separate trusted device, use Google’s official account page to:
- change the password and change it anywhere else it was reused;
- sign out or revoke other active sessions;
- remove unrecognized devices, third-party access and app passwords;
- verify recovery email addresses and phone numbers;
- inspect Gmail forwarding, filters and delegation settings;
- enable a passkey or security key where practical.
Changing the password alone should not be assumed to invalidate every stolen session. If this involved an organizational account, report it promptly to the security or IT team so they can review sign-ins and revoke sessions centrally.