📅 Operation CloudFire: How Google Calendar Invites Were Used to Hijack Corporate Sessions and Bypass MFA

Material Security reported that the campaign had been active since mid-August 2026 and targeted corporate Google users. Invitations used ordinary business pretexts such as voicemail notifications, RFP/RFI requests, court summonses and missed-payment notices. Some invites were sent by BCC and often originated from organisations with which recipients had previously corresponded. The visible links commonly used Google’s own URL redirector, while other waves used share.google, Google Drive links or, in one variant, Intuit transaction-notification links.

The attacker placed a live reverse proxy between the victim and the genuine Google sign-in service. The victim interacted with a real Google login and completed real MFA prompts, while the proxy relayed the exchanges to Google in real time. This enabled the operator to obtain an authenticated session cookie/token. The result was session hijacking: the attacker could potentially access Google Workspace resources available to the victim without repeatedly asking for the password or MFA challenge.

Material’s October 28 Operation CloudFire update reported 68,676 campaign messages blocked, 2,112 unique malicious URLs analysed, 897 unique domains taken down, and 8,570 compromised sender addresses across 6,354 root domains during the reported measurement period. These figures came from participating customers and were stated to be lower than the likely total campaign volume.

• Compromised sender accounts created trust

Material observed 8,570 compromised sender addresses across 6,354 root domains. Those accounts were already controlled by the operator before the invites were sent. Invitations were sent to saved contacts and other recipients, making the sender identity and business relationship appear familiar.

• Calendar invites delivered the lure

The campaign used Google Calendar invitations, sometimes delivered using BCC. Themes included voicemail notifications, RFP/RFI requests, court summonses and missed-payment notices. Calendar invitations can be missed by controls designed primarily to inspect conventional email messages.

• A trusted link concealed the true destination

Many invite links began with Google’s own /url redirector, with the actual destination embedded in a query parameter. Other observed variants used share.google and Drive file links. Because the first visible hop belonged to Google, domain and certificate reputation could look legitimate at the time of initial scoring.

• Browser challenge and dynamically built phishing page

Some flows used a Cloudflare Turnstile challenge. Material reported that some builds used the genuine Cloudflare widget. After the visitor passed the challenge, JavaScript constructed the credential-capture page in the browser. The final phishing page therefore did not necessarily exist as a static page for conventional crawlers or proxy scanners to retrieve.

• Reverse proxy relayed the real Google authentication

The phishing service acted as a live reverse proxy in front of the genuine Google sign-in page. The victim entered credentials and received genuine authentication prompts. The attacker’s proxy relayed SMS codes, authenticator codes, Google Tap-Yes number matching and phone-based account-recovery steps to Google as they arrived.

• Authenticated session was captured

Once authentication completed, the attacker could capture the resulting live Google session. This is different from simply learning a password: the session can represent an already-authenticated user and may remain usable until it expires, is revoked or otherwise invalidated.

• Access could extend across Workspace

Material warned that a hijacked session could reach Gmail, Google Drive and the ability to grant OAuth access in the victim’s name. Depending on permissions and what the attacker did, this could support mailbox and file access, internal impersonation, further phishing and unauthorised third-party app access. The public reporting describes this potential blast radius; it does not quantify confirmed data theft for every compromised account.

Traditional MFA is highly valuable against password-only theft. However, a reverse-proxy phishing attack can place itself in the middle of a genuine login flow. The victim is not approving a fake MFA prompt: the attacker’s proxy forwards the victim’s real interaction to Google and relays the service’s real challenge back to the victim. When the session is established, the attacker may obtain the authenticated session material.

This does not mean MFA is useless or that every MFA method is equally vulnerable. It means that one-time codes and push approval alone may not protect against real-time adversary-in-the-middle phishing. Phishing-resistant authentication, especially FIDO2/WebAuthn security keys or passkeys bound to the legitimate origin, can substantially reduce this class of credential-relay attack.

Trusted first hop: a link may begin with a genuine Google URL redirector, so checking only the visible hostname can miss the final destination.

Reputation blind spot: the lure domain, certificate and first-hop service may appear legitimate, while the malicious destination is concealed or short-lived.

Dynamic page construction: the credential form may be generated in the browser after a challenge, leaving no static page for a crawler to scan.

Calendar delivery: invitations can bypass mail security workflows that focus on ordinary email body links and attachments.

Compromised senders: a familiar sender address and existing correspondence history can make a malicious invite appear contextually normal.

Session rather than password theft: conventional password reset workflows may be insufficient if an attacker still holds a valid session or OAuth grant.

A live Google session can give the attacker access to services and data permitted to the victim’s account. Material specifically identifies Gmail, Drive and OAuth grant capability as part of the potential blast radius. In practical terms, an attacker may be able to read or search mail, access shared files, impersonate the victim in internal communications, target contacts with further lures, or authorise an application to maintain access. The actual impact depends on the user’s permissions, session controls, OAuth policy and the attacker’s actions.

Do not assume every account involved suffered all these outcomes. The public campaign report documents the session-hijacking technique and potential access, but does not provide a per-victim inventory of files viewed, messages stolen or OAuth grants created.

February 2026 — the Nyasher framework was publicly documented after a hardcoded key was found in its JavaScript, according to Material.

Mid-August 2026 — Material dates the start of the observed Google session-hijacking campaign.

Late August to early September 2026 — the activity became recognisable as a broader campaign; lure domains were returning clean results in commercial reputation feeds.

Late September 2026 — Material decided that detection tuning alone was insufficient and launched Operation CloudFire to report gateway and backend infrastructure.

1 October 2026 — Material published its initial research describing Calendar invites and live MFA proxy session theft.

28 October 2026 — Material published its Operation CloudFire results: 897 domains taken down and the one-month campaign statistics.

4 November 2026 — BleepingComputer published a report summarising the campaign and its current status.

5 November 2026 — this public-awareness analysis was prepared from the supplied topic and the published reporting available at this date.

The sources reviewed identify the activity as an operation tracked by Material Security and name the phishing framework Nyasher. They do not provide a verified criminal group name, state sponsor, individual operator identity or country attribution. The compromised sender accounts and infrastructure rotation describe the campaign’s tradecraft, not the identity of the people behind it. This article therefore attributes the tracking and disruption work to Material Security and Cloudflare, but does not assign the attacks to a named threat actor.

By late September, Material concluded that improving detection rules and models would not stop the operator from preparing new waves. Its Threat Research team began analysing gateway and backend URLs while messages were being sent and reporting them through Cloudflare’s abuse process. Cloudflare validated the fake interstitial and proxied sign-in destinations and applied phishing warnings. This forced the operator to re-register, re-point and re-certify infrastructure and also displayed warnings to other internet users who followed reported links.

Material’s one-month figures were 68,676 campaign messages blocked, 2,112 unique malicious URLs analysed, 897 unique domains taken down, and 8,570 compromised sender addresses across 6,354 root domains. Material cautioned that the numbers reflected only customers who agreed to share data.

Material reported that the lure theme had shifted from Calendar invites to Google Drive file/document-share invitations and that activity from the observed group appeared to have dispersed. The campaign looked finished, but Material cautioned that this was not a final verdict: rebuilding infrastructure was inexpensive, the Nyasher framework was public, and an unfinished Microsoft 365 branch was present alongside the Google code. The existence of that branch is a warning of possible future adaptation, not evidence that a Microsoft 365 campaign was already active.

Treat unexpected calendar invitations as potential phishing, even when they appear from a familiar organisation or contact.

Do not rely only on the visible link text or first domain. Preview the final destination carefully; if the invite is unexpected, verify with the sender through a separate known channel.

Be cautious of invitations that create urgency around voicemail, legal notices, RFPs, missed payments or account documents.

Never enter Google credentials after following an unexpected invite link. Open Google services using a known bookmark or by typing the official address yourself.

Use phishing-resistant MFA such as passkeys or FIDO2 security keys where supported. SMS codes and push approvals can be relayed by real-time proxy phishing.

Do not approve an unexpected Tap-Yes prompt or account-recovery request. Stop and verify independently.

Report suspicious Calendar invites to your IT/security team and remove them only in accordance with organisational reporting procedures.

Inspect calendar invitations as a distinct threat surface, not just conventional email. Correlate invite content, sender identity, recipient relationship, link resolution and timing.

Analyse redirect chains to the final destination rather than trusting a Google-owned first-hop URL.

Use phishing-resistant authentication for high-risk accounts and administrators. Where possible, apply session-binding and device/context controls.

Monitor Google Workspace audit logs for unusual session activity, unfamiliar IPs/devices, mailbox access patterns, Drive access and unexpected OAuth grants.

Build a rapid response process to revoke sessions, remove suspicious OAuth grants, reset credentials, investigate mailbox rules and review Drive sharing.

Review compromised sender accounts and contact patterns; a trusted sender can itself be an attacker-controlled account.

Ensure incident responders can contain a suspected session compromise quickly. Material specifically recommends asking whether teams can revoke sessions, contain OAuth grants and reset affected accounts within an hour.

Train users that calendar invites, file-share notifications and trusted redirect domains can be used in phishing.

From a known-clean device, contact your IT/security team immediately. Do not continue using the suspicious link.

Ask the administrator to revoke active sessions and sign out the affected account across devices.

Reset the account password from the official Google account page and review recovery options. A password reset alone should not be treated as sufficient until sessions and tokens are also handled.

Review and revoke unfamiliar third-party app/OAuth access and investigate recent consent grants.

Review Gmail forwarding rules, filters, delegated access, sent mail and suspicious messages; review Drive sharing and recent file activity.

Check Workspace audit logs for unusual login/session, Gmail, Drive and OAuth activity. Preserve evidence and identify recipients of any follow-on phishing.

Notify contacts if the compromised account may have sent malicious invitations or messages.

Operation CloudFire shows how phishing has evolved beyond fake login pages and password theft. By combining familiar calendar invitations, compromised senders, trusted redirects, dynamically constructed pages and a live reverse proxy, attackers can capture an authenticated session even when a user completes conventional MFA. The most important defensive shift is to treat calendar invites and cloud sessions as part of the identity attack surface. Verify unexpected invitations, use phishing-resistant authentication, monitor Workspace audit activity and be ready to revoke sessions and OAuth access quickly.

BleepingComputer, Google Calendar phishing campaign hijacks sessions, bypasses MFA, 4 November 2026: https://www.bleepingcomputer.com/news/security/google-calendar-phishing-campaign-hijacks-sessions-bypasses-mfa/

Material Security Threat Research Team, Reputation Says It’s Fine: How Calendar Invites and a Live MFA Proxy Steal Google Sessions, 1 October 2026: https://material.security/resources/reputation-says-its-fine-how-calendar-invites-and-a-live-mfa-proxy-steal-google-sessions

Material Security, 897 Domains Later: How Operation CloudFire Burned the Calendar Invite Campaign, 28 October 2026: https://material.security/resources/897-domains-later-how-operation-cloudfire-burned-the-calendar-invite-campaign

Methodology note: This article is based on the supplied two-page input and the cited public reporting. Campaign statistics are attributed to Material Security and reflect its participating-customer telemetry, not a global census. No unverified actor attribution or victim-specific data theft claim is made.