Azure Penetration Testing: Rules, Scope and Attack Paths

Azure compromises rarely start with the network. They start with identity: an app registration with more permissions than it needs, a client secret left in a repository, a managed identity with owner rights, or a consent grant nobody reviewed. Azure penetration testing targets that layer, plus the storage, secrets and workloads it controls.

This guide covers Microsoft’s testing rules, what a test checks, an example attack path written the way a report describes it, the link between on-premises Active Directory and the cloud, and how to scope an engagement. It is the Azure companion to our AWS penetration testing guide and GCP penetration testing guide.

Why Entra ID is the real Azure perimeter

Every Azure resource is managed through an identity in Microsoft Entra ID (formerly Azure AD): a user, a group, an app’s service principal, or a managed identity. A valid token for the right identity reaches the management plane from anywhere. Network rules on a virtual network do not stand between a stolen credential and your subscriptions; identity controls do.

Azure also has two permission systems that are easy to review separately and hard to reason about together:

• Entra roles govern the directory: users, groups, app registrations and tenant settings.
• Azure roles (RBAC) govern resources: management groups, subscriptions, resource groups and everything in them.

Microsoft states that the two are “secured independently from one another,” then documents a setting that lets a Global Administrator assign themselves User Access Administrator at root scope, over every subscription and management group in the tenant (Microsoft Learn). A test that looks at only one of the two systems misses the paths that cross between them.

Microsoft’s rules for testing Azure

You do not need Microsoft’s approval. As of June 15, 2017, Microsoft no longer requires pre-approval to test Azure resources, and notification is no longer required. You and any firm you hire must follow the Microsoft Cloud Unified Penetration Testing Rules of Engagement. A third party needs explicit written authorization from the resource owner, and Microsoft does not grant it on your behalf (Microsoft Learn: Penetration testing).

Prohibited under the rules of engagement:

• Denial-of-service testing of any kind. DDoS is prohibited under all circumstances; Microsoft lists approved simulation partners for resilience testing.
• Accessing, scanning or testing tenants, data or storage accounts you do not own or have permission to test.
• Using credentials or secrets that are not your own, including ones leaked publicly.
• Network-intensive fuzzing or automated testing that generates excessive traffic.
• Phishing Microsoft employees, or using Microsoft services to phish anyone else.
• Going beyond initial proof of concept if the test finds a flaw in a Microsoft service itself. That finding goes to the Microsoft Security Response Center.

Encouraged by the same rules: creating test accounts or trial tenants to test cross-tenant scenarios, fuzzing and port scanning your own Azure virtual machines, testing your tenant’s security monitoring and detection, evaluating Conditional Access and Intune app protection policies, and attempting to break out of shared service containers such as App Service or Functions, with an immediate stop and report on success.

Two practical effects. A phishing test cannot use Azure-hosted infrastructure to send its lures. And Azure’s abuse detection may flag legitimate testing, so keep the written authorization where you can find it quickly.

Shared responsibility: what you may test

Microsoft’s shared responsibility matrix makes three areas yours under every service model, whether IaaS, PaaS or SaaS: your data, your configurations and settings, and your identities and users. Applications and network controls are shared in PaaS. Physical hosts, the physical network and the datacenter are Microsoft’s (Microsoft Learn).

That line sets the scope. Your tenant, your identities, your subscriptions, your configurations and your applications are testable. Microsoft’s hosts and infrastructure are not, and there is nothing there you would need to test anyway.

What an Azure penetration test covers

Entra ID roles and privileged access

Who holds Global Administrator and the other privileged roles, and whether that access is standing or activated on demand through Privileged Identity Management. Break-glass accounts, guest users with more reach than intended, and Conditional Access policies with gaps: legacy authentication still allowed, broad exclusions, or admin portals outside MFA.

App registrations, service principals and consent

Every app registration can hold secrets or certificates, and every one of those is a credential. The test inventories them: how old they are, who owns the app, and which API permissions were granted with admin consent. It also checks whether ordinary users can consent to third-party apps, which is how malicious OAuth apps get into a tenant.

Managed identities

