nldcsc-elastic-rules 0.0.8__py3-none-any.whl

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml

@@ -0,0 +1,128 @@
+[metadata]
+creation_date = "2020/08/17"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/27"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of diagnostic settings in Azure, which send platform logs and metrics to different destinations.
+An adversary may delete diagnostic settings in an attempt to evade defenses.
+"""
+false_positives = [
+    """
+    Deletion of diagnostic settings may be done by a system or network administrator. Verify whether the username,
+    hostname, and/or resource name should be making changes in your environment. Diagnostic settings deletion from
+    unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted
+    from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Diagnostic Settings Deletion"
+note = """## Triage and analysis
+
+### Investigating Azure Diagnostic Settings Deletion
+
+Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- If this is a service principal, determine which application is associated with it and examine credential use with authentication sources to identify potential compromise.
+- Examine the resource group and subscription context to understand the scope of the deletion and whether it affects critical resources.
+- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time.
+- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities.
+- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent.
+- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities.
+
+### False positive analysis
+
+- Examine the service principal or user account involved in the deletion to determine if it is part of an automated process or legitimate administrative activity.
+- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening.
+- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect.
+- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior.
+- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations.
+
+### Response and remediation
+
+- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups.
+- Review the Azure activity logs to identify the source of the deletion request, including the user account, service principal and IP address involved. This will help determine if the action was authorized or malicious.
+- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations.
+- Conduct a thorough investigation of the user account or service principal involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege.
+- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat.
+- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts.
+- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings.
+"""
+references = [
+    "https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings",
+    "https://www.microsoft.com/en-us/security/blog/2025/10/20/inside-the-attack-chain-threat-activity-targeting-azure-blob-storage/",
+]
+risk_score = 47
+rule_id = "5370d4cd-2bb3-4d71-abf5-1e1d0ff5a2de"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset:azure.activitylogs
+    and azure.activitylogs.operation_name:"MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
+    and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+[[rule.threat.technique.subtechnique]]
+id = "T1562.008"
+name = "Disable or Modify Cloud Logs"
+reference = "https://attack.mitre.org/techniques/T1562/008/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "event.action",
+    "source.ip",
+    "azure.activitylogs.identity.authorization.evidence.principal_type",
+    "azure.activitylogs.identity.authorization.evidence.role_assignment_scope",
+    "azure.activitylogs.properties.entity",
+    "azure.activitylogs.identity.claims.appid",
+    "azure.resource.name",
+    "azure.resource.provider",
+]
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.resource.group"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"
+
+

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_event_hub_deletion.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies an Event Hub deletion in Azure. An Event Hub is an event processing service that ingests and processes large
+volumes of events and data. An adversary may delete an Event Hub in an attempt to evade detection.
+"""
+false_positives = [
+    """
+    Event Hub deletions may be done by a system or network administrator. Verify whether the username, hostname, and/or
+    resource name should be making changes in your environment. Event Hub deletions by unfamiliar users or hosts should
+    be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Event Hub Deletion"
+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 Event Hub Deletion
+
+Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions.
+- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation.
+- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign.
+- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts.
+- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives.
+- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise.
+- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts.
+- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups.
+- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs.
+- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data.
+- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise.
+- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources.
+- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly.
+- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege.
+
+## 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/event-hubs/event-hubs-about",
+    "https://azure.microsoft.com/en-in/services/event-hubs/",
+    "https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features",
+]
+risk_score = 47
+rule_id = "e0f36de1-0342-453d-95a9-a068b257b053"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.008"
+name = "Disable or Modify Cloud Logs"
+reference = "https://attack.mitre.org/techniques/T1562/008/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml

@@ -0,0 +1,100 @@
+[metadata]
+creation_date = "2020/08/18"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of a firewall policy in Azure. An adversary may delete a firewall policy in an attempt to evade
+defenses and/or to eliminate barriers to their objective.
+"""
+false_positives = [
+    """
+    Firewall policy deletions may be done by a system or network administrator. Verify whether the username, hostname,
+    and/or resource name should be making changes in your environment. Firewall policy deletions by unfamiliar users or
+    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Firewall Policy Deletion"
+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 Firewall Policy Deletion
+
+Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and ensuring the event outcome is "Success".
+- Identify the user or service principal responsible for the deletion by examining the 'caller' field in the activity logs.
+- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time.
+- Investigate the context of the deletion by reviewing any related activities performed by the same user or service principal, such as modifications to other security settings or unusual login patterns.
+- Assess the impact of the deletion by identifying which resources or networks were protected by the deleted firewall policy and evaluating the potential exposure or risk introduced by its removal.
+- Contact the responsible user or team to verify if the deletion was authorized and part of a planned change or if it was unexpected and potentially malicious.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can trigger the deletion event. Ensure that such activities are logged and verified by cross-referencing with change management records.
+- Automated scripts or tools used for infrastructure management might delete and recreate firewall policies as part of their operation. Identify these scripts and exclude their activity from alerts by using specific identifiers or tags.
+- Test environments often undergo frequent changes, including policy deletions. Consider excluding activity from known test environments by filtering based on resource group or subscription IDs.
+- Scheduled policy updates or rotations might involve temporary deletions. Document these schedules and adjust monitoring rules to account for these expected changes.
+- Ensure that any third-party integrations or services with permissions to modify firewall policies are accounted for, and their actions are reviewed and whitelisted if necessary.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources to prevent further unauthorized access or data exfiltration. This can be done by applying restrictive network security group (NSG) rules or using Azure Security Center to quarantine resources.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts or credentials.
+- Restore the deleted firewall policy from backups or recreate it using predefined templates to ensure that network security rules are reinstated promptly.
+- Implement conditional access policies to enforce multi-factor authentication (MFA) for all users with permissions to modify or delete firewall policies, reducing the risk of unauthorized changes.
+- Escalate the incident to the security operations team for further investigation and to determine if additional resources or systems have been compromised.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future.
+- Enhance monitoring by configuring alerts for any future attempts to delete or modify critical security policies, ensuring rapid detection and response to potential threats.
+
+## 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/firewall-manager/policy-overview"]
+risk_score = 21
+rule_id = "e02bd3ea-72c6-4181-ac2b-0f83d17ad969"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Use Case: Network Security Monitoring",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml

@@ -0,0 +1,103 @@
+[metadata]
+creation_date = "2021/08/01"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies the deletion of a Frontdoor Web Application Firewall (WAF) Policy in Azure. An adversary may delete a
+Frontdoor Web Application Firewall (WAF) Policy in an attempt to evade defenses and/or to eliminate barriers to their
+objective.
+"""
+false_positives = [
+    """
+    Azure Front Web Application Firewall (WAF) Policy deletions may be done by a system or network administrator. Verify
+    whether the username, hostname, and/or resource name should be making changes in your environment. Azure Front Web
+    Application Firewall (WAF) Policy deletions by unfamiliar users or hosts should be investigated. If known behavior
+    is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted"
+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 Frontdoor Web Application Firewall (WAF) Policy Deleted
+
+Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success.
+- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs.
+- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment.
+- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources.
+- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats.
+- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts.
+- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers.
+- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions.
+- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls.
+- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies.
+- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring.
+- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly.
+- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response.
+
+## 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/role-based-access-control/resource-provider-operations#networking",
+]
+risk_score = 21
+rule_id = "09d028a5-dcde-409f-8ae0-557cef1b7082"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Use Case: Network Security Monitoring",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.007"
+name = "Disable or Modify Cloud Firewall"
+reference = "https://attack.mitre.org/techniques/T1562/007/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml

@@ -0,0 +1,98 @@
+[metadata]
+creation_date = "2021/06/24"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies when events are deleted in Azure Kubernetes. Kubernetes events are objects that log any state changes.
+Example events are a container creation, an image pull, or a pod scheduling on a node. An adversary may delete events in
+Azure Kubernetes in an attempt to evade detection.
+"""
+false_positives = [
+    """
+    Events deletions may be done by a system or network administrator. Verify whether the username, hostname, and/or
+    resource name should be making changes in your environment. Events deletions by unfamiliar users or hosts should be
+    investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Kubernetes Events Deleted"
+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 Kubernetes Events Deleted
+
+Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success".
+- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs.
+- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes.
+- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise.
+- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost.
+- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary.
+- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses.
+- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening.
+- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs.
+- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation.
+- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing.
+- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future.
+- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation.
+- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign.
+- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats 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/role-based-access-control/resource-provider-operations#microsoftkubernetes",
+]
+risk_score = 47
+rule_id = "8b64d36a-1307-4b2e-a77b-a0027e4d27c8"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Log Auditing", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and
+event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+

nldcsc_elastic_rules/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml

@@ -0,0 +1,99 @@
+[metadata]
+creation_date = "2020/08/31"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/26"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies the deletion of a Network Watcher in Azure. Network Watchers are used to monitor, diagnose, view metrics, and
+enable or disable logs for resources in an Azure virtual network. An adversary may delete a Network Watcher in an
+attempt to evade defenses.
+"""
+false_positives = [
+    """
+    Network Watcher deletions may be done by a system or network administrator. Verify whether the username, hostname,
+    and/or resource name should be making changes in your environment. Network Watcher deletions by unfamiliar users or
+    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*", "filebeat-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Network Watcher Deletion"
+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 Network Watcher Deletion
+
+Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and ensuring the event outcome is marked as "Success" or "success".
+- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs.
+- Investigate the timeline of events leading up to the deletion by reviewing related activity logs for any unusual or unauthorized access patterns or changes in permissions.
+- Assess the impact of the deletion by determining which resources were being monitored by the deleted Network Watcher and evaluating the potential security implications.
+- Check for any other suspicious activities or alerts in the Azure environment that may indicate a broader attack or compromise, focusing on defense evasion tactics.
+
+### False positive analysis
+
+- Routine maintenance activities by authorized personnel may trigger the deletion alert. Verify if the deletion aligns with scheduled maintenance and consider excluding these operations from alerts.
+- Automated scripts or tools used for infrastructure management might delete Network Watchers as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives.
+- Changes in network architecture or resource reallocation can lead to legitimate deletions. Review change management logs to confirm if the deletion was planned and adjust the detection rule to exclude these scenarios.
+- Test environments often undergo frequent changes, including the deletion of Network Watchers. If these environments are known to generate false positives, consider creating exceptions for specific resource groups or subscriptions associated with testing.
+
+### Response and remediation
+
+- Immediately isolate the affected Azure resources to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules.
+- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts.
+- Restore the deleted Network Watcher by redeploying it in the affected regions to resume monitoring and logging capabilities.
+- Conduct a security review of the affected Azure environment to identify any other potential misconfigurations or unauthorized changes.
+- Implement stricter access controls and auditing for Azure resources, ensuring that only authorized personnel have the ability to delete critical monitoring tools like Network Watchers.
+- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary.
+- Enhance detection capabilities by ensuring that alerts for similar deletion activities are configured to notify the security team immediately.
+
+## 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/network-watcher/network-watcher-monitoring-overview"]
+risk_score = 47
+rule_id = "323cb487-279d-4218-bcbd-a568efe930c6"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Data Source: Azure",
+    "Use Case: Network Security Monitoring",
+    "Tactic: Defense Evasion",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1562"
+name = "Impair Defenses"
+reference = "https://attack.mitre.org/techniques/T1562/"
+[[rule.threat.technique.subtechnique]]
+id = "T1562.001"
+name = "Disable or Modify Tools"
+reference = "https://attack.mitre.org/techniques/T1562/001/"
+
+
+
+[rule.threat.tactic]
+id = "TA0005"
+name = "Defense Evasion"
+reference = "https://attack.mitre.org/tactics/TA0005/"
+