Microsoft 365 admin role member removed
A member was removed from a directory role.
What it detects
A member was removed from a directory role.
The pack already alerts when someone is ADDED to a privileged role; removal is the other half and is not merely its opposite. Stripping the legitimate administrators is how an intruder who has taken over one admin account keeps the others from responding — it is a defensive move against the incident responder, and it lands during the response rather than before it.
Deliberately medium and single-event. Role membership legitimately changes during offboarding and access reviews, so this is a lead to correlate — most valuable when the actor or the target already appears in another finding — rather than a standalone verdict.
MITRE ATT&CK mapping
False positives and triage
This is the noisiest rule in the admin-activity set, by design — routine offboarding, access reviews, and role rotations all produce it, so in a healthy tenant most hits are benign and it should be read alongside other findings rather than alone. Escalate on: removal of an account that is not leaving, removal by an actor who does not normally administer roles, removal shortly after a suspicious sign-in by the SAME actor, or several removals clustered in minutes (an access review is paced by a human reading a list). Whether the removed member was a Global Administrator matters more than the count.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 50%. Source: rules/cloud/m365_admin_role_member_removed.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_admin_role_member_removed
version: 1.0.0
status: stable
severity: medium
confidence: 0.5
platforms: [application]
mitre_techniques: [T1531, T1098]
description: |
A member was removed from a directory role.
The pack already alerts when someone is ADDED to a privileged role; removal is
the other half and is not merely its opposite. Stripping the legitimate
administrators is how an intruder who has taken over one admin account keeps the
others from responding — it is a defensive move against the incident responder,
and it lands during the response rather than before it.
Deliberately medium and single-event. Role membership legitimately changes during
offboarding and access reviews, so this is a lead to correlate — most valuable
when the actor or the target already appears in another finding — rather than a
standalone verdict.
match:
provider: Office365
event_action_any:
- "Remove member from role."
correlation_keys: [user_name, target_user_name]
false_positive_guidance: |
This is the noisiest rule in the admin-activity set, by design — routine
offboarding, access reviews, and role rotations all produce it, so in a healthy
tenant most hits are benign and it should be read alongside other findings rather
than alone. Escalate on: removal of an account that is not leaving, removal by an
actor who does not normally administer roles, removal shortly after a suspicious
sign-in by the SAME actor, or several removals clustered in minutes (an access
review is paced by a human reading a list). Whether the removed member was a
Global Administrator matters more than the count.
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.