Azure Penetration Testing: Methodology and Approach

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. Teams also running on AWS can compare the best AWS penetration testing companies.

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.

Azure Penetration Testing: The Short Answer

Azure penetration testing is an authorized simulation of attacks against the Azure resources and Microsoft Entra ID tenant an organization owns. It focuses on identities and permissions, exposed services, storage, containers, serverless functions and the paths an attacker could use to move from one foothold to sensitive data or control of a subscription.

Microsoft has not required pre-approval since June 15, 2017, but every test must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement. Denial-of-service testing, testing tenants you do not own and using credentials that are not your own are prohibited. Microsoft summarizes the rules on its Azure penetration testing page.

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 keys 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

Many large enterprises run critical workloads and identities on Azure and Microsoft Entra ID, making them a prime target for threat actors. While Microsoft provides robust security controls, misconfigurations, weak identity management, and excessive permissions remain the biggest attack surfaces. Experienced Azure consulting specialists can help organizations design secure cloud architectures, strengthen access controls, and reduce configuration-related risks.

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.

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.
• No pre-approval, but rules apply: Microsoft dropped the notification requirement for Azure in 2017; the Rules of Engagement are the authoritative source for what is allowed.
• Third-party testers: consultants and red teams need explicit written authorization from the resource owner. Microsoft does not grant authorization on the customer's behalf.
• No denial-of-service testing: DoS and DDoS tests are prohibited in all cases. Use one of Microsoft's approved DDoS simulation partners if you need to test resilience.
• Abuse alerts: Azure may flag legitimate testing. Keep the signed authorization ready so you can answer an abuse notification quickly.

Tip: Use a signed Rules of Engagement (RoE) document to protect both the testing team and the client, and if you're outsourcing the work, check how the leading cloud penetration testing companies define scope before you commit.

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 (Microsoft Entra ID, formerly 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 Microsoft Entra admin center.
• Review sign-in logs for low-privilege accounts accessing portal.

Mitigation

• Setting Restrict access to Microsoft Entra admin center to Yes only adds friction to portal browsing; Microsoft states it is not a security measure. To limit enumeration, restrict default user permissions (for example, guest access restrictions and, where business needs allow, the authorization-policy default permission allowedToReadOtherUsers) and rely on Conditional Access and monitoring of Graph/directory reads.
• 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; no credentials)
curl -s "https://<acct>.blob.core.windows.net/<container>?restype=container&comp=list"
# An XML blob list means anonymous listing is enabled; 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: Obtain bearer tokens from a compromised Cloud Shell session.

# Inside Cloud Shell (current Azure CLI uses MSAL)
az account get-access-token --resource https://management.azure.com
az account get-access-token --resource https://graph.microsoft.com
# MSAL token cache (plaintext on Linux): ~/.azure/msal_token_cache.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

For a wider comparison of tools across AWS, Azure and Google Cloud, see our cloud penetration testing tools guide.

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.

Frequently Asked Questions

Do I need Microsoft's permission to pentest Azure?

No. Microsoft has not required pre-approval for penetration testing of Azure resources since June 15, 2017. You must still follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement, and you may only test resources you own or are explicitly authorized to test.

What is not allowed when pentesting Azure?

Microsoft prohibits denial-of-service testing of any kind, testing tenants or data you do not own, using credentials or secrets that are not your own, network-intensive fuzzing, phishing Microsoft employees, and post-exploitation against Microsoft online services beyond an initial proof of concept.

What should an Azure penetration test cover?

A typical test covers Microsoft Entra ID users, roles and app registrations; Azure RBAC and managed identities; storage accounts and Key Vault; containers (ACR, AKS); Functions and App Service; network exposure; and whether logging and detection catch the attack paths found.

Can a third party pentest my Azure environment?

Yes. Consulting firms, managed security providers and red teams can test Azure resources with explicit written authorization from the resource owner, documented in the service agreement before testing begins.

How do you pentest Azure without disrupting production?

Agree scope and testing windows in writing, use dedicated test accounts, start with read-only enumeration, avoid any denial-of-service or high-volume traffic, and keep the signed authorization ready in case Azure flags the activity.

Expert Sources Referenced

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