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

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_compute_vm_snapshot_deletions.toml

@@ -0,0 +1,136 @@
+[metadata]
+creation_date = "2025/10/10"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/10"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a single user or service principal deletes multiple Azure disk snapshots within a short time period.
+This behavior may indicate an adversary attempting to inhibit system recovery capabilities, destroy backup evidence, or
+prepare for a ransomware attack. Mass deletion of snapshots eliminates restore points and significantly impacts disaster
+recovery capabilities, making it a critical indicator of potentially malicious activity.
+"""
+false_positives = [
+    """
+    Infrastructure teams may legitimately delete multiple snapshots during planned maintenance, storage optimization, or
+    cleanup of expired backup data according to retention policies. Verify that the deletion activity was expected and
+    follows organizational change management processes. Consider exceptions for approved maintenance windows or
+    automation service principals managing backup retention.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Compute Snapshot Deletions by User"
+note = """## Triage and analysis
+
+### Investigating Azure Compute Snapshot Deletions by User
+
+Azure disk snapshots are critical backup and recovery resources that enable organizations to restore data and investigate security incidents. Mass deletion of snapshots is a highly suspicious activity commonly associated with ransomware preparation, evidence destruction, or sabotage operations. Adversaries frequently target snapshots to prevent victims from recovering data without paying ransom or to eliminate forensic evidence of their activities. This detection identifies when a single identity deletes multiple snapshots in a short timeframe, which is rarely performed by legitimate administrators except during controlled maintenance activities.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the multiple snapshot deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
+- Check the specific snapshot names in `azure.resource.name` to understand which backups were deleted and assess the overall impact on recovery capabilities.
+- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
+- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
+- Verify if the snapshot deletions align with approved change requests, maintenance windows, or data retention policies in your organization.
+- Check if other backup-related resources (backup vaults, recovery services, additional snapshots) were also accessed or modified by the same principal.
+- Review any related alerts or activities such as VM encryption, disk modifications, or unusual data access that occurred before the deletions.
+- Investigate if other Azure resources (VMs, disks, storage accounts) were also deleted or modified by the same principal.
+- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
+- Determine if any remaining snapshots or alternative backups exist for the affected resources.
+
+### False positive analysis
+
+- Legitimate bulk cleanup of expired snapshots according to data retention policies may trigger this alert. Document approved retention management processes and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
+- Infrastructure-as-Code (IaC) automation tools or backup management solutions may delete multiple expired snapshots. Identify service principals used by backup retention tools and consider creating exceptions for these identities when following documented retention schedules.
+- Cost optimization initiatives may involve bulk deletion of old or redundant snapshots. Coordinate with finance and infrastructure teams to understand planned optimization activities and schedule them during documented maintenance windows.
+- Disaster recovery testing or environment teardown may involve deletion of multiple test snapshots. Work with business continuity and DevOps teams to identify these patterns and create time-based exceptions during testing periods.
+- Storage migration or consolidation projects may require deletion of old snapshots. Coordinate with infrastructure teams to understand planned migration activities and create exceptions during documented project timelines.
+
+### Response and remediation
+
+- Immediately investigate whether the deletions were authorized by verifying with backup administrators, infrastructure teams, or relevant stakeholders.
+- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Check if any snapshots can be recovered through Azure backup services, soft-delete capabilities, or alternative backup mechanisms.
+- Create new snapshots of all critical disks immediately to establish new restore points if the deleted snapshots were part of your backup strategy.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained snapshot deletion capabilities and remove excessive permissions.
+- Conduct a full security assessment to identify the initial access vector, any other compromised accounts, and potential lateral movement.
+- Implement Azure Resource Locks on all critical snapshots and backup resources to prevent accidental or malicious deletion.
+- Configure Azure Policy to restrict snapshot deletion permissions to only authorized backup administrators and require approval workflows for deletion operations.
+- Enable Azure Activity Log alerts and configure notifications to security teams immediately when snapshots are deleted.
+- Review and enhance backup strategies to ensure redundant backup mechanisms exist beyond Azure snapshots, including geo-redundant backups and offline copies.
+- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential ransomware preparation or broader compromise.
+- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+]
+risk_score = 47
+rule_id = "d4e5f6a7-8b9c-0d1e-2f3a-4b5c6d7e8f9a"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.COMPUTE/SNAPSHOTS/DELETE" and
+    azure.activitylogs.properties.status_code: "Accepted" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+'''
+
+[rule.investigation_fields]
+field_names = [
+    "@timestamp",
+    "azure.activitylogs.identity.claims_initiated_by_user.name",
+    "azure.activitylogs.identity.authorization.evidence.principal_id",
+    "azure.activitylogs.identity.claims.appid",
+    "azure.activitylogs.identity.claims.sid",
+    "azure.resource.name",
+    "azure.resource.group",
+    "azure.activitylogs.operation_name",
+    "azure.subscription_id",
+    "azure.activitylogs.tenant_id",
+    "source.ip",
+]
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+[[rule.threat.technique]]
+id = "T1490"
+name = "Inhibit System Recovery"
+reference = "https://attack.mitre.org/techniques/T1490/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.threshold]
+field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
+value = 1
+[[rule.threshold.cardinality]]
+field = "azure.resource.name"
+value = 3
+
+

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_key_vault_modified.toml

@@ -0,0 +1,95 @@
+[metadata]
+creation_date = "2020/08/31"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/07/09"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies modifications to a Key Vault in Azure. The Key Vault is a service that safeguards encryption keys and secrets
+like certificates, connection strings, and passwords. Because this data is sensitive and business critical, access to
+key vaults should be secured to allow only authorized applications and users. This is a New Terms rule that detects when this activity hasn't been seen by the user in a specified time frame.
+"""
+false_positives = [
+    """
+    Key vault modifications 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. Key vault modifications 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 = ["filebeat-*", "logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Key Vault Modified"
+note = """## Triage and analysis
+
+### Investigating Azure Key Vault Modified
+
+Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects modifications to Key Vaults, which may indicate potential security incidents or misconfigurations.
+
+### Possible investigation steps
+- Review the `azure.activitylogs.operation_name` field to identify the specific operation performed on the Key Vault. Common operations include `Microsoft.KeyVault/vaults/write` for modifications and `Microsoft.KeyVault/vaults/delete` for deletions.
+- Check the `event.outcome` field to confirm the success of the operation. A successful outcome indicates that the modification or deletion was completed.
+- Investigate the `azure.activitylogs.identity.principal_id` or `azure.activitylogs.identity.principal_name` fields to determine the user or service principal that performed the operation. This can help identify whether the action was authorized or potentially malicious.
+- Analyze the `azure.activitylogs.resource_id` field to identify the specific Key Vault that was modified. This can help assess the impact of the change and whether it affects critical resources or applications.
+- Cross-reference the time of the modification with other security events or alerts in the environment to identify any patterns or related activities that may indicate a coordinated attack or misconfiguration.
+- Consult with relevant stakeholders or system owners to verify if the modification was planned or expected, and gather additional context if necessary.
+
+### False positive analysis
+- Routine maintenance activities by administrators can trigger alerts when they modify or delete Key Vaults. To manage this, create exceptions for known maintenance windows or specific administrator accounts.
+- Automated scripts or tools used for Key Vault management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags.
+- Changes made by authorized third-party services or integrations that manage Key Vault configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts.
+- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only.
+- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods.
+
+### Response and remediation
+- Immediately isolate the affected Key Vault to prevent further unauthorized access or changes.
+- Review the Azure activity logs to identify the specific operations performed on the Key Vault and their outcomes.
+- Collaborate with security teams to assess the impact of the modifications and determine if any sensitive data was compromised.
+- If unauthorized changes are confirmed, initiate incident response procedures, including notifying affected parties and conducting a thorough investigation.
+- Implement additional monitoring and alerting for the affected Key Vault to detect any further suspicious activity.
+"""
+references = [
+    "https://docs.microsoft.com/en-us/azure/key-vault/general/basic-concepts",
+    "https://docs.microsoft.com/en-us/azure/key-vault/general/secure-your-key-vault",
+    "https://learn.microsoft.com/en-us/azure/key-vault/general/security-features"
+]
+risk_score = 21
+rule_id = "792dd7a6-7e00-4a0a-8a9a-a7c24720b5ec"
+severity = "low"
+tags = [
+    "Domain: Cloud",
+    "Domain: Identity",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Tactic: Impact",
+    "Use Case: Configuration Audit",
+    "Resources: Investigation Guide"
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "azure.activitylogs"
+    and azure.activitylogs.operation_name: MICROSOFT.KEYVAULT/VAULTS/*
+    and event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
+
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-14d"

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_storage_account_deletion.toml

@@ -0,0 +1,110 @@
+[metadata]
+creation_date = "2025/10/08"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/08"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when an Azure Storage Account is deleted. Adversaries may delete storage accounts to disrupt operations,
+destroy evidence, or cause denial of service. This activity could indicate an attacker attempting to cover their tracks
+after data exfiltration or as part of a destructive attack. Monitoring storage account deletions is critical for
+detecting potential impact on business operations and data availability.
+"""
+false_positives = [
+    """
+    Storage administrators may legitimately delete storage accounts during decommissioning, resource cleanup, or
+    infrastructure optimization. Verify that the deletion was expected and follows organizational change management
+    processes. Consider exceptions for approved maintenance windows.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Storage Account Deletion by Unusual User"
+note = """## Triage and analysis
+
+### Investigating Azure Storage Account Deletion by Unusual User
+
+Azure Storage Accounts provide scalable cloud storage for applications and services. Deletion of storage accounts is a high-impact operation that permanently removes all contained data including blobs, files, queues, and tables. Adversaries may delete storage accounts to destroy evidence of their activities, disrupt business operations, or cause denial of service as part of ransomware or destructive attacks. This detection monitors for successful storage account deletion operations to identify potential malicious activity.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the storage account deletion by examining the principal ID, UPN and user agent fields.
+- Check the specific storage account name in `azure.resource.name` to understand which storage resources were deleted and assess the business impact.
+- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns, privilege escalation attempts, or other resource deletions.
+- Examine the user's recent activity history to identify any other storage accounts or Azure resources that were deleted or modified by the same principal.
+- Verify if the storage account deletion aligns with approved change requests or maintenance windows in your organization.
+- Check if the deleted storage account contained critical data and whether backups are available for recovery.
+- Review any related alerts or activities such as data exfiltration, configuration changes, or access policy modifications that occurred before the deletion.
+- Investigate if the account was recently compromised by checking for suspicious authentication events or privilege escalations.
+
+### False positive analysis
+
+- Legitimate decommissioning of unused storage accounts may trigger this alert. Document approved storage account cleanup activities and coordinate with infrastructure teams to understand planned deletions.
+- DevOps automation tools might delete temporary storage accounts as part of infrastructure lifecycle management. Identify service principals used by CI/CD pipelines and consider creating exceptions for these automated processes.
+- Testing and development environments may have frequent storage account creation and deletion cycles. Consider filtering out non-production storage accounts if appropriate for your environment.
+- Cost optimization initiatives may involve deleting unused or redundant storage accounts. Coordinate with finance and infrastructure teams to understand planned resource optimization activities.
+
+### Response and remediation
+
+- Immediately investigate whether the deletion was authorized by verifying with the account owner or relevant stakeholders.
+- If the deletion was unauthorized, attempt to recover the storage account if soft-delete is enabled, or restore data from backups.
+- Disable the compromised user account or service principal if unauthorized activity is confirmed and investigate how the credentials were obtained.
+- Review and restrict Azure RBAC permissions to ensure only authorized users have storage account deletion capabilities (requires Contributor or Owner role).
+- Implement Azure Resource Locks to prevent accidental or malicious deletion of critical storage accounts.
+- Configure Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted.
+- Conduct a full security assessment to identify any other compromised resources or accounts and look for indicators of broader compromise.
+- Document the incident and update security policies and procedures to prevent similar incidents in the future.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/"
+]
+risk_score = 47
+rule_id = "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"

nldcsc_elastic_rules/rules/integrations/azure/impact_azure_storage_account_deletion_multiple.toml

@@ -0,0 +1,115 @@
+[metadata]
+creation_date = "2025/10/08"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/10/08"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period.
+This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute
+a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely
+performed by legitimate administrators except during controlled decommissioning activities.
+"""
+false_positives = [
+    """
+    Infrastructure teams may legitimately delete multiple storage accounts during planned decommissioning, resource
+    cleanup, or large-scale infrastructure optimization. Verify that the deletion activity was expected and follows
+    organizational change management processes. Consider exceptions for approved maintenance windows or automation service
+    principals.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Storage Account Deletions by User"
+note = """## Triage and analysis
+
+### Investigating Azure Storage Account Deletions by User
+
+Azure Storage Accounts are critical infrastructure components that store application data, backups, and business-critical information. Mass deletion of storage accounts is an unusual and high-impact activity that can result in significant data loss and service disruption. Adversaries may perform bulk deletions to destroy evidence after data exfiltration, cause denial of service, or as part of ransomware campaigns targeting cloud infrastructure. This detection identifies when a single identity deletes multiple storage accounts in a short timeframe, which is indicative of potentially malicious activity.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the multiple storage account deletions by examining the principal ID, UPN and user agent fields in `azure.activitylogs.identity.claims_initiated_by_user.name`.
+- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact.
+- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
+- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
+- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization.
+- Check if the deleted storage accounts contained critical data and whether backups are available for recovery.
+- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions.
+- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal.
+- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
+
+### False positive analysis
+
+- Legitimate bulk decommissioning of storage accounts during infrastructure cleanup may trigger this alert. Document approved resource cleanup activities and coordinate with infrastructure teams to create exceptions during planned maintenance windows.
+- Infrastructure-as-Code (IaC) automation tools or CI/CD pipelines may delete multiple test or temporary storage accounts. Identify service principals used by automation tools and consider creating exceptions for these identities when operating in non-production environments.
+- Cloud resource optimization initiatives may involve bulk deletion of unused storage accounts. Coordinate with finance and infrastructure teams to understand planned cost optimization activities and schedule them during documented maintenance windows.
+- Disaster recovery testing or blue-green deployment strategies may involve deletion of multiple storage accounts. Work with DevOps teams to identify these patterns and create time-based exceptions during testing periods.
+
+### Response and remediation
+
+- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders.
+- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
+- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts.
+- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role).
+- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
+- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion.
+- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions.
+- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted.
+- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise.
+- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+]
+risk_score = 73
+rule_id = "b2c3d4e5-6f7a-8b9c-0d1e-2f3a4b5c6d7e"
+severity = "high"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Impact",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "threshold"
+
+query = '''
+event.dataset: azure.activitylogs and
+    azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and
+    azure.activitylogs.identity.claims_initiated_by_user.name: *
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1485"
+name = "Data Destruction"
+reference = "https://attack.mitre.org/techniques/T1485/"
+
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+
+[rule.threshold]
+field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
+value = 1
+
+[[rule.threshold.cardinality]]
+field = "azure.resource.name"
+value = 5

nldcsc_elastic_rules/rules/integrations/azure/impact_kubernetes_pod_deleted.toml

@@ -0,0 +1,96 @@
+[metadata]
+creation_date = "2021/06/24"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/30"
+
+[rule]
+author = ["Austin Songer"]
+description = """
+Identifies the deletion of Azure Kubernetes Pods. Adversaries may delete a Kubernetes pod to disrupt the normal behavior
+of the environment.
+"""
+false_positives = [
+    """
+    Pods may be deleted by a system administrator. Verify whether the user identity, user agent, and/or hostname should
+    be making changes in your environment. Pods 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 Pods 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 Pods Deleted
+
+Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring 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.
+- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities.
+- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications.
+- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity.
+- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident.
+
+### False positive analysis
+
+- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
+- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes.
+- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags.
+- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers.
+
+### Response and remediation
+
+- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily.
+- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized.
+- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime.
+- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise.
+- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future.
+- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected.
+- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly.
+
+## 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 = "83a1931d-8136-46fc-b7b9-2db4f639e014"
+severity = "medium"
+tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Asset Visibility", "Tactic: Impact", "Resources: Investigation Guide"]
+timestamp_override = "event.ingested"
+type = "query"
+
+query = '''
+event.dataset:azure.activitylogs and azure.activitylogs.operation_name:"MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and
+event.outcome:(Success or success)
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1489"
+name = "Service Stop"
+reference = "https://attack.mitre.org/techniques/T1489/"
+
+[[rule.threat.technique]]
+id = "T1529"
+name = "System Shutdown/Reboot"
+reference = "https://attack.mitre.org/techniques/T1529/"
+
+
+[rule.threat.tactic]
+id = "TA0040"
+name = "Impact"
+reference = "https://attack.mitre.org/tactics/TA0040/"
+