The Gmail PhaaS Playbook: Anatomy of a Repeat Offender

8 hours ago
5 min read

After seeing more than a dozen Gmail account-compromise incidents, a pattern has emerged that is too consistent to be coincidental. The victim receives a legitimate-looking Google MFA prompt on their mobile device, accepts it thinking nothing of it, and their account is silently handed to an attacker sitting on a VPS somewhere overseas. Within hours — sometimes minutes — the hijacked inbox becomes a launchpad, blasting hundreds of phishing emails to the victim's contact list.

The kill chain is almost identical across every case. Same hosting providers, same post-compromise behaviour, same evasion technique. This article documents what I've observed in the field, and makes the case that these campaigns are being powered by a commoditised, black-market Phishing-as-a-Service (PhaaS) toolkit — the Google-targeting cousin of well-documented Microsoft 365 kits like Tycoon 2FA.

How the Attack Works:

The attack flow is a textbook Adversary-in-the-Middle (AiTM) operation. Rather than breaking encryption or exploiting a Google vulnerability, the attacker positions a reverse proxy server between the victim and Google's real login page. The victim authenticates — for real — and the proxy captures their live session cookie. MFA is never "bypassed" in the traditional sense; the user completes it legitimately, and the attacker simply steals the authenticated session that results.

The Mailer-Daemon Block: An Underappreciated Tell

The single most distinctive indicator in these cases — and the one I've rarely seen documented specifically for Gmail AiTM campaigns — is the deliberate blocking of mailer-daemon@googlemail.com immediately prior to the outbound spam run.

When an email fails to deliver, Google's mail delivery subsystem sends a Non-Delivery Report (NDR), or "bounce," back to the sending address from mailer-daemon@googlemail.com. In a bulk phishing operation sending to hundreds of targets, a significant proportion of those addresses will be invalid, dormant, or protected by spam filters — generating a flood of bounce-back messages into the victim's inbox. These bounces are a bright red flag. A victim seeing their inbox fill with hundreds of delivery failures for emails they never sent would immediately know something is wrong and likely raise the alarm or change their credentials before the phishing campaign reaches full effect.

By creating the block rule first, the attacker buys time. The victim's inbox appears normal. No bounces arrive. The campaign runs undetected for longer. This is not a casual decision — it's an operationally deliberate step that indicates the actor understands the detection risk and has scripted a mitigation into their workflow.

This Is a PhaaS Toolkit — Not a Solo Operator

The uniformity across unrelated cases is the giveaway. Independent victims, different organisations, different time periods — yet the same hosting providers, the same post-compromise playbook, the same sequencing. This is not the signature of a creative threat actor adapting their approach. It is the signature of a product.

The Microsoft 365 side of this problem is well-documented. Tycoon 2FA, first surfaced by Sekoia researchers in late 2023, is the most prominent example: a fully commercialised AiTM PhaaS platform sold via Telegram for as little as $120 for a 10-day phishing window. It targets both Microsoft 365 and Gmail accounts, operates across over 1,100 domains, and had generated more than $394,000 in Bitcoin transactions by mid-2024 alone. It is actively maintained, with regular updates to improve evasion and obfuscation of its phishing pages.

The Google-specific variant I've encountered in the field bears the same hallmarks of a packaged kit: automated steps, consistent infrastructure choices, and pre-built post-compromise actions (like the mailer-daemon filter) that no manual operator would apply identically across ten separate victim accounts. The most likely explanation is that there is a Google-focused PhaaS toolkit — or a Google module within an existing one — circulating in black-market channels that has simply received less public research attention than the Microsoft 365-focused kits.

Why MFA Didn't Stop This

A common client reaction when these incidents are presented is disbelief that MFA "failed." It didn't fail — it was bypassed elegantly. The AiTM technique doesn't attack MFA at the protocol level. It weaponises the user's trust in their own device notification and the real-time nature of the proxy relay. The victim completes a genuine MFA challenge against the real Google

infrastructure. The attacker simply intercepts what that authentication produces: a session cookie representing an already-authenticated session.

Stolen cookies allow attackers to replay a session and maintain access even if credentials are subsequently changed, because the session was established with valid MFA consent. The only authentication methods that are technically resistant to AiTM are FIDO2 hardware keys and passkeys, both of which bind the authentication response cryptographically to the legitimate origin domain — something a proxy cannot forge. Traditional TOTP codes, SMS codes, and push-notification approvals are all susceptible.

What IR Reports Should Document

If you're handling a similar case, the following artifacts are the most valuable to preserve and document. Timeline of Gmail filter creation (found in Gmail's audit logs or via Google Workspace Admin Console) is critical — the timestamp of the mailer-daemon block rule relative to the first anomalous login and the first outbound phishing email establishes the operator's automated playbook. Login IP addresses and ASN data will likely cluster around a small set of VPS providers; cross-case correlation on these is highly productive for attribution and building shared IoC sets.

Sent mail folder content — if not deleted — reveals phishing template design, which can often be matched to known PhaaS kit templates. And device approval logs will show the precise moment the victim accepted the fraudulent MFA prompt, which is useful both for forensic reconstruction and for explaining the compromise to the victim.

The good news, if there is any, is that the repeatability of this attack pattern means that once you've worked one case thoroughly, you have a reliable template for the next. The bad news is that the repeatability also means the toolkit is stable, functional, and being actively used at scale.

Bottom Line

Gmail-targeted AiTM attacks are being conducted with the same tooling discipline seen in the well-documented Microsoft 365 PhaaS ecosystem. The specific post-compromise behaviour of blocking bounce notifications before a bulk phishing blast is a repeatable, operational artefact of an automated kit — not improvised tradecraft.

Security teams responding to Gmail BEC incidents should treat this pattern as a reliable indicator of kit-based attacks, add the mailer-daemon filter check to their standard Gmail triage checklist, and escalate intelligence on hosting providers and infrastructure to contribute to broader community detection efforts.

Phishing-as-a-Service has lowered the floor for conducting sophisticated MFA-bypassing campaigns to the price of a budget software subscription. The Google ecosystem deserves the same research scrutiny the Microsoft 365 PhaaS space has received.