[New Rule] Azure Storage Account Deletion

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"

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