[New Rule] Entra ID Named Location Modified

[descambiado]

Summary

Adds a detection for the creation, modification, or deletion of a Conditional Access named location in Entra ID.

Named locations define the trusted or excluded IP ranges and countries that Conditional Access policies evaluate as a condition. An attacker with Conditional Access Administrator or Global Administrator privileges can widen a trusted IP range to include an attacker-controlled address, or remove a country restriction, without touching the Conditional Access policy object itself. Existing policies stay enabled and visible in monitoring dashboards, so alerts that watch for policy state changes do not fire.

Checked the existing ruleset first: the only Conditional Access rule currently in the repo (Entra ID Conditional Access Policy (CAP) Modified) only fires on event.action: "Update conditional access policy", never on a named location change. This is a distinct, unobserved path to the same outcome.

Validation

Detection logic and the investigation guide are derived from audit events generated and captured in a live Entra ID tenant (Microsoft Entra ID P2 trial), not from documentation.

Ran all three operations end to end: created, updated, and deleted a named IP-range location, using RFC 5737 documentation ranges (203.0.113.0/24, 198.51.100.0/24), not real infrastructure.

Category        : Policy
OperationName    : Add named location / Update named location / Delete named location
Initiated by     : User (UPN, object id, IP address present) via ADIbizaUX
Result           : success

target_resources.modifiedProperties (Update):
  NamedLocation.displayName -> unchanged
  NamedLocation.ipRanges    -> old/new diff present
  NamedLocation.isTrusted   -> old/new diff present when toggled

All three operations logged as Category: Policy, actor attribution correct via initiated_by, and the modifiedProperties shape for NamedLocation matches this rule's assumptions.

One operational note worth carrying over from testing: audit log ingestion latency was on the order of minutes, not instant, consistent with what I observed while validating the two rules already merged in #6168.

Checks:

• TOML parses, single MITRE threat block (Defense Evasion), T1562.001
• No non-ASCII characters
• rule_id verified unique against the repository
• severity/risk_score set to medium/47, matching the closest comparable Conditional Access rule already in the ruleset

What I did not verify

• I did not test the case where a named location is renamed without any IP/country change, only additions, removals, and full delete/recreate.
• I could not run detection_rules validate-rule locally (same missing toolchain dependency noted in [New Rule] Entra ID Admin Registered MFA Method for User #6680), so this has only been checked by hand and by parsing. CI will be the first real run.

Notes

Happy to adjust severity or fold this into the existing Conditional Access policy rule instead if you'd rather see it as one broader rule than two narrow ones.