AiTM Worm in Google Workspace: How It Spreads and What Stops It

A Google Workspace tenant with 2FA enforced can still be hollowed out in a weekend by a self-propagating worm that uses AiTM (adversary-in-the-middle) reverse-proxy phishing. The worm does not need the password or the 2FA code. It captures the session cookie while the user is still typing, then uses that cookie to pivot from one Workspace account to the next inside the same tenant. Push-based 2FA (TOTP, SMS, Google prompt) does not stop it. FIDO2/WebAuthn does. And the brand-side role of DMARC is honest but narrow: it removes the easiest phishing lure variant, not the session-side attack itself.

This post walks through how AiTM reverse-proxy phishing works against a Workspace user, how the captured cookie turns into a tenant-wide worm, why push 2FA fails, and which layered controls actually break the chain.

What AiTM reverse-proxy phishing actually does to a Workspace user

AiTM phishing is not a credential-harvesting page that stores passwords for later. It is a real-time relay that sits between the victim and the real Google login servers.

The three steps are:

What AiTM reverse-proxy phishing actually does to a Workspace user

AiTM phishing is not a credential-harvesting page that stores passwords for later. It is a real-time relay that sits between the victim and the real Google login servers.

The three steps are:

1. Lure. The victim clicks a link in an email, chat, calendar invite, or SMS that lands on a phishing page visually identical to the real Google sign-in. The page is not a static form. It is a reverse proxy.
2. Relay. When the victim types their email and password, the proxy forwards the credentials to the real Google servers. When Google responds with a 2FA challenge (TOTP code, SMS code, Google prompt), the proxy forwards that challenge back to the victim. The victim completes the 2FA challenge in real time, believing it is normal.
3. Replay. Google issues a session cookie to the proxy. The proxy captures it, then either forwards a real session to the victim (so they see a working Workspace) or simply keeps the cookie and never lets the victim in at all. From that moment on, the attacker can replay the session cookie against Google's APIs and the Workspace admin console with the full authority of the signed-in user.

The crucial point: the proxy completes the 2FA challenge in real time. The attacker does not need to see the password or the code. They get a session cookie that is just as good as one the user would have received themselves.

This is why TOTP, SMS codes, and Google prompt all fail against AiTM. The challenge-response model assumes the user is talking to the real server. AiTM defeats that assumption by proxying the entire conversation. Phishing-resistant MFA works differently. FIDO2/WebAuthn keys and platform passkeys produce an origin-bound cryptographic response that the proxy cannot relay to a different domain. The phishing page can ask for it, but the key refuses to sign for the wrong origin.

How the worm self-propagates once one account is captured

A single compromised Workspace account does not stop at mail theft. The captured cookie is reused against the Workspace APIs, often inside seconds:

Mail rules. The attacker creates inbox rules to mark phishing messages as read, move them out of view, or forward replies to an external address the attacker controls.
OAuth grants. The attacker consents to a third-party app on behalf of the user, often using mail, drive, contacts, or admin scopes. Once granted, the app can read mail, send mail as the user, and reach drive contents even if the user's password later changes.
Contact scraping. The attacker pulls the user's address book, recent recipients, and group memberships. This builds the next wave's target list.
Repeat wave. The attacker sends a new wave of phishing mail from the captured account. The recipient sees an internal sender they know, clicks the lure, and the proxy captures another session cookie. The cycle repeats with each new account.

The propagation speed is what makes this a worm rather than a single-account takeover. Sysadmins who have fought this pattern describe accounts compromised per hour inside one tenant, not per day.

Why push-based 2FA and password rotation alone do not stop it

The intuition that "we have 2FA on, so we are safe" breaks here for two reasons.

First, captured session cookies are valid until they expire or are revoked. Changing the user's password does not invalidate already-issued session cookies. Many tenants keep Workspace session lifetimes at 8 hours, 24 hours, or longer. The attacker has the full validity window to act before the cookie times out.

Second, session control tightening and refresh-token revocation matter more than password rotation frequency. A stolen cookie with a 24-hour session lifetime is a 24-hour pass to the tenant, regardless of how many times the user rotates the password after the fact.

This is why Workspace tenants that rely on TOTP, SMS, or Google prompt remain vulnerable to AiTM even when the per-user security posture looks strong on paper. The proxy completes the challenge in real time, and the user ends up with a session cookie that the proxy captures instead.

The layered-control checklist that actually breaks the chain

There is no single control that stops this worm. There is a layered set, and each layer closes a different gap.

1. Enroll FIDO2/WebAuthn for all users, starting with admins. Hardware security keys (YubiKey, Titan, Feitian) and platform passkeys produce origin-bound responses that AiTM proxies cannot relay. For Workspace admins especially, this is the single highest-impact control.
2. Shorten Google session lifetime. Move from session lifetimes to 1 to 4 hours for admins and other high-risk roles. This bounds the validity window of any captured cookie.
3. Disable legacy access paths. Turn off less-secure-app access, IMAP, and POP3 fallback for the tenant. Each of these is a back door that does not require modern session validation.
4. Audit and revoke unused OAuth grants. Run a tenant-wide audit of third-party apps with mail, drive, contacts, or admin scopes. Revoke anything that is not in active use, and require admin approval for new high-scope consents.
5. Audit mail rules tenant-wide. Look for forwarding rules, mark-as-read rules, and move-to-trash rules on every mailbox. Attackers add these on day one to hide their tracks.
6. Turn on Google Workspace Advanced Protection Program for admins. This forces stricter download, app, and sign-in controls on administrator accounts.
7. Force re-login after containment. When a tenant-wide incident is contained, force every session to reauthenticate. Captured cookies stop being valid the moment the user is forced back through sign-in.

None of these is sufficient on its own. Together, they raise the cost of reusing a stolen cookie high enough that the worm stops spreading.

Where DMARC and DMARCFlow fit

Honest framing matters here. DMARC does not stop AiTM session theft. The attack is not on the email authentication layer. It is on the session layer inside the browser, and it succeeds regardless of whether the lure email passes DMARC.

What DMARC does is close a different, narrower gap: it prevents the attacker from spoofing the user's own brand in the lure email. Without DMARC at p=quarantine or p=reject, an attacker can send an email that appears to come from the user's own IT department, from the user's own HR team, or from the user's own finance team, all using the user's own domain in the From header. That is the most credible variant of the AiTM lure. DMARC enforcement takes that variant off the table.

DMARCFlow fits in this layered defense by making DMARC enforcement operationally realistic. Enforcing DMARC at p=quarantine or p=reject across a tenant requires aggregate report parsing, sender change tracking, and a monitored rollout from p=none to p=quarantine to reject over weeks. DMARCFlow's Personal tier (1 EUR/month for up to 5 domains) and SMB tier (34.99 EUR/month for up to 25 domains, with real-time alerts, RBAC, and multi-domain management) handle that enforcement rollout. EU-only data hosting in Germany is relevant for tenants with that requirement.

That said: do not treat DMARCFlow as the AiTM control. It is the brand-side control that removes the most credible lure variant. The session-side controls in the checklist above are what actually break the AiTM chain.

A 24-hour response plan if you are already inside the worm

If a tenant is already inside the worm, time matters more than order.

Revoke all OAuth grants and active sessions tenant-wide. Use the Google Admin console to revoke every third-party app token and every active user session.
Reset all user passwords. Force a tenant-wide password reset, but treat it as defense in depth, not as the primary control.
Reissue identity tokens. If you use SSO, reissue SAML/OIDC tokens. Plan certificate rotation separately; doing it under pressure introduces signing outages.
Audit mail rules tenant-wide. Look for any rule that forwards, marks read, or moves mail. Delete anything not added by the user themselves.
Force FIDO2 re-enrollment. For any user who has not enrolled a phishing-resistant second factor yet, require it before they can sign in again.
Notify affected contacts. Internal-domain phishing waves target the next user. Warn the wider org to be suspicious of internal-looking mail until containment is verified.

Containment is measurable: zero new AiTM-compromised accounts over a 24-hour window, with all mail rules and OAuth grants restored to a clean baseline.

Summary

The AiTM reverse-proxy worm is a session-layer attack, not an email-authentication attack. TOTP and Google prompt fail because the proxy completes the challenge in real time. FIDO2/WebAuthn succeeds because the response is origin-bound. Short Workspace session lifetimes, OAuth grant audits, mail rule audits, and forced re-login each close a different gap. DMARC and DMARCFlow close the brand-side gap so the most credible lure variant is gone before the session-side controls ever have to fire. Use all of them together. None of them is sufficient alone.

FAQ

Does Google Workspace stop AiTM reverse-proxy phishing out of the box?
No. Workspace stops many attack types, but AiTM reverse-proxy phishing is a session-layer attack that succeeds unless phishing-resistant MFA (FIDO2/WebAuthn) is enrolled for the user. Workspace enforces what is configured. Configure FIDO2/WebAuthn, short sessions, and admin approval on OAuth grants.

Why does TOTP or Google prompt 2FA not stop the worm?
TOTP, SMS, and Google prompt all complete in real time. The proxy relays the challenge to the real Google server, captures the session cookie that Google returns, and replays it. The attacker never needs to see the password or the 2FA code.

What FIDO2 hardware works with Workspace?
Any FIDO2/WebAuthn-compliant security key or platform passkey. YubiKey, Titan, Feitian, and built-in platform passkeys on modern operating systems all work. Workspace admins can require FIDO2 keys for admin sign-in.

Where does DMARC fit, and what does DMARCFlow do in this picture?
DMARC enforcement closes the brand-side gap. Without DMARC at p=quarantine or p=reject, an attacker can send phishing mail that appears to come from the user's own domain. DMARCFlow helps tenants make that enforcement real by aggregating RUA reports, surfacing new senders, and supporting a monitored rollout from p=none to p=quarantine to reject. It is the brand-side control. The session-side controls above are what actually break the AiTM chain.

How fast does the AiTM worm spread inside one tenant?
Reports from sysadmins who have fought this pattern describe accounts compromised per hour inside a single tenant, not per day. The worm spreads through captured address books and recent-recipient lists, which is why OAuth audit and session control tightening matter more than password policy alone.