Microsoft 365 application impersonation granted
The ApplicationImpersonation role was assigned in Exchange Online.
What it detects
The ApplicationImpersonation role was assigned in Exchange Online.
This role lets its holder act AS any mailbox in the tenant — read it, send from it, manage it — without the mailbox owner's credentials, without their MFA, and without generating a delegation entry on the mailbox itself. It is a tenant-wide mailbox skeleton key, and unlike per-mailbox delegation it leaves nothing visible on the mailboxes it reaches.
It earns its own rule rather than folding into the app-permission rules because it arrives by a different route: ApplicationImpersonation is an Exchange RBAC MANAGEMENT ROLE assignment (New-ManagementRoleAssignment), not an OAuth app permission. m365_app_permission_escalation watches app registrations and m365_high_privilege_consent watches consent — neither sees an RBAC role assignment, so without this rule the most direct path to every mailbox in the tenant is the one nothing was watching.
Microsoft has been retiring the role in favour of scoped RBAC for applications, which makes a new assignment *more* notable over time, not less: legitimate new uses are increasingly rare while its usefulness to an attacker is unchanged.
MITRE ATT&CK mapping
False positives and triage
There are real uses, and they cluster in a small set of products: mailbox migration tools, backup and archiving products, journaling, CRM/telephony integrations that read calendars, and some e-discovery tooling. Each assigns the role once, at deployment, usually to a dedicated service account.
So the questions are about provenance, not the role:
* **Was a product deployed?** Correlate with change records. A migration that nobody scheduled is not a migration. * **Who holds it now?** The assignee should be a service account whose purpose is documented. A regular user account, or an account that was granted admin rights in the same window, is an incident. * **Is it scoped?** An assignment with a management scope limiting it to a subset of mailboxes is a considered deployment; an unscoped one reaches everything.
A standing assignment discovered during a review is worth raising even when it turns out to be legitimate: a migration finished two years ago should not still hold a key to every mailbox, and this is one of the most common findings in an M365 posture review.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 85%. Source: rules/cloud/m365_application_impersonation_granted.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_application_impersonation_granted
version: 1.0.0
status: stable
severity: critical
confidence: 0.85
platforms: [application]
mitre_techniques: [T1098.002, T1098.003, T1114.002]
description: |
The `ApplicationImpersonation` role was assigned in Exchange Online.
This role lets its holder act AS any mailbox in the tenant — read it, send from
it, manage it — without the mailbox owner's credentials, without their MFA, and
without generating a delegation entry on the mailbox itself. It is a
tenant-wide mailbox skeleton key, and unlike per-mailbox delegation it leaves
nothing visible on the mailboxes it reaches.
It earns its own rule rather than folding into the app-permission rules because
it arrives by a different route: `ApplicationImpersonation` is an Exchange RBAC
MANAGEMENT ROLE assignment (`New-ManagementRoleAssignment`), not an OAuth app
permission. `m365_app_permission_escalation` watches app registrations and
`m365_high_privilege_consent` watches consent — neither sees an RBAC role
assignment, so without this rule the most direct path to every mailbox in the
tenant is the one nothing was watching.
Microsoft has been retiring the role in favour of scoped RBAC for applications,
which makes a new assignment *more* notable over time, not less: legitimate new
uses are increasingly rare while its usefulness to an attacker is unchanged.
match:
provider: Office365
raw_message_contains_any:
- ApplicationImpersonation
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
There are real uses, and they cluster in a small set of products: mailbox
migration tools, backup and archiving products, journaling, CRM/telephony
integrations that read calendars, and some e-discovery tooling. Each assigns
the role once, at deployment, usually to a dedicated service account.
So the questions are about provenance, not the role:
* **Was a product deployed?** Correlate with change records. A migration that
nobody scheduled is not a migration.
* **Who holds it now?** The assignee should be a service account whose purpose
is documented. A regular user account, or an account that was granted admin
rights in the same window, is an incident.
* **Is it scoped?** An assignment with a management scope limiting it to a
subset of mailboxes is a considered deployment; an unscoped one reaches
everything.
A standing assignment discovered during a review is worth raising even when it
turns out to be legitimate: a migration finished two years ago should not still
hold a key to every mailbox, and this is one of the most common findings in an
M365 posture review.
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.