Google Calendar invitations have become the entry point for a phishing campaign that, according to security firm Material Security, targets corporate Google Workspace accounts and is designed to hijack an employee’s session even when the company requires two-step verification. The case, which Material calls “Operation CloudFire” and says has been running since mid-August 2026, raises an uncomfortable question for IT teams once again: which authentication methods still hold up when the attacker inserts itself in the middle of the sign-in flow.
Key risks for Google Workspace businesses, in 20 seconds
- Material Security attributes the campaign to the Nyasher kit, which uses a reverse proxy.
- SMS codes, app codes, and approvals are relayed to Google in real time.
- Since August 14, 2026, admins can restrict which invitations get added to Calendar automatically.
- Passkeys, FIDO2 security keys, and DBSC are the defenses Google is proposing.
The mechanics of the attack are explained in detail in opensecurity.es’s analysis of the Google Calendar phishing campaign. In short, the victim receives a calendar invitation, often from the compromised inbox of an organization they already work with, along with a link that passes through Google redirectors and a Cloudflare Turnstile filter before landing on a page that replays the real sign-in flow live. Everything the user types or approves travels to Google through the attacker, who keeps the session cookie.
The figures should be read with caution. Material disclosed the case on BleepingComputer through a sponsored piece written by the company itself, and all the data comes from its own customers’ telemetry: 68,676 blocked messages, 2,112 malicious URLs analyzed, 897 domains taken down, and 8,570 compromised senders across 6,354 root domains over one month of activity. There is no independent estimate of how many accounts were compromised, nor any statement from Google on the case.
Why the calendar is a blind spot for businesses
Many organizations have spent years filtering email, but the calendar is treated as a productivity tool, not an entry channel. An accepted or automatically added invitation shows up in the agenda, generates reminders, and carries the link to a place where employees don’t expect to find fraud. In a Workspace environment, that invitation can also arrive from a real vendor or client whose inbox has been hijacked, so the usual trust signals (a known domain, an existing business relationship, valid certificates) end up working in the attacker’s favor.
That’s why Material argues that invitations should be analyzed as their own attack surface, with detection combining several signals rather than just sender or link reputation. The company also recommends reviewing Workspace audit logs and having the ability to revoke sessions, contain OAuth permissions, and reset accounts within about an hour of detecting a compromise. Those timeframes are the recommendation of a vendor that sells exactly these kinds of tools, so each organization will need to adjust them to its own incident-response procedures.
The problem isn’t exclusive to Google. According to Material, the kit has a Microsoft 365 branch that hasn’t been activated yet, which for now is a prediction rather than an observed attack. Anyone managing mixed environments can review how Microsoft 365 and Google Workspace have tightened email access, since much of the defensive logic is the same.
What a Workspace admin can adjust
The first adjustment sits in Calendar itself. On August 14, 2026, Google rolled out new controls that let admins decide, per organizational unit, which invitations get added to calendars automatically. In the Admin console, under Calendar’s advanced settings, admins set a least-restrictive level (invitations from anyone, only from known senders, or only those the user has replied to by email) along with a default value. Users can change their own preference, but never beyond that limit. Google notes that the changes apply to future invitations and can take up to 24 hours to take effect.
Restricting invitations to known senders cuts down on calendar spam, but in this campaign it has an obvious limit: if the sender is a partner whose inbox has been compromised, they’re still “known.” The option to add only invitations replied to by email is stricter, though it forces a change in habits and can draw complaints from teams with a lot of external scheduling.
The deeper defense lies in authentication. Google argues on its Workspace blog that passkeys are more phishing-resistant because each one is tied to a specific service and the user can’t hand it over to an intermediary website. The company lets admins audit the passkey registry and restrict passkeys to physical security keys, an option aligned with the FIDO2 standard that makes sense for privileged accounts, executives, and finance staff. The methods Material describes as being relayed by the proxy (SMS, app codes, number matching, and phone-based recovery) don’t offer that same guarantee.
Device-bound sessions and context-aware access
Even with strong authentication, a cookie stolen through another route is still a risk. For that scenario, Google offers Device Bound Session Credentials (DBSC), in open beta and available in Chrome for Windows, which tie a session to the device where it started and make it harder to reuse elsewhere. They’re enabled under Google’s session control section in the Admin console. Since it’s a beta limited to one platform, it doesn’t yet cover a typical company’s entire device fleet.
Google presents DBSC as a complement to context-aware access, which lets admins condition access to Workspace applications on attributes such as device status or location. It’s the piece that most resembles what other environments call conditional access: if a valid session shows up from an unmanaged device, the policy can block it even though the cookie is genuine. Its availability depends on the Workspace edition a company has, something each organization needs to check before planning a rollout.
The combination that emerges from Google’s documentation and the case described by Material is clear in its order: limit what gets added to calendars automatically, move critical users to passkeys or FIDO2 security keys, bind sessions to devices wherever possible, and condition access on context. None of these measures appears, in the available information, to be a complete solution on its own.
Frequently asked questions
Can Workspace admins block invitations from unknown senders?
Yes. Since August 14, 2026, admins can set the least-restrictive level for adding invitations to Calendar per organizational unit, including options limited to known senders only or only invitations replied to by email.
Is requiring two-step verification enough?
Not against this type of attack. According to Material Security, the proxy relays SMS codes, app codes, and approvals in real time, so the attacker obtains the session anyway.
What does DBSC give a business?
It ties the session cookie to the device where it started, making it harder to reuse it from another device. It’s in open beta and works in Chrome for Windows.
Does this also affect Microsoft 365?
Material says the kit has a Microsoft 365 branch that isn’t active yet. For now that’s the company’s prediction, not a documented attack.
Sources:
- opensecurity.es: A phishing campaign with Google Calendar steals sessions and bypasses MFA
- BleepingComputer: Google Calendar phishing campaign hijacks sessions, bypasses MFA (sponsored content by Material Security)
- Google Workspace Updates: new admin controls for Calendar invitations
- Google Workspace Admin Help: automatically add events to calendars
- Google Workspace Blog: passkeys and DBSC against account takeovers
This article is also available in Spanish: «Phishing en Google Calendar: qué debe revisar una empresa con Workspace», on revistacloud.com.
