Calendar

Since mid-August 2026, a phishing operation has been harvesting live Google sessions from corporate users. Every signal defenders usually rely on to judge a link returned a reassuring answer, and the operator built the chain that way on purpose.

Material Security’s Threat Research team identified the campaign and has taken down hundreds of domains used by attackers in what they have dubbed Operation CloudFire. Here’s what they learned along the way.

The lure: Google Calendar invites

The messages arrive as Google Calendar invites, sometimes delivered by BCC and often sent from an organization the recipient has already corresponded with. The pretexts are mundane: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices.

Most links point to Google itself. The typical pattern is Google’s own /url redirector with the real destination in a query parameter, though other waves used share.google and Drive file links for the same purpose. One variant used Intuit transaction notification links.

In every case, when the message is scored, the domain, certificate, and reputation displayed are legitimate and trusted.

The capture: Reverse proxy in front of a Google sign-in page

The attacker runs a live reverse proxy in front of the genuine Google sign-in page. The victim enters a password, receives a real prompt, and approves it, all while the operator watches the session in real time.

The server relays SMS codes, authenticator codes, Google’s Tap-Yes number matching, and phone-based account recovery to Google as each one arrives, so none of the second-factor controls stop the session from being captured.

The framework behind this, Nyasher, has been documented publicly since February, after a hardcoded key was found in its JavaScript.

Attack flow

Why the controls don’t fire

Reputation systems answer a question about ownership: who registered the domain, what else it has hosted, and whether anyone has complained about it. This campaign was assembled so that those answers were consistently benign, and it has three layers.

The first layer is Google’s redirector. The second is a Cloudflare Turnstile challenge, which in some builds is the genuine widget served from Cloudflare’s own infrastructure. The third layer is the password-capture page itself, which has no static website to scan.

The Javascript constructs it in the browser after the visitor clears the challenge, so a crawler has nothing to fetch and a proxy log has nothing to record. To Material’s knowledge, no one had scanned those pages before the campaign was documented.

The infrastructure is disposable by design. The initially observed campaign used many lure domains across multiple registrars, most registered only days before use. Receiving endpoints were staged one to twenty days ahead of the wave they served.

One wildcard certificate was issued 46 minutes before the domain it covers was registered. Blocking any single component costs the operator a few dollars and an afternoon of work.

What defending it has looked like

Material has tracked the campaign since its start, following each variant as lures, gates, and receiving endpoints rotated. Since August, once the campaign was identified and detections built, Material has caught over 99% of the malicious messages, with a reclassification rate of 0.01%.

This has been a continuous effort as the attacker shifted their TTP’s, themes and lure text to evade static, ML and agentic detections.

The approach works because no single signal decides the outcome. Reputation alone would not have caught this, and neither would link analysis by itself, since the first hop is a Google URL and the final page doesn’t exist until a browser constructs it.

Material scores technical indicators, the apparent intent of the message, where links actually resolve, and the sending relationship behind the message. Any one of those can be enough to act on.

A detection built around one signal inherits that signal’s blind spots, and this operator has spent considerable effort mapping them.

Where the analysis runs also matters. A calendar invite is a poor fit for a gateway designed to inspect mail in transit, yet much of this campaign arrives as an invite.

Material treats calendar invites as a threat surface in their own right and uses the account’s full history as context alongside the technical signals.

Where the damage lands

When the outcome is a hijacked session rather than a stolen password, the evidence appears in Workspace audit logs. A live Google session reaches mail, Drive, and the ability to grant OAuth access in the victim’s name, so the blast radius extends well past the inbox.

Defenders should ask two questions: who is reviewing those logs, and how quickly can they be acted on? Equally important is whether the team can revoke sessions, contain OAuth grants, and reset the affected account within an hour.

Many programs cannot, and an attacker with a live session can do a great deal in that time.

Operation CloudFire: Targeting the infrastructure

By late September, Material concluded that tuning rules, retraining models, and updating agents would not solve the problem alone. Detection protects customers but does nothing about the operator who is preparing the next wave.

Material’s Threat Research team therefore launched Operation CloudFire to target the infrastructure itself.

The team analyzed the gateway and backend URLs as the messages were being sent and reported them through Cloudflare’s abuse reporting system. Cloudflare’s abuse team validated the fake interstitial and the proxied Google sign-in page behind it, then applied its own phishing interstitial to those destinations.

This had two effects. The attacker’s infrastructure was burned: each reported gateway and receiving endpoint had to be re-registered, re-pointed, and re-certified before the operator could send again. The broader internet also benefited.

Anyone who clicked a reported link, whether or not they were a Material customer, saw a warning rather than a credential form.

The numbers over one month

These figures come only from customers who agreed to share data with Material, so the true totals are higher. Over a month of Operation CloudFire, Material recorded:

  • 68,676 campaign messages blocked
  • 2,112 unique malicious URLs analyzed
  • 897 unique domains taken down
  • 8,570 unique compromised sender addresses across 6,354 root domains
  • Send cadence that followed US business hours
Message delivery time of day heat map
Message delivery time of day heat map

The sender count shows how the campaign achieved its credibility. Each compromised address belonged to an account the attacker controlled before the first invite went out, and each one sent invites to the victim’s saved contacts, among other addresses.

Recipients saw a name or domain they knew, on a domain with a clean history, at a plausible time. Reputation feeds had no reason to flag any of it, so every layer that scores ownership and history returned a reassuring result.

Where things stand

The phishing themes have shifted, from calendar invites to Google Drive file and document share invites. Material has not seen a matching rise in other lures or TTPs, and activity from this group appears to have dispersed. The campaign looks finished.

Messages detected by week
Messages detected by week

Domains registered by interval
Domains registered by interval

That is a status update, not a verdict. Rebuilding the infrastructure is cheap, the framework has been public since February, and the operator shipped an unfinished Microsoft 365 branch alongside the live Google code.

The branch includes a stylesheet path, a second harness, and a title string that decodes to a Microsoft sign-in prompt. None of those paths resolve today, and adding the brand requires dropping in a file rather than changing any code.

The operator has built the follow-on and has not activated it. Material reads the theme rotation as iteration, not retirement, and expects the next pivot to look much like this one with a different brand.

The full technical breakdown, including indicators and a timeline, is available in the companion whitepaper. Teams hunting for this activity in their own environments should start there.

Sponsored and written by Material Security.