Google Session Hijacking Campaign Exposes Sophisticated Phishing Tactics

68,676 campaign messages were blocked over one month of tracking — and that is just the slice of traffic organizations agreed to share.

The lure: Google Calendar invites that look ordinary

The operation began with innocuous calendar invites. Messages arrived by BCC or from organizations the recipient had legitimately exchanged email with, and the pretexts were deliberately mundane: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices. Most links routed through Google itself — typically Google’s /url redirector — with the real destination tucked into a query parameter. Other waves used share.google and Drive file links the same way, and one variant relied on Intuit transaction notification links. Because the visible domain, certificate, and reputation were legitimate, the lures blended into busy inboxes and into calendar UIs without obvious red flags.

The capture: a live reverse proxy and a public framework called Nyasher

When a victim clicked, the attacker placed a live reverse proxy in front of the genuine Google sign-in page. Victims entered passwords into pages that presented genuine prompts; the operator watched in real time and relayed each second factor back to Google as it was entered. The proxied flow accepted SMS codes, authenticator codes, Google’s Tap‑Yes number matching, and phone-based account recovery — none of which prevented the session from being captured. Material Security’s researchers identified the underlying framework as Nyasher, a codebase that has been publicly documented since February after a hardcoded key was found in its JavaScript.

How three-layer design and ephemerality kept defenders quiet

The campaign was engineered so the controls defenders commonly rely on returned harmless answers. It ran in three layers: first, a Google redirector provided a trusted initial URL; second, a Cloudflare Turnstile challenge gated access (in some builds the real widget was served from Cloudflare’s infrastructure); third, the credential capture page was built in-browser by JavaScript only after the challenge cleared. That meant crawlers had nothing to fetch and proxy logs had nothing to record. Infrastructure was ephemeral: lure domains were often registered days before use, receiving endpoints went live one to twenty days ahead of a wave, and one wildcard certificate was issued 46 minutes before the domain it covered was registered. Taken together, those design choices turned reputation signals, static scanners, and link analysis into poor single points of decision.

Operation CloudFire: takedowns, protections, and one-month metrics

Material Security’s Threat Research team tracked the campaign and launched what it calls Operation CloudFire, pulling gateway and backend URLs while messages were still being sent and reporting them through Cloudflare’s abuse reporting system. Cloudflare’s abuse team confirmed the fake interstitials and proxied Google sign-in pages and placed its own phishing warning in front of those destinations. That response had two effects: the attacker’s infrastructure burned — forcing re-registration, re-pointing, and re-certification — and anyone who clicked a reported link saw a warning page instead of the credential form.

• 68,676 campaign messages blocked (sample of agreeing organizations)
• 2,112 unique malicious URLs analyzed
• 897 unique domains taken down
• 8,570 unique compromised sender addresses across 6,354 root domains
• Detections caught more than 99% of malicious messages after rules and signals were in place, with a reclassification rate of 0.01%

The researchers also noted the sends tracked U.S. business hours and that the attacker used compromised accounts to invite the victim’s saved contacts, reinforcing trust.

What this means for technologists, affected enterprises, and end users

• Technologists and security teams: detection must combine signals — technical indicators, apparent intent, where links actually resolve, and the sending relationship — because reputation and link analysis alone were insufficient. Gateways built to inspect mail in transit are a poor fit for calendar invites; calendar invites and invites to Drive need to be treated as a distinct threat surface with account history used as context.
• Affected enterprises and procurement leaders: the blast radius of a hijacked session extends beyond the inbox into mail, Drive, and the ability to grant OAuth access. The researchers ask hard operational questions: who is reviewing Google Workspace audit logs, and can teams revoke sessions, contain OAuth grants, and reset affected accounts within an hour? Many programs cannot.
• End users and the general public: the campaign’s social engineering relied on trusted senders, sensible times of day, and unremarkable subject matter. Researchers observed the campaign pivoting from calendar invites to Google Drive file and document share invites; that shift is the nearest visible change right now.

For now the activity looks finished, the researchers said, but the framework has been public since February and the operator shipped an unfinished Microsoft 365 branch alongside the live Google code — a stylesheet path and a title string that decodes to a Microsoft sign‑in prompt, though none of those paths resolve today. Rebuilding infrastructure is cheap, and the follow‑on is waiting; whether defenders can keep detection holistic and act quickly on audit logs will determine how far the next wave can reach.

Original reporting