Notifications
Clear all
Topic starter
27/06/2026 1:56 pm
TL;DR: Attackers are hiding phishing payloads inside Outlook calendar invites and Teams-style meeting requests, including .ics attachments and raw EML code that can create events without visible cues, according to Abnormal AI. The core issue is that mail authentication can succeed while calendar trust assumptions still fail, leaving Microsoft 365 access and user attention exposed.
NHIMG editorial — based on content published by Abnormal AI: calendar invite remediation and Outlook-based phishing abuse
Questions worth separating out
Q: How should security teams handle phishing messages that create calendar invites?
A: They should treat the calendar event as a security object, not just the email that created it.
Q: Why do SPF, DKIM, and DMARC not stop Teams-style phishing?
A: Because those controls validate message authenticity, not attacker intent.
Q: What breaks when malicious OAuth consent is used instead of password theft?
A: Traditional password protection can look successful while access still persists through delegated application permissions.
Practitioner guidance
- Extend phishing response to calendar artefacts Verify that remediation workflows remove Outlook-generated events when the parent message is confirmed malicious, and confirm that restoration works when a message is later reclassified as safe.
- Tighten OAuth consent review paths Restrict which Microsoft 365 applications can request persistent access, and require additional scrutiny for consent prompts that seek profile access or continuous API permissions.
- Treat authenticated mail as untrusted until content is inspected Use message inspection to look for embedded invites, .ics attachments, and hidden EML calendar data before users can interact with the event or link.
What's in the full article
Abnormal AI's full analysis covers the operational detail this post intentionally leaves for the source:
- Detection logic for hidden .ics and raw EML calendar data that Outlook converts into events
- Graph API remediation workflow details for deleting malicious calendar events while preserving legitimate meetings
- Campaign-specific indicators from the Microsoft Teams-style phishing lure and OAuth consent flow
- Setup guidance for permissions used to delete and restore events after remediation decisions
👉 Read Abnormal AI's analysis of calendar invite phishing and Outlook remediation →
Calendar invite phishing in Outlook: what IAM teams need to know?
Explore further
27/06/2026 3:27 pm
Calendar objects have become an identity governance surface. This pattern works because the enterprise still treats inbox security and scheduling security as separate control domains. Once Outlook auto-creates an event, the malicious object can outlive the email that spawned it, which means remediation must account for downstream artefacts as well as the original message. Practitioners should view calendar persistence as a governance problem, not just an email filtering issue.
A few things that frame the scale:
- 5% of organisations maintain a unified inventory of all non-human identities, according to Ultimate Guide to NHIs , Why NHI Security Matters Now.
- Only 44% of developers are reported to follow security best practices for secrets management, which shows how quickly trust assumptions break down when operational controls depend on human discipline.
A question worth separating out:
Q: Who is accountable when a phishing email creates a persistent Microsoft 365 foothold?
A: Accountability sits across messaging, identity, and cloud application governance. Email security owns detection and quarantine, IAM owns consent policy and privileged app approval, and collaboration teams own cleanup of artefacts such as calendar events. If those controls are siloed, the attacker benefits from the gaps between them.
👉 Read our full editorial: Calendar invite phishing exposes Outlook’s trust gap in Microsoft 365
