Azure Blob Container to Initial Access

What this lab covers

You discover an Azure storage account with a container more accessible than intended, enumerate what it holds, and recover material from earlier blob versions that leads to access in the tenant.

It is the Azure counterpart to the S3 versioning problem, and the reasoning transfers in both directions. The specific commands differ, the underlying mistake does not.

No prior Azure experience is assumed, and it is a good entry point to the Azure labs because it introduces the CLI and the storage model before anything involving identity.

How Azure Blob exposure works

A storage account contains containers, and each container has a public access level. It can be private, allow anonymous read of blobs when the exact name is known, or allow anonymous listing as well as reading. The difference between the last two decides whether an attacker needs a name or gets an inventory.

Storage account names form a global namespace and resolve to predictable hostnames, so they are enumerable in the same way S3 bucket names are. Organizations name them after the company, environment and application, which makes generated candidate lists effective.

Versioning changes what deletion means. With it enabled, writing over a blob preserves the previous version, and listing versions is a distinct operation from listing blobs. A container that looks clean today may still serve a configuration file from three months ago that contained a live credential.

How to detect this in your own environment

Enable diagnostic logging for the storage account, specifically read and list operations on blobs. This is not on by default, and without it anonymous access to a public container leaves no record you can query.

Alert on changes to container public access level and on account-level changes that permit anonymous access. These are control plane operations recorded in the activity log, and they are rare enough to alert on individually.

Watch for anonymous requests at all on accounts that should not receive any. Volume matters less than the fact of it, since a single anonymous listing on a container holding backups is worth investigating.

How to prevent it

Disable anonymous blob access at the storage account level. This overrides container settings, so it holds even when someone sets a container to public by mistake, which makes it the equivalent of block public access in AWS.

Use short-lived, narrowly scoped shared access signatures rather than public containers where external access is genuinely required, and prefer user delegation signatures tied to an Entra ID identity so they can be revoked.

Rotate any secret that has ever been stored in a blob, rather than overwriting the file. Then use lifecycle management to expire previous versions, since indefinite version retention mainly benefits an attacker.

Real-world context

Misconfigured Azure Blob storage has been behind numerous disclosed data exposures, following the same pattern as object storage exposure on other platforms. The recurring cause is a container made public to solve an immediate delivery problem.

Azure adds a distinctive second issue in shared access signatures. Because a SAS is a URL carrying its own authorisation, one that leaks provides access to anyone holding it until expiry, and long-lived account-level signatures have featured in significant real-world incidents.

The pattern maps to MITRE ATT&CK T1530 Data from Cloud Storage Object and T1552.001 Credentials In Files.

Applying this at work

• Disable anonymous access at the storage account level across your subscriptions, treating exceptions as documented decisions.
• Inventory containers with public access and check whether listing is permitted as well as reading.
• Enable diagnostic logging for blob read and list operations on accounts holding anything sensitive.
• Check for previous blob versions of configuration files and treat any secret found as needing rotation.
• Replace long-lived account SAS tokens with short-lived user delegation signatures that can be revoked.

Frequently asked questions

What is the difference between blob and container public access?

Blob-level access allows anonymous read when the exact blob name is known. Container-level access also allows anonymous listing, which reveals the full inventory. The second turns a narrow exposure into a complete one.

Does overwriting a blob remove a leaked secret?

No, if versioning is enabled. The previous version is retained and readable by anyone able to enumerate versions. Rotation is the remediation, and deleting old versions is housekeeping.

Is anonymous access to Azure storage logged?

Only if diagnostic logging for blob operations is enabled, which is not the default. Without it, anonymous reads leave no record you can query after the fact.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.