Microsoft 365 MFA policy changed
The tenant's multi-factor authentication policy was rewritten (Set Company Information changing StrongAuthenticationPolicy).
What it detects
The tenant's multi-factor authentication policy was rewritten (Set Company Information changing StrongAuthenticationPolicy).
This is where per-tenant MFA behaviour lives, including the TRUSTED IP ranges that are allowed to skip MFA entirely. Adding an attacker-controlled address to that list disables MFA for them alone while leaving it enabled — and visibly healthy — for everybody else, so a posture review sees nothing wrong. It is a tenant-wide control change disguised as a company-information edit.
MITRE ATT&CK mapping
False positives and triage
Tenants do legitimately configure trusted IPs for their own offices, and a Conditional Access migration will touch this policy. The signal is a change with no matching project, one made by an account that does not normally administer identity, or one whose new range is not an address the organisation owns — read the policy diff and compare the ranges against known egress addresses. Because the change is tenant-wide, treat an unexplained one as urgent even if only one range was added.
The rule
Declarative YAML read by the detection engine — data, never executed. Confidence 70%. Source: rules/cloud/m365_mfa_policy_changed.yaml, licensed under the Apache License 2.0.
id: cloud.identity.m365_mfa_policy_changed
version: 1.0.0
status: stable
severity: high
confidence: 0.7
platforms: [application]
mitre_techniques: [T1562.007, T1556.006]
description: |
The tenant's multi-factor authentication policy was rewritten
(`Set Company Information` changing `StrongAuthenticationPolicy`).
This is where per-tenant MFA behaviour lives, including the TRUSTED IP ranges that
are allowed to skip MFA entirely. Adding an attacker-controlled address to that list
disables MFA for them alone while leaving it enabled — and visibly healthy — for
everybody else, so a posture review sees nothing wrong. It is a tenant-wide control
change disguised as a company-information edit.
match:
provider_any: [Office365, AzureAD]
event_action_contains_any:
- Set Company Information
- Set-MsolCompanySettings
raw_message_contains_any:
- StrongAuthenticationPolicy
- TrustedIp
- SkipMfa
correlation_keys: [user_name]
false_positive_guidance: |
Tenants do legitimately configure trusted IPs for their own offices, and a
Conditional Access migration will touch this policy. The signal is a change with no
matching project, one made by an account that does not normally administer identity,
or one whose new range is not an address the organisation owns — read the policy diff
and compare the ranges against known egress addresses. Because the change is
tenant-wide, treat an unexplained one as urgent even if only one range was added.
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.