Microsoft 365 Purview policy tampering
A Microsoft Purview data-protection or retention policy was disabled, removed or weakened.
What it detects
A Microsoft Purview data-protection or retention policy was disabled, removed or weakened.
These policies are the two controls that make M365 exfiltration hard and M365 investigation possible, and each is undone by a single cmdlet:
* **DLP** blocks or flags sensitive data leaving the tenant. Disable the policy and the same exfiltration that would have been stopped proceeds silently — the attacker does not need to evade the control, only to switch it off. * **Retention and litigation hold** are what make deleted mail recoverable. Remove them and the mailbox's history becomes genuinely destructible, which turns a recoverable incident into an unreconstructable one.
Weakening either is an administrative action with no operational upside during an intrusion, which is what makes it a strong signal: unlike most M365 admin activity, there is no benign version that happens to look identical.
MITRE ATT&CK mapping
False positives and triage
Compliance teams tune these policies as a matter of routine, and a Set- on a DLP or retention policy is far more often a false-positive tuning change than an attack. The rule matches Set- as well as Remove- because weakening a policy in place is the quieter way to do it — but that choice is what makes the rule noisy in a tenant with an active compliance programme.
Triage in this order:
* **Read the changed properties in the evidence.** A Set- that narrows the scope, drops a rule, or flips an enforcement mode from Enforce to Audit is the finding. A Set- that adds a location or a new sensitive-info type is the compliance team doing its job. * **Who made the change?** A compliance admin during business hours is normal. A recently privileged account, a service principal, or an account with a risky sign-in is not. * **What surrounds it?** Policy weakening immediately before a mass download, a mass delete, or a bulk external share is the sequence that matters; the change alone is a lead.
For a tenant that tunes these weekly, prefer suppressing the known compliance admins by name over dropping the Set- operations — losing Set- would lose the in-place weakening that an attacker prefers.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 75%. Source: rules/cloud/m365_purview_policy_tampering.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_purview_policy_tampering
version: 1.0.0
status: stable
severity: high
confidence: 0.75
platforms: [application]
mitre_techniques: [T1562.001, T1562.008, T1070]
description: |
A Microsoft Purview data-protection or retention policy was disabled, removed or
weakened.
These policies are the two controls that make M365 exfiltration hard and M365
investigation possible, and each is undone by a single cmdlet:
* **DLP** blocks or flags sensitive data leaving the tenant. Disable the
policy and the same exfiltration that would have been stopped proceeds
silently — the attacker does not need to evade the control, only to switch
it off.
* **Retention and litigation hold** are what make deleted mail recoverable.
Remove them and the mailbox's history becomes genuinely destructible, which
turns a recoverable incident into an unreconstructable one.
Weakening either is an administrative action with no operational upside during
an intrusion, which is what makes it a strong signal: unlike most M365 admin
activity, there is no benign version that happens to look identical.
match:
provider: Office365
event_action_contains_any:
# DLP
- "Remove-DlpCompliancePolicy"
- "Set-DlpCompliancePolicy"
- "Remove-DlpComplianceRule"
- "Set-DlpComplianceRule"
- "Disable-DlpCompliancePolicy"
- "Remove-DlpPolicy"
- "Set-DlpPolicy"
# Retention / holds
- "Remove-RetentionCompliancePolicy"
- "Set-RetentionCompliancePolicy"
- "Remove-RetentionComplianceRule"
- "Set-RetentionComplianceRule"
- "Remove-ComplianceTag"
- "Set-Mailbox -LitigationHoldEnabled"
- "Remove-CaseHoldPolicy"
- "Set-CaseHoldPolicy"
# Audit retention
- "Remove-UnifiedAuditLogRetentionPolicy"
- "Set-UnifiedAuditLogRetentionPolicy"
# Information-barrier / label policy
- "Remove-LabelPolicy"
- "Set-LabelPolicy"
- "Remove-AutoSensitivityLabelPolicy"
correlation_keys: [user_name]
false_positive_guidance: |
Compliance teams tune these policies as a matter of routine, and a `Set-` on a
DLP or retention policy is far more often a false-positive tuning change than an
attack. The rule matches `Set-` as well as `Remove-` because weakening a policy
in place is the quieter way to do it — but that choice is what makes the rule
noisy in a tenant with an active compliance programme.
Triage in this order:
* **Read the changed properties in the evidence.** A `Set-` that narrows the
scope, drops a rule, or flips an enforcement mode from Enforce to Audit is
the finding. A `Set-` that adds a location or a new sensitive-info type is
the compliance team doing its job.
* **Who made the change?** A compliance admin during business hours is normal.
A recently privileged account, a service principal, or an account with a
risky sign-in is not.
* **What surrounds it?** Policy weakening immediately before a mass download,
a mass delete, or a bulk external share is the sequence that matters; the
change alone is a lead.
For a tenant that tunes these weekly, prefer suppressing the known compliance
admins by name over dropping the `Set-` operations — losing `Set-` would lose
the in-place weakening that an attacker prefers.
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.