Detecting Azure Blob Public Access: Defender for Cloud and Sentinel KQL

Retrospective: this article looks back at events from October 2022, written in 2026 with the benefit of hindsight.

Public Azure Blob access is often discovered by outsiders scanning for open containers. Detecting both the configuration and anonymous access helps you find exposure first.

Signals worth watching

• Storage accounts with allowBlobPublicAccess enabled and containers set to Blob or Container public access level.
• Changes enabling anonymous access.
• Anonymous read requests in storage logs.
• Defender for Storage alerts, for example access from suspicious IP addresses, anonymous scanning, or unusual data extraction.

Where the data lives

• Azure Resource Graph for configuration.
• Azure Activity logs for storage account and container setting changes.
• StorageBlobLogs (diagnostic settings) for request-level detail, including the authentication type.
• Defender for Storage alerts.

A starting query

Anonymous requests in blob logs:

StorageBlobLogs
| where AuthenticationType == "Anonymous"
| summarize Requests = count(), Bytes = sum(ResponseBodySize) by AccountName, CallerIpAddress, bin(TimeGenerated, 1h)
| sort by Requests desc

Configuration changes:

AzureActivity
| where OperationNameValue =~ "MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE"
| where ActivityStatusValue == "Success"
| project TimeGenerated, Caller, _ResourceId, Properties

Response

1. Disable anonymous access and change container access levels to private.
2. Review logs to determine what was accessed and by whom.
3. Rotate any keys or tokens stored in the exposed data.
4. Enforce Azure Policy to prevent recurrence.