[New Rule] Azure Storage Account Blob Public Access Enabled (#5139)

# Pull Request *Issue link(s)*: * https://github.com/elastic/detection-rules/issues/5138  ## Summary - What I changed Adds a missing detection for Azure storage account updates that enabled Blob Storage public access. **Please see the related issue for more details.**  ## How To Test Query can be used in TRADE stack for example data.  ## Checklist  - [ ] Added a label for the type of pr: `bug`, `enhancement`, `schema`, `maintenance`, `Rule: New`, `Rule: Deprecation`, `Rule: Tuning`, `Hunt: New`, or `Hunt: Tuning` so guidelines can be generated - [ ] Added the `meta:rapid-merge` label if planning to merge within 24 hours - [ ] Secret and sensitive material has been managed correctly - [ ] Automated testing was updated or added to match the most common scenarios - [ ] Documentation and comments were added for features that require explanation ## Contributor checklist - Have you signed the [contributor license agreement](https://www.elastic.co/contributor-agreement)? - Have you followed the [contributor guidelines](https://github.com/elastic/detection-rules/blob/main/CONTRIBUTING.md)?
2025-10-06 09:15:07 -04:00
parent ca640a62ab
commit d6b6f99b27
2 changed files with 108 additions and 1 deletions
@@ -200,7 +200,8 @@
    "azure.activitylogs.properties.authentication_protocol": "keyword",
    "azure.activitylogs.properties.appId": "keyword",
    "azure.activitylogs.properties.resourceDisplayName": "keyword",
-    "azure.activitylogs.properties.appDisplayName": "keyword"
+    "azure.activitylogs.properties.appDisplayName": "keyword",
+    "azure.activitylogs.properties.responseBody": "keyword"
  },
  "logs-azure.graphactivitylogs-*": {
    "azure.graphactivitylogs.properties.c_idtyp": "keyword",
@@ -0,0 +1,106 @@
+[metadata]
+creation_date = "2025/09/22"
+integration = ["azure"]
+maturity = "production"
+updated_date = "2025/09/22"
+
+[rule]
+author = ["Elastic"]
+description = """
+Identifies when Azure Storage Account Blob public access is enabled, allowing external access to blob containers. This
+technique was observed in cloud ransom-based campaigns where threat actors modified storage accounts to expose
+non-remotely accessible accounts to the internet for data exfiltration. Adversaries abuse the
+Microsoft.Storage/storageAccounts/write operation to modify public access settings.
+"""
+false_positives = [
+    """
+    Storage administrators may legitimately enable public access for specific business requirements such as hosting
+    public content or CDN integration. Verify that the configuration change was expected and follows organizational
+    policies. Consider exceptions for approved storage accounts.
+    """,
+]
+from = "now-9m"
+index = ["logs-azure.activitylogs-*"]
+language = "kuery"
+license = "Elastic License v2"
+name = "Azure Storage Account Blob Public Access Enabled"
+note = """## Triage and analysis
+
+### Investigating Azure Storage Account Blob Public Access Enabled
+
+Azure Storage Accounts provide cloud storage solutions with various access control mechanisms. The public access setting, when enabled, allows anonymous internet access to blob containers, bypassing authentication requirements. Adversaries exploit this feature to expose sensitive data for exfiltration or to establish persistent external access. This detection monitors for successful modifications that enable public blob access, a technique notably used in STORM-0501 cloud ransom-based campaigns.
+
+### Possible investigation steps
+
+- Review the Azure activity logs to identify the user or service principal that initiated the storage account modification 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 affected and assess the sensitivity of data stored there.
+- Investigate the timing of the event to correlate with any other suspicious activities, such as unusual login patterns or privilege escalation attempts.
+- Examine the request or response body details to understand the full scope of changes made to the storage account configuration beyond public access settings.
+- Review access logs for the affected storage account to identify any subsequent data access or exfiltration attempts following the public access enablement.
+- Verify if the storage account modification aligns with approved change requests or maintenance windows in your organization.
+- Check for other storage accounts modified by the same principal to identify potential lateral movement or widespread configuration changes.
+- Pivot into related activity for the storage account and/or container such as data deletion, encryption or further permission changes.
+
+### False positive analysis
+
+- Legitimate CDN integration or public website hosting may require enabling public blob access. Document approved storage accounts used for public content delivery and create exceptions for these specific resources.
+- DevOps automation tools might temporarily enable public access during deployment processes. Identify service principals used by CI/CD pipelines and consider time-based exceptions during deployment windows.
+- Testing and development environments may have different access requirements. Consider filtering out non-production storage accounts if public access is acceptable in those environments.
+- Migration activities might require temporary public access. Coordinate with infrastructure teams to understand planned migrations and create temporary exceptions with defined expiration dates.
+
+### Response and remediation
+
+- Immediately disable public blob access on the affected storage account using Azure Portal IaC, or Azure CLI command.
+- Audit all blob containers within the affected storage account to identify which data may have been exposed and assess the potential impact of the exposure.
+- Review Azure Activity Logs and storage access logs to determine if any data was accessed or exfiltrated while public access was enabled.
+- Rotate any credentials, keys, or sensitive data that may have been stored in the exposed blob containers.
+- If unauthorized modification is confirmed, disable the compromised user account or service principal and investigate how the credentials were obtained.
+- Implement Azure Policy to prevent enabling public blob access on storage accounts containing sensitive data, using built-in policy definitions for storage account public access restrictions.
+- Consider implementing private endpoints for storage accounts that should never be publicly accessible, ensuring network-level isolation.
+"""
+references = [
+    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
+    "https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-configure",
+]
+risk_score = 47
+rule_id = "4c5a4e8b-3f2d-4a6e-9b5c-7d8f9e0a1b2c"
+severity = "medium"
+tags = [
+    "Domain: Cloud",
+    "Domain: Storage",
+    "Data Source: Azure",
+    "Data Source: Azure Activity Logs",
+    "Use Case: Threat Detection",
+    "Tactic: Collection",
+    "Resources: Investigation Guide",
+]
+timestamp_override = "event.ingested"
+type = "new_terms"
+
+query = '''
+event.dataset: "azure.activitylogs" and
+event.action: "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and
+event.outcome: "success" and
+azure.activitylogs.properties.responseBody: *\"allowBlobPublicAccess\"\:true*
+'''
+
+
+[[rule.threat]]
+framework = "MITRE ATT&CK"
+[[rule.threat.technique]]
+id = "T1530"
+name = "Data from Cloud Storage"
+reference = "https://attack.mitre.org/techniques/T1530/"
+
+
+[rule.threat.tactic]
+id = "TA0009"
+name = "Collection"
+reference = "https://attack.mitre.org/tactics/TA0009/"
+
+[rule.new_terms]
+field = "new_terms_fields"
+value = ["azure.resource.name"]
+[[rule.new_terms.history_window_start]]
+field = "history_window_start"
+value = "now-7d"