Calendar Invite Phishing Detection Guide

A malicious meeting invite can land on a user's calendar without being opened, and stays there after the email that carried it is quarantined or deleted. Calendar systems were built to add invitations automatically, so an attacker who gets one meeting request through the mail filter gets a lure that appears beside real meetings, sends reminders and carries a join link nobody questions. This guide covers how invite phishing works, the platform settings that decide whether invites are added automatically, the signals to detect in mail and calendar logs, and how to clean up events as well as messages. It covers Google Workspace and Microsoft 365 with Exchange Online, listed alphabetically, and is written for email security engineers, SOC analysts and workspace administrators. Phishing detection in general is covered in the MITRE ATT&CK T1566 Phishing guide; this page goes deeper on the calendar channel only.

Source note: regulatory and specification details are summarised from the official sources listed at the end. Confirm against the official text before relying on it.

Key takeaways

The calendar is a second delivery path. A meeting request is an email with a text/calendar part; once processed, the event lives in the calendar independently of the message.
Automatic adding is the root setting. Google Calendar's "Add invitations to my calendar" and Exchange's Calendar Attendant behaviour decide whether unknown senders can place events without a click.
The organizer field is not authenticated by the From header. RFC 6047 says From, Sender and Reply-To cannot reliably identify the organizer, so spoofed organizers pass casual inspection.
Clean the event, not only the email. Remediation that removes the message but leaves the calendar entry leaves the lure, and its reminders, in place.
AI assistants widen the impact. Assistants that read calendars treat invite descriptions as input; the Gemini calendar prompt injection showed an invite can steer an assistant into leaking meeting details.

How calendar invite phishing works

Under the hood, invitations travel as iMIP messages. RFC 6047 (Standards Track, December 2010) defines how iTIP scheduling messages are carried in email: the calendar part uses the text/calendar media type with a method parameter (for example REQUEST or CANCEL), and organizer and attendee addresses are mailto: URIs inside the calendar data. The RFC requires S/MIME for authentication and says unsigned messages may not be trusted, but in practice most invitations are unsigned, so clients act on whatever the calendar data says.

Variant	How it reaches the user	What the attacker wants	ATT&CK
Auto-added lure event	Meeting request processed into the calendar, often with urgent wording ("payroll review", "contract signature")	Clicks on a credential harvesting or fake meeting join link from the event body	T1566.002, T1204.001
Attached `.ics` file	Calendar file attached to a normal email, opened and imported by the user	Same as above, plus bypassing link scanning that only inspects the message body	T1566.001, T1204.002
Invite sent through the calendar service	Event created in an attacker-controlled account of a legitimate calendar service, so the invitation comes from the provider's own infrastructure	Inherit the provider's sender reputation and authentication results	T1566.003
Fake meeting join for token theft	Event points to a "join" page that leads to a device code or consent prompt	Access tokens without a password. See the Device Code Phishing Guide.	T1528
Internal invite from a compromised account	Meeting request sent from a real colleague's mailbox	Lateral movement with high trust	T1534
Reconnaissance invite	Invite that asks the user to confirm details or reveals who accepts	Valid addresses and response behaviour	T1598.003
Instruction-bearing invite for AI assistants	Invite description containing hidden natural language instructions	Steer a calendar-reading assistant into exposing or creating data	T1566.002 delivery; see the AI section below

Why it works: the event inherits the trust of the calendar UI, it repeats through reminders, and users are trained to click "join" quickly. Delivery and detection also split across two systems, the mail filter and the calendar store, and many teams only watch the first.

The settings that decide whether invites are auto-added

Each platform has its own controls for automatic adding. They are customer-side settings and worth reviewing before writing detections, because they change how much reaches the calendar.

Google Workspace

User setting: in Google Calendar, Settings, General, Event settings, Add invitations to my calendar offers "From everyone", "Only if the sender is known" and "When I respond to the invitation in email". Google's help page defines a known sender as someone in the user's contacts, part of the organisation, or someone the user has interacted with. Changes apply to new invitations only.
Admin default: the Google Workspace Updates announcement (July 2022) states that admins can set the default for their users in the Admin console, that the default shows invitations from everyone, and that users can change their own preference. The help page adds that the administrator controls which invitation options users can choose.
Pending invitations visibility: with either of the restrictive options, a related setting controls whether others with permission to view the calendar also see pending invitations.

