Microsoft 365 app mailbox access many
One identity read items from MANY DIFFERENT mailboxes through the API in a short window — MailItemsAccessed records whose client is REST/Graph or…
What it detects
One identity read items from MANY DIFFERENT mailboxes through the API in a short window — MailItemsAccessed records whose client is REST/Graph or Exchange Web Services rather than a person's mail client.
This is what mass mailbox harvesting looks like in Microsoft 365. An attacker who has obtained a consented OAuth application — or an app registration with Mail.Read/full_access_as_app — does not sign in as each victim; the app reads every mailbox in the tenant directly, so the sign-in log stays quiet and only the Exchange audit trail shows it. Counting DISTINCT mailboxes rather than events is the point: an application legitimately reading one mailbox a great many times is ordinary, and reading many mailboxes once each is not.
MITRE ATT&CK mapping
False positives and triage
Legitimate tenant-wide applications read many mailboxes by design — backup and archiving products, e-discovery and DLP tooling, journaling, and migration jobs all produce exactly this shape and will trip this rule on every run. It is therefore only useful against a baseline of the app registrations entitled to do it: identify those and treat them as expected. The signal is a NEW app_id doing it, an app whose consent was granted recently (correlate with cloud.identity.m365_oauth_consent_grant and cloud.identity.m365_service_principal_added), or access from an IP or ASN that does not match the vendor the app claims to be.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 65%. Source: rules/cloud/m365_app_mailbox_access_many.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_app_mailbox_access_many
version: 1.0.0
status: stable
severity: high
confidence: 0.65
platforms: [application]
mitre_techniques: [T1114.002, T1098.002]
description: |
One identity read items from MANY DIFFERENT mailboxes through the API in a short
window — `MailItemsAccessed` records whose client is REST/Graph or Exchange Web
Services rather than a person's mail client.
This is what mass mailbox harvesting looks like in Microsoft 365. An attacker who
has obtained a consented OAuth application — or an app registration with
`Mail.Read`/`full_access_as_app` — does not sign in as each victim; the app reads
every mailbox in the tenant directly, so the sign-in log stays quiet and only the
Exchange audit trail shows it. Counting DISTINCT mailboxes rather than events is
the point: an application legitimately reading one mailbox a great many times is
ordinary, and reading many mailboxes once each is not.
match:
provider: Office365
event_action: MailItemsAccessed
raw_message_contains_any:
- "Client=REST"
- "Client=WebServices"
- "ExchangeWebServicesProxy"
- "app_id="
threshold:
count: 3
window_seconds: 3600
distinct: user_name
group_by: [source_ip]
correlation_keys: [source_ip]
false_positive_guidance: |
Legitimate tenant-wide applications read many mailboxes by design — backup and
archiving products, e-discovery and DLP tooling, journaling, and migration jobs all
produce exactly this shape and will trip this rule on every run. It is therefore
only useful against a baseline of the app registrations entitled to do it: identify
those and treat them as expected. The signal is a NEW `app_id` doing it, an app
whose consent was granted recently (correlate with
`cloud.identity.m365_oauth_consent_grant` and
`cloud.identity.m365_service_principal_added`), or access from an IP or ASN that
does not match the vendor the app claims to be.
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.