Microsoft 365 calendar contacts delegated
A named account was granted read rights on someone's CALENDAR or CONTACTS.
What it detects
A named account was granted read rights on someone's CALENDAR or CONTACTS.
Attention goes to the inbox, so the surveillance goes next door. A calendar gives up who an executive is meeting, when they travel, which deal has a closing date and when the room will be empty — everything needed to time a wire-fraud approach or an in-person visit — and the contact folder supplies the internal names and addresses to make the approach credible. None of it touches mail, so mailbox rules, forwarding rules and message trace stay silent.
The pack already covers a folder opened to Everyone, Default or Anonymous. This covers the quieter version: rights granted to ONE specific principal, which is what an attacker does when they want the access to keep working and not be noticed in a permissions review.
The regex requires a grantee that looks like a real address, which is what separates this from the default entries every mailbox carries — Owner@local, Member@local and the holiday calendars shared to Everyone with no rights are the normal population of these records, and none of them match.
MITRE ATT&CK mapping
False positives and triage
Delegation of a calendar is a normal working arrangement — an assistant, a manager, a shared team calendar — so the grant on its own proves nothing. Ask whether the grantee has any business relationship with the mailbox owner, and whether the grantee is an EXTERNAL identity: a guest or a partner address on an executive's calendar is the version worth pursuing immediately. Check who ran the change; a delegation the owner made themselves in Outlook is different from one an administrator or a third account made on their behalf. Finally, look at whether the grantee's own account shows recent sign-in findings — a legitimate delegation to a colleague whose account was taken over is the same evidence with a different victim, and the response is the colleague, not the calendar.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/m365_calendar_contacts_delegated.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_calendar_contacts_delegated
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1114, T1213, T1098.002]
description: |
A named account was granted read rights on someone's CALENDAR or CONTACTS.
Attention goes to the inbox, so the surveillance goes next door. A calendar gives
up who an executive is meeting, when they travel, which deal has a closing date
and when the room will be empty — everything needed to time a wire-fraud approach
or an in-person visit — and the contact folder supplies the internal names and
addresses to make the approach credible. None of it touches mail, so mailbox
rules, forwarding rules and message trace stay silent.
The pack already covers a folder opened to `Everyone`, `Default` or `Anonymous`.
This covers the quieter version: rights granted to ONE specific principal, which
is what an attacker does when they want the access to keep working and not be
noticed in a permissions review.
The regex requires a grantee that looks like a real address, which is what
separates this from the default entries every mailbox carries — `Owner@local`,
`Member@local` and the holiday calendars shared to `Everyone` with no rights are
the normal population of these records, and none of them match.
match:
provider: Office365
event_action_contains_any:
- ModifyFolderPermissions
- AddFolderPermissions
- Add-MailboxFolderPermission
- Set-MailboxFolderPermission
raw_message_regex: "folder_member=[^ @]+@[^ @]+\\.[A-Za-z]{2,}.*folder_rights=[^=]*(ReadAny|Reviewer|Editor|Author|Owner|Contributor|FreeBusyDetailed).*folder(_path)?=[^ ]*(Calendar|Contacts)"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Delegation of a calendar is a normal working arrangement — an assistant, a
manager, a shared team calendar — so the grant on its own proves nothing. Ask
whether the grantee has any business relationship with the mailbox owner, and
whether the grantee is an EXTERNAL identity: a guest or a partner address on an
executive's calendar is the version worth pursuing immediately. Check who ran the
change; a delegation the owner made themselves in Outlook is different from one
an administrator or a third account made on their behalf. Finally, look at
whether the grantee's own account shows recent sign-in findings — a legitimate
delegation to a colleague whose account was taken over is the same evidence with
a different victim, and the response is the colleague, not the calendar.
Related detections
Run this rule on your own logs — offline
KIROSEC runs this rule and the rest of the library over Windows, Linux, macOS and cloud audit logs on the analyst's own machine. Every alert links to the events that raised it, and nothing leaves the device.