Microsoft 365 mailbox region moved
A mailbox's data RESIDENCY was changed — PreferredDataLocation or RemoteRoutingAddress altered, or the mailbox moved outright.
What it detects
A mailbox's data RESIDENCY was changed — PreferredDataLocation or RemoteRoutingAddress altered, or the mailbox moved outright.
Where the data lives decides which monitoring sees it. Moving a mailbox to another geo backend can put it outside the region a tenant's DLP, archiving and in-country logging are scoped to, so collection continues from a place the controls do not watch. Nothing is deleted and nothing is forwarded, which is why it is quiet: the mailbox still exists and still receives mail.
Residency is a provisioning decision, set once when the account is created and changed only for a relocation with an HR record behind it. Mid-life changes are rare enough to look at every time.
MITRE ATT&CK mapping
False positives and triage
Multi-geo tenants move mailboxes legitimately when someone relocates, and a hybrid migration changes RemoteRoutingAddress on every mailbox it touches — in bulk, by a migration account, over a planned window. That bulk-and-scheduled shape is the benign one. Escalate a SINGLE mailbox moved in isolation, especially an executive or finance account, or a move by an actor with no migration role. Check the new region against where the user actually works; a relocation to a geo the company has no presence in answers the question by itself.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 60%. Source: rules/cloud/m365_mailbox_region_moved.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mailbox_region_moved
version: 1.0.0
status: stable
severity: high
confidence: 0.6
platforms: [application]
mitre_techniques: [T1213.002, T1074.002]
description: |
A mailbox's data RESIDENCY was changed — `PreferredDataLocation` or
`RemoteRoutingAddress` altered, or the mailbox moved outright.
Where the data lives decides which monitoring sees it. Moving a mailbox to
another geo backend can put it outside the region a tenant's DLP, archiving and
in-country logging are scoped to, so collection continues from a place the
controls do not watch. Nothing is deleted and nothing is forwarded, which is why
it is quiet: the mailbox still exists and still receives mail.
Residency is a provisioning decision, set once when the account is created and
changed only for a relocation with an HR record behind it. Mid-life changes are
rare enough to look at every time.
match:
provider: Office365
event_action_any:
- Set-Mailbox
- Move-Mailbox
- New-MoveRequest
raw_message_contains_any:
- "PreferredDataLocation"
- "RemoteRoutingAddress"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Multi-geo tenants move mailboxes legitimately when someone relocates, and a
hybrid migration changes `RemoteRoutingAddress` on every mailbox it touches — in
bulk, by a migration account, over a planned window. That bulk-and-scheduled
shape is the benign one. Escalate a SINGLE mailbox moved in isolation, especially
an executive or finance account, or a move by an actor with no migration role.
Check the new region against where the user actually works; a relocation to a geo
the company has no presence in answers the question by itself.
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.