Since mid-August 2026, a phishing operation has been harvesting live Google sessions from professional users. Each signal that defenders typically rely on to judge a link returned a reassuring response, and the operator deliberately constructed the chain that way.
Material Security’s threat research team identified the campaign and took down hundreds of domains used by the attackers in what they dubbed Operation CloudFire. Here’s what they learned along the way.
The appeal: Google Calendar invitations
The messages arrive as Google Calendar invitations, sometimes sent by BCC and often sent by an organization with which the recipient has previously corresponded. The pretexts are banal: voicemail notifications, RFP and RFI requests, court summons and missed payment notices.
Most of the links point to Google itself. The typical pattern is Google’s own redirector /url with the actual destination in a query parameter, although other waves have used share.google and Drive file links for the same purpose. A variation used Intuit transaction notification links.
In all cases, when the message is evaluated, the domain, certificate, and reputation displayed are legitimate and trustworthy.
The capture: reverse proxy in front of a Google login page
The attacker runs a live reverse proxy in front of the real Google login page. The victim enters a password, receives a real prompt and approves it, while the operator monitors the session in real time.
The server relays SMS codes, authentication codes, Google Tap-Yes number matching, and phone account recovery to Google as each arrives, so that none of the second-factor checks prevent the session from being captured.
The framework behind this, Nyasher, has been publicly documented since February, after a hardcoded key was found in its JavaScript.
Why commands don’t trigger
Reputation systems answer a question about ownership: who registered the domain, what else it hosted, and whether anyone has complained about it. This campaign has been designed so that these responses are consistently benign and has three levels.
The first layer is the Google redirector. The second is a Cloudflare Turnstile challenge, which in some versions is the actual widget served from Cloudflare’s own infrastructure. The third layer is the password capture page itself, which has no static websites to scan.
The Javascript builds it into the browser after the visitor completes the challenge, so a crawler has nothing to retrieve and a proxy log has nothing to record. To Material’s knowledge, no one had scanned these pages before the campaign was documented.
Infrastructure is disposable by design. The initially observed campaign used numerous decoy domains from multiple registrars, with most registered just days before use. Receiving endpoints were set up one to twenty days before the wave they served.
A wildcard certificate was issued 46 minutes before the domain it covers was registered. Blocking a single component costs the operator a few dollars and an afternoon of work.
Material automatically detects and remediates phishing, BEC, and targeted attacks, even after delivery.
No complex rules, no user quarantine, no endless manual sorting.
What his defense looks like
Material has followed the campaign from its beginning, tracking each variant as it rotates through lures, gates, and receiving points. Since August, once the campaign was identified and detections established, Material detected over 99% of malicious messages, with a reclassification rate of 0.01%.
This has been an ongoing effort as the attacker has modified their TTPs, themes, and lure text to evade static, ML, and agent detections.
This approach works because no single signal decides the outcome. Reputation alone would not have detected this, nor would link analysis, since the first hop is a Google URL and the final page does not exist until a browser constructs it.
The material notes technical indicators, the apparent intent of the message, where links actually resolve, and the sending relationship behind the message. Any one of them can be enough to take action.
A detection built around a signal inherits the blind spots of that signal, and this operator has put considerable effort into mapping them.
Where the analysis is run is also important. A calendar invitation is not suitable for a gateway designed to inspect mail in transit, but much of this campaign arrives as an invitation.
Material treats calendar invites as a threat surface in their own right and uses full account history as context alongside technical signals.
Where the damage lands
When the result is a hacked session rather than a stolen password, the evidence appears in Workspace audit logs. A live Google session reaches Email, Drive, and the ability to grant OAuth access on behalf of the victim, so the blast radius extends well beyond the inbox.
Advocates must ask themselves two questions: Who is reviewing these logs and how quickly can action be taken? Equally important is whether the team can revoke sessions, hold OAuth permissions, and reset the affected account within an hour.
Many programs can’t, and an attacker with a live session can do a lot of things in that time.
Operation CloudFire: Targeting Infrastructure
In late September, Material concluded that tweaking rules, retraining models, and updating agents wouldn’t solve the problem alone. Detection protects customers but does nothing for the operator who is preparing the next wave.
So Material’s threat research team launched Operation CloudFire to target the infrastructure itself.
The team analyzed gateway and backend URLs as messages were sent and reported them through Cloudflare’s abuse reporting system. Cloudflare’s anti-abuse team validated the fake interstitial and the proxy Google login page behind it, then applied its own phishing interstitial to these destinations.
This had two effects. The attacker’s infrastructure was destroyed: every reported gateway and receiving endpoint had to be re-registered, redirected, and recertified before the operator could send again. The wider Internet has also benefited.
Anyone who clicked on a flagged link, whether or not they were a Material customer, saw a warning rather than an identification form.
Figures over one month
These numbers only come from customers who have agreed to share data with Material, so the actual totals are higher. During a month of CloudFire operation, Material recorded:
- 68,676 campaign messages blocked
- 2,112 unique malicious URLs analyzed
- 897 unique domains deleted
- 8,570 unique sender addresses compromised across 6,354 root domains
- Shipping rate that followed business hours in the United States
The number of senders shows how the campaign gained credibility. Each compromised address belonged to an account that the attacker controlled before sending the first invitation, and each sent invitations to the victim’s saved contacts, among other addresses.
Recipients saw a name or domain they knew, on a domain with a clear history, at a plausible time. The reputation feeds had no reason to report anything, so each layer that evaluates ownership and history returned a reassuring result.
Where are things
Phishing themes have changed from calendar invitations to Google Drive file and document sharing invitations. Hardware has not seen a corresponding increase in other lures or TTPs, and activity in this group appears to have dispersed. The campaign seems to be over.
This is a status update, not a verdict. Rebuilding the infrastructure is inexpensive, the framework has been public since February, and the operator shipped an unfinished Microsoft 365 branch alongside live Google code.
The branch includes a stylesheet path, a second harness, and a title string that decodes to a Microsoft login prompt. None of these paths are resolved today, and adding the brand requires submitting a file rather than modifying a code.
The operator built tracking and did not enable it. Material views theme rotation as an iteration, not a retreat, and expects the next pivot to look a lot like this one with different branding.
The full technical breakdown, including indicators and a timeline, is available in the complementary white paper. Teams looking for this activity in their own environment should start there.
Sponsored and written by Material Security.