Managed identities remove stored secrets, which is good. They also give a resource its own access, and that access is often broader than the resource needs. The test maps which virtual machines, App Service apps and Functions carry an identity, what that identity can reach, and whether a flaw in the application would hand an attacker that access. This is the Azure version of the metadata-service risk in our AWS guide, and the reason a web application test and a cloud test belong in the same conversation.

Azure RBAC, subscriptions and management groups

Owner, Contributor and User Access Administrator assignments at broad scopes, inherited from a management group where nobody looks. Custom roles with wildcard actions. Identities that can assign roles, because an identity that can grant access can grant it to itself.

Storage accounts and SAS tokens

Containers open to anonymous access, storage account keys still enabled and shared widely, and shared access signature (SAS) tokens with long lifetimes or broad permissions sitting in code, config files or URLs. Network rules that leave storage reachable from the internet when it should be private.

Key Vault

Who can read secrets, keys and certificates, whether the vault uses access policies or Azure RBAC, and whether soft delete and purge protection are on. The test also looks at what is stored. A vault full of passwords for other identities is a map to the next step.

Functions and App Service

Secrets in app settings, deployment credentials that still allow basic authentication, exposed management endpoints, and the identity each app runs as.

Network controls

Management ports open to the internet in network security groups, virtual machines with public IPs, and PaaS services with public network access on when a private endpoint exists. Network controls matter less than identity in Azure, but they still decide what an attacker can reach from the outside.

Logging and detection

Whether Entra sign-in and audit logs, the Azure activity log and Microsoft Defender for Cloud would have caught each step of the test, and whether anyone was alerted. A finding that says “we reached the subscription and nothing fired” changes priorities faster than one that only says “we reached the subscription.”

Example attack path: a leaked app secret to subscription owner

This is how a report narrates an attack path. Each step on its own looks like a medium or low finding. Together they are critical.

1. A secret in source control. A client secret for the app registration used by a deployment pipeline sits in an old commit in a code repository.
2. A role broader than the job. The pipeline’s service principal can deploy to one application, but it holds a role over the whole resource group, including a Key Vault it has no reason to read.
3. A credential for something bigger. The Key Vault stores the secret of an older deployment identity from a migration project.
4. Standing owner rights. That older identity was given Owner on the production subscription during the migration and never reduced.

From one leaked secret, the tester ends with Owner on production: control of every resource in the subscription and the ability to grant access to anyone. In an authorized test, the tester proves the access without changing production and stops there, as the rules of engagement for the test require.

The fixes, in order:

• Remove and rotate the leaked secret, then move the pipeline to workload identity federation, which lets GitHub Actions or Azure Pipelines authenticate without a stored secret (Microsoft Learn).
• Scope the pipeline’s role to the resources it deploys.
• Replace stored credentials in Key Vault with managed identities where possible.
• Remove standing Owner assignments and use Privileged Identity Management for the rare times they are needed.
• Alert on new role assignments at subscription and management group scope.

A configuration scanner reports steps 2 and 4 as separate items, and it cannot see step 1 or connect step 3. The value of the test is showing the chain. Our guide to CI/CD pipeline security covers the same pipeline trust from the build side.

Hybrid identity: where Active Directory and Azure meet

Most Microsoft-stack companies sync on-premises Active Directory to Entra ID. Microsoft says the Entra Connect server “contains critical identity data” and “must be treated as a Tier 0 component” (Microsoft Learn). In practice that means a compromise on one side can become a compromise on the other. A synced account with a privileged Entra role puts cloud control one on-premises password away, and a weak sync server puts the domain at risk.

A hybrid test covers both halves: an internal network penetration test for the Active Directory side, and the cloud test for Entra ID and Azure. When only the directory is in question, our Active Directory security assessment covers the on-premises paths from $6,000, and our Active Directory hardening checklist lists the Tier 0 checks to run first. When the concern is the Microsoft 365 tenant rather than Azure subscriptions, the Microsoft 365 security assessment reviews Entra ID, Conditional Access, Exchange Online and sharing settings from $4,200. Two quick wins we recommend: keep Entra admin roles on cloud-only accounts rather than synced ones, and treat the sync server with the same care as a domain controller.

Configuration review vs attack-path test

