What is Azure penetration testing? Rules and best practices

What is Azure penetration testing?

Azure penetration testing is authorized, offensive security testing performed against Azure-hosted infrastructure, applications, identities, and data to discover exploitable vulnerabilities before real attackers do. In cloud environments where misconfigurations, over-permissioned identities, and exposed services change daily, periodic testing is essential to validate that your security controls actually hold up under real-world conditions.

The difference between Azure pen testing and traditional on-prem penetration testing comes down to one concept: the shared responsibility model.

Pen testers targeting Azure environments focus on attack paths such as Entra ID abuse or service principal compromise across services like Entra ID (formerly Azure AD), Managed Identities, Blob Storage, Key Vault, AKS clusters, Azure Functions, and App Services. Entra ID controls access across Azure, M365, and connected SaaS applications, and with 600 million daily identity attacks tracked by Microsoft, most attack paths pivot around identity and permissions.

Here is what makes Azure pen testing distinct from traditional infrastructure testing:

• Shared responsibility boundaries: You can test your tenant's configurations but not Microsoft's underlying hypervisor or physical infrastructure.

• Identity-centric attack surface: Entra ID roles, service principals, and Managed Identities replace traditional domain admin escalation paths.

• Ephemeral and serverless workloads: Functions, Logic Apps, and containerized services spin up and down, creating a moving target.

• Cloud-native data stores: Blob Storage, CosmosDB, and Key Vault each have unique access control models that require specialized testing.

Azure Vulnerability Management Best Practices [Cheat Sheet]

If your organization runs critical workloads on Azure and you’re looking for a clear, practical starting point for vulnerability management – this cheat sheet is for you.

Votre adresse e-mail professionnelle ici

Get the cheat sheet

Why Azure penetration testing matters

Azure attack surfaces are expanding rapidly, with 54% of cloud environments exposing VMs with sensitive data. Cloud migration, AI workload deployment, and multi-cloud adoption mean organizations are spinning up new services faster than security teams can review them. Thales reports 44% of organizations have experienced a cloud data breach, and these gaps between what gets deployed and what gets reviewed are exactly what offensive testing reveals.

Compliance frameworks treat penetration testing differently. PCI DSS and FedRAMP explicitly require regular penetration testing, while SOC 2 and ISO 27001 strongly incentivize it as a common way to validate security controls, risk treatment, and assessment coverage in cloud environments. Azure penetration testing supports compliance most directly when it maps test activities to specific control expectations. For example, PCI DSS Requirement 11.4 requires external and internal penetration testing at least annually and after significant changes, while FedRAMP requires annual third-party assessments that validate cloud security controls in production-like environments.

SOC 2 and ISO 27001 do not explicitly mandate penetration testing in all cases, but pen testing is a widely used way to demonstrate control effectiveness, risk treatment, and security assessment maturity. In practice, Azure test evidence such as scope, methodology, findings, retest results, and ownership records helps audit teams prove that cloud controls were validated, not just documented.

Azure environments also drift constantly. New subscriptions, resource groups, role assignments, and networking rules change weekly. A pen test validates whether your security posture holds up against real-world attack techniques, not just whether individual controls pass a configuration check. Azure pen testing must account for identity-based lateral movement, cross-subscription pivoting, and serverless abuse paths that simply did not exist in on-prem environments.

Consider this real-world scenario: a pen tester discovers that a user with the Contributor role can execute commands on VMs via the Run Command feature, pivot to a Managed Identity with Key Vault access, and retrieve production database credentials. No CVE was involved. The risk came entirely from chained identity permissions and misconfigured trust boundaries.

Azure penetration testing rules and scope

Microsoft does not require pre-approval to conduct a penetration test against Azure resources. This removed a significant friction point that previously slowed down engagements. While notifying Microsoft of penetration testing activities is no longer required, customers must still comply with the Microsoft Cloud Penetration Testing Rules of Engagement.

Here is a clear breakdown of what Microsoft's penetration testing rules permit and prohibit:

