Skip to content

[New Rule] Azure Storage Account Blob Public Access Enabled #5138

@terrancedejesus

Description

@terrancedejesus

Summary

Missing detections for MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE operations in Azure Storage regarding Blob Storage being made publicly accessible. This was seen in a recent STORM-0501 ransom campaign where data was targeted after identity compromise for encryption or deletion. Access to storage accounts allowed the adversary to make Blob Storage publicly available and accessible externally.

event.dataset:"azure.activitylogs" and
event.action:"MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and
event.outcome:"success" and
azure.activitylogs.properties.responseBody: *\"allowBlobPublicAccess\"\:true*

Additional Information:

  • Emulation - We emulated this in TRADE's tenant by creating a resource group > creating a storage account (Standard_LRS) > storage update --allow-public-access true to make the Blob Storage to be public.
  • There is some data discrepencies with azure.activitylogs.properties.... It is meant to be a nested field, but we have escaped JSON strings in requestBody and responseBody causing us to use wildcards and escapes in the query above. An issue has been submitted to security integration -> [Azure] Escaped JSON in azure.activitylogs.properties integrations#15421
  • New Terms - This rule should be a new terms on azure.resource.name which is the Storage Account associated with the setting. We also want to make sure our filter is on responseBody within event.outcome: success as this confirms the Storage Account has the setting updated according to the response. New terms will help ensure we only flag if we have never seen the Storage Account with public access enabled.

STORM-0501 Ref: https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/

The threat actor then targeted the organization’s Azure Storage accounts. Using the public access features in Azure Storage, Storm-0501 exposed non-remotely accessible accounts to the internet and to their own infrastructure, paving the way for data exfiltration phase. They did this by utilizing the public access features in Azure Storage. To modify the Azure Storage account resources, the threat actor abused the Azure Microsoft.Storage/storageAccounts/write operation.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions