diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml deleted file mode 100644 index 78a2a290ba5..00000000000 --- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml +++ /dev/null @@ -1,84 +0,0 @@ -[metadata] -creation_date = "2020/09/01" -integration = ["azure"] -maturity = "production" -updated_date = "2025/01/15" - -[rule] -author = ["Elastic"] -description = """ -Identifies when an Azure Conditional Access policy is modified. Azure Conditional Access policies control access to -resources via if-then statements. For example, if a user wants to access a resource, then they must complete an action -such as using multi-factor authentication to access it. An adversary may modify a Conditional Access policy in order to -weaken their target's security controls. -""" -from = "now-25m" -index = ["filebeat-*", "logs-azure*"] -language = "kuery" -license = "Elastic License v2" -name = "Azure Conditional Access Policy Modified" -note = """## Triage and analysis - -> **Disclaimer**: -> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. - -### Investigating Azure Conditional Access Policy Modified - -Azure Conditional Access policies are critical for managing secure access to resources by enforcing specific conditions, such as requiring multi-factor authentication. Adversaries may exploit this by altering policies to weaken security, potentially bypassing authentication measures. The detection rule monitors logs for successful modifications to these policies, flagging potential unauthorized changes that could indicate malicious activity. - -### Possible investigation steps - -- Review the Azure activity and audit logs to identify the specific user account associated with the "Update conditional access policy" action and verify if the modification was authorized. -- Examine the details of the modified Conditional Access policy to understand the changes made, focusing on any alterations that could weaken security, such as the removal of multi-factor authentication requirements. -- Check the event.outcome field to confirm the success of the policy modification and correlate it with any recent access attempts or suspicious activities involving the affected resources. -- Investigate the history of changes to the Conditional Access policies to identify any patterns or repeated unauthorized modifications that could indicate persistent malicious activity. -- Assess the user's role and permissions to determine if they have legitimate access to modify Conditional Access policies, and review any recent changes to their account or role assignments. - -### False positive analysis - -- Routine administrative updates to Conditional Access policies by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system. -- Scheduled policy reviews and updates as part of regular security audits may also result in false positives. Document these activities and schedule them during known maintenance windows to differentiate them from unauthorized changes. -- Automated scripts or tools used for policy management might generate alerts if they modify policies. Ensure these tools are properly documented and their actions are logged separately to distinguish them from potential threats. -- Changes made during the onboarding or offboarding of employees can appear as suspicious activity. Implement a process to log these events separately and cross-reference them with HR records to verify legitimacy. -- Integration with third-party security solutions that modify policies for compliance or optimization purposes can lead to false positives. Establish a clear change management process and whitelist these integrations to prevent unnecessary alerts. - -### Response and remediation - -- Immediately review the modified Conditional Access policy to understand the changes made and assess the potential impact on security controls. -- Revert any unauthorized or suspicious changes to the Conditional Access policy to restore the original security posture. -- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs for unusual activity or unauthorized access attempts. -- Temporarily increase monitoring and logging of Conditional Access policy changes to detect any further unauthorized modifications. -- Notify the security team and relevant stakeholders about the incident and the steps taken to mitigate the risk. -- If malicious activity is confirmed, initiate an incident response process, including isolating affected accounts and conducting a full security assessment. -- Implement additional security measures, such as stricter access controls or enhanced multi-factor authentication requirements, to prevent similar incidents in the future. - -## Setup - -The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" -references = ["https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview"] -risk_score = 47 -rule_id = "bc48bba7-4a23-4232-b551-eca3ca1e3f20" -severity = "medium" -tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Persistence", "Resources: Investigation Guide"] -timestamp_override = "event.ingested" -type = "query" - -query = ''' -event.dataset:(azure.activitylogs or azure.auditlogs) and -event.action:"Update conditional access policy" and event.outcome:(Success or success) -''' - - -[[rule.threat]] -framework = "MITRE ATT&CK" -[[rule.threat.technique]] -id = "T1098" -name = "Account Manipulation" -reference = "https://attack.mitre.org/techniques/T1098/" - - -[rule.threat.tactic] -id = "TA0003" -name = "Persistence" -reference = "https://attack.mitre.org/tactics/TA0003/" - diff --git a/rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml new file mode 100644 index 00000000000..674ba5a966b --- /dev/null +++ b/rules/integrations/azure/persistence_entra_conditional_access_policy_modified.toml @@ -0,0 +1,116 @@ +[metadata] +creation_date = "2020/09/01" +integration = ["azure"] +maturity = "production" +updated_date = "2025/03/24" + +[rule] +author = ["Elastic"] +description = """ +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. +""" +from = "now-9m" +index = ["filebeat-*", "logs-azure*"] +language = "kuery" +license = "Elastic License v2" +name = "Microsoft Entra ID Conditional Access Policy (CAP) Modified" +note = """## 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. + +- **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. + +### 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 = [ + "https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview", + "https://www.rezonate.io/blog/microsoft-entra-id-the-complete-guide-to-conditional-access-policies/" +] +risk_score = 47 +rule_id = "bc48bba7-4a23-4232-b551-eca3ca1e3f20" +severity = "medium" +tags = [ + "Domain: Cloud", + "Data Source: Azure", + "Data Source: Microsoft Entra ID", + "Data Source: Microsoft Entra ID Audit Logs", + "Use Case: Identity and Access Audit", + "Use Case: Configuration Audit", + "Tactic: Persistence", + "Resources: Investigation Guide" +] +timestamp_override = "event.ingested" +type = "new_terms" + +query = ''' +event.dataset: "azure.auditlogs" + and event.action:"Update conditional access policy" + and event.outcome: "success" +''' + + +[[rule.threat]] +framework = "MITRE ATT&CK" +[[rule.threat.technique]] +id = "T1556" +name = "Modify Authentication Process" +reference = "https://attack.mitre.org/techniques/T1556/" + +[[rule.threat.technique.subtechnique]] +id = "T1556.009" +name = "Conditional Access Policies" +reference = "https://attack.mitre.org/techniques/T1556/009/" + + +[rule.threat.tactic] +id = "TA0003" +name = "Persistence" +reference = "https://attack.mitre.org/tactics/TA0003/" + +[rule.new_terms] +field = "new_terms_fields" +value = ["azure.auditlogs.properties.initiated_by.user.userPrincipalName"] +[[rule.new_terms.history_window_start]] +field = "history_window_start" +value = "now-14d"