All encouraged testing activities must be performed within your own tenant or assets for which you have explicit authorization. You own and can test everything above the infrastructure layer, including your VMs, containers, applications, identities, data, and network configurations. You cannot test Microsoft's hypervisor, physical network, or host OS on managed services.

If you need to test your DDoS resilience, you can use Microsoft-approved simulation partners, including BreakingPoint Cloud, a self-service traffic generator for DDoS Protection-enabled public endpoints. Before any engagement, pen testers should define Azure scope at the management group, subscription, tenant, and workload level. That means naming which subscriptions are in scope, whether shared services such as Key Vault, networking hubs, Azure Firewall, or build pipelines are included, whether production testing is allowed, and whether connected services such as Microsoft 365, B2B guest access, or cross-tenant Entra ID trust relationships are part of the engagement.

This scoping step prevents false assumptions. In multi-subscription Azure estates, one shared identity plane or peered network can create an attack path that crosses team boundaries, so ownership, approval, and data-handling rules should be documented before testing starts.

Azure penetration testing methodology

Azure penetration testing usually follows a four-step flow:

1. External reconnaissance: discover public Azure assets such as Blob Storage, App Services, databases, and tenant identifiers.

2. Authenticated enumeration: map Entra ID users, groups, roles, service principals, Managed Identities, subscriptions, and resource permissions.

3. Exploitation and attack chaining: validate whether misconfigurations, exposed services, or excessive permissions can be chained into access to VMs, Key Vault, storage, databases, or Kubernetes clusters.

4. Reporting and remediation: document evidence, rate business impact, assign owners, and retest fixes.

This flow keeps the engagement scoped, repeatable, and aligned with Azure's identity-first attack surface.

Reconnaissance and external attack surface discovery

The first phase maps the target's Azure footprint without credentials through attack surface discovery techniques. Key techniques include:

• DNS suffix enumeration: Probing Azure-specific DNS suffixes like .blob.core.windows.net, .azurewebsites.net, and .database.windows.net to discover exposed services.

• Blob Storage scanning: Checking for publicly accessible storage containers with anonymous read access enabled.

• Tenant enumeration: Using OpenID Connect configuration endpoints to identify the tenant GUID via the issuer field, which helps with scoping.

• Subdomain discovery: Identifying Azure App Services, API Management instances, and other public-facing resources through subdomain brute-forcing.

• OSINT techniques: Searching public code repositories and error messages for leaked Azure connection strings, SAS tokens, or tenant IDs.

This phase often reveals shadow IT resources, forgotten test deployments, and misconfigured storage accounts that expose sensitive data to the public internet. The resources you find during recon today may not have existed last month, which is why periodic pen tests alone leave gaps.

Authenticated testing and privilege escalation

In this gray-box testing phase, the pen tester operates with valid but limited Azure credentials to simulate an insider threat or compromised user account. The key activities include:

• Entra ID enumeration: Mapping users, groups, roles, app registrations, and enterprise applications to understand the identity landscape.

• RBAC analysis: Checking if assigned roles include Owner, Contributor, or custom roles with permissions like Microsoft.Compute/virtualMachines/runCommand/action, which could grant the ability to run commands on VMs.

• Managed Identity abuse: Testing for overprivileged Managed Identities attached to VMs or App Services that allow pivoting to Key Vault, databases, or other sensitive resources.

• Service principal exploitation: Checking for service principals with application-level permissions or credentials stored in accessible locations.

• Token extraction: Attempting to extract access tokens from VM metadata endpoints (IMDS), Azure Cloud Shell sessions, or App Service environment variables.

• Lateral movement paths: Chaining together individual permissions to move from a low-privilege starting point to high-value targets like production databases or Key Vault secrets.

The most critical findings in Azure pen tests are rarely single vulnerabilities. They are multi-step attack chains that combine identity over-permissions, network exposure, and data access.

