Detecting SAS Token Exposure: Defender for Cloud and Sentinel KQL

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

Overly permissive or leaked SAS tokens provide direct access to Azure Storage. These detections help find token exposure and misuse.

Signals worth watching

• Storage requests authenticated with SAS from unfamiliar IP addresses.
• SAS-authenticated requests that write or delete data unexpectedly.
• Large downloads using SAS tokens.
• SAS tokens with long expiry detected in code repositories (GitHub secret scanning alerts).
• Storage account key regeneration or listing by unexpected identities.
• Defender for Storage alerts.

Where the data lives

• StorageBlobLogs (and file/queue/table logs): AuthenticationType shows SAS, AccountKey, OAuth or Anonymous.
• Azure Activity logs: listKeys, regenerateKey.
• GitHub secret scanning alerts.
• Defender for Storage alerts.

A starting query

SAS-authenticated access by caller IP:

StorageBlobLogs
| where AuthenticationType == "SAS"
| summarize Requests = count(), Writes = countif(OperationName in ("PutBlob", "DeleteBlob", "PutBlock")),
    Bytes = sum(ResponseBodySize) by AccountName, CallerIpAddress, bin(TimeGenerated, 1h)
| sort by Bytes desc

Response

1. Revoke the token: for account or service SAS, rotate the storage account key (and update legitimate consumers); for user delegation SAS, revoke user delegation keys.
2. Review accessed and modified data.
3. Check integrity of data that may have been modified, such as AI models or software packages.
4. Remove exposed tokens from repositories and history.