Google Calendar phishing steals sessions after sign-in checks

A familiar calendar invitation can lead to an account takeover even when the user receives a genuine sign-in challenge. In research published in October 2026, Material Security described a Google session-hijacking campaign delivered through calendar invites. The incident deserves a retrospective look because ordinary office routines, rather than an obviously exotic exploit, supplied its credibility.

A session is the website’s way of remembering that someone has already signed in. Think of it as a temporary admission pass: without one, a person would have to authenticate again whenever they opened another message. Microsoft documented phishing that stole these passes in 2022. Session theft and adversary-in-the-middle attacks therefore predate this campaign; the Google case should not be presented as the invention of a new way to defeat authentication.

According to Material, links frequently began on legitimate Google infrastructure before directing the visitor elsewhere. A live intermediary relayed the sign-in interaction. That creates a dangerous gap between a trustworthy first stop and an untrustworthy final destination. A recognizable service name at the beginning of a journey does not authenticate every page that follows it.

Material’s October 28 follow-up reported action against 897 domains and 68,676 blocked messages in participating customers’ data. Those are infrastructure and message counts, not a count of victims. The company also said activity had dispersed and the campaign appeared to have ended. These are historical findings, not evidence that the same operation is running at that scale today.

Google’s own Calendar guidance offers a useful first layer: automatically add invitations only from known senders, and report suspicious events as spam. “Known” includes contacts, colleagues and people with whom a user has interacted. That filter reduces unsolicited clutter, but it cannot guarantee that a familiar correspondent still controls their account. An unexpected request to sign in deserves a separate check through the service’s usual entry point.

Authentication design matters too. NIST explains that manually entered one-time codes are not phishing-resistant because they can be relayed into another authentication exchange. FIDO2/WebAuthn instead binds authentication to the genuine service’s domain. The distinction resembles a spoken code versus a key that recognizes a particular lock. The practical lesson is layered protection: control what enters the calendar, scrutinize where sign-in happens, and protect the resulting session. Turning on a second factor remains valuable, but the kind of factor makes a difference.

Original research dates: Material Security, October 1, 2026; follow-up, October 28, 2026.