Azure Pentesting

Azure differs from AWS/GCP in one key point: it’s deeply intertwined with Entra ID (formerly Azure AD), the identity that also governs Microsoft 365. That means an Azure compromise can extend to M365 and vice versa (see Microsoft 365 and Entra ID), and that enumeration and escalation revolve around the tenant’s users, roles, applications, and managed identities. It’s the most common cloud environment in companies already using Windows/AD.

Two planes: Entra ID and Azure Resource Manager

Entra ID (identity)         users, groups, apps, directory roles (Global Admin...)
Azure RM (resources)        subscriptions, resource groups, VMs, storage, RBAC roles (Owner...)

Both have their own roles and their own escalation. Global Administrator (Entra) and Owner (RM) are the targets. A key link: a Global Admin can elevate to control all subscriptions.

Credentials and access

# ways in
az login                              # user/password, token, service principal
az login --service-principal -u <appId> -p <secret> --tenant <tenant>
# stolen tokens, refresh tokens (see cloud-m365), managed identities (cloud-metadata)

Enumeration

# CLI
az account show ; az ad signed-in-user show
az role assignment list --all ; az resource list
# specialized tools
ROADrecon        # thorough Entra ID enumeration (dump to a database)
AzureHound       # BloodHound for Azure -> escalation graph
MicroBurst       # enum/exploitation scripts (PowerShell)
Stormspotter / PowerZure

AzureHound + BloodHound is as powerful here as in on-prem AD: it maps escalation paths between users, roles, apps, and resources.

Typical escalation vectors

# Entra ID
- Application / Service Principal with excessive permissions (API permissions, consent)
- misassigned directory roles; "Privileged Role Administrator" -> Global Admin
- app consent abuse (illicit consent grant) -> users' tokens
- misconfigured dynamic groups (add yourself to a privileged group)
# Azure RM
- roleAssignments/write (User Access Administrator) -> assign yourself Owner
- a VM/function's Managed Identity with permissions -> steal its token (cloud-metadata)
- Automation Accounts / Runbooks with credentials or privileged identities
- Custom roles with dangerous actions (Microsoft.Authorization/*)

Managed Identities (the equivalent of the instance role)

# from a compromised VM, request its Managed Identity token (see cloud-metadata)
curl -H "Metadata:true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
# use the token to act as that identity (az rest / API)

Persistence

# add credentials to a Service Principal (clientSecret/cert) -> persistent access
# create an app with permissions and consent; add a user to a privileged role
# federation / authentication changes (stealthier, see cloud-m365)

For the defense

MFA and Conditional Access on all users, especially privileged ones.
PIM (Privileged Identity Management): just-in-time privileged roles, not permanent.
Review app/Service Principal permissions and consent (block user consent).
RBAC least privilege; watch roleAssignments/write and dangerous custom roles.
Logs: Entra ID sign-in/audit logs, Azure Activity Log, Microsoft Defender for Cloud; alerts on role/SP-credential changes.

Testing checklist

Access with user/SP/token and az account show
Enumerate Entra ID (ROADrecon) and RM resources
AzureHound + BloodHound for escalation paths
Apps/Service Principals with excessive permissions / consent
roleAssignments/write → Owner; directory roles → Global Admin
VM/function Managed Identities (token, Metadata Service (IMDS))
Automation Accounts/Runbooks with credentials
Bridge to M365 (Microsoft 365 and Entra ID) and persistence