Microsoft 365 inbox rule change

Any Microsoft 365 mailbox inbox rule was created, modified, removed, enabled, or disabled (New-InboxRule / Set-InboxRule / UpdateInboxRules / Remove-InboxRule / Enable-InboxRule / Disable-InboxRule). Inbox-rule tampering is the signature post-BEC move: a compromised mailbox gets a rule that forwards or hides mail, and the attacker later removes or disables it to cover their tracks. This rule surfaces the WHOLE lifecycle as a lead — including plain creations and edits that carry no forwarding/deletion keywords, which the high-severity forwarding (m365_inbox_forwarding_rule) and hiding (m365_mailbox_hiding_rule) rules do not fire on. Deliberately medium/low-confidence because benign rule changes are common; the escalation is an inbox-rule change from a client IP the offline IOC / reputation sweep has flagged, or from an unfamiliar IP right after a suspicious sign-in — correlate this alert's source_ip against those findings.

• T1564.008Hide Artifacts: Email Hiding Rules· Defense Evasion
• T1114.003Email Collection: Email Forwarding Rule· Collection

Users and admins create, edit, and delete their own inbox rules constantly, so this fires broadly and is a LEAD, not a verdict — expect to tune it per tenant. The high-fidelity signal is an inbox-rule change whose source_ip matches the case's IP/IOC blocklist sweep or a suspicious sign-in for the same mailbox, or a forwarding/deletion rule (already raised at high severity by the dedicated rules). Confirm the mailbox owner made the change and read the rule name/actions in the event evidence before escalating.

Declarative YAML read by the detection engine — data, never executed. Confidence 40%. Source: rules/cloud/m365_inbox_rule_change.yaml, licensed under the Apache License 2.0.

id: cloud.identity.m365_inbox_rule_change
version: 1.0.0
status: stable
severity: medium
confidence: 0.4
platforms: [application]
mitre_techniques: [T1564.008, T1114.003]
description: |
  Any Microsoft 365 mailbox inbox rule was created, modified, removed, enabled, or
  disabled (New-InboxRule / Set-InboxRule / UpdateInboxRules / Remove-InboxRule /
  Enable-InboxRule / Disable-InboxRule). Inbox-rule tampering is the signature
  post-BEC move: a compromised mailbox gets a rule that forwards or hides mail, and
  the attacker later removes or disables it to cover their tracks. This rule
  surfaces the WHOLE lifecycle as a lead — including plain creations and edits that
  carry no forwarding/deletion keywords, which the high-severity forwarding
  (`m365_inbox_forwarding_rule`) and hiding (`m365_mailbox_hiding_rule`) rules do
  not fire on. Deliberately medium/low-confidence because benign rule changes are
  common; the escalation is an inbox-rule change from a client IP the offline IOC /
  reputation sweep has flagged, or from an unfamiliar IP right after a suspicious
  sign-in — correlate this alert's `source_ip` against those findings.
match:
  provider: Office365
  event_action_any:
    - New-InboxRule
    - Set-InboxRule
    - UpdateInboxRules
    - Remove-InboxRule
    - Enable-InboxRule
    - Disable-InboxRule
correlation_keys: [user_name, source_ip]
false_positive_guidance: |
  Users and admins create, edit, and delete their own inbox rules constantly, so
  this fires broadly and is a LEAD, not a verdict — expect to tune it per tenant.
  The high-fidelity signal is an inbox-rule change whose `source_ip` matches the
  case's IP/IOC blocklist sweep or a suspicious sign-in for the same mailbox, or a
  forwarding/deletion rule (already raised at high severity by the dedicated rules).
  Confirm the mailbox owner made the change and read the rule name/actions in the
  event evidence before escalating.

• Microsoft 365 mail written directly to folderSeverity high
• Microsoft 365 mailbox hiding ruleSeverity high
• Microsoft 365 payment mail hiding ruleSeverity critical
• Microsoft 365 legacy protocol enabledSeverity high
• Microsoft 365 transport rule reorderedSeverity high
• Microsoft 365 AI agent createdSeverity high