Microsoft 365 mailbox export request
A native Exchange mailbox export was started — an entire mailbox written out as a .pst to a file share or blob container.
What it detects
A native Exchange mailbox export was started — an entire mailbox written out as a .pst to a file share or blob container.
This is bulk mail theft with almost no mail-access telemetry behind it. Reading a mailbox item by item leaves thousands of MailItemsAccessed records and trips every volume rule the pack has; New-MailboxExportRequest produces one administrative event and then copies years of correspondence, attachments and calendar in a single job that the mailbox owner cannot see and their client never reflects.
The destination is the part to read first. The cmdlet takes a UNC path or a blob URL, so the record names where a complete copy of someone's mail was just sent.
MITRE ATT&CK mapping
False positives and triage
Exports happen for real reasons — a legal hold, an offboarding archive, a migration rollback — and each of those has a request behind it, so the first question is always whether one exists. After that, three things decide it: WHOSE mailbox (an executive or finance account raises the stakes), WHERE it went (a path on the organisation's own file server is different from a blob container in an unfamiliar storage account, and a URL should be resolved before anything else), and WHO ran it (mailbox export requires a high Exchange role, so an account that has it and never uses it is worth as much attention as the export). Treat the mailbox as fully disclosed unless the destination is confirmed to be internal and the file is accounted for.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/m365_mailbox_export_request.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mailbox_export_request
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1114.002, T1005, T1530]
description: |
A native Exchange mailbox export was started — an entire mailbox written out as
a `.pst` to a file share or blob container.
This is bulk mail theft with almost no mail-access telemetry behind it. Reading a
mailbox item by item leaves thousands of `MailItemsAccessed` records and trips
every volume rule the pack has; `New-MailboxExportRequest` produces one
administrative event and then copies years of correspondence, attachments and
calendar in a single job that the mailbox owner cannot see and their client never
reflects.
The destination is the part to read first. The cmdlet takes a UNC path or a blob
URL, so the record names where a complete copy of someone's mail was just sent.
match:
provider: Office365
event_action_any:
- New-MailboxExportRequest
- Start-MailboxExportRequest
- Resume-MailboxExportRequest
- Set-MailboxExportRequest
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
Exports happen for real reasons — a legal hold, an offboarding archive, a
migration rollback — and each of those has a request behind it, so the first
question is always whether one exists. After that, three things decide it: WHOSE
mailbox (an executive or finance account raises the stakes), WHERE it went (a
path on the organisation's own file server is different from a blob container in
an unfamiliar storage account, and a URL should be resolved before anything else),
and WHO ran it (mailbox export requires a high Exchange role, so an account that
has it and never uses it is worth as much attention as the export). Treat the
mailbox as fully disclosed unless the destination is confirmed to be internal and
the file is accounted for.
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.