Material detected a session-hijacking campaign that uses Google Calendar invites. Read the research.
TL;DR: A session-hijacking campaign has run against Google Workspace since mid-August. As of mid-September, the reputation feeds still scored it clean. Material detected it, helped our customers stop it, and helped take down portions of its infrastructure. This is a summary of what we’ve seen.
Since mid-August 2026, a phishing operation has been stealing live Google sessions from corporate users. Through mid-September, the lure domains carrying it came back clean in every commercial reputation feed Material's threat research team checked. Material is no stranger to calendar-based attacks, but this new attack methodology is especially insidious because of its use of Google’s own infrastructure.
The attacker runs a live proxy in front of the real Google sign-in page, so the victim enters a password, receives a genuine prompt, and approves it, all inside a session the operator is watching. SMS codes, authenticator codes, Google's Tap-Yes number match, and phone-based account recovery are all handled, because the server relays each one to Google as it arrives.
How it arrives
The lure comes as a calendar invite, sometimes delivered by BCC, often from an organization the recipient has corresponded with before. The themes are deliberately dull: voicemail notifications, RFP and RFI requests, court summonses, missed payment notices.
The links inside are almost all legitimately Google. It is Google's own /url redirector, with the real destination tucked into a query parameter. Other waves used share.google and Drive file links for the same purpose. We did see one variant that used Intuit transaction notification links, but in all cases, at the moment a message gets scored, the domain, the certificate, and the reputation on display are legitimate and trusted.
The framework behind all this has been documented publicly since February under the name Nyasher, after a key left hardcoded in its JavaScript.
.png)
Why nothing flags it
Reputation controls answer a question about ownership. Who registered this domain, what else has it hosted, has anyone complained about it. This campaign was assembled so that all those questions consistently returned reassuring answers.
The first layer is Google, and the second is a Cloudflare Turnstile challenge, in some builds the genuine widget served from Cloudflare itself. The third layer, the page that captures the password, has no address to scan at all. It is built-in memory by script after a visitor clears the challenge, which leaves nothing for a crawler to fetch and nothing to turn up in a proxy log. To Material's knowledge those pages have never been scanned by anyone. That is how they were designed to work.
The infrastructure is bought to be thrown away. Nine lure domains across five registrars, most registered days before use, with receiving endpoints staged one to twenty days ahead of the wave they serve. One wildcard certificate was issued 46 minutes before the domain it covers was even registered. Blocking any single piece of this costs the operator a few dollars and an afternoon.
What tracking it has looked like
Material has monitored the campaign since it began and follows each new variant as lures, gates, and receiving endpoints rotate. Since August 2026, as soon as we learn about a new campaign and develop detections against it Material catches over 99% of the malicious messages in that campaign, with a reclassification rate of 0.01%. But because this single cover is over multiple campaigns we expect more to come.
That holds because no single signal carries the decision. Reputation was never going to catch this. Link analysis on its own would not have either, when the first hop is a Google URL and the final page does not exist until a browser builds it. Material scores technical indicators, the intent of the message, where links resolve, and the sending relationship behind them. A hit on any one of those is enough to act on. Detection built around a single signal inherits that signal's blind spots, and this operator has spent months finding them.
Where the analysis happens matters too. A calendar invite is a poor fit for a gateway built to inspect mail in transit, and much of this campaign arrives as an invite. Material treats calendar invites as a threat surface of their own, with the account's full history available as context.
Three questions for your team
- When a phishing link arrives wrapped in a Google URL, what in the stack examines where it leads?
- When the outcome is a hijacked session rather than a stolen password, the evidence lands in Workspace logs instead of the mail filter. Who is reading those, and how quickly?
- A live Google session reaches mail, Drive, and the ability to grant OAuth access in the victim's name. How much of that blast radius can your team close inside an hour?
The next campaign is already written
Shipped alongside the live Google code is an unfinished Microsoft 365 branch: a stylesheet path, a second harness, and a title string that decodes to a Microsoft sign-in prompt. None of those paths resolve today. Adding the brand takes a file drop and no code changes. The operator has already built the follow-on and has not switched it on yet. Material expects that pivot and is watching for it.
The full technical breakdown, including indicators and a timeline, is available here for teams that want to hunt for this in their own environment. Material will continue to update this list as we discover more.