Azure Storage data exfiltration: SAS tokens and blob logs
Investigate Azure Storage data exfiltration: listAccountSas and listKeys in the Activity Log, GetBlob bursts in blob logs, SAS token hashes, what to rotate.
TL;DR. Storage exfiltration leaves two kinds of traces. In the Activity Log: listKeys/action, listAccountSas/action, listServiceSas/action, and configuration changes that open the account (allowBlobPublicAccess: true, firewall defaultAction: Allow). In the storage resource logs (StorageRead / StorageBlobLogs, only if enabled): GetBlob requests with the caller IP, the authentication type, a hash of the SAS or token, the object key and the bytes returned. A SAS signed client-side with an account key is never logged at creation; you only see it when it is used. Rotating both account keys revokes account and service SAS.
The storage account is where the data is. The investigation question after a cloud compromise is almost always "what did they take?", and for blob storage that question is answerable — if the right diagnostic setting existed.
How attackers get to the data
| Path | Control-plane trace (Activity Log) | Data-plane trace (storage log) |
|---|---|---|
| Read the account keys, sign their own SAS offline | Microsoft.Storage/storageAccounts/listKeys/action | GetBlob with SAS or AccountKey authentication |
| Ask Azure Resource Manager to mint an account or service SAS | listAccountSas/action / listServiceSas/action | GetBlob with SAS authentication, statusText SASSuccess |
| Use an Entra identity with a data role (Storage Blob Data Reader…) | Possibly a roleAssignments/write first | GetBlob with OAuth, requester object ID |
| Make a container public | storageAccounts/write or containers/write with public access | GetBlob with Anonymous |
| Open the storage firewall | storageAccounts/write with defaultAction: Allow or public network access enabled | Requests from IPs that were blocked before |
MITRE ATT&CK tracks the collection as T1530 Data from Cloud Storage. Storm-0501, as documented by Microsoft Threat Intelligence, used listkeys/action and exfiltrated with AzCopy before mass-deleting storage accounts.
The SAS problem: creation is invisible
A shared access signature is a signed URL. Microsoft's documentation is blunt: "It's not possible to audit the generation of SAS tokens", and a SAS token "is not tracked by Azure Storage in any way" (SAS overview). A SAS signed locally with an account key produces no event at all. What you can see:
listKeys/action— someone retrieved the keys (and could sign unlimited SAS offline).listAccountSas/action/listServiceSas/action— someone asked ARM to sign one. The request body shows the requested services, permissions, start and expiry.- Every use of a SAS, in the storage resource logs, if enabled.
Microsoft's recommendation to disallow Shared Key authorization on accounts that do not need it removes the whole class: without Shared Key, account and service SAS stop working.
Reading StorageBlobLogs
The Blob Storage monitoring reference documents the fields. The ones that matter for exfiltration:
| Field (storage export) | Example | Why |
|---|---|---|
operationName | GetBlob, ListBlobs, PutBlob, DeleteBlob | What happened |
callerIpAddress | 203.0.113.66:51234 | Where from (note the port suffix) |
identity.type | SAS, AccountKey, OAuth, Anonymous | How the request was authorized |
identity.tokenHash | key1(…),SasSignature(…) | Which key signed the SAS, and a SHA-256 of the SAS itself |
identity.requester.objectId | GUID | The Entra identity, for OAuth |
properties.objectKey | /account/container/blob | Which blob |
properties.responseBodySize | bytes | How much left |
properties.userAgentHeader | AzCopy/10.x … | Which tool |
statusCode / statusText | 200 / SASSuccess | Success or failure |
The SasSignature(…) hash is your pivot: every request with the same hash used the same SAS token, whoever held it. The analyzer uses it as the principal for SAS access (shown as sas:<hash prefix>), so one leaked SAS appears as one entity with its IPs and total bytes.
Storage logs are voluminous. The analyzer keeps routine reads out of the events table but still counts and evaluates every one of them.
What the analyzer flags
| Rule | Detects | Level |
|---|---|---|
AZ-ST-001 | Account or service SAS generated through ARM (listAccountSas, listServiceSas) | High |
AZ-ST-002 | Account keys listed or regenerated | Low |
AZ-ST-003 | Anonymous blob access enabled on the account or a container | High |
AZ-ST-004 | Storage firewall opened to all networks | Medium |
AZ-ST-005 | Bulk download: at least 50 distinct blobs read by the same identity from the same IP within 60 minutes, with total bytes | High |
AZ-ST-006 | Anonymous blob reads | Medium |
AZ-VM-005 | Disk or snapshot exported with a SAS URL | High |
AZ-ST-002 is low on purpose: the portal's storage browser, Function Apps and backup tools list keys all the time. It becomes interesting next to other findings.
Sizing the exposure
Breach-notification work needs facts, not "the attacker had access to the account". Build them from the logs:
- List the blobs read by the suspicious principal / SAS hash / IP: object keys, sizes, timestamps. The Azure Forensics analyzer groups them per identity, IP and account, with the byte total.
- Separate reads from listings.
ListBlobsreveals names;GetBlobreveals content. - Check partial reads. A
downloadRangefield means only part of the blob was transferred. - Check writes and deletes (
StorageWrite,StorageDelete): ransomware-style actors delete after copying. - Check the other services. Blob logs do not cover Files, Queues or Tables; each has its own log categories.
For example, in the site's fictional sample, one SAS used from one IP reads 330 distinct backup blobs in 18 minutes, about 48.6 GB in total. That number, per container, is what legal teams need.
Remediation
- Rotate both storage account keys. Microsoft documents that account and service SAS are signed with the account key, so regenerating the key invalidates them. User delegation SAS are revoked by revoking user delegation keys.
- Disable anonymous access and restore the firewall (default action Deny, private endpoints).
- Consider disallowing Shared Key authorization.
- Enable
StorageRead/StorageWrite/StorageDeleteon the blob service of sensitive accounts, now. - Establish what data was read, for notification obligations (for example the GDPR's 72-hour notification to the supervisory authority, Article 33).