Microsoft 365 and Exchange Online

Calendar Attendant: the Exchange Set-CalendarProcessing documentation describes AddNewRequestsTentatively: when $true (the default) new meeting requests are added to the calendar as tentative; when $false only existing calendar items are updated by the Calendar Attendant. Pilot a change on a small group, because it alters normal meeting workflow.
Resource mailboxes: ProcessExternalMeetingMessages controls whether meeting requests from outside the organisation are processed; the documented default is $false, so external requests are rejected. Keep it that way for rooms and equipment unless there is a business need.
Events from email: Set-MailboxCalendarConfiguration -EventsFromEmailEnabled (default $true in Exchange Online) controls whether events are created from email messages such as flight, hotel and parcel notifications. Disabling it for high-risk users removes another automatic path onto the calendar.
Mail flow rules: the transport rule condition MessageTypeMatches Calendaring matches meeting requests and responses, so you can combine it with an external sender condition to tag, report or route external invitations.

Detection signals

Good detection combines what the mail layer sees on arrival with what the calendar layer records afterwards.

Signal	Where to see it	Why it matters
External sender with a `text/calendar` part, first contact	Email security logs; Exchange mail flow rule on `Calendaring` plus external scope; Gmail logs	Most legitimate external invites come from senders users already correspond with
ORGANIZER in calendar data differs from the From address or its domain	Content inspection of the `text/calendar` part	RFC 6047 says headers cannot identify the organizer; a mismatch is a possible spoofing indicator (forwarded invites can also differ)
Large external attendee list with hidden or bulk recipients	Calendar part ATTENDEE count, message recipient count	Mass invite campaigns spray many addresses in one event
Links in the event description or location that are not the organisation's meeting providers	URL extraction from the calendar part and event body	Join links to look-alike domains are the core lure
`.ics` attachment on a non-invite email	Attachment type and extension logs	Bypasses tooling that only treats real meeting requests as calendar items
Event guest added, description or location changed by an external actor	Google Calendar log events (Event guest added, Event description modified, Event location modified)	Attackers update events after delivery to swap in a malicious link
Assistant or app creates events with unusual titles or external guests	Google Calendar log events Actor application name and API kind; app audit logs	Catches automated writes, including assistant actions triggered by injected instructions
Same event title or link across many mailboxes in a short window	Mail and calendar log aggregation	Campaign clustering lets you remediate everywhere at once

Google Calendar log events: available under Menu, Reporting, Audit and investigation, Calendar log events (Audit and Investigation administrator privilege), and in the security investigation tool on supported editions. Useful fields include Event title, Event ID, Organizer calendar ID, Actor, Actor application name, Target, IP address and User agent. Entries usually appear within about half an hour and the default view covers the last 7 days, so widen the range when hunting.

Exchange Online: a mail flow rule using MessageTypeMatches Calendaring with an external sender condition can add a header or subject tag that your SIEM and users can see, or generate an incident report for the security mailbox. Pair it with your email security tool's URL and attachment telemetry for the same messages.

Response and clean-up

Scope the campaign: search by sender, organizer address, event title and join URL across mail logs, and by event title or ID in calendar logs. Keep the list of affected users.
Remove messages and events: purge the message, then confirm the calendar entry is gone too. Check whether your remediation tool removes the calendar item; if not, delete the events through the platform's admin tooling or by working with users.
Block the infrastructure: block sender, domains and URLs at the mail layer and the web proxy, including look-alike meeting domains.
Check who clicked and what followed: for users who visited the link, review sign-in logs for new sessions, device registrations (T1098.005), consent grants and device code flows; revoke sessions and reset credentials where needed. See the Phishing Incident Response Playbook.
Review settings: if invites were auto-added, decide whether to move the affected population to "Only if the sender is known" or to disable automatic tentative adding.
Tell users clearly: name the event title and say to delete it rather than decline, since a decline can confirm a live address to the sender.

Where AI assistants fit

