Calendar Invites and Live Proxies: Inside a Google Session Hijacking Campaign

The campaign, dubbed Operation CloudFire by Material Security, has been active since mid-August 2026. It targets corporate users by sending Google Calendar invites that appear to come from trusted contacts or organizations.

The lures are deliberately mundane, such as voicemail notifications, RFP requests, or court summonses, making them easy to overlook in a busy inbox. The messages use Google’s own redirector and other trusted services to mask the final destination.

Once a victim clicks the link, the attacker runs a live reverse proxy in front of the real Google sign-in page. The victim types their password and approves a second factor, all while the operator watches in real time.

The framework behind the attack, known as Nyasher, was publicly documented in February after researchers found a hardcoded key in its JavaScript. The operator has since updated it to bypass standard security controls.

The attack works in three layers to evade detection. The first is Google’s redirector, which provides a trusted URL. The second is a Cloudflare Turnstile challenge, and the third is a password capture page built dynamically in the browser.

This dynamic page means there is no static site for scanners to fetch and no proxy log to record. The infrastructure is also designed to be disposable, with domains registered just days before use and wildcard certificates issued minutes before the domain goes live.

Traditional reputation systems failed to flag the campaign because every answer they checked—ownership, certificate, and history—came back clean. The attacker controlled each compromised account before sending invites to the owner’s saved contacts.

A hijacked session grants the attacker access to mail, Drive, and the ability to grant OAuth access in the victim’s name. This blast radius goes well past the inbox and leaves a trail in Google Workspace audit logs.

Security teams face difficult questions about how quickly they can act on audit logs. An attacker holding a live session can do significant damage within an hour, yet many programs cannot revoke sessions or contain OAuth grants that fast.

Operation CloudFire takes down infrastructure

Material Security researchers decided that tuning detection rules alone would not stop the operator from prepping the next wave. Instead, they went after the infrastructure behind the campaign.

Analysts tracked the campaign from the start, following each variant as lures, gates, and endpoints rotated. Once detections were in place, they caught more than 99% of the malicious messages.

The team pulled gateway and backend URLs as messages were sent and reported them through Cloudflare’s abuse reporting system. Cloudflare confirmed the fake interstitial and the proxied Google sign-in page, then placed its own phishing warning in front of those destinations.

This action burned the attacker’s infrastructure, forcing them to re-register, re-point, and re-certify every endpoint before they could send again. It also protected people well beyond any single company’s customers.

Over one month of Operation CloudFire, researchers recorded 68,676 campaign messages blocked, 2,112 unique malicious URLs analyzed, and 897 unique domains taken down. They also identified 8,570 unique compromised sender addresses across 6,354 root domains.

The messages followed a clear rhythm, sending during US business hours. This timing, combined with the use of known contacts, helped the campaign earn trust and avoid triggering reputation filters.

Next steps and ongoing threat

The phishing themes have shifted from calendar invites to Google Drive file and document share invites. Researchers have not seen a matching jump in other lures or tactics, and activity from this group appears to have scattered.

The operator has already 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.

None of those paths resolve today, but adding the new brand would only require dropping in a file with no code changes. The follow-on is built and waiting for the next pivot.

The researchers see the theme rotation as ongoing iteration and expect the next pivot to look similar, just with a different brand. The full technical breakdown, including indicators of compromise and a timeline, is available in a companion whitepaper.