Half one: configuration review. Settings are checked against the CIS Microsoft Azure Foundations Benchmark and the Microsoft cloud security benchmark with read-only access. Microsoft Defender for Cloud, and open-source tools such as Prowler and ScoutSuite, enumerate misconfigurations at a scale no person can match. This half answers one question: does each setting match the recommended value?

Half two: attack paths. The tester starts from a realistic foothold, such as a standard user, a developer’s identity, a leaked secret or a compromised web app, and works toward the data and the subscriptions. Identity graph tools such as BloodHound help map the relationships. This half answers the question that matters: what can an attacker reach, and how?

A secure score or a benchmark report is half one, and auditors know the difference. When a read-only review is what you need, our cloud security assessment delivers half one on its own, from $4,200.

How to scope an Azure penetration test

Have these answers ready and scoping takes one call:

1. Tenants and subscriptions: how many, and how the management groups are laid out.
2. Workloads: rough counts of virtual machines, App Service apps, Functions, AKS clusters, SQL databases, storage accounts and Key Vaults.
3. Identity: how many app registrations and service principals, whether you sync from on-premises AD, whether Privileged Identity Management is in use, and how many guest users.
4. Access for the test: Reader on the subscriptions plus a read-only directory role such as Global Reader for the configuration half, and test identities that mirror real roles for the attack-path half.
5. Applications: which web apps and APIs run in Azure, and whether to test them in the same engagement through API penetration testing or a web application test.
6. Starting points: which footholds to model, such as a standard employee, a developer, or an attacker with only internet access.
7. Compliance driver: it decides what the report has to map to.
8. Anything outside the rules: DDoS resilience goes to a Microsoft-approved simulation partner, and phishing runs from outside Azure.

Compliance and Azure

Running in Azure does not remove a testing obligation. It moves it.

• SOC 2 auditors expect testing that covers the infrastructure the service runs on. See SOC 2 penetration testing.
• PCI DSS Requirement 11.4 applies to the cardholder data environment wherever it runs, including segmentation inside Azure. See PCI DSS penetration testing.
• HIPAA requires an evaluation of the safeguards around ePHI, including storage accounts and databases that hold it. See HIPAA penetration testing.
• NYDFS Part 500 requires annual penetration testing of a covered entity’s information systems. See NYDFS penetration testing.
• CMMC Level 2 enclaves hosted in Azure, including GCC High, still need their boundary tested. See the CMMC Level 2 requirements checklist.

What an Azure penetration test costs

Our cloud penetration testing starts at $6,800 for a single subscription on one provider, fixed in writing before work begins. Several subscriptions, with AKS or serverless workloads tested alongside, start at $10,500. Large estates with many subscriptions and identities, or more than one cloud, start at $17,500. A hybrid engagement adds the internal network test for Active Directory, from $6,000. Every test includes the configuration review, the attack-path testing, a full report and a free retest of the fixes. The tiers are on the cloud penetration testing pricing page.

Frequently asked questions

Do I need Microsoft’s permission to run an Azure penetration test? No. Pre-approval ended on June 15, 2017, and notification is no longer required. You must follow Microsoft’s rules of engagement, and a testing firm needs your written authorization.

Can the test include Entra ID? Yes, and it should. Entra ID holds the identities that control every Azure resource, so most serious Azure findings start or end there.

Is a Microsoft Defender for Cloud secure score enough? No. It is a configuration review, the first half of a test. It does not show how findings chain together or what an attacker could reach.

How long does it take? About a week of testing for a single subscription, then reporting and the retest once your fixes are in. More subscriptions, more identities and container or serverless workloads take longer. See how long a penetration test takes.

Will the test affect production? The configuration review is read-only. Attack-path testing uses agreed test identities, stays inside the scope you approve, avoids everything on Microsoft’s prohibited list, and proves access without changing production.

How much does it cost? From $6,800 for a single subscription, from $10,500 for several, and from $17,500 for large or multi-cloud estates, each with a free retest.

If you run on Azure and want to know what an attacker could reach from one leaked secret, scope a cloud assessment. Comparing vendors first? Our list of cloud penetration testing companies covers the field.