Microsoft 365 user consent policy weakened
The tenant's authorization policy was changed so ORDINARY USERS may consent to applications (PermissionGrantPolicyIdsAssignedToDefaultUserRole gaining…
What it detects
The tenant's authorization policy was changed so ORDINARY USERS may consent to applications (PermissionGrantPolicyIdsAssignedToDefaultUserRole gaining a ManagePermissionGrantsForSelf policy).
This is the precondition for illicit consent grant, not the grant itself, and that is exactly why it is worth alerting on. With user consent disabled, a consent-phishing lure dead-ends at an admin approval request. With it enabled, every user in the tenant can authorise an attacker's OAuth app against their own mailbox and files, and each of those grants then looks like a normal user action.
One tenant-wide setting change quietly re-opens the door for everyone, so it is cheap to miss among per-user noise and expensive to have missed. The pack already alerts on the consent grants themselves; this catches the change that makes them possible, which is the earlier and more actionable moment.
MITRE ATT&CK mapping
False positives and triage
Tenants do enable user consent deliberately, usually early in a rollout or to reduce admin-approval friction, and often paired with an app-consent policy that bounds WHICH permissions users may grant. Check whether the new value is a restrictive built-in policy (...low-impact) or an unrestricted one, whether the change was made by an admin who routinely edits tenant policy, and whether OAuth consent grants follow it within hours — a policy loosened and immediately used is the sequence that matters, and the pack's consent rules will show the second half.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/m365_user_consent_policy_weakened.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_user_consent_policy_weakened
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1550.001, T1548]
description: |
The tenant's authorization policy was changed so ORDINARY USERS may consent to
applications (`PermissionGrantPolicyIdsAssignedToDefaultUserRole` gaining a
`ManagePermissionGrantsForSelf` policy).
This is the precondition for illicit consent grant, not the grant itself, and
that is exactly why it is worth alerting on. With user consent disabled, a
consent-phishing lure dead-ends at an admin approval request. With it enabled,
every user in the tenant can authorise an attacker's OAuth app against their own
mailbox and files, and each of those grants then looks like a normal user action.
One tenant-wide setting change quietly re-opens the door for everyone, so it is
cheap to miss among per-user noise and expensive to have missed. The pack already
alerts on the consent grants themselves; this catches the change that makes them
possible, which is the earlier and more actionable moment.
match:
# No provider constraint: the SAME "Update authorization policy." record is
# attributed Office365 or AzureAD depending on how the export labels its
# workload, and pinning one silently halves the coverage.
event_action_any:
- "Update authorization policy."
raw_message_contains_any:
- "PermissionGrantPolicyIdsAssignedToDefaultUserRole"
correlation_keys: [user_name]
false_positive_guidance: |
Tenants do enable user consent deliberately, usually early in a rollout or to
reduce admin-approval friction, and often paired with an app-consent policy that
bounds WHICH permissions users may grant. Check whether the new value is a
restrictive built-in policy (`...low-impact`) or an unrestricted one, whether the
change was made by an admin who routinely edits tenant policy, and whether OAuth
consent grants follow it within hours — a policy loosened and immediately used is
the sequence that matters, and the pack's consent rules will show the second half.
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.