Calendar-reading assistants turn invite text into model input. In the Gemini calendar prompt injection, disclosed in January 2026, an invite description carried hidden instructions; when the user later asked about their schedule, the assistant summarised private meetings into a new event that the attacker could see. Google confirmed and mitigated the issue. The detection lessons carry over to any assistant: treat external invites as untrusted input, separate read and write permissions for assistants, require confirmation before an assistant creates events, and log assistant actions so they can be traced to the invite that triggered them. See the AI Meeting Assistant Security Guide and the Gemini for Google Workspace Security Guide.

Rolling out controls

Measure first (week 1): count external meeting requests per week and the share from first-time senders, using mail logs and a report-only mail flow rule.
Tag and report (weeks 2 to 3): add an external calendar tag or header for meeting requests from outside the organisation and route a copy or incident report to the SOC.
Pilot restrictive adding (weeks 3 to 6): move a pilot group, for example executives, assistants and finance, to "Only if the sender is known" in Google Workspace or test AddNewRequestsTentatively $false in Exchange Online. Collect complaints about missed meetings.
Deploy hunting rules (weeks 4 to 6): build the signal table rules in the SIEM, starting with organizer mismatch, external first contact with links, and campaign clustering.
Expand by risk (weeks 6 onward): widen restrictive settings to more groups where the pilot showed low friction.
Rollback: both settings can be reverted per user or group; keep the previous values recorded so you can restore them if critical external scheduling breaks.

Decision guidance

Restrict for high-value groups first: executives, their assistants, finance and IT administrators are the most targeted and benefit most from known-sender adding. See the Security Awareness for Executives and Assistants Guide.
Sales, recruiting and support: these teams schedule with strangers daily. Keep automatic adding but rely on tagging, link scanning and fast clean-up.
Small organisations: change the default invitation setting and add one tagging rule; this covers most of the risk without a SOC.
Large organisations: invest in calendar log ingestion and campaign clustering so one report can remove an event from thousands of calendars.

Detection and measurement

Auto-add exposure: percentage of users whose calendars add invitations from everyone, tracked by group.
Event clean-up completeness: share of remediated campaigns where calendar entries were confirmed removed, not only messages. Target 100 percent.
Time to remove: median time from first report to removal of the event from all calendars.
User reports of malicious invites: count and share of campaigns first reported by users.
Click-through on invite links: users who visited a malicious join link per campaign, from proxy logs.

Common failure patterns

Purging the email, leaving the event: the message is quarantined, but the tentative or accepted event keeps sending reminders with the link.
Trusting the organizer name: analysts read the organizer shown in the calendar UI and assume it was authenticated, when RFC 6047 says headers cannot establish it.
Ignoring .ics attachments: rules that only look at real meeting requests miss calendar files attached to ordinary mail.
Only watching mail logs: post-delivery edits to the event, such as swapping the location link, never show in the mail filter.
Asking users to decline: a decline response goes back to the sender and confirms the address.
Leaving assistants with silent write access: assistants that can create events without confirmation turn an invite into an action channel, as the Gemini case showed.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK	T1566.001, T1566.002, T1566.003, T1204.001, T1534, T1528	Delivery, user execution, internal spread and token theft through invites
MITRE ATT&CK mitigations	M1054 Software Configuration, M1017 User Training	Invitation settings and user guidance
NIST CSF 2.0	PR.AT-01, DE.AE-02, RS.MI-01	Awareness, analysing adverse events, containment
NIST SP 800-53 Rev. 5	SI-8, SI-4, AT-2	Spam protection, monitoring, awareness training
CIS Controls v8.1	9 Email and Web Browser Protections, 14 Security Awareness and Skills Training	Mail filtering and user training

Practitioner checklist

Record current invitation settings: Google "Add invitations to my calendar" defaults and Exchange AddNewRequestsTentatively values.
Move high-risk groups to known-sender or respond-first adding after a pilot.
Keep ProcessExternalMeetingMessages at $false on resource mailboxes unless needed.
Tag external meeting requests with a mail flow rule or gateway policy and send a signal to the SOC.
Inspect text/calendar parts for organizer mismatch and non-standard join links.
Ingest Google Calendar log events or equivalent calendar telemetry into the SIEM.
Make every phishing remediation confirm that calendar entries were removed.
Require confirmation before AI assistants create or change events.

Calendar Invite Phishing Detection: Catching Malicious Meeting Invites and Auto Added Events