Azure Alert Suppression Rule Created or Modified

 1[metadata]
 2creation_date = "2021/08/27"
 3integration = ["azure"]
 4maturity = "production"
 5updated_date = "2025/01/15"
 6
 7[rule]
 8author = ["Austin Songer"]
 9description = """
10Identifies the creation of suppression rules in Azure. Suppression rules are a mechanism used to suppress alerts
11previously identified as false positives or too noisy to be in production. This mechanism can be abused or mistakenly
12configured, resulting in defense evasions and loss of security visibility.
13"""
14false_positives = [
15    """
16    Suppression Rules can be created legitimately by a system administrator. Verify whether the user identity, user
17    agent, and/or hostname should be making changes in your environment. Suppression Rules created by unfamiliar users
18    should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
19    """,
20]
21from = "now-25m"
22index = ["filebeat-*", "logs-azure*"]
23language = "kuery"
24license = "Elastic License v2"
25name = "Azure Alert Suppression Rule Created or Modified"
26note = """## Triage and analysis
27
28> **Disclaimer**:
29> 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.
30
31### Investigating Azure Alert Suppression Rule Created or Modified
32
33Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility.
34
35### Possible investigation steps
36
37- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success".
38- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs.
39- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications.
40- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats.
41- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity.
42- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies.
43
44### False positive analysis
45
46- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel.
47- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation.
48- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts.
49- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications.
50- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period.
51
52### Response and remediation
53
54- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change.
55- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed.
56- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked.
57- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts.
58- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture.
59- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed.
60- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes.
61
62## Setup
63
64The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
65references = [
66    "https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations",
67    "https://docs.microsoft.com/en-us/rest/api/securitycenter/alerts-suppression-rules/update",
68]
69risk_score = 21
70rule_id = "f0bc081a-2346-4744-a6a4-81514817e888"
71severity = "low"
72tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
73timestamp_override = "event.ingested"
74type = "query"
75
76query = '''
77event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and
78event.outcome: "success"
79'''
80
81
82[[rule.threat]]
83framework = "MITRE ATT&CK"
84[[rule.threat.technique]]
85id = "T1562"
86name = "Impair Defenses"
87reference = "https://attack.mitre.org/techniques/T1562/"
88
89
90[rule.threat.tactic]
91id = "TA0005"
92name = "Defense Evasion"
93reference = "https://attack.mitre.org/tactics/TA0005/"