Azure Storage Account Deletions by User

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/10/08"
  3integration = ["azure"]
  4maturity = "production"
  5updated_date = "2025/10/08"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when a single user or service principal deletes multiple Azure Storage Accounts within a short time period.
 11This behavior may indicate an adversary attempting to cause widespread service disruption, destroy evidence, or execute
 12a destructive attack such as ransomware. Mass deletion of storage accounts can have severe business impact and is rarely
 13performed by legitimate administrators except during controlled decommissioning activities.
 14"""
 15false_positives = [
 16    """
 17    Infrastructure teams may legitimately delete multiple storage accounts during planned decommissioning, resource
 18    cleanup, or large-scale infrastructure optimization. Verify that the deletion activity was expected and follows
 19    organizational change management processes. Consider exceptions for approved maintenance windows or automation service
 20    principals.
 21    """,
 22]
 23from = "now-9m"
 24index = ["logs-azure.activitylogs-*"]
 25language = "kuery"
 26license = "Elastic License v2"
 27name = "Azure Storage Account Deletions by User"
 28note = """## Triage and analysis
 29
 30### Investigating Azure Storage Account Deletions by User
 31
 32Azure 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.
 33
 34### Possible investigation steps
 35
 36- 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`.
 37- Check the specific storage account names in `azure.resource.name` to understand which storage resources were deleted and assess the overall business impact.
 38- Investigate the timing and sequence of deletions to determine if they followed a pattern consistent with automated malicious activity or manual destruction.
 39- Examine the user's recent activity history including authentication events, privilege changes, and other Azure resource modifications to identify signs of account compromise.
 40- Verify if the storage account deletions align with approved change requests, maintenance windows, or decommissioning activities in your organization.
 41- Check if the deleted storage accounts contained critical data and whether backups are available for recovery.
 42- Review any related alerts or activities such as data exfiltration, unusual authentication patterns, or privilege escalation that occurred before the deletions.
 43- Investigate if other Azure resources (VMs, databases, resource groups) were also deleted or modified by the same principal.
 44- Check the authentication source and location to identify if the activity originated from an expected network location or potentially compromised session.
 45
 46### False positive analysis
 47
 48- 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.
 49- 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.
 50- 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.
 51- 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.
 52
 53### Response and remediation
 54
 55- Immediately investigate whether the deletions were authorized by verifying with the account owner or relevant stakeholders.
 56- If the deletions were unauthorized, disable the compromised user account or service principal immediately to prevent further damage.
 57- Attempt to recover deleted storage accounts if soft-delete is enabled, or restore data from backups for critical storage accounts.
 58- Review and audit all Azure RBAC permissions to identify how the attacker gained storage account deletion capabilities (requires Contributor or Owner role).
 59- Conduct a full security assessment to identify the initial access vector and any other compromised accounts or resources.
 60- Implement Azure Resource Locks on all critical storage accounts to prevent accidental or malicious deletion.
 61- Configure Azure Policy to require approval workflows for storage account deletions using Azure Blueprints or custom governance solutions.
 62- Enable Azure Activity Log alerts to notify security teams immediately when storage accounts are deleted.
 63- Escalate the incident to the security operations center (SOC) or incident response team for investigation of potential broader compromise.
 64- Document the incident and update security policies, playbooks, and procedures to prevent similar incidents in the future.
 65"""
 66references = [
 67    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
 68]
 69risk_score = 73
 70rule_id = "b2c3d4e5-6f7a-8b9c-0d1e-2f3a4b5c6d7e"
 71severity = "high"
 72tags = [
 73    "Domain: Cloud",
 74    "Domain: Storage",
 75    "Data Source: Azure",
 76    "Data Source: Azure Activity Logs",
 77    "Use Case: Threat Detection",
 78    "Tactic: Impact",
 79    "Resources: Investigation Guide",
 80]
 81timestamp_override = "event.ingested"
 82type = "threshold"
 83
 84query = '''
 85event.dataset: azure.activitylogs and
 86    azure.activitylogs.operation_name: "MICROSOFT.STORAGE/STORAGEACCOUNTS/DELETE" and
 87    azure.activitylogs.identity.claims_initiated_by_user.name: *
 88'''
 89
 90
 91[[rule.threat]]
 92framework = "MITRE ATT&CK"
 93[[rule.threat.technique]]
 94id = "T1485"
 95name = "Data Destruction"
 96reference = "https://attack.mitre.org/techniques/T1485/"
 97
 98[[rule.threat.technique]]
 99id = "T1489"
100name = "Service Stop"
101reference = "https://attack.mitre.org/techniques/T1489/"
102
103
104[rule.threat.tactic]
105id = "TA0040"
106name = "Impact"
107reference = "https://attack.mitre.org/tactics/TA0040/"
108
109[rule.threshold]
110field = ["azure.activitylogs.identity.claims_initiated_by_user.name"]
111value = 1
112
113[[rule.threshold.cardinality]]
114field = "azure.resource.name"
115value = 5

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

Related rules

to-top