> For the complete documentation index, see [llms.txt](https://docs.material.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.material.security/email-protections/email-threats/detections/material-email-threat-detections/calendar-invite-attacks.md). # Calendar Invite Attacks Attackers use calendar invitations to put a malicious link or request in front of your users, where an event already sitting on a calendar carries more trust than an email. Defending against them takes two halves. Material removes malicious events when it remediates the message that carried them. An invitation can also be added straight to a calendar with no message behind it, and that path is closed by a setting in Google Workspace or Microsoft 365 rather than by Material. This page covers both. ### Start here Work through these in order: {% stepper %} {% step %} ### [Grant Material access to calendars](#grant-material-access-to-calendars) Until you do, calendar remediation can't remove anything. We'll prompt you to do this. {% endstep %} {% step %} ### [Turn on calendar remediation](#turn-on-calendar-remediation) This removes malicious events along with the messages that carried them. {% endstep %} {% step %} ### [Find accounts that accept every invitation](#find-accounts-that-accept-every-invitation) If you use Google Workspace, Material shows you who's currently exposed. {% endstep %} {% step %} ### [Change your provider's calendar setting](#change-your-providers-calendar-setting) This closes the gap remediation can't reach. {% endstep %} {% step %} ### [Clear invitations already on calendars](#clear-invitations-already-on-calendars) The steps above protect against what arrives next. This handles what's already there. {% endstep %} {% endstepper %} *** ## Grant Material access to calendars Calendar remediation needs the Google Calendar scope. Until you grant it, Material can't remove events, even with the response turned on. When the scope is missing, your Material instance displays a warning prompting you to grant it. Click the button in the prompt to navigate to Google where you can grant it, then give Google time to apply the change:
{% hint style="warning" %} Google can take up to 24 hours to apply a new scope, though it's usually much faster. Calendar remediation keeps failing until the change reaches Material, so grant the scope ahead of time rather than during an active campaign. See Google's guidance on [how changes propagate to Google services](https://knowledge.workspace.google.com/admin/support/troubleshooting/how-changes-propagate-to-google-services). {% endhint %} ## Turn on calendar remediation in Material There are two places to enable calendar remediation: the responses Material applies automatically, and the classifications your analysts apply by hand. Turn on both, so an invitation is removed whether Material catches the message itself or someone flags it later. To include calendar remediation in your automatic responses: 1. From the left navigation, expand **Email Threats**, expand **Settings**, then click **Material Detection**. 2. Under **Remediate messages**, check **Delete associated calendar events**. To include it in the responses your analysts apply during triage: 1. From the left navigation, expand **Email Threats**, expand **Settings**, then click **Issue Triage**. 2. Click **Malicious**, then check **Delete associated calendar events**. 3. Repeat for **Spam** and **Unknown**. When an analyst sets a classification on an issue, calendar remediation is now part of the suggested response. They can still change it before applying it. The same option is available in **User Reports** > **Settings**, and on individual custom detections. {% hint style="success" %} **Delete associated calendar events** is on by default. If your instance predates the option, confirm it's selected in each of the places above. {% endhint %}
❓ What calendar remediation does The **Delete associated calendar events** response removes the calendar event that came with a remediated message. It soft-deletes the event, so the invitation disappears from both the organizer's and the attendee's calendars. * When a calendar notification lands in someone else's mailbox, such as an assistant who receives notifications for the person they support, Material removes the event from the Google calendar that actually holds it, not from the mailbox the notification arrived in. Before acting on another user's calendar, Material confirms the notification genuinely came from Google Calendar and that the recipient really has access to that calendar, so a forged notification can't be used to delete someone else's events. * If you later remove the calendar remediation, or reclassify the issue so it no longer applies, Material puts the event back on the calendar. It recreates the event rather than reviving the original, so it may appear as a new entry, and in some cases the user shows as the organizer. Restoration reads the original message, so it depends on that message still being retained. * Material checks the event's authoritative organizer first, so meetings owned by the mailbox holder, their aliases, or internal trusted users are left alone. {% hint style="info" %} This response acts on the message that carried the invitation. An event added straight to a calendar with no message behind it isn't in scope, and neither is an invitation whose message your email provider quarantined before Material could see it. Your provider's calendar setting is what covers those. {% endhint %}
*** ## Find accounts that accept every invitation Material includes a detection called `Google account automatically adds calendar invitations from everyone`, enabled by default. It flags accounts configured so that any event lands on the calendar, whoever sent it.
Unlike detections that flag a suspicious message, this one flags a configuration, so there's no response or remediation to apply. The setting lives in your Google Workspace admin console, which means Material can show you who's affected but can't change it for you. To see which accounts are affected, filter your issues by the detection name. That list tells you how widely your organization is exposed, and where to start if you'd rather tighten the setting in stages instead of everywhere at once. Change the setting as described below, then use the same filter to check your progress. *** ## Change your provider's calendar setting This is the half Material can't do for you. Tightening the setting adds friction, so it won't suit every organization. Where it works for yours, or even for part of it, it stops events from reaching calendars on their own. It doesn't stop anyone from receiving calendar invitations. Invitations still arrive as email, and the event appears on the calendar once the user accepts it from the message. What changes is that an event no longer appears on its own, which puts each invitation back in front of your email filtering and the user's own judgment. ### Google Workspace Google Workspace has a single setting that controls which invitations land on calendars. You can set it for your whole organization or for one organizational unit. To change which invitations are added automatically: 1. Sign in to the [Google Workspace Admin console](https://admin.google.com). 2. From the left navigation, click **Apps** > **Google Workspace** > **Calendar** > **Advanced settings**. 3. Select the organizational unit you want to change. 4. Scroll to **Add invitations to Calendar**, then select one of the three options below. 5. Click **Save**. {% hint style="info" %} Refer to [Google's documentation](https://support.google.com/calendar/answer/37242) for up to date instructions in their Admin console. {% endhint %} | Option | What it does | What to weigh | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Invitations from everyone** | Adds every event to the calendar, whatever the source. | The most permissive setting. Invitations from senders your users have never dealt with land on calendars on their own. | | **Invitations from known senders** | Adds events only from people in your directory, or senders the user has interacted with before. | The least disruptive change for your users. A known sender whose account is compromised can still add events. | | **Invitations users have responded to via email** | Adds an event only after the user responds to the invitation from their email. | The strictest option, and it holds up even when a known sender's account is compromised. Users who work mostly out of their calendar may not see an invitation until they check email. | **Invitations from known senders** is a solid baseline that most teams barely notice. **Invitations users have responded to via email** also closes the gap a compromised known sender leaves open, at the cost of more friction. If the stricter setting isn't workable everywhere, apply it to your highest-risk organizational units rather than skipping it entirely. [Learn more about automatically adding events to calendars](https://knowledge.workspace.google.com/admin/calendar/automatically-add-events-to-calendars) {% hint style="warning" %} This setting applies to invitations that arrive after you change it. Events already on a calendar stay there, and Google can take up to 24 hours to apply the change. {% endhint %} ### Microsoft 365 {% hint style="warning" %} The Google Workspace and Microsoft 365 settings work at different points. In Google Workspace, the invitation still reaches the user and the event simply isn't added on its own. In Microsoft 365, the mail flow rule holds the invitation for review before it's delivered. If you run both, plan a release process for legitimate invitations on the Microsoft side. {% endhint %} **Option A: disable automatic calendar processing per mailbox.** Run the following in Exchange Online PowerShell to update every existing mailbox: ```powershell Get-Mailbox -ResultSize Unlimited | ForEach-Object { Set-CalendarProcessing $_.Identity -AutomateProcessing None } ``` Because this is a per-mailbox setting a mailbox owner can change, add it to your account creation playbooks and run it on a schedule so the setting doesn't drift. Test it on a single mailbox before you apply it broadly. See Microsoft's reference for [Set-CalendarProcessing](https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-calendarprocessing). **Option B: filter external calendar invitations with a mail flow rule.** In the Exchange admin center, create a mail flow rule that matches **The message type is** set to **Calendaring** and **The sender is located** set to **Outside the organization**. * For the action, use **Quarantine the message**. Quarantined invitations are held for review and can be released, so a legitimate meeting request the rule catches isn't lost. Expect to release some. This rule matches every external calendar invitation, not just malicious ones, so plan for a review queue and add exceptions for partner domains whose invitations your users rely on. * Avoid **Reject the message**. It bounces the invitation with a delivery failure notice, which turns every legitimate external meeting request the rule catches into a support ticket, and tells the sender their message was blocked. This rule applies to calendar invitations that arrive as email through Exchange Online. It doesn't cover events added to a calendar another way, such as by a delegate or an application with calendar permissions, and it doesn't apply to senders inside your organization. [See Microsoft's reference for mail flow rule conditions and exceptions](https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/conditions-and-exceptions). *** ## Clear invitations already on calendars Changing your provider's setting only affects invitations that arrive afterward. An event that's already on a calendar stays there until you remediate the message that carried it. Ask the user to report the message, or find it yourself: 1. From the left navigation expand **Explorer**, then click **Messages**. 2. Search for and select the message, then click **Create Issue**. 3. Classify the issue. Any classification you've set up for calendar remediation works, so use the one that fits what you found. If you followed **Turn on calendar remediation** above, that's **Malicious**, **Spam**, or **Unknown**. 4. Check that the response includes **Delete associated calendar events**. This is the only response required to clear the event. Two more responses are worth adding, though neither is required: * **Auto Threat Hunt** finds matching and similar messages, so an invitation sent to many mailboxes is cleaned up in one pass. * **Move to spam** takes the message itself out of the inbox. **Delete messages** also removes the message and its calendar events, but it removes all other remediations. *** ## Learn more [The quiet phish: stopping calendar invitation attacks](https://material.security/resources/the-quiet-phish-stopping-calendar-invitation-attacks) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.material.security/email-protections/email-threats/detections/material-email-threat-detections/calendar-invite-attacks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.