Microsoft 365 app role assignment granted
An APP ROLE ASSIGNMENT was granted — a user or a service principal was given a role on an enterprise application.
What it detects
An APP ROLE ASSIGNMENT was granted — a user or a service principal was given a role on an enterprise application.
App role assignments are the access path that directory-role reviews miss. "Who is a Global Administrator" says nothing about who holds a role on the application federating your AWS console, your HR system, or your VPN. Granting a role to a service principal is the more serious half: it hands standing, non-interactive access to an identity that has no MFA, no sign-in risk score, and no owner who notices it logging in at 3am.
The pack already covers illicit CONSENT (permissions an app requests) and credential additions (how an app authenticates). This is the third leg — who is entitled to use the app once it exists — and it had no rule.
Deliberately medium and single-event: assignment is also how ordinary access is granted, so this is a lead to correlate rather than a finding on its own.
MITRE ATT&CK mapping
False positives and triage
In a tenant that manages application access properly this fires routinely — every new joiner assigned to an SSO app produces one — so read it alongside other findings rather than alone, and expect volume proportional to headcount churn.
Escalate on: an assignment to a SERVICE PRINCIPAL rather than a user (rare and rarely routine), an assignment granted by an actor who does not administer that application, an assignment to an account that is a guest or was created in the last few days, or one landing shortly after a consent grant or credential addition on the same application — that sequence is an attacker finishing the job of making an app usable to them.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 55%. Source: rules/cloud/m365_app_role_assignment_granted.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_app_role_assignment_granted
version: 1.0.0
status: stable
severity: medium
confidence: 0.55
platforms: [application]
mitre_techniques: [T1136.003, T1098.003]
description: |
An APP ROLE ASSIGNMENT was granted — a user or a service principal was given a
role on an enterprise application.
App role assignments are the access path that directory-role reviews miss.
"Who is a Global Administrator" says nothing about who holds a role on the
application federating your AWS console, your HR system, or your VPN. Granting
a role to a service principal is the more serious half: it hands standing,
non-interactive access to an identity that has no MFA, no sign-in risk score,
and no owner who notices it logging in at 3am.
The pack already covers illicit CONSENT (permissions an app requests) and
credential additions (how an app authenticates). This is the third leg —
who is entitled to use the app once it exists — and it had no rule.
Deliberately medium and single-event: assignment is also how ordinary access is
granted, so this is a lead to correlate rather than a finding on its own.
match:
provider_any: [Office365, AzureAD]
event_action_contains_any:
- "Add app role assignment grant to user"
- "Add app role assignment to service principal"
- "Add app role assignment to group"
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
In a tenant that manages application access properly this fires routinely —
every new joiner assigned to an SSO app produces one — so read it alongside
other findings rather than alone, and expect volume proportional to headcount
churn.
Escalate on: an assignment to a SERVICE PRINCIPAL rather than a user (rare and
rarely routine), an assignment granted by an actor who does not administer that
application, an assignment to an account that is a guest or was created in the
last few days, or one landing shortly after a consent grant or credential
addition on the same application — that sequence is an attacker finishing the
job of making an app usable to them.
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.