Calendar Invite Phishing Can Relay Google Sign-Ins and Keep the Session

Material Security says a campaign running since mid-August 2026 used Google Calendar invites to send corporate users to a proxy of Google's sign-in page, capturing sessions even after MFA. The report is the only source for the campaign's details, but the relay technique and the defenses against it are established.

A calendar invite can lead to a fake Google sign-in page that passes every step of the real login back and forth in real time. According to security vendor Material Security, a campaign it calls "Operation CloudFire" has done exactly this to corporate Google users since mid-August 2026. The victim types a password, approves a genuine prompt and sees nothing wrong, while the operator watching the relay ends up holding the logged-in session that Google issues afterward.

The case matters because the victim does everything that standard security advice asks. The password is correct and the second factor is completed. The weakness lies in where the approval is given, not in the strength of the code. One caveat applies up front: nearly all detail on this campaign comes from Material Security itself, and the research behind this article found no Google statement on it, no independent confirmation, no victim counts and no peer-reviewed study. The general technique, by contrast, is documented by CISA and by Google's own Chrome team.

What Material Security reported, and how far the evidence goes

In its threat research, Material Security says the operator ran a live proxy in front of the real Google sign-in page. A victim who entered a password received a genuine prompt, approved it, and did so inside a session the operator could observe. The company says the server relayed SMS codes, authenticator codes, Google's Tap-Yes number matching and phone-based account recovery to Google as each arrived.

Material also says a captured Google session gives access to mail and Drive, and the ability to grant OAuth access in the victim's name. Its figures on the response include 897 domains taken down in about a month, which other coverage rounds to "nearly 900," and more than 68,000 messages blocked. Material says Cloudflare's abuse team validated the fake interstitial page and the proxied sign-in page, then applied its own phishing warning.

Those numbers have no denominator. There is no published total of invites sent, sessions stolen, victims or losses, so the 68,000 blocked messages should not be read as a count of people compromised. The claim that MFA was bypassed rests on Material's description of how the proxy was built, and no published incident-response case was found.

Press coverage largely repeats the vendor's account. Two outlets describe the BleepingComputer version as sponsored content from Material, so it is best treated as a copy of the vendor's claims rather than a second opinion. Material's report also attributes the activity to a phishing kit called "Nyasher." A secondary site says the kit has been documented publicly since February 2026, after a hardcoded key turned up in its JavaScript, but that detail is second-hand and unverified.

Partial corroboration exists. Paubox, a vendor blog summarizing a June 2026 Google scams advisory, reports that Google named "Calendar Phishing," including fake renewal notices added directly to Calendar and relay pages that capture passwords and session cookies. The original Google page was not retrieved, so that account is also secondhand. A separate vendor, Aegis AI, described a calendar campaign built on real compromised mailboxes. It installed a remote-management agent rather than stealing sessions, so it is related but not the same operation.

Why a calendar invite gets past email defenses

Material says the invites sometimes arrived by BCC and often appeared to come from an organization the recipient had dealt with before. As reported by Mezha, pretexts included voicemail notices, requests for proposals or information, court summonses and missed payments. A reader who expects such messages in a work inbox has little reason to treat one as unusual.

The links were the more telling feature. According to Material, as relayed by Mezha, most went through Google's own URL redirector, while others used share.google, Google Drive links or Intuit transaction-notification links. When the vendor scored those domains, their certificates and reputations looked legitimate. SC Media's summary of the report notes that domain-reputation tools alone fell short here because the links ran through trusted services.

Three layers between the click and the sign-in page

Material describes a chain of three steps. The first is Google's redirector, which lends the link a trusted address. The second is a Cloudflare Turnstile challenge, a check that looks routine to the visitor. The third is the password-capture page, which is where the proxy relays the login to Google.

The vendor also says calendar invites fit poorly with gateways that inspect mail in transit. It describes a later shift in lure themes from calendar invites toward Google Drive file and document-share invites. Aegis AI's separate campaign adds technical detail on why Calendar is attractive. Its invites passed DKIM authentication as google.com because Google Calendar itself generated them. Some created events automatically without a click and carried a genuine Google Meet link.

Where the invites came from is only partly settled

A CISO Series news summary says the CloudFire invites came from compromised Google Calendar accounts. Material's own material says they often came from organizations the recipient had corresponded with, which is not the same claim. Only the separate Aegis campaign explicitly documents compromised mailboxes. How the senders' accounts were obtained, whether through compromise, newly created accounts or spoofed identities, remains an open question.

How a live relay turns an ordinary MFA approval into a stolen session

Vendor explainers from Group-IB, Stingrai and Obsidian Security describe the pattern in consistent terms. A proxy relays the victim through the legitimate login flow, and tools such as Evilginx and Modlishka automate it. After MFA succeeds, the service issues a session token. The proxy copies the token, and the attacker replays it from their own machine.

The point is not confined to vendors. Google's Chrome team states in a 2024 blog post that cookie theft happens after login, so it bypasses two-factor authentication and login-time reputation checks. The session cookie is the proof of login a service hands out after a successful sign-in, and whoever holds it is treated as signed in. That explains why "MFA bypassed" is shorthand. The second factor works as designed, but it is satisfied on the wrong site, and the result is delivered to the wrong party.

Which kinds of MFA a live relay can pass along

What an attacker can do with a captured session

Material says a stolen Google session opens mail and Drive and lets the holder grant OAuth access, the mechanism by which third-party apps get permission to act on an account. Vendor sources add that OAuth grants can survive password resets and MFA changes, which is why cleanup has to look at them directly. A vendor explainer maps the techniques to MITRE ATT&CK entries: AiTM as T1557, session-cookie theft as T1539 and OAuth token abuse as T1528.

What actually stops a relay attack

CISA's guidance describes phishing-resistant MFA as the most secure form of multi-factor authentication. Its MFA page says FIDO/WebAuthn is the only widely available phishing-resistant authentication, and that the protocol blocks the attempt when a user is tricked into logging in to a fake site. The CISA fact sheet dates from October 2022, so it predates this campaign, and no 2026 CISA statement on calendar phishing was found.

The mechanism is origin binding. A passkey is tied to the genuine domain, so a proxy standing at a fake address never receives a usable credential for accounts.google.com, according to WorkOS explainers. The FIDO Alliance's PasskeyCentral page, which cites NIST guidance, frames phishing resistance as preventing authenticator outputs from reaching an impostor without depending on the user's vigilance. That last clause is the practical distinction: the protection does not rely on anyone noticing a suspicious address.

CISA treats number matching, the feature in which a user types a displayed number into a phone prompt, as an interim step for push-based MFA, and says it is "not as strong" as phishing-resistant MFA. That fits Material's claim that the CloudFire proxy relayed number matching. A secondary WorkOS blog reports that Google deployed security keys to more than 85,000 employees in 2018 with no successful phishing since, though the original source was not retrieved.

Limits of passkeys and security keys

Origin binding protects the sign-in step, not the session afterward. WorkOS notes that it does not stop OAuth consent phishing, where a user is tricked into approving an app, or malware already on the device. A WorkOS post citing an Apple statement adds that if SMS recovery or password-reset flows remain available, adding passkeys does not make a system phishing-resistant, because an attacker can steer the victim toward the weaker route. Some of the vendor wording on this topic is promotional, such as "structurally impossible," and should be read with that in mind.

Chrome's device-bound sessions: useful, but not shown to stop this attack

Device Bound Session Credentials (DBSC) became generally available in Chrome 146 on Windows, announced in April 2026, according to SecurityWeek, The Hacker News and other coverage. Chrome issues short-lived cookies only when the browser proves it holds a private key kept in hardware. Google reported a notable decline in session-theft events during a year of testing with partners including Okta. Coverage describes a rollout to Workspace customers, Workspace Individual subscribers and personal Google accounts, on by default for Workspace with admins unable to turn it off. Reports conflict on macOS: one says no timeline exists and another says support is coming in an upcoming release.

DBSC is framed by Google and the press as a defense against malware that steals cookies from a victim's device. No source reviewed shows that it stops a reverse proxy that obtains a session directly. One outlet lists DBSC among defenses Google is proposing for the CloudFire campaign, but that is not backed by any Google material retrieved. Whether DBSC binds sessions created through a relay is unresolved and would be settled by Google's documentation.

Calendar settings, habits and cleanup

Google Calendar's "Add invitations to my calendar" setting can be limited to "Only if the sender is known." Gadget Review reports that Google counts contacts, people in the same organization and people the user has interacted with as known. Workspace administrators gained a control to restrict which invitations are added automatically on August 14, 2026, according to one source, while another says only August 2026. Evidence that these settings reduce harm is thin: the sources are vendor and consumer-tech advice with no measured results, and a familiar sender can be a compromised account.

Several habits recur in the sources, with differing reliability:

• Avoid clicking links, scanning QR codes or calling phone numbers in suspicious events (Gadget Review).
• Confirm an unexpected invite with the supposed sender through a separate channel (CyberUnit).
• Be cautious with the "I know the sender" button. A vendor blog says clicking it on a phishing invite adds the attacker to the allowed senders, though this was not checked against Google documentation.
• Declining an invite may confirm that the address is active, according to Paubox.

If credentials were entered on a suspicious page

Vendor sources list revoking all active sessions as a first step and reviewing OAuth grants, since those can outlast a password change. A consumer-tech outlet advises changing the password through the official site and notifying the workplace IT team. A password change alone may not end an attacker's session, and Google's own help pages on ending sessions, OAuth access and recovery settings were not retrieved, so those pages are the authority to consult. This is context drawn from the research, not personal security advice.

A surge that cannot be measured yet

Several outlets describe calendar phishing as surging, but the figures do not hold together. Gadget Review cites a 33,000% rise in calendar-file phishing between May and September 2026 without naming the original source or baseline. CyberUnit attributes a 49% rise over six months to KnowBe4 Threat Labs, second-hand and with the report unretrieved. Aegis AI reports malicious invites up tenfold in a week, but that covers a single campaign seen by one vendor.

These numbers differ by orders of magnitude and measure different things, so none should be taken as an established trend. What can be said is narrower: calendar invites are a recognized delivery route, named in Google's reported June advisory and seen in at least two distinct campaigns.

What this means going forward

The CloudFire details are one company's account, and its infrastructure was reportedly cheap to rebuild. One summary says an unfinished Microsoft 365 branch was found, and another says attackers could pivot there, so the technique is not tied to Google. The lasting lesson comes from the better-documented mechanism: a second factor that a person can hand to the wrong site is only as strong as that person's attention.

The strongest defenses sit with those who set policy: requiring passkeys or security keys, removing weak fallback sign-in routes, restricting automatic invites and reviewing OAuth grants. What to watch next is Google's own account of the campaign, clarity on whether session binding reaches relayed logins, and independent measurement of how often these invites succeed.

Frequently asked questions

Can a Google Calendar invite steal a login even if MFA is turned on?

According to Material Security, yes, when the invite leads to a live proxy of Google's sign-in page. The victim completes MFA on the relay, and the attacker keeps the session Google then issues. The claim about this campaign comes from one vendor, but Google's Chrome team confirms that post-login cookie theft bypasses two-factor authentication.

Which kinds of MFA does a live relay phishing attack beat?

Material says its proxy relayed SMS codes, authenticator codes, Tap-Yes number matching and phone-based recovery. CISA calls number matching an interim measure that is not as strong as phishing-resistant MFA. Passkeys and security keys are bound to the real domain, so a proxy cannot relay them.

Do passkeys fully protect against calendar phishing?

They protect the sign-in step against relay phishing, according to CISA and vendor explainers. They do not stop OAuth consent phishing or malware on the device, and weak fallbacks such as SMS recovery can undermine them. Passkeys work best when required and when those fallbacks are removed.

Does the Google Calendar setting for known senders help?

Calendar can be set to add invitations only if the sender is known, and Workspace admins gained a control over automatic invites in August 2026. No measured results on effectiveness were found, and a familiar sender can be a compromised account.

What should someone do after entering a password on a suspicious Google page?

Vendor sources suggest revoking all sessions, reviewing OAuth grants and notifying IT, since a password change alone may not end an attacker's session. Google's own help pages on these steps were not retrieved, so they are the authority to check.

Sources

1. Reputation Says It's Fine: How Calendar Invites and a Live MFA Proxy Steal Google Sessions , Material Security
2. Google Calendar phishing campaign hijacks sessions, bypasses MFA , BleepingComputer (2026-11-04)
3. Blood bank fridge hacks, Anthropic identity, Calendar phishing (Cybersecurity News, Nov 5, 2026) , CISO Series (2026-11-05)
4. Operation CloudFire: phishing campaign targets corporate Google sessions , SC Media
5. Google Calendar phishing campaign hijacks sessions despite MFA , Mezha (2026-11-04)
6. False calendar invites deliver phishing links past email filters , Paubox (2026-11-02)
7. Google Calendar Phishing: The Invite That Installs an RMM Agent , Aegis AI
8. Calendar Invite Phishing Is Surging. Here's How to Spot It Before You Click. , Gadget Review
9. Google Calendar Phishing: How to Stop Fake Meeting Invites from Reaching Your Team , CyberUnit
10. Google Calendar Phishing Bypasses MFA on Workspace , CloudNews (2026-11-05)
11. Google Calendar Phishing Steals Workspace Sessions Despite MFA; Microsoft 365 Code Found , WindowsForum
12. Google Calendar phishing campaign hijacks sessions, bypasses MFA , Daily.dev (2026-11-04)
13. Phishing con Google Calendar que roba sesiones y salta la MFA , OpenSecurity.es
14. Implementing Phishing-Resistant MFA , CISA (2022-10-01)
15. CISA Releases Guidance on Phishing-Resistant and Numbers Matching Multifactor Authentication , CISA (2022-10-31)
16. More than a Password , CISA
17. Fighting cookie theft using device bound sessions , Google Chrome team (Google blog) (2024-04-01)
18. Google Rolls Out Cookie Theft Protections in Chrome , SecurityWeek
19. Google Rolls Out DBSC in Chrome 146 to Block Session Theft on Windows , The Hacker News (2026-04-01)
20. Google Chrome adds session cookie theft protection for all users , BleepingComputer
21. Google Chrome 146 Updates Device Bound Session Credentials to Stop Session Cookie Theft on Windows , gHacks Tech News (2026-04-10)
22. Google Locks Chrome Sessions to Devices to Stop Cookie Theft , GBHackers
23. Passkeys: The Journey to Prevent Phishing Attacks , FIDO Alliance (PasskeyCentral)
24. Passkeys stop phishing. Your MFA fallbacks undo it. , WorkOS
25. Cryptographic origin binding: How passkeys make phishing structurally impossible , WorkOS
26. AITM Phishing Attack: How It Works and How to Stop It , Group-IB
27. AitM Phishing: MFA Bypass Detection (2026) , Stingrai
28. Token-Based Attacks: How Attackers Bypass MFA , Obsidian Security