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"
Triage and analysis
Investigation Guide: Microsoft Entra ID Conditional Access Policy (CAP) Modified
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).
Possible Investigation Steps
-
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.
- Check the value of
-
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).
- Look at
-
Analyze the policy change:
- Compare the
old_value
andnew_value
fields underazure.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.
- Compare the
-
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
).
- Pivot on
-
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.
Validation & False Positive Considerations
- 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.
Response & Remediation
- 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
- First Occurrence of Entra ID Auth via DeviceCode Protocol
- Azure AD Global Administrator Role Assigned
- Azure Automation Account Created
- Azure Automation Runbook Created or Modified
- Azure Automation Webhook Created