Microsoft 365 mass user deletion
Several directory accounts deleted by one actor in a short window.
What it detects
Several directory accounts deleted by one actor in a short window.
Bulk account deletion is destruction, and in a cloud tenant it is also denial of access: the deleted users cannot sign in to notice or respond, and in Entra a deleted user is recoverable for only 30 days. It appears at the END of an intrusion — after the data is taken — or as the whole point of it, and either way the response is time-boxed by that recovery window, which is why this is critical rather than high.
Grouped by the ACTOR, not the target, so one rampage is one finding naming every account it touched rather than one alert per deleted user.
MITRE ATT&CK mapping
- T1531Account Access Removal· Impact
False positives and triage
Legitimate bulk deletion is real: offboarding after a redundancy round, cleaning up a migration's leftover or test accounts, or a deprovisioning script running on schedule. The discriminators are the actor and the shape — a scripted deprovisioning runs as a service principal or a known admin at a predictable hour, and the accounts share something (a leaver cohort, a test- prefix, an expired-contractor OU). An interactive admin deleting unrelated live accounts out of hours is the case to escalate. Check whether the same actor also appears in sign-in findings before treating it as routine.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/m365_mass_user_deletion.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mass_user_deletion
version: 1.0.0
status: stable
severity: critical
confidence: 0.7
platforms: [application]
mitre_techniques: [T1531]
description: |
Several directory accounts deleted by one actor in a short window.
Bulk account deletion is destruction, and in a cloud tenant it is also denial of
access: the deleted users cannot sign in to notice or respond, and in Entra a
deleted user is recoverable for only 30 days. It appears at the END of an
intrusion — after the data is taken — or as the whole point of it, and either
way the response is time-boxed by that recovery window, which is why this is
critical rather than high.
Grouped by the ACTOR, not the target, so one rampage is one finding naming every
account it touched rather than one alert per deleted user.
match:
provider: Office365
event_action_any:
- "Delete user."
threshold:
count: 5
window_seconds: 3600
group_by: [user_name]
correlation_keys: [user_name]
false_positive_guidance: |
Legitimate bulk deletion is real: offboarding after a redundancy round, cleaning
up a migration's leftover or test accounts, or a deprovisioning script running on
schedule. The discriminators are the actor and the shape — a scripted
deprovisioning runs as a service principal or a known admin at a predictable
hour, and the accounts share something (a leaver cohort, a `test-` prefix, an
expired-contractor OU). An interactive admin deleting unrelated live accounts out
of hours is the case to escalate. Check whether the same actor also appears in
sign-in findings before treating it as routine.
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.