A Google Calendar Invite From Someone You Know Is Stealing Live Google Sessions Through Your MFA. Change One Calendar Setting, and Know That a Password Reset Will Not Evict Them.
If you run Google Workspace, do four things today. First, in the Admin console go to Apps, Google Workspace, Calendar, Advanced settings, and look at "Add invitations to Calendar." The default adds invitations from everyone. The strictest option, "Invitations users have responded to via email," keeps every invite off the calendar until the user acts on it; "Invitations from known senders" helps less than it sounds against this campaign, because many of these invites come from real accounts at organizations the victim already corresponds with. Second, if anyone entered their Google password after clicking a calendar link since mid-August, reset their sign-in cookies, not just their password: the attacker holds a live session. Third, check that user's Connected applications for an app grant they did not make. Fourth, move the people who matter most to passkeys or security keys and enforce "Only security key" 2-Step Verification for them, because SMS codes, authenticator codes and Google's Tap-Yes prompt were all relayed in real time.
What is confirmed
Material Security's threat research team published a 17-page whitepaper, "Two toolkits, one gate," dated September 2026 (the PDF was created September 30). The Hacker News ran Material's write-up of the campaign and its response, which it calls Operation CloudFire, on November 12. Everything below about the attack comes from those two documents; the whitepaper is the primary.
Material says the campaign "has been running continuously since mid-August 2026 while registering as clean in every commercial reputation feed we tested (as of mid-September 2026)." The targets are corporate Google Workspace users.
The chain has four steps, and only the last one is the attacker's own infrastructure in a way a filter can see.
- The lure is a calendar invite, not an email with an attachment. In Material's words, it "arrives from an organization you have corresponded with before, or it arrives via BCC. It carries no attachment and no macro, just a themed calendar invite with a link." Themes seen: voicemail, RFP and RFI requests with document links, court summonses, missed payments. Per The Hacker News piece, the operator took over sender accounts and mailed their contacts; Material counted 8,570 compromised sender addresses across 6,354 root domains in one month of its data-sharing customers.
- The link is Google's. Material: "The link in the invite is not the attacker's URL. It is www.google.com/url, Google's own redirector, wrapping the lure domain inside q=." Other waves used share.google, direct Drive file links, and links.notification.intuit.com transaction notifications.
- The gate is a lure domain registered days before use, carrying a 4-byte hex token. Without the token it redirects somewhere harmless (example.com was one choice). With it, the visitor sees a Cloudflare Turnstile check, sometimes the real widget and sometimes a fake one drawn in CSS. Both post to /captcha/verify.
- The harvester is built in the browser at run time, so it never exists as a fetchable page. Kit A runs as Cloudflare Workers that load genuine Google sign-in markup and lay invisible input fields over the username and password boxes. Kit B, served from hostvipxfl.com/in/, "sits inside a live proxy of the real Google sign-in flow." Material lists what it relays: "SMS and authenticator codes, Google's Tap-Yes numeric prompt, phone-based account recovery, and the unenrolled-MFA path are all handled, so a victim completes their own second factor inside a session the operator is observing."
Material ties this to a framework other researchers named Nyasher in public reporting from February, June and July 2026, after a key hardcoded in its JavaScript. The live code also carries an unfinished Microsoft 365 branch whose paths do not resolve today.
Scale, per The Hacker News piece and covering only Material's data-sharing organizations over one month: 68,676 campaign messages blocked, 2,112 unique malicious URLs analyzed, 897 domains taken down with Cloudflare.
Why a password reset is not enough
The attacker is not after the password. A live proxy captures the session the victim just authenticated, with MFA already satisfied. Google's own Admin Help is direct about the fix: after resetting a user's password, also reset the user's sign-in cookies, which signs the user out of their Google Account and Workspace apps on all devices. Google notes two limits worth knowing. Gmail sessions can take up to an hour to end, and resetting cookies does not sign the user out of desktop apps such as Gmail and Google Drive for desktop. The Directory API method users.signOut does the same thing for scripts. Suspending a user resets their cookies automatically.
A live session can also grant OAuth access in the victim's name, which The Hacker News piece names as part of the reach. On the user's Security page, Connected applications lists third-party apps with access to the account and when they were authorized. Google says removing one is temporary: once the user signs in to that app again, access returns. To make it stick, block the scope or run an allowlist of approved apps.
What is not known
- How many organizations had a session actually stolen. Material reports messages blocked and domains taken down, not confirmed account takeovers.
- Who the operator is. Material says registration data is shielded and gives no attribution. It notes one developer-looking Gmail address hardcoded three times in the Kit B page; that is an identity, not a blockable indicator, and we did not ingest it.
- Whether the Microsoft 365 branch will be finished. Material says it can carry a second brand "with a file drop and no code change."
- When Google's newer, more granular admin controls for adding invitations reached your tenant. Google announced them on August 14, 2026 with up to 15 days for the feature to become visible, but we did not see your console.
What to do
- Calendar. Admin console, Apps, Google Workspace, Calendar, Advanced settings, "Add invitations to Calendar." Google defines known senders as "someone that is in the user's domain or contact list or that they've interacted with." That definition is exactly what a hijacked partner account satisfies, so for high-value groups choose "Invitations users have responded to via email." Google applies a changed default only to future invitations; the ones already on calendars stay.
- Session. For anyone who entered a password after a calendar link: reset password, then reset sign-in cookies, then review Connected applications, Recovery information (a changed recovery phone or email is a persistence move) and Passkeys and security keys (look for a key the user did not add).
- Factor. Passkeys and security keys are bound to the real site, so a proxy on a look-alike domain has nothing it can relay. In the 2-Step Verification policy (Security, Authentication, 2-Step Verification), "Only security key" accepts both security keys and passkeys. Under that mode users cannot make their own backup codes, so set the grace period and plan for lockouts before you flip it.
- Hunt. In the Admin console's audit and investigation pages, look for Calendar events whose description links through google.com/url or share.google to a domain under a month old; a sign-in followed within minutes by a new OAuth grant or a recovery-info change; and invites that came from a real partner domain but were sent outside your normal relationship with that sender. Material also describes a five-request burst at 500 millisecond intervals from one visitor to a workers.dev relay, which a web proxy log can show.
- Block. Add the 15 domains below to your DNS or web filter. Material notes that lure domains rotate constantly and the receiving endpoints are replaced mid-campaign, so treat this list as a hunt list for the past three months more than as a shield for the next three.
The indicators, and what we did with them
Material's appendix publishes domains, registrars and creation dates. We screened every entry before ingesting. All values here are Material's research; none is a DugganUSA observation.
Lure layer (the Turnstile gates and redirectors): biddingselection[.]com, gcheckonline[.]live, voicenotemail[.]sbs, hostvipxfl[.]com (Kit B gate and loader), northernstatemechanical[.]com, world-invitedocument[.]com, facilitiessolution[.]com, corneriglen[.]vu (entry point into Kit A, for example audiovoicemail.corneriglen[.]vu/playback/), myconsultingconstructionvoice[.]us.
Kit B proxy origin: kinihunmeta[.]help.
Receiving layer (where stolen data goes): sommiedo[.]site (the long-lived backend; gold.sommiedo[.]site over a websocket at /ws, seen across four campaigns), longling[.]sbs, zyellop[.]online (qwqeq.zyellop[.]online), burswel[.]sbs, bucking[.]top.
Left out on purpose, because blocking them would break legitimate services or block a person: the Kit A Cloudflare Workers hosts under workers.dev (attached-copy-7tgi.w-swjsii.workers[.]dev and the playback-xtmw Workers; hunt the exact host names, never the platform); form.jotform[.]com/260456798964376, a real Jotform page the kit uses as a harmless decoy when its relay fails; example.com; verify.cloudflare.com.us, a name the kit references that Material says was never registered; 89.106.200[.]1, which Material ties to a public redirect service; and the hardcoded Gmail address. Google's and Intuit's redirector hosts are the abused delivery path, not attacker infrastructure.
Before ingest, our corpus held none of the 15 domains: our correlate endpoint returned held false with zero same-site neighbors for every one, and enrich-ioc returned not found. So this is not a case of us having seen it first. We have now added all 15 under source manual-batch-cloudfire-2026-11, attributed to the Nyasher operator per Material, at confidence 80 to 90, each confirmed by read-back after the write.
How we know
We read Material's whitepaper page by page (it is an image-based PDF, so we read the rendered pages rather than extracted text) and quoted it. The Hacker News piece supplied the Operation CloudFire name, the August-to-November framing and the one-month counts; it is Material's own account, so we count the two as one source, not two. The Google settings and their limits come from Google Workspace Admin Help pages on automatically adding events to calendars, managing a user's security settings, signing a user out of a managed account and deploying 2-Step Verification, and from the Workspace Updates post of August 14, 2026.
We also checked our own edge. Our edge check scanned 438,984 edge block events, 129,338 edge canary hits and 5,594 origin honeypot captures since August 1 for the kit's paths (/captcha/verify, /captcha-widget-error, /gmail-goback, /gmail-ar, /eal and /playback/), anchored so our own /post/ pages could not match. All three came back zero. That is expected and is not reassurance: this attack is delivered to people's calendars and runs on the attacker's servers. A website like ours would only see it if someone pointed the kit at us, so our edge is the wrong instrument for this one.
Calendar invites as an attack surface are not new territory for us; in January we wrote about invites as a way to reach AI assistants. For the sign-in log side of an MFA-bypassing phish, see our November 8 post on seven signals to look for in your own logs.
Sources
Material Security Threat Research, "Two toolkits, one gate," whitepaper, September 2026 (content.material.security, CalendarInviteWhitepaper-sep2026.pdf). The Hacker News, "Calendar Invites and Live Proxies: Inside a Google Session Hijacking Campaign," contributed by Material Security, November 12, 2026. Google Workspace Admin Help: "Automatically add events to calendars," "Manage a user's security settings," "Sign a user out of a managed Google Account," "Deploy 2-Step Verification." Google Workspace Updates, "New admin controls for adding invitations to Google Calendar," August 14, 2026.
Indicators here are Material Security's, cited, not DugganUSA observations. The screening, ingest and edge measurement are ours, done November 13, 2026. We cap ourselves at 95 percent confidence.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.