A Google session hijacking campaign delivered through calendar invites stole live logins from corporate users, and every trust signal defenders check came back clean.
The Threat Research team at Material Security documented the operation and has been tracking it since mid-August 2026. Their findings, published at The Hacker News, describe a phishing campaign that defeated reputation checks, multi-factor authentication, and static link analysis all at once. If your organization runs Google Workspace, exchanges email with other businesses, or relies on MFA as your primary control against account takeover, this campaign deserves your attention. That includes healthcare organizations, defense contractors, and anyone handling regulated data in the cloud.
Key Takeaways
- Since mid-August 2026, attackers have used Google Calendar invites, and later Drive share invites, to deliver links that lead through a reverse proxy capturing live Google sessions, including MFA prompts.
- Every link in the campaign pointed to legitimate infrastructure: Google's own /url redirector, share.google, Drive links, and in one variant Intuit transaction notification links, so domain reputation and certificate checks saw nothing suspicious.
- The capture page did not exist as a static site. JavaScript built it in the browser after a Cloudflare Turnstile challenge, leaving crawlers and proxy logs with nothing to scan.
- Material Security's Operation CloudFire reported attacker gateways and backends through Cloudflare's abuse system, burning infrastructure and forcing the operator to rebuild before each new wave.
- Over one month, researchers recorded 8,570 unique compromised sender addresses across 6,354 root domains among organizations that agreed to share data, so the real totals are higher.
What Happened: The Facts in Detail
The campaign and who found it
Material Security's Threat Research team identified a phishing operation running since mid-August 2026 that steals live Google sessions from corporate users. The team has taken down hundreds of attacker domains in an effort they call Operation CloudFire. The campaign appears to have wound down: phishing themes 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 the group seems to have scattered. The researchers treat that as a snapshot that could change fast, because rebuilding the infrastructure is cheap and the underlying framework has been public since February.
How the messages arrived
The phishing messages appeared as Google Calendar invites. Some arrived by BCC, and many came from an organization the recipient had already traded email with. The pretexts were deliberately unremarkable: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices. Nothing about them stood out in a busy inbox.
The trust behind those senders was earned, not spoofed. The attacker controlled each compromised account before the first invite went out, and each account sent invites to the owner's saved contacts, among others. Recipients saw a name or domain they knew, on a domain with a clean history, at a sensible time of day. Sends tracked US business hours. Reputation feeds had no reason to flag any of it.
Why every link looked legitimate
Most links pointed to Google itself. The usual pattern ran through Google's own /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 leaned on Intuit transaction notification links. Whenever a message got scored, the domain, certificate, and reputation on display were all legitimate.
The capture: a reverse proxy in front of Google sign-in
Once a victim clicked through, the attacker ran a live reverse proxy in front of the real Google sign-in page. The victim typed a password, received a genuine prompt, and approved it while the operator watched in real time. The server passed each second factor along to Google as it arrived, whether that was an SMS code, an authenticator code, Google's Tap-Yes number matching, or phone-based account recovery. None of those controls stopped the session from being captured.
The framework behind the operation, known as Nyasher, has been publicly documented since February, after researchers found a hardcoded key in its JavaScript.
Three layers built to defeat scanning
The researchers describe the design as working in three layers. The first is Google's redirector, which gives the initial hop a trusted Google URL. The second is a Cloudflare Turnstile challenge, and in some builds it is the real widget served from Cloudflare's own infrastructure. The third is the password capture page, and that is where defenders run into a wall: there is no static site to scan. JavaScript builds the page in the browser after the visitor clears the challenge, so a crawler has nothing to fetch and a proxy log has nothing to record. As far as the researchers know, nobody had scanned those pages before the campaign was documented.
Infrastructure designed to be disposable
The infrastructure was meant to be thrown away. Early waves used many lure domains spread across several registrars, and most were registered just days before use. Receiving endpoints went live one to twenty days ahead of the wave they served. One wildcard certificate was issued 46 minutes before the domain it covers was even registered. Blocking any single piece costs the operator a few dollars and an afternoon.
Detection and takedown
Material Security 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, with a reclassification rate of 0.01%. The attacker kept changing tactics, themes, and lure text to slip past static, machine learning, and agentic detections, so it was steady work.
By late September, the team concluded that tuning rules, retraining models, and updating agents would not solve the problem alone. Detection protects customers, but it does nothing about an operator already prepping the next wave. So they went after the infrastructure. Analysts pulled the gateway and backend URLs as messages were being sent and reported them through Cloudflare's abuse reporting system. Cloudflare's abuse team confirmed the fake interstitial and the proxied Google sign-in page behind it, then put its own phishing warning in front of those destinations.
That had two effects. The attacker's infrastructure got burned: every reported gateway and endpoint had to be re-registered, re-pointed, and re-certified before the operator could send again. And the protection extended well beyond any one company's customers, because anyone who clicked a reported link saw a warning page instead of a credential form.
The scale, with a caveat
The figures below only cover organizations that agreed to share data, so the real totals are higher. Over one month of Operation CloudFire, researchers recorded 8,570 unique compromised sender addresses across 6,354 root domains.
What may come next
The operator 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, and adding the new brand would only mean dropping in a file, with no code changes. The researchers see the theme rotation as ongoing iteration and expect the next pivot to look a lot like this one, just with a different brand on it. The full technical breakdown, including indicators of compromise and a timeline, is in the companion whitepaper, and teams hunting for this activity in their own environments should start there.
How Google Session Hijacking Works, and Why It Matters Technically
The phrase "Google session hijacking" describes what this campaign actually steals: not a password the attacker stores for later, but a live, authenticated session they can use immediately. The distinction matters for how you think about your controls.
A reverse proxy attack sits between the victim and the real service. The victim believes they are signing in to Google, and in a sense they are: the proxy relays everything to the genuine sign-in page and relays Google's responses back. Because the second factor is forwarded in real time, the attacker does not need to defeat MFA. They simply ride through it. By the time the victim lands on a normal-looking page, the operator holds a working session.
This is why the usual advice, "check the URL before you enter your password," fails here. The first hop is a genuine Google URL. The capture page is assembled in the browser after a challenge clears, so there is no suspicious domain visible at the moment of entry and no static page for a scanner to inspect. Reputation systems answer questions about who registered a domain, what else it has hosted, and whether anyone has complained. This campaign was built so every one of those answers came back harmless.
The blast radius of a captured session extends well past the inbox. A live session reaches mail, Drive, and the ability to grant OAuth access in the victim's name. That means an attacker can read correspondence, reach files, and authorize third-party applications while appearing to be the legitimate user. For a regulated business, that turns one clicked invite into a potential data exposure event, and it leaves its trail in Google Workspace audit logs.
It also explains why the campaign chose calendar invites as the delivery vehicle. Gateways built to inspect mail in transit are not a great fit for calendar invites, and much of this campaign arrived as invites. Material Security's conclusion is that calendar invites need to be treated as a threat surface of their own, with the account's full history used as context alongside technical signals. Their detection approach weighs technical indicators together with the apparent intent of the message, where its links actually end up, and the sending relationship behind it. Any one of those can be enough to act on. A detection built around a single signal inherits that signal's blind spots, and this operator put real effort into mapping them.
Organizations running Google Workspace alongside Microsoft 365 should note that the framework is brand-agnostic by design. The Microsoft 365 branch of Nyasher is built and waiting, and the researchers expect the next pivot to mirror this one under a different brand. Our related coverage of Google Cloud penetration testing rules and best practices and Google Workspace HIPAA compliance for Gmail, Chat, Drive and Meet covers the broader configuration questions this raises for regulated tenants.
What the Evidence Does and Does Not Show
The reporting is detailed, but it has boundaries worth respecting.
The scale figures are partial. The 8,570 compromised sender addresses and 6,354 root domains cover only organizations that agreed to share data with Material Security. The researchers state plainly that the real totals are higher, but by how much is not known.
The campaign's status is a snapshot, not a conclusion. Activity from the group seems to have scattered, and the campaign looks finished for now. The researchers themselves flag that this could change fast: rebuilding the infrastructure is cheap, the Nyasher framework has been public since February, and a Microsoft 365 variant is built and waiting even though none of its paths resolve today.
Attribution is not addressed. The sources describe the operator's tactics, infrastructure, and rhythm, but they do not identify who is behind the campaign. Nothing in the reporting establishes a motive beyond the observable behavior.
The victim population is described only qualitatively. The sources say the targets were corporate users and that compromised accounts sent invites to their saved contacts, but they do not break down victims by industry, size, or geography. Regulated businesses should not assume they were or were not targeted.
Some defensive details are unknown. The researchers note that, as far as they know, nobody had scanned the dynamically built capture pages before the campaign was documented. How many victims clicked, how many sessions were fully exploited after capture, and what attackers did with the access are not stated in the sources.
The takedown is real but reversible. Cloudflare confirmed the fake interstitial and proxied sign-in page and placed warnings in front of reported destinations. Hundreds of domains were taken down. But the economics favor the attacker: blocking any single piece costs the operator a few dollars and an afternoon, and the researchers expect continued iteration.
What the evidence does show clearly is the mechanics: a repeatable technique that turns trusted platforms, real MFA prompts, and clean reputations into an account takeover, documented by a research team that measured its own detections catching more than 99% of malicious messages once tuned. Part two of this analysis covers what this means for regulated businesses specifically, and the concrete steps security teams should evaluate, from audit log review to session revocation readiness.
Why Session Hijacking Is a Compliance Problem, Not Just a Security Problem
For a regulated business, the question is never only "did an attacker get in?" It is "what obligations were triggered the moment they did?" A live Google session is not a failed login attempt that a filter blocked. It is authenticated access to mail, Drive, and the ability to grant OAuth access in the victim's name. If that account touches protected health information, controlled unclassified information, or cardholder data, the compromise is a reportable and auditable event, not an inbox nuisance.
Consider what a hijacked session means under the frameworks most readers of this article answer to. HIPAA's Security Rule at 45 CFR Part 164 requires a risk analysis under 45 CFR 164.308(a)(1)(ii)(A) and administrative, physical, and technical safeguards across 18 standards. A session captured through a reverse proxy is exactly the kind of reasonably anticipated threat that analysis is supposed to address, and the Breach Notification Rule at 45 CFR 164.404, 164.406, and 164.408 governs what happens next if ePHI was exposed. For defense contractors, NIST SP 800-171's Incident Response family requires an operational incident handling capability, and DFARS 252.204-7012 requires reporting a cyber incident affecting covered defense information to DoD within 72 hours of discovery via dibnet.dod.mil. Neither requirement is satisfied by discovering the compromise three weeks later in an audit log nobody was reading.
The deeper compliance issue is the one Material Security's researchers put their finger on: every signal defenders normally document came back clean. The first hop was a Google URL. The certificate was legitimate. The sending domain belonged to a real organization the recipient had traded email with. A control program built entirely on link reputation and user vigilance has a documented blind spot here, and an assessor or auditor will eventually ask how your program accounts for threats that defeat those signals. That is a question about your risk analysis, not your spam filter.
There is also an evidentiary problem. Google Workspace audit logs carry the trail of a hijacked session, but logs only satisfy auditors if someone reviews them and can act quickly. NIST SP 800-171 requires that incidents be tracked, documented, and reported; a timely external report with no internal process still fails the requirement. The researchers' own framing is the right test: could your team revoke sessions, contain OAuth grants, and reset the affected account within an hour? An attacker holding a live session can do a great deal in an hour.
What This Means for Regulated Industries
Defense Contractors and the Defense Industrial Base
The mechanics of this campaign matter enormously for contractors handling CUI. A compromised Google Workspace session in an engineering or program office can reach mail and Drive, which is often where CUI lives in practice, and can grant OAuth access that persists after the session itself is revoked. If covered defense information was in that mailbox, DFARS 252.204-7012's 72-hour reporting clock starts at discovery, which means discovery has to be fast. Contractors should also remember that the SPRS self-assessment score under DFARS 252.204-7019 is supposed to reflect reality; an environment where calendar invites are an unmonitored threat surface is not the environment the score describes. The DoD CIO suspended the 2026-11-10 Phase II deadline on 2026-07-13, but Phase I self-assessments remain in force, and the underlying safeguarding obligations did not pause with the milestones.
Healthcare
Healthcare organizations live in Google Workspace and Microsoft 365 all day, and the pretexts in this campaign, voicemail notifications and missed payment notices, are precisely the messages that get opened in a busy practice. A captured session that reaches mail and Drive may expose ePHI, which triggers the Breach Notification Rule and HHS OCR scrutiny. The enforcement environment is not theoretical: HHS OCR has recently imposed penalties including $3M against Solara in January 2025, a $548,265 civil money penalty against Children's Hospital Colorado in December 2024 where MFA had been disabled, and an April 2026 ransomware sweep totaling $1.165M. Note what that Colorado penalty tells you: having MFA was not enough, because the surrounding program has to work. In this campaign, MFA did work as designed and the session was still captured. HIPAA-regulated entities should align their documentation to NIST SP 800-66 Rev 2 and treat calendar and Drive share invites as a threat surface requiring active detection, not just user training.
Legal
Law firms were not named in the reporting, but the campaign's pretexts included court summonses and RFP and RFI requests, and the sender pattern, compromised accounts mailing their saved contacts, maps directly onto how firms exchange email with clients, courts, and opposing counsel. A hijacked firm mailbox exposes privileged communications and client confidences, and the attacker can send convincing follow-on lures from a trusted address. Firms should assume that a client's compromise can arrive as an invite from the client's own account, and that no amount of caution about "strange links" will catch a first hop that reads as Google.
Financial Services
Missed payment notices were among the lures, and Intuit transaction notification links appeared in one wave, which is a natural fit for accounting, payroll, and finance workflows. A captured session in a financial services firm reaches mail and Drive and can grant OAuth access in the victim's name, which is the access path attackers use to reach data long after the initial click. Firms subject to SOC 2 or PCI DSS expectations should treat this campaign as evidence for why single-signal controls, reputation scoring in particular, need to be supplemented with behavioral and relationship-based detection, and why audit log review needs a named owner and a response clock.
An Action Plan for This Month
Everything below can be started now, without new budget cycles, because of what this campaign demonstrated.
- Audit your calendar invite handling. Confirm whether your mail gateway inspects calendar invites at all. The researchers found gateways built to inspect mail in transit are a poor fit for invites, and much of this campaign arrived as invites. If your gateway does not see them, you have a gap to document and close.
- Assign a named owner for Google Workspace audit log review. The trail of a hijacked session lives in those logs. If nobody is reviewing them, write down who will, how often, and what they look for.
- Time your containment. Run a tabletop exercise against the researchers' test: can your team revoke sessions, contain OAuth grants, and reset the affected account within an hour? If the answer is no, you now have a specific, measurable gap.
- Inventory third-party OAuth grants. A live session can grant OAuth access in the victim's name. Review what applications currently have access to your Workspace domain and remove what is not justified.
- Rehearse the 72-hour clock. If you are a defense contractor, confirm you hold a DoD-approved medium assurance certificate for DFARS 252.204-7012 reporting before an incident, and that your team knows the dibnet.dod.mil process. Healthcare organizations should do the same rehearsal against the Breach Notification Rule timelines.
- Stop treating reputation as a control. Update your phishing awareness guidance to reflect that a legitimate Google URL, a valid certificate, and a known sender domain were all true in this campaign. Teach the behavior that matters: unexpected invites, especially with boring pretexts, get verified out of band.
- Review detection coverage against multi-signal analysis. The approach that caught this campaign weighed technical indicators alongside message intent, where links actually ended up, and the sending relationship. Ask your email security provider how many independent signals drive their verdicts, and what happens when the first signal is a Google URL.
- Check your evidence trail. Whatever monitoring you have, confirm it produces the evidence auditors need for HIPAA, CMMC, PCI DSS, SOC 2, and NIST 800-171 verification. A control that works but cannot be demonstrated does not help you in an assessment.
- Plan for the Microsoft 365 variant. The researchers found an unfinished Microsoft 365 branch in the attacker's framework, built and waiting. If you run Microsoft 365, assume the same technique will arrive under a different brand and confirm your detection covers it.
- Update your risk analysis. Both HIPAA under 45 CFR 164.308(a)(1)(ii)(A) and NIST SP 800-171 expect threats to be assessed against your actual environment. Document this campaign, its techniques, and your responses to it. That documentation is what an assessor wants to see.
How Petronella Technology Group, Inc. Helps
The core problem this campaign exposed is an identity and detection blind spot in cloud workspaces, and that is where our managed security practice is built. Our Managed Detection and Response service provides 24/7 threat monitoring, AI-powered analytics, and human-led investigation, with cloud coverage that integrates Microsoft 365, Azure, AWS, and Google Workspace to detect unauthorized access, impossible travel, and suspicious API activity. That is precisely the visibility a captured session defeats when nobody is watching the audit logs. Onboarding is operational within 30 days of contract signing, and the service scales from 25-endpoint small businesses to 5,000-endpoint enterprises.
For organizations that cannot send sensitive data to a public-cloud SOC, our AI-augmented hybrid SOC runs on the company's private AI cluster and serves defense industrial base and healthcare clients. The guardrails are explicit: the AI never closes a ticket on its own, never touches production systems without human authorization, and every action is logged for CMMC and HIPAA audit. A Digital Forensics Examiner is on staff, and MDR reporting is designed to provide the evidence auditors need for HIPAA, CMMC, PCI DSS, SOC 2, and NIST 800-171 verification.
For defense contractors, our CMMC readiness consulting addresses the incident response and audit trail questions this campaign raises, including the operational incident handling capability NIST SP 800-171 requires and the DFARS 252.204-7012 reporting process. For healthcare organizations, our HIPAA compliance services align documentation to NIST SP 800-66 Rev 2 and the HHS Office for Civil Rights audit protocol. Our broader compliance practice covers the frameworks regulated businesses answer to, and our Google Cloud managed hosting team works with organizations that have made Google part of their infrastructure. If you want a direct, confidential conversation about your exposure, our Petronella Private Session gives you one-on-one access to Craig Petronella.
Related reading
- Gmail Calendar Phishing Scam Targets 1.5 Billion Users
- Private Cloud vs iCloud and Google Drive: Who Owns Data?
- Google Docs Phishing Scam: Don't Click That Link
- Compromised Logins Now the Top Entry Point for Ransomware
Sources
- Calendar Invites and Live Proxies: Inside a Google Session Hijacking Campaign
- Email Security for Google & M365
- 45 CFR Part 164 - Subpart C - Security Standards for the Protection of Electronic Protecte
- SP 800-66 Rev. 2, Implementing the Health Insurance Portability and Accountability Act (HI
Frequently Asked Questions
Can MFA stop a Google session hijacking attack?
No, not in this campaign. The attacker ran a live reverse proxy in front of the real Google sign-in page and relayed each second factor to Google in real time, including SMS codes, authenticator codes, Google's Tap-Yes number matching, and phone-based account recovery. The victim approved a genuine prompt while the operator watched. MFA remains essential, but this campaign shows it cannot be the only control.
How did the phishing links look legitimate if they were malicious?
Because the first hop really was legitimate. Most links ran through Google's own /url redirector, with the real destination hidden in a query parameter, and other waves used share.google and Drive file links. The domain, certificate, and reputation on display were all genuine. The malicious page did not exist until JavaScript built it in the browser after a Cloudflare Turnstile challenge, so crawlers and proxy logs had nothing to scan.
Is the Google Calendar hijacking campaign still active?
The researchers report that the campaign looks finished for now. Lures shifted from calendar invites to Google Drive file and document share invites, and activity from the group appears to have scattered. However, they expect the next pivot to look much the same with a different brand, and an unfinished Microsoft 365 branch was already built into the attacker's framework.
What should I do if a user in my organization clicked one of these calendar invites?
Treat it as a potential live session compromise, not a phishing report. Revoke the user's sessions, review and contain OAuth grants, reset the account, and check Google Workspace audit logs for mail, Drive, and OAuth activity during the exposure window. If ePHI or covered defense information was reachable, your breach assessment and reporting obligations start at discovery, so move quickly and document what you find.
Why did reputation-based security tools miss this campaign?
Because the campaign was engineered so every reputation question had a harmless answer. Early waves used many lure domains across several registrars, most registered just days before use, and receiving endpoints went live one to twenty days ahead of the wave they served. The messages came from compromised accounts mailing their saved contacts, so recipients saw a name and domain they knew. The researchers found that detection worked only when no single signal made the call.
Does this attack affect Microsoft 365 users too?
Not yet, based on the reporting. The researchers found an unfinished Microsoft 365 branch in the Nyasher framework, including 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 mean dropping in a file with no code changes. Microsoft 365 organizations should prepare now rather than wait.
If this campaign has you questioning whether your identity monitoring and incident response would pass the one-hour test, call Penny, our AI assistant, at 919-348-4912 to book a consultation, or reach Petronella Technology Group, Inc. through our contact form.
Free, practical, and specific to regulated environments. We will email it to you.
No spam. Unsubscribe anytime.
