Does 2FA by SMS stop phishing?

It stops attacks that only have your password, but not a live relay page. A fake sign-in page that passes everything to Google in real time can forward an SMS code or a phone prompt within seconds. Passkeys and security keys cannot be relayed this way because they check the website first.

How can an email from someone I know be phishing?

If that person's mailbox has been hacked, the attacker sends from their real account. The email passes SPF, DKIM and DMARC because it really is from them. Treat any unexpected request to sign in to view a file as suspicious and confirm with the sender another way.

What should I do right after a Google security alert?

Change the password and sign out of all sessions, not just the one you are using. In Google Workspace an admin can do both from the Admin console. Then check recovery options, 2-Step Verification methods, forwarding rules and connected apps.

Phishing that bypasses 2FA: a real Google account takeover

This month we investigated an account takeover for a client. Nobody clicked a strange attachment, no laptop was infected, and the victim was careful. Her Google account was still taken over, kept quietly for a week, and then used to send a malicious "invitation" to more than 1,400 of her contacts. We are sharing how it worked, with every name removed, because the same pattern is hitting small businesses everywhere and it is easy to stop once you have seen it.

How it started: a real person's hacked mailbox

The email came from a school principal our client had genuinely worked with a few weeks earlier. His account had been hacked, and the attackers used it to email everyone he had been in contact with, all in Bcc. The message was short: "has shared a file with you", a "Read document" button, and his real email signature.

Because it came from his real mailbox, it passed every technical check. SPF, DKIM and DMARC all confirmed it was genuinely his, and the spam filter had no reason to stop it. That is what makes this kind of phishing work: it arrives from someone you know, not from a stranger.

The fake sign-in page

The button did not go to a random website. It opened a page hosted on a legitimate Google service, so the first address looked like google.com. That page asked the reader to "verify your identity to view the document" and then sent them to a copy of Google's sign-in screen on the attackers' own domain.

This was not a crude copy. It was the real Google sign-in page, passed through the attackers' server in real time. Security teams call this an adversary-in-the-middle attack. Everything typed goes to the attacker first and then on to Google: the password, and then the phone check Google asks for. Within eight minutes of the click, the attackers were signed in to her account from a hosting server.

Why the phone check did not help

Google did ask for a second step. It was completed through the same fake page, because to the victim it looked like a normal part of signing in. Codes sent by SMS, codes from an app and "Is it you?" prompts can all be relayed like this. The page does not need to break anything. It just forwards what the person does.

What the attackers really wanted was the result: once Google accepts the sign-in, it gives the browser a session, the thing that keeps you signed in. The fake page kept that session for the attackers. From then on they did not need the password or the phone again.

There was one thing they could not relay. Their first move was to try to change her 2-Step Verification settings, most likely to add their own phone and lock her out. That step asked for her passkey, which only works on the real google.com, and it failed.

A week of silence, then the blast

Google flagged both actions as suspicious and sent a security alert that morning. The alert was opened, but the password was not changed and nobody signed out the other sessions, so the attackers stayed in. For seven days they did nothing visible.

Then, on a Monday, they used the stolen session from a different server to send a "special dinner party invitation" from her account to more than 1,400 contacts, in five messages. The link installed remote-control software on the computers of anyone who ran it. They also hid the bounce messages and replies so the victim would not notice. It stopped when she changed her password that afternoon.

The chain then closed on itself: some of those 1,400 recipients worked at the same school the first email came from. Each hacked mailbox becomes the trusted sender for the next round.

What would have stopped it

Two things would each have stopped this attack on their own. Everything else lowers the odds.

Passkeys or security keys for sign-in. They check that the site really is Google before they answer, so a relay page gets nothing. This is what the US cybersecurity agency CISA calls phishing-resistant MFA. Google Workspace can require it for everyone with the "Only security key" 2-Step Verification setting, which accepts both security keys and passkeys.
Acting on the alert the same day. After any Google security alert: change the password and sign out of every session (an admin can do it for the user). Changing the password alone was what finally ended this attack, a week too late.

If passkeys are not an option yet, these still help a lot:

Shorter sessions. In the Admin console, Google session control sets how long web sessions last before people must sign in again. A stolen session that expires in a day is far less useful than one that lasts weeks.
Alerts that reach an admin. Send suspicious sign-in and 2-Step Verification change alerts to the person who can act, not only to the user.
A password manager. It only fills your Google password on the real Google domain. When it refuses to fill, treat that as a warning, not a bug.
A team rule for shared files. If an email asks you to sign in to see a file, even from someone you know, check with them by phone or text first.
Look at the address bar before you sign in. Google's sign-in page is always on accounts.google.com.

If it already happened

Change the password, sign out all sessions, and check what the attacker may have changed: recovery email and phone, 2-Step Verification methods, mail forwarding and filters, and connected apps. Then pull the Gmail and sign-in logs in the Admin console to see what was sent and from where, warn your contacts, and report the fake page and its hosting provider. Your computer was probably not infected, but it is worth a check, because some of these campaigns end with remote-control software.

How Guanacos Tech helps

We investigate account takeovers in Google Workspace from the logs up: how they got in, what was touched, who received what, and whether any device was affected. Then we set up the controls above, including passkeys or security keys without locking anyone out, shorter sessions and admin alerts, and give your team a one-page guide they will actually read.

Why 2FA did not stop this Google account takeover, and what would