Between engagements, identity permissions drift as teams respond to incidents, onboard new services, and grant temporary access that becomes permanent. Continuous identity and entitlement monitoring catches these changes as they happen, so the privilege escalation paths validated during a pen test do not quietly reappear weeks later.

Per-service attack surface testing

Each Azure service has its own access control model and common misconfiguration patterns. A thorough pen test covers the services actually deployed in the target environment:

Serverless and PaaS services are frequently undertested because traditional pen test methodologies focus on VMs and networks. Yet these services often have direct access to sensitive data and secrets.

Watch 12-min demo

Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.

Votre adresse e-mail professionnelle ici

Watch now

Point-in-time pen testing vs. continuous cloud security

Traditional penetration testing produces a point-in-time snapshot. Azure environments change daily as teams deploy new resources, modify role assignments, and update network rules. The security posture validated on Monday may no longer hold by Friday.

Between annual or quarterly pen tests, real risks slip through: new subscriptions onboarded without security review, Managed Identities granted excessive permissions during incident response, storage accounts temporarily set to public for a migration and never locked back down.

Modern approaches layer continuous posture management, automated attack path analysis, and AI-powered exploitation on top of traditional pen test cycles. Here is how the two approaches compare:

Pen testing validates depth and creative exploitation. Continuous security catches drift and new exposures between engagements. The most effective security programs treat pen test findings as calibration inputs for their continuous monitoring, using results to refine detection rules and posture checks.

Wiz's approach to Azure penetration testing and continuous security

Wiz does not replace Azure penetration testing. It extends and amplifies its value. Pen tests give you depth at a point in time. Wiz fills the gaps between engagements and surfaces the same types of risks pen testers hunt for, continuously and at scale.

When Wiz connects to your Azure subscriptions, its agentless scanning immediately builds a complete inventory of resources, identities, network configurations, and data stores. This gives your security team the same reconnaissance view that pen testers spend days building manually, including resource inventory, identity mapping, and network exposure analysis, but updated continuously rather than once per engagement.

The Wiz Security Graph then connects these resources into a unified risk model. It correlates misconfigurations, identity permissions, network exposure, and sensitive data to surface exploitable attack paths. This is the same multi-step chain analysis described in the authenticated testing phase above, where a Contributor role chains into a Managed Identity into Key Vault secrets. The difference is that this analysis runs continuously rather than once a quarter.

Wiz's CSPM and CIEM capabilities continuously check Azure configurations and identity permissions against the same benchmarks pen testers test for manually (overly permissive RBAC assignments, publicly accessible storage containers, Key Vault access policy misconfigurations, and unmonitored service principals), helping teams like Datavant reduce vulnerabilities by 51%. When drift happens, Wiz flags it immediately instead of waiting for the next engagement cycle.

Beyond posture checks, the Wiz Red Agent adds an AI-powered layer that autonomously discovers logic flaws, authentication bypasses, and multi-step attack chains in Azure-hosted APIs and applications. The Red Agent reasons about application behavior and adapts its approach in real time, finding vulnerabilities that manual pen tests and traditional scanners miss, including in AI-generated code and vibe-coded applications increasingly deployed across Azure environments.

Get a demo to see how Wiz extends your Azure pen test program with continuous attack path analysis, identity drift detection, and AI-powered application testing.

Agentless full stack coverage of your Azure workloads in minutes

Learn why CISOs at the fastest growing organization choose Wiz to get complete visibility into their entire Azure environment.

Adresse e-mail professionnelle*

Prénom*

Nom*

Pays

Numéro de téléphone*

Entreprise*

Je souhaite recevoir des informations sur les nouveaux produits Wiz, les actualités du secteur et l’agenda des événements (vous pouvez vous désabonner à tout moment)

Abonnez-moi aux e-mails de synthèse du blog Wiz

Soumettre

Pour plus d’informations sur la façon dont Wiz traite vos données personnelles, veuillez consulter notre Politique de confidentialité.

Votre adresse e-mail professionnelle ici

Demander une démo

FAQs about Azure penetration testing