Google Calendar Phishing: How a Trusted Invite Ends in a Live MFA Proxy

Material Security’s Threat Research team describes a Google Calendar phishing campaign that began in mid-August 2026 and, by its latest update, appears to have ended. An invite arrives from a sender the victim may know, and its link starts on a Google address. The page at the end relays the victim’s password and MFA approval to the real Google as they happen.

The attacker keeps a live Google session, not just a password. This post explains the mechanism, why reputation checks missed it, and what a Workspace admin can check today.

What Is a Live MFA Proxy Session Hijack?

In an adversary-in-the-middle (AiTM) attack, the phishing page is a relay, not a copy of the sign-in page. It passes each request to the real sign-in page and returns the real answers, so the victim sees genuine Google prompts. Material says the operator runs such a proxy in front of Google’s sign-in page.

Material says SMS codes, authenticator codes, Google’s number-matching prompt and phone-based account recovery are all relayed to Google as they arrive. When the victim approves, the operator holds a live session. From there, Material says, the operator can reach Gmail and Drive and can grant OAuth access in the victim’s name.

That is why multi-factor authentication alone did not stop it. The code was correct and the victim typed it in. A second factor cannot tell the genuine Google from a relay of it. In general, a session is held by a session cookie; Material’s page does not describe the token mechanics, so that part is our general description.

Our mapping to ATT&CK is Spearphishing Link (T1566.002), Adversary-in-the-Middle (T1557), Steal Web Session Cookie (T1539) and Cloud Accounts (T1078.004). See our page on session hijacking for the wider pattern.

How Does an Invite Reach a Live Proxy?

Material lists the lure themes as voicemail notifications, RFP and RFI requests, court summonses and missed payment notices. Most links use Google’s own redirector, with the real destination in a query parameter. Other waves used share.google links and Google Drive file links, and one variant used Intuit transaction notification links.

The second layer is a Cloudflare Turnstile challenge, which Material says is in some builds the genuine widget. The third layer captures the password. Material says that page has no address a scanner could fetch, because a script builds it in the browser after the visitor clears the challenge.

The invites came from accounts the operator already controlled. In its Operation CloudFire post, dated 28 October 2026, Material counts 8,570 compromised sender addresses across 6,354 root domains. It says the operator then mailed each victim’s saved contacts, and that sends followed US business hours.

Why Did Every Reputation Check Say Clean?

Material argues that reputation controls answer a question about ownership: who registered a domain, what it has hosted and whether anyone has complained. It says the lure domains came back clean in every commercial reputation feed its team checked, through mid-September 2026. Our reading is that the campaign was built so each of those questions returned a reassuring answer.

The infrastructure was cheap and short-lived. Material reports nine lure domains across five registrars, most registered only days before use. Receiving endpoints were staged one to twenty days ahead of the wave they served, and one wildcard certificate was issued 46 minutes before the domain it covers was registered.

Material says the framework behind the pages has been documented publicly since February under the name Nyasher, after a key was left hardcoded in its JavaScript. In our reading, a public framework means the next operator does not need to write the code.

What Did Operation CloudFire Change?

Material says detection kept its customers safe but did nothing about the operator preparing the next wave. So its team studied the gateway and backend URLs used while messages were sent and reported them through Cloudflare’s abuse process. Cloudflare validated the fake interstitial and the proxied Google sign-in page behind it, and applied its own phishing warning to the destinations.

Material says these figures come only from customers who agreed to share data, so the true totals are higher. Every reported gateway had to be re-registered and re-certified before the operator could send again, and anyone who clicked a reported link, customer or not, saw a warning page.

Material says the campaign appears to have ended, but it does not call the threat over. The infrastructure is cheap to rebuild and the framework is public. The operator also left an unfinished Microsoft 365 branch, which Material says would need a file drop and no code changes to activate.

What Should Workspace Admins Check?

1. Inspect where Google-wrapped links lead. Search mail logs for Google redirector and share.google links whose destination parameter points to recently registered domains.
2. Read the login audit and Gmail logs, not only the mail filter. Look for a new device or IP shortly after a normal sign-in, then new OAuth grants, mail filters or forwarding rules.
3. Prepare to contain a hijacked session within about an hour: sign the user out, reset sign-in cookies, revoke OAuth tokens and app passwords, remove forwarding, then reset the password.
4. Move high-risk users to security keys or passkeys. They are bound to the real sign-in address, so a relay on a lookalike domain cannot complete them.
5. Review how external calendar invitations are added to calendars, and keep warnings on for unknown senders.
6. Report malicious destinations to the registrar and the hosting or CDN abuse desk. Our entry on phishing takedown explains the process.

Steps 1 to 3 follow the three questions Material puts to security teams, and the actions inside them are ours. Steps 4 to 6 are also our advice; Material’s posts do not make those recommendations. The same relay idea sits behind other kits, covered in our post on phishing-as-a-service that bypasses MFA.

What Is Still Open?

Material’s first post links a technical breakdown with indicators and a timeline, and a read-only list of the taken-down domains with registrar, registration date and role. We did not use either, so check them before you hunt. The first post counts nine lure domains and the second counts 897 domains taken down. Neither page explains the gap, so we do not try to reconcile the two figures.

What would change our view: a Google statement on the abuse of its redirector, or a Material update that names a Microsoft 365 variant in use. We will add either here once published.