Identity

Material Security says a phishing operation it calls Operation CloudFire has been stealing Google Workspace sessions since mid-August 2026. The lure is a Google Calendar invitation, often sent from the hacked mailbox of a vendor or client the target already deals with. The link leads to a reverse proxy, a server that sits between the victim and the real Google sign-in and passes everything through in real time, so passwords, SMS codes, authenticator codes and "Tap Yes" approvals all reach Google and the attacker keeps the signed-in session.

Any Workspace tenant whose users sign in with a password plus an SMS code, an authenticator app or a phone prompt is exposed; passkeys and security keys are what the kit cannot relay. On sourcing: the main BleepingComputer article is sponsored content written by Material Security, and every count in it is Material's own. We checked the mechanics against Material's research post, an earlier independent analysis of the kit by ZeroBEC, and Google's documentation.

How the attack works

Google can add invitations to the calendar automatically, so the lure shows up as a meeting with reminders even if the email is ignored. Material's lure themes were voicemail notices, requests for proposals, court summonses and missed payments, sometimes sent by BCC. In December 2025 Material also noted that an event can stay on the calendar after the email that delivered it has been reported and removed.

The link in the invite rarely points at the attacker directly. Material saw Google's own /url redirector, share.google short links, Google Drive file links and, in one variant, Intuit transaction notification links. Reputation filters see a trusted domain and let it through.

Next comes a Cloudflare Turnstile challenge, sometimes the genuine Cloudflare widget, which keeps automated scanners out. Only after it passes does the page's JavaScript assemble the fake sign-in screen in the browser. There is no fixed address that serves the credential page, so a crawler that fetches the link gets nothing worth flagging. ZeroBEC saw the same pattern in June: a first stage on a webflow.io subdomain, "press and hold" gates on workers.dev, and a Google sign-in page running from a blob: URL created in the browser.

The final stage relays the session live. The proxy submits the victim's password to Google, shows them Google's real second-factor prompt and forwards the answer, including number matching and phone-based account recovery. Google then issues the session cookie to the proxy, and the operator takes it. A code or a tap approves whichever browser is asking, and here that browser belongs to the attacker.

A passkey or FIDO2 security key behaves differently. The browser binds the signature to the domain the user is actually on, so a key used on a proxy domain produces nothing Google will accept for accounts.google.com.

What the attackers did and the kit behind it

Material ties the campaign to Nyasher, a reverse proxy phishing framework. Material says it has been publicly documented since February under that name, which comes from a key left hardcoded in its JavaScript. The earliest public write-up we found is ZeroBEC's on June 29, which names the key as _SuperBigNyasher47_ and dates samples to December 2025, February 2026 and June 2026. Sources differ on dates, but the kit predates this campaign.

ZeroBEC's decoded configuration shows WebSocket control traffic, per-victim tracking of browser and location details, and flags such as accessed_inbox and use_persistent.

Material's figures cover one month and only customers who agreed to share data:

• 68,676 campaign messages blocked
• 2,112 unique malicious URLs analysed
• 897 unique domains taken down, by reporting them through Cloudflare's abuse channel
• 8,570 compromised sender addresses across 6,354 root domains

Material counted nine lure domains across five registrars, mostly registered days before use, with receiving servers staged one to twenty days ahead of each wave. One wildcard certificate was issued 46 minutes before its domain was registered.

In an October 28 follow-up, Material said the lures had moved from Calendar invites to Google Drive file and document share invites, and that activity then seemed to disperse. Material also found an unfinished Microsoft 365 branch in the kit: a stylesheet path, a second harness and a title string that decodes to a Microsoft sign-in prompt. None of those paths resolve, so no Microsoft 365 attacks have been observed. A pivot to Microsoft is Material's prediction.

What to do in Google Workspace

1. Cap automatic Calendar additions. Since August 14, 2026, admins can set a ceiling on what users choose, not only a default. In the Admin console go to Menu, Apps, Google Workspace, Calendar, then Advanced settings, and set the least restrictive level to "Invitations users have responded to via email". "Invitations from known senders" does less here, because known means your domain, the user's contacts or anyone they have dealt with, and this campaign sent from hacked accounts of real partners. The control ships set to "From everyone", applies only to future invitations, can take up to 24 hours, and can be set per organizational unit, so start with finance and executives if the change worries the sales team.
2. Move high-value users to phishing-resistant sign-in. Under Security, Authentication, 2-step verification, turn on enforcement for an organizational unit and set the allowed methods to "Only security key", after checking in a test unit how that setting treats the passkeys your users already have. Do this first for admins, executives and anyone who approves payments, and review which keys are registered to those accounts.
3. Know what Device Bound Session Credentials (DBSC) covers. DBSC ties the Google session cookie to a key in the device's TPM, the laptop's security chip. Google made it generally available and on by default for Workspace in Chrome on Windows from May 25, 2026, with no admin switch. It defeats cookies copied off a user's laptop. A proxy that completes the sign-in itself is the device the cookie was issued to, so DBSC does not replace step 2. Where your edition supports it, context-aware access rules that only allow managed devices do block a session used from the operator's machine.
4. Hunt for proxied logins. Under Reporting, Audit and investigation, User log events, filter for login_success events and compare the IP address and the login_challenge_method parameter with the user's history. A password plus SMS or authenticator code from a hosting or Cloudflare address the user has never used deserves a look. Also check for "Suspicious login" and "User signed out due to suspicious session cookie" events. Through the Reports API, eventName=login_success&filters=is_suspicious==true gives a quick first list.
5. Contain a hit within the hour. Material's target is an hour from session theft to containment. Go to Directory, Users, open the user, then Security, Sign-in cookies, Reset (or call the Admin SDK users.signOut method). Then reset the password, review OAuth log events for new app grants, check the user's Gmail filters, forwarding and delegates, and delete the lure event from their calendar.

Filters cannot carry this alone

Every hop in this chain was a trusted service: a real partner's mailbox, a Google redirect, a Cloudflare challenge. Takedowns of 897 domains in a month did not stop the operator; it moved to Drive invites. Sign-in methods tied to the domain, and session rules tied to managed devices, still hold when the next lure gets through.

We test this kind of chain in safeguarding and hardening reviews of Workspace tenants, and watch for proxied sign-ins in security operations. If you want to know how your tenant would handle a Nyasher-style lure, open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: BleepingComputer (sponsored content by Material Security), Material Security research, Material Security on calendar invite attacks, ZeroBEC on Nyasher, CloudNews, WindowsForum, Mimikama, Google Workspace Updates, August 14, 2026, Google Admin Help: automatically add events, Google Workspace Updates on DBSC, Google Admin Help: suspicious session cookies, Google Admin Help: sign a user out, Google Cloud login audit samples.