Since mid-August 2026, a phishing operation has been harvesting live Google sessions from corporate users. The vendor Material Security identified it and calls its disruption effort Operation CloudFire. BleepingComputer published Material's account as sponsored content, with Material as author. Treat every statistic below as a Material claim.
What happened
The lures arrive as Google Calendar invitations. They are sometimes sent by BCC and often come from an organization the recipient has already dealt with. The pretexts are deliberately dull:
- Voicemail notifications
- RFP and RFI requests
- Court summonses
- Missed-payment notices
Most links point at Google itself, usually through its /url redirector with the real destination in a query parameter. Other waves used share.google and Drive file links. One variant used Intuit transaction-notification links. Nothing in the reporting says Google or Intuit were compromised. The attackers abused trusted domains, so the link scored as legitimate.
Why MFA didn't help
The attacker runs a live reverse proxy in front of the real Google sign-in page. According to Mezha's summary of Material's findings, victims enter passwords and approve real prompts while the operator watches in real time, and the server relays SMS codes, authenticator codes, Tap-Yes number matching and phone-based recovery to Google as they arrive.
"Bypasses MFA" is therefore a little loose. The second factor works as designed. The victim simply completes it on the attacker's behalf, and the attacker keeps the resulting session. Material says the underlying framework, Nyasher, has been documented publicly since February after a key was left hardcoded in its JavaScript.
Three layers that look clean
Material says reputation systems ask who owns a domain and what it has hosted, and this chain was built to answer those questions benignly:
- Google's redirector as the first hop.
- A Cloudflare Turnstile challenge, which in some builds is the genuine widget served from Cloudflare.
- A capture page built in the browser by JavaScript after the challenge is passed.
The third layer is the key problem. There is no static page for a crawler to fetch, and Material says a proxy log has nothing to record. Material also says that, to its knowledge, no one had scanned those pages before it documented the campaign. That claim is limited to Material's own knowledge.
The infrastructure is cheap and disposable:
- Lure domains were mostly registered days before use.
- Receiving endpoints were staged one to twenty days ahead of each wave.
- One wildcard certificate was issued 46 minutes before the domain it covers was registered.
- Material says blocking any single piece costs the operator only a few dollars and an afternoon.
Operation CloudFire
By late September, Material decided detection tuning wasn't enough. Its team analyzed gateway and backend URLs while messages were being sent and reported them through Cloudflare's abuse system. Per Material, Cloudflare's abuse team validated the fake interstitial and the proxied Google sign-in page, then applied its own phishing interstitial to those destinations. Anyone who clicked a reported link then saw a warning instead of a credential form, whether or not they were a Material customer. No separate Cloudflare statement was available, so this is Material's account of the collaboration.
Material reports these figures for one month, drawn only from customers who agreed to share data:
| Metric | Reported figure |
|---|---|
| Campaign messages blocked | 68,676 |
| Unique malicious URLs analyzed | 2,112 |
| Unique domains taken down | 897 |
| Compromised sender addresses | 8,570 |
| Root domains behind those senders | 6,354 |
Sending followed US business hours. Material says each compromised sender was an account the attacker already controlled, and each mailed the victim's saved contacts and other addresses. That explains why the invites often looked like they came from known parties, on domains with clean histories.
Material also claims it caught over 99% of the malicious messages once detections were built, with a 0.01% reclassification rate. The report doesn't define the denominator, the measurement period or what "reclassification" means. Treat these numbers as marketing-adjacent until independently validated.
The Microsoft 365 angle
Material says the operator shipped an unfinished Microsoft 365 branch alongside the live Google code. It includes a stylesheet path, a second harness and a title string that decodes to a Microsoft sign-in prompt. Material says none of those paths resolve today. It also says adding the brand takes a file drop and no code changes.
This is not evidence that Microsoft 365 accounts were attacked in this campaign. Material's expectation of a future pivot is a prediction, not an observed event. The fair reading is that session-relay phishing against Microsoft sign-in pages is a well-understood technique. This framework is reportedly one config change from supporting it. Material's own site markets protection for both Google Workspace and Microsoft 365.
Status
By its October 28 follow-up, Material said the lure theme had shifted from Calendar invites to Google Drive file and document-share invites. It saw no matching rise in other lures, and activity appeared to have dispersed. In its words, the campaign has seemingly ended. Material itself called that a status update, not a verdict, and said rebuilding infrastructure is cheap.
What administrators can do
The evidence supports layered preparation, not a single fix. These steps follow from the reported facts:
- Treat Calendar invites as an attack surface. Material's earlier guidance says default settings in both Microsoft 365 and Google Workspace can place calendar invites directly onto calendars, bypassing email filters. Review your tenant's settings for automatically adding invitations.
- Don't trust the visible domain. A Google or Intuit URL can still lead to an attacker's page through a redirect.
- Expect that a completed MFA prompt may not mean a safe session. Phishing-resistant methods, such as passkeys or hardware security keys, are generally recommended against real-time proxy attacks. That is general industry knowledge, not a claim from Material's research.
- Know where session evidence lands. Material says a hijacked session shows up in Workspace audit logs, not the mail filter. Decide who reads those logs and how fast.
- Rehearse containment. A live session reaches mail and Drive and can grant OAuth access in the victim's name. Material suggests asking whether your team can revoke sessions, contain OAuth grants and reset the account within an hour. That is Material's benchmark, not an industry standard.
- Watch for the pivot. Calendar and file-share invites styled as Microsoft sign-in prompts would be the natural next step. Review Entra sign-in and session logs with that in mind.
The bottom line
The core lesson holds regardless of the vendor angle. Reputation checks answer who owns a domain, not whether the page behind it is honest. A phishing chain built from Google, Cloudflare and just-in-time JavaScript can pass those checks cleanly. Material's numbers deserve skepticism because the company is promoting its own product. The technique is still plausible, and the same approach could be pointed at Microsoft sign-in pages.