Microsoft 365 transport rule reordered
An EXISTING mail-flow rule was reordered or short-circuited — a Set-TransportRule that changes Priority or StopRuleProcessing.
What it detects
An EXISTING mail-flow rule was reordered or short-circuited — a Set-TransportRule that changes Priority or StopRuleProcessing.
Mail flow evaluates transport rules in priority order, and StopRuleProcessing on an earlier rule ends the chain. So a compliance, journaling or DLP rule can be disabled without being touched: push it below the attacker's rule, or set an earlier rule to stop processing, and it never runs. Nothing is deleted, nothing is disabled, and the rule keeps reporting as enabled — a tenant auditing its mail-flow configuration sees exactly the rule it expects to see, in the list, switched on.
Deliberately separate from m365_transport_rule, which catches a rule that forwards or blind-copies. Merging the two was tried and rejected on evidence: Priority is set on almost every rule CREATION, so folding it into that rule made two disabled test rules in a corpus capture alert. Set on an existing rule is the shape that carries meaning; New is not.
MITRE ATT&CK mapping
False positives and triage
Mail-flow rules are reordered legitimately whenever a new one is introduced, so the parameter alone is not the finding — WHICH rule moved and WHICH WAY is. Read the rule name in the record: a compliance, journaling, DLP or quarantine rule pushed to a higher number (later) is the case worth pursuing, while an ordinary business rule being slotted into place is housekeeping. StopRuleProcessing set to True deserves more attention than a priority change, because it ends evaluation outright. Check what else the same actor did in the window: this technique exists to make room for another rule, so a reorder with no accompanying change is usually genuine administration.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/m365_transport_rule_reordered.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_transport_rule_reordered
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1562.001, T1114.003]
description: |
An EXISTING mail-flow rule was reordered or short-circuited — a `Set-TransportRule`
that changes `Priority` or `StopRuleProcessing`.
Mail flow evaluates transport rules in priority order, and `StopRuleProcessing` on
an earlier rule ends the chain. So a compliance, journaling or DLP rule can be
disabled without being touched: push it below the attacker's rule, or set an
earlier rule to stop processing, and it never runs. Nothing is deleted, nothing is
disabled, and the rule keeps reporting as enabled — a tenant auditing its mail-flow
configuration sees exactly the rule it expects to see, in the list, switched on.
Deliberately separate from `m365_transport_rule`, which catches a rule that
forwards or blind-copies. Merging the two was tried and rejected on evidence:
`Priority` is set on almost every rule CREATION, so folding it into that rule made
two disabled test rules in a corpus capture alert. `Set` on an existing rule is
the shape that carries meaning; `New` is not.
match:
provider: Office365
event_action_any:
- Set-TransportRule
raw_message_contains_any:
- "Priority"
- "StopRuleProcessing"
correlation_keys: [user_name]
false_positive_guidance: |
Mail-flow rules are reordered legitimately whenever a new one is introduced, so
the parameter alone is not the finding — WHICH rule moved and WHICH WAY is. Read
the rule name in the record: a compliance, journaling, DLP or quarantine rule
pushed to a higher number (later) is the case worth pursuing, while an ordinary
business rule being slotted into place is housekeeping. `StopRuleProcessing` set
to `True` deserves more attention than a priority change, because it ends
evaluation outright. Check what else the same actor did in the window: this
technique exists to make room for another rule, so a reorder with no accompanying
change is usually genuine administration.
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.