Microsoft 365 audit license downgrade
A user's Microsoft 365 licence was changed ("Change user license").
What it detects
A user's Microsoft 365 licence was changed ("Change user license").
Licence changes are mundane, with one consequential exception: the mailbox-access audit records an investigation depends on — MailItemsAccessed, the only evidence that says WHICH messages an intruder read — are a Purview Audit (Premium) feature. Removing that licence from an account silently stops the logging for it. Nothing is disabled, no audit setting changes, and the account keeps working; the evidence simply stops being generated. It is defence evasion disguised as licence administration, which is why it is worth surfacing at all.
MITRE ATT&CK mapping
- T1562.008Impair Defenses: Disable or Modify Cloud Logs· Defense Evasion
False positives and triage
Licence assignment is routine — onboarding, offboarding, and cost-driven reassignment all produce this, in bulk, and it will usually be exactly that. Rated medium/low-confidence for that reason: this is timeline context, not a verdict. The signal is a licence REMOVED from an account that is already under investigation, a change made by an account that does not normally administer licensing, or a change immediately before mailbox activity that then has no MailItemsAccessed records to explain it.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 50%. Source: rules/cloud/m365_audit_license_downgrade.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_audit_license_downgrade
version: 1.0.0
status: stable
severity: medium
confidence: 0.5
platforms: [application]
mitre_techniques: [T1562.008]
description: |
A user's Microsoft 365 licence was changed ("Change user license").
Licence changes are mundane, with one consequential exception: the mailbox-access
audit records an investigation depends on — `MailItemsAccessed`, the only evidence
that says WHICH messages an intruder read — are a Purview Audit (Premium) feature.
Removing that licence from an account silently stops the logging for it. Nothing is
disabled, no audit setting changes, and the account keeps working; the evidence
simply stops being generated. It is defence evasion disguised as licence
administration, which is why it is worth surfacing at all.
match:
provider_any: [Office365, AzureAD]
event_action_contains_any:
- "Change user license"
- "Change user licenses"
correlation_keys: [target_user_name]
false_positive_guidance: |
Licence assignment is routine — onboarding, offboarding, and cost-driven
reassignment all produce this, in bulk, and it will usually be exactly that. Rated
medium/low-confidence for that reason: this is timeline context, not a verdict.
The signal is a licence REMOVED from an account that is already under
investigation, a change made by an account that does not normally administer
licensing, or a change immediately before mailbox activity that then has no
`MailItemsAccessed` records to explain it.
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.