Microsoft 365 collaboration invite lure
A burst of collaboration invitations / mentions / comment notifications sent from one mailbox — the propagation phase of a business email compromise.
What it detects
A burst of collaboration invitations / mentions / comment notifications sent from one mailbox — the propagation phase of a business email compromise.
Once an account is taken over, the attacker stops reading and starts sending. A file-share or project invitation from a real, already-trusted colleague is a far better lure than a spoofed external email: it survives SPF/DKIM/DMARC because it genuinely is that account, it arrives with the sender's real display name, and the recipient has no reason to doubt it. The link in the invite leads to the credential-harvest or consent page, and the compromise spreads — often to other organisations, which turns an internal incident into a notifiable one.
This is the step KiroSec was blind to: on a real BEC case 317 such invitations went out from a compromised mailbox — 379 of the sending events came from the attacker's own IP — and not one rule fired, even while 41 separate recipients reported those exact messages as phishing.
MITRE ATT&CK mapping
False positives and triage
Collaboration invitations are ordinary work: onboarding a team, kicking off a project, or a chatty reviewer commenting through a document will all clear this threshold legitimately. What makes it a finding is the surrounding behaviour — the same account also showing mailbox access bursts, a hiding inbox rule, mass deletion, or send-as impersonation; invitations going to recipients outside the organisation; or the sending client/IP differing from that account's norm. Check whether the invitations name a project the account actually works on, and whether any recipient reported them. Treat a lone burst with no other signal as context, not a verdict.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/m365_collaboration_invite_lure.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_collaboration_invite_lure
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1534, T1566.002]
description: |
A burst of collaboration invitations / mentions / comment notifications sent from
one mailbox — the propagation phase of a business email compromise.
Once an account is taken over, the attacker stops reading and starts sending. A
file-share or project invitation from a real, already-trusted colleague is a far
better lure than a spoofed external email: it survives SPF/DKIM/DMARC because it
genuinely is that account, it arrives with the sender's real display name, and
the recipient has no reason to doubt it. The link in the invite leads to the
credential-harvest or consent page, and the compromise spreads — often to other
organisations, which turns an internal incident into a notifiable one.
This is the step KiroSec was blind to: on a real BEC case 317 such invitations
went out from a compromised mailbox — 379 of the sending events came from the
attacker's own IP — and not one rule fired, even while 41 separate recipients
reported those exact messages as phishing.
match:
provider: Office365
event_action: Create
raw_message_contains_any:
- "invited you to a project"
- "added you to a project"
- "mentioned you in a Project"
- "shared a file with you"
- "shared with you"
- "added a comment"
threshold:
count: 5
window_seconds: 3600
group_by: [user_name]
correlation_keys: [user_name]
false_positive_guidance: |
Collaboration invitations are ordinary work: onboarding a team, kicking off a
project, or a chatty reviewer commenting through a document will all clear this
threshold legitimately. What makes it a finding is the surrounding behaviour —
the same account also showing mailbox access bursts, a hiding inbox rule, mass
deletion, or send-as impersonation; invitations going to recipients outside the
organisation; or the sending client/IP differing from that account's norm. Check
whether the invitations name a project the account actually works on, and whether
any recipient reported them. Treat a lone burst with no other signal as context,
not a verdict (ADR-004).
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.