Microsoft Entra ID Conditional Access Policy (CAP) Modified

Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2020/09/01"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/03/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity.
 11"""
 12from = "now-9m"
 13index = ["filebeat-*", "logs-azure*"]
 14language = "kuery"
 15license = "Elastic License v2"
 16name = "Microsoft Entra ID Conditional Access Policy (CAP) Modified"
 17note = """## Triage and analysis
 18
 19## Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified
 20
 21Azure Conditional Access Policies (CAPs) are critical for enforcing secure access requirements such as multi-factor authentication (MFA), restricting specific users or groups, and managing sign-in conditions. Modifying these policies can be a technique for weakening an organization’s defenses and maintaining persistence after initial access.
 22
 23This rule detects a successful update to a Conditional Access Policy in Microsoft Entra ID (formerly Azure AD).
 24
 25### Possible Investigation Steps
 26
 27- **Identify the user who modified the policy:**
 28  - Check the value of `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to determine the identity that made the change.
 29  - Investigate their recent activity to determine if this change was expected or authorized.
 30
 31- **Review the modified policy name:**
 32  - Look at `azure.auditlogs.properties.target_resources.*.display_name` to find the name of the affected policy.
 33  - Determine whether this policy is related to critical controls (e.g., requiring MFA for admins).
 34
 35- **Analyze the policy change:**
 36  - Compare the `old_value` and `new_value` fields under `azure.auditlogs.properties.target_resources.*.modified_properties.*`.
 37  - Look for security-reducing changes, such as:
 38    - Removing users/groups from enforcement.
 39    - Disabling MFA or risk-based conditions.
 40    - Introducing exclusions that reduce the policy’s coverage.
 41
 42- **Correlate with other activity:**
 43  - Pivot on `azure.auditlogs.properties.activity_datetime` to identify if any suspicious sign-ins occurred after the policy was modified.
 44  - Check for related authentication logs, particularly from the same IP address (`azure.auditlogs.properties.initiated_by.user.ipAddress`).
 45
 46- **Assess the user's legitimacy:**
 47  - Review the initiator’s Azure role, group memberships, and whether their account was recently elevated or compromised.
 48  - Investigate whether this user has a history of modifying policies or if this is anomalous.
 49
 50### Validation & False Positive Considerations
 51
 52- **Authorized administrative changes:** Some organizations routinely update CAPs as part of policy tuning or role-based access reviews.
 53- **Security reviews or automation:** Scripts, CI/CD processes, or third-party compliance tools may programmatically update CAPs.
 54- **Employee lifecycle events:** Policy changes during employee onboarding/offboarding may include updates to access policies.
 55
 56If any of these cases apply and align with the activity's context, consider tuning the rule or adding exceptions for expected patterns.
 57
 58### Response & Remediation
 59
 60- Revert unauthorized or insecure changes to the Conditional Access Policy immediately.
 61- Temporarily increase monitoring of CAP modifications and sign-in attempts.
 62- Lock or reset the credentials of the user account that made the change if compromise is suspected.
 63- Conduct a broader access review of conditional access policies and privileged user activity.
 64- Implement stricter change management and alerting around CAP changes.
 65"""
 66references = [
 67    "https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview",
 68    "https://www.rezonate.io/blog/microsoft-entra-id-the-complete-guide-to-conditional-access-policies/"
 69]
 70risk_score = 47
 71rule_id = "bc48bba7-4a23-4232-b551-eca3ca1e3f20"
 72severity = "medium"
 73tags = [
 74    "Domain: Cloud",
 75    "Data Source: Azure",
 76    "Data Source: Microsoft Entra ID",
 77    "Data Source: Microsoft Entra ID Audit Logs",
 78    "Use Case: Identity and Access Audit",
 79    "Use Case: Configuration Audit",
 80    "Tactic: Persistence",
 81    "Resources: Investigation Guide"
 82]
 83timestamp_override = "event.ingested"
 84type = "new_terms"
 85
 86query = '''
 87event.dataset: "azure.auditlogs"
 88    and event.action:"Update conditional access policy"
 89    and event.outcome: "success"
 90'''
 91
 92
 93[[rule.threat]]
 94framework = "MITRE ATT&CK"
 95[[rule.threat.technique]]
 96id = "T1556"
 97name = "Modify Authentication Process"
 98reference = "https://attack.mitre.org/techniques/T1556/"
 99
100[[rule.threat.technique.subtechnique]]
101id = "T1556.009"
102name = "Conditional Access Policies"
103reference = "https://attack.mitre.org/techniques/T1556/009/"
104
105
106[rule.threat.tactic]
107id = "TA0003"
108name = "Persistence"
109reference = "https://attack.mitre.org/tactics/TA0003/"
110
111[rule.new_terms]
112field = "new_terms_fields"
113value = ["azure.auditlogs.properties.initiated_by.user.userPrincipalName"]
114[[rule.new_terms.history_window_start]]
115field = "history_window_start"
116value = "now-14d"
...
toml

Azure Conditional Access Policies (CAPs) are critical for enforcing secure access requirements such as multi-factor authentication (MFA), restricting specific users or groups, and managing sign-in conditions. Modifying these policies can be a technique for weakening an organization’s defenses and maintaining persistence after initial access.

This rule detects a successful update to a Conditional Access Policy in Microsoft Entra ID (formerly Azure AD).

  • Identify the user who modified the policy:

    • Check the value of azure.auditlogs.properties.initiated_by.user.userPrincipalName to determine the identity that made the change.
    • Investigate their recent activity to determine if this change was expected or authorized.
  • Review the modified policy name:

    • Look at azure.auditlogs.properties.target_resources.*.display_name to find the name of the affected policy.
    • Determine whether this policy is related to critical controls (e.g., requiring MFA for admins).
  • Analyze the policy change:

    • Compare the old_value and new_value fields under azure.auditlogs.properties.target_resources.*.modified_properties.*.
    • Look for security-reducing changes, such as:
      • Removing users/groups from enforcement.
      • Disabling MFA or risk-based conditions.
      • Introducing exclusions that reduce the policy’s coverage.
  • Correlate with other activity:

    • Pivot on azure.auditlogs.properties.activity_datetime to identify if any suspicious sign-ins occurred after the policy was modified.
    • Check for related authentication logs, particularly from the same IP address (azure.auditlogs.properties.initiated_by.user.ipAddress).
  • Assess the user's legitimacy:

    • Review the initiator’s Azure role, group memberships, and whether their account was recently elevated or compromised.
    • Investigate whether this user has a history of modifying policies or if this is anomalous.
  • Authorized administrative changes: Some organizations routinely update CAPs as part of policy tuning or role-based access reviews.
  • Security reviews or automation: Scripts, CI/CD processes, or third-party compliance tools may programmatically update CAPs.
  • Employee lifecycle events: Policy changes during employee onboarding/offboarding may include updates to access policies.

If any of these cases apply and align with the activity's context, consider tuning the rule or adding exceptions for expected patterns.

  • Revert unauthorized or insecure changes to the Conditional Access Policy immediately.
  • Temporarily increase monitoring of CAP modifications and sign-in attempts.
  • Lock or reset the credentials of the user account that made the change if compromise is suspected.
  • Conduct a broader access review of conditional access policies and privileged user activity.
  • Implement stricter change management and alerting around CAP changes.

References

Related rules

to-top