« Azure Storage Account Keys Accessed by Privileged User Azure Storage Blob Retrieval via AzCopy »
Elastic Docs ›Elastic Security [8.19] ›Detections and alerts ›Prebuilt rule reference

Azure Storage Anonymous Blob Access to Unusual Resource

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Azure Storage Anonymous Blob Access to Unusual Resource

edit

Identifies the first time an Azure Storage resource receives an anonymous data-plane read (GetBlob and related Get or List operations). Anonymous requests are used to probe public containers and to test stolen blob URLs before a SAS is appended. First-seen resource ID keeps volume down while still covering WireServer-related probes of status or extension blobs.

Rule type: new_terms

Rule indices:

  • logs-azure.platformlogs-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: Azure
  • Data Source: Azure Platform Logs
  • Platform: Azure
  • Service: Azure Storage
  • Use Case: Threat Detection
  • Tactic: Discovery
  • Tactic: Collection
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Azure Storage Anonymous Blob Access to Unusual Resource

StorageRead platform logs record AuthenticationType as Anonymous when no SAS, OAuth, or account key is presented. A first-seen azure.resource.id (typically the blob service /subscriptions/.../storageAccounts/<account>/blobServices/default) means this resource has not had anonymous Get or List traffic in the history window.

WireServer SAS-replay chains often start with an anonymous GetBlob (HTTP 409/403) against the same object, then a SAS 200. This rule does not require guest-agent path strings; those lab container names are not production observables.

source.ip is often empty. Use source.address (ip:port).

Possible investigation steps

  • Review event.action, azure.platformlogs.statusCode, and azure.platformlogs.uri.
  • HTTP 200 with Anonymous means the container or blob is publicly readable. HTTP 409/403 is a probe.
  • Identify the account from azure.resource.id / azure.resource.name and check whether public access is intended.
  • Search for SAS-authenticated GetBlob to the same account from the same source shortly after.
  • If the URI contains /$system/ or md-hdd-, correlate with WireServer access on VMs in the subscription.

False positive analysis

  • Public blob websites and CDN origins. Exclude the azure.resource.id for approved public accounts.
  • New accounts that enable StorageRead for the first time will alert on the first scanner hit.

Response and remediation

  • Disable anonymous public access on accounts that should be private.
  • If a follow-on SAS read exists, revoke that SAS and review how the URL was obtained.
  • Keep StorageRead diagnostic logs enabled on storage accounts of interest.

Setup

edit

Required Azure Storage Diagnostic Logs

Enable StorageRead diagnostic logs on Azure Storage Accounts and stream them to the Event Hub used by the Azure integration. Anonymous vs SAS is azure.platformlogs.identity.type.

Rule query

edit
data_stream.dataset: azure.platformlogs and
    azure.platformlogs.identity.type: Anonymous and
    event.action: (
        GetBlob or GetBlobMetadata or GetBlobProperties or GetBlockList or
        GetPageRanges or QueryBlobContents or ListBlobs or
        GetContainerProperties or GetContainerMetadata or GetContainerAcl
    )

Framework: MITRE ATT&CKTM

« Azure Storage Account Keys Accessed by Privileged User Azure Storage Blob Retrieval via AzCopy »