Calendar Invite Triage
A queue of meeting invites lands in your inbox — a daily stand-up, a vendor kickoff, a “your mailbox is almost full” nudge, a Teams “missed meeting”, an HR briefing with an attached .ics. Some are real. Some are the October 2026 campaign Check Point reported: fake calendar invites engineered to steal Microsoft credentials. For each, call it genuine or phishing and name the primary tell — a link whose text disagrees with its real destination, an organiser whose domain is not the real From, a look-alike or newly-registered Microsoft-login domain, an external URL hidden in the .ics, or an OAuth consent grant on a genuine Microsoft domain. Inspect before you click. Defensive only, no working lures.
The real job. More noise, a tighter clock.
Invite queue
1 / 10 triaged
Platform team daily stand-up
Organiser: Dana Okafor <dana.okafor@northwind.com>
From: dana.okafor@northwind.com
When: Recurring · weekdays 09:30
Attendees: you + 6 teammates
Tip: inspect the real destination before you decide — the visible link text can lie.
1 · Verdict
2 · Primary tell
Pick a verdict and the primary tell to continue.
Sender-domain age
This invite’s sending domain is ~107 months old. One signal among several — weigh it with the From domain, the link and any .ics.
Triage
A queue of 10 meeting invites and .ics calendar emails. For each, call it genuine or phishing and name the primary tell. Several are legitimate — do not over-flag.
So far: 0 / 10 invites triaged.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based triage drill: work a queue of realistic meeting invites and .ics calendar emails and, for each, decide genuine vs phishing and name the primary tell.
- Grounded in the October 2026 fake-calendar-invite campaign Check Point reported — ~302,386 unique phishing emails across ~40,000 organisations, using .ics attachments and Teams-invite lures to drive victims to fake Microsoft sign-in and consent pages.
- The tells are a fixed set: link text that disagrees with the real href, an organiser whose domain differs from the real From, a look-alike or newly-registered Microsoft-login domain, an external join URL smuggled inside the .ics, an OAuth consent grant on a genuine Microsoft domain, or "legitimate — no red flag".
- Several invites are genuine on purpose — the skill is telling a real meeting apart from a lure without over-flagging, because a young domain can be a real new partner and an old domain can be hijacked.
- Defensive only: it never generates a working lure or sign-in page. Every URL is a defanged, obviously-fake illustrative string. Difficulty tiers, a speed bonus and an S–D grade.
The verdict follows the signals, not the theme
The campaign Check Point reported in October 2026 worked at scale — on the order of 302,386 unique phishing emails across roughly 40,000 organisations — precisely because a calendar invite is something people expect and act on quickly. It leaned on .ics attachments and Teams-invite lures, link text that disagrees with the real URL, and newly-registered sender domains, all pointing at fake Microsoft sign-in and consent pages. The defence is not to fear every invite; it is to read the signals. Inspect the real href before you click, because the visible link can say anything. Trust the From domain over the organiser display name. Treat typo- and homograph-squats of login.microsoftonline.com as credential traps. Open the .ics and check its URL, LOCATION and DESCRIPTION fields — the email body can be clean while the calendar file carries the link.
Just as important: do not over-flag. A newly-onboarded partner legitimately has a young domain, and a genuine Microsoft OAuth authorize URL lives on a real Microsoft domain — so “the domain looks right” is not a clearance when the attack is a consent grant to an unknown app. Conversely, a hijacked but long-established sender sits on an old domain that the age signal never flags. No single signal is the verdict. The whole skill of triage is weighing them together — and spending your attention where the evidence actually points.
Frequently asked questions
What does the Calendar Invite Triage lab teach?
It trains the fast decision a SOC analyst, help-desk agent or security-aware user makes on a meeting invite or .ics calendar email: is it a genuine invitation or a phishing lure, and what is the specific tell? You work a queue of invite cards — each with an organiser, a real From address, a Join link whose visible text can differ from its true destination, and sometimes an attached .ics — and for each you call the verdict and pick the primary tell from a fixed set. It is detection and triage practice, not a tool that touches your mailbox.
Is this based on a real attack?
Yes. Check Point reported an October 2026 campaign that abused fake calendar invites to steal Microsoft credentials: roughly 302,386 unique phishing emails reached about 40,000 organisations, using .ics calendar attachments and Teams-invite lures, link-text-versus-real-URL mismatches, and newly-registered sender domains to funnel victims to fake Microsoft sign-in and OAuth consent pages. The lab reproduces those tells as a defender exercise. All figures are attributed as Check Point reported; no numbers are invented.
Does it generate phishing emails or sign-in pages?
No. This is strictly a defensive training drill. It contains no working lure, no credential-capture page and no live link — every URL shown is a defanged, obviously-fake illustrative string (for example teams-microsoft[.]login-verify[.]com) used only so you can learn to recognise the pattern. Nothing here can be sent or clicked to cause harm.
What are the real-world mitigations it points to?
Three that match the campaign. First, verify the destination before you sign in: inspect the real href, trust the From domain over the organiser display name, and read the .ics itself, not just the email body. Second, deploy phishing-resistant authentication — passkeys and hardware security keys defeat credential capture even when a user reaches a convincing fake page, and they neutralise consent phishing far better than a password plus a one-time code. Third, monitor for the infrastructure: alert on external URLs inside .ics attachments and on newly-registered or look-alike sender domains, and review OAuth app consent grants for over-broad scopes.