Azure Storage Account Attacks and Detections

What it is

A practitioner walkthrough of Azure Storage Account abuse, centered on Shared Access Signature (SAS) tokens for blob storage and Azure Files. The distinction that matters: user-delegation SAS (signed with a key tied to the generating Entra user's permissions) versus account-key SAS (signed with the storage account's access key — effectively a "god key").

How it works

An account-key-signed SAS grants whatever it's scoped to (read, write, container-wide) with none of the identity guardrails. The page states such tokens are NOT subject to password policy, Conditional Access, or JIT/PIM, and can be issued with near-indefinite expiry. They surface in the wild — the author reports finding them "floating out in a GitHub build or repo" and in pipelines.

Detection turns on one field. Generating a user-delegation key logs an operation named GetUserDelegationKey; the account-key path produces no equivalent documented event (the author notes this is undocumented, inferred behavior). So you detect on the signature at use time: a user-delegation SAS carries skoid (the Entra principal's object ID) plus sktid/skt/ske/sks/skv; an account-key SAS has none of these — no object ID exists to record.

Preconditions / Affected

• Detection requires Diagnostic Settings enabled on the blob resource, logging to StorageBlobLogs.
• Matters wherever account-key SAS tokens are issued — CI/CD pipelines and any environment still using SAS instead of Managed Identities.

What to do

Hunt for account-key SAS usage — the absence of skoid on a SAS-authenticated GetBlob:

StorageBlobLogs
| where OperationName == 'GetBlob'
| where AuthenticationType == "SAS"
| where not(Uri has "skoid")

Defensive priority order stated by the page:

1. Don't use SAS tokens at all — prefer Managed Identities.
2. If you must, use user-delegation keys over account keys for granular, revocable control.
3. Restrict tokens to specific IP addresses and set real expiration dates ("that aren't 200 years in the future").

Caveats

• The missing-event behavior for account-key SAS is the author's research finding, explicitly not documented by Microsoft — treat it as an assumption, not a guarantee.
• Detection is use-time only: because account-key SAS generation leaves no clear log, you cannot reliably alert on a token being minted, only on it being used against a blob.
• The skoid-absence heuristic depends on Diagnostic Settings being on beforehand; it gives no retroactive visibility.

The object-replication cross-tenant exfiltration technique is only introduced, not completed, in the captured text — the summary's mention is as far as the page (as fetched) goes.