Azure Penetration Testing Guide

Introduction

An enterprise organization migrated their identity infrastructure to Azure, implementing Entra ID (formerly Azure AD) for single sign-on across hundreds of applications. The migration was successful from a functionality standpoint, but security review was deferred due to project timelines. Months later, an attacker used a phishing campaign to compromise a single user account. Because that account had been granted Global Administrator through a nested group membership that wasn't documented, the attacker gained complete control of the Azure tenant—accessing email, SharePoint, and every connected application.

Azure's deep integration with enterprise identity, hybrid environments, and Microsoft 365 creates a complex attack surface. Misconfigurations in Entra ID, Azure resources, or the boundaries between on-premises and cloud can have cascading effects. This guide covers Azure penetration testing policies, common attack vectors, and testing strategies.

Azure Penetration Testing Policy

Microsoft permits penetration testing on Azure services without prior approval, provided you follow their rules of engagement. You may test applications and services you own, Azure resources within your subscription, and your Entra ID tenant.

Prohibited activities include:

• Denial of Service attacks against any Azure services
• Testing infrastructure you don't own
• Attempting to access other customers' data
• Social engineering attacks against Microsoft employees

For red team or adversary simulation that might trigger Microsoft's security monitoring, submit a penetration testing notification through the Azure portal. This prevents your testing from being flagged as malicious.

Testing Entra ID Security

Entra ID (Azure Active Directory) is often the highest-value target. A compromised privileged identity can access every connected resource.

Directory Enumeration: Test what information is exposed to authenticated users:

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All"
Get-MgUser -All | Select-Object DisplayName, UserPrincipalName, AccountEnabled
Get-MgGroup -All | Select-Object DisplayName, Description

Default configurations often allow all users to enumerate directory objects, helping attackers identify targets.

Privileged Role Assignments: Identify users with high-privilege roles:

# Get Global Administrators
Get-MgDirectoryRoleMember -DirectoryRoleId (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
 
# List all role assignments
Get-MgDirectoryRole | ForEach-Object {
    $role = $_
    Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | ForEach-Object {
        [PSCustomObject]@{
            Role = $role.DisplayName
            Member = $_.AdditionalProperties.displayName
        }
    }
}

Look for users with permanent Global Administrator assignments (should use PIM), nested group memberships granting unintended privileges, service principals with high-privilege roles, and external identities with privileged access.

Conditional Access Gaps: Test for bypass conditions—policies that exclude users, legacy authentication not blocked, or overly broad trusted locations. Test from different IP ranges, device types, and authentication methods.

Application Permissions: Review applications with dangerous permissions like Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory that enable privilege escalation if the application is compromised.

Testing Azure Resource Security

Storage Accounts: Test for public access:

az storage account list --query '[].{Name:name,PublicAccess:allowBlobPublicAccess}'
az storage container list --account-name <storage-account> --query '[].{Name:name,PublicAccess:properties.publicAccess}'

Look for containers with "blob" or "container" public access, SAS tokens with excessive permissions, and missing encryption.

Network Security Groups: Find overly permissive rules:

az network nsg list --query '[].{Name:name,Rules:securityRules[?access==`Allow` && direction==`Inbound`]}'

Common misconfigurations: RDP (3389) or SSH (22) exposed to 0.0.0.0/0, database ports accessible from the internet.

Key Vault Security: Verify access controls:

az keyvault show --name <vault-name> --query 'properties.accessPolicies'
az keyvault show --name <vault-name> --query 'properties.networkAcls'

Look for access policies granting all permissions, Key Vaults accessible from all networks, and soft delete disabled.

Azure-Specific Attack Vectors

Hybrid Identity Attacks: Organizations using Azure AD Connect face specific risks:

• The sync server stores credentials that can be extracted with admin access
• Pass-through authentication agents can be compromised for authentication interception
• Misconfigured federation can enable token forgery

Managed Identity Abuse: Compromised VMs with managed identities can use those identities to access other Azure resources:

az vm identity show --name <vm-name> --resource-group <rg>

Test what resources each managed identity can access.

ARM Template Secrets: Deployment history may contain sensitive parameters:

az deployment group show --name <deployment-name> --resource-group <rg>

Automation Account Abuse: Runbooks execute with automation account credentials and can be modified if users have contributor access.

Testing Azure Functions and App Services

# Check authentication settings
az functionapp auth show --name <app-name> --resource-group <rg>
 
# Check HTTPS enforcement
az webapp show --name <app-name> --resource-group <rg> --query 'httpsOnly'
 
# Check for FTP access
az webapp show --name <app-name> --resource-group <rg> --query 'ftpsState'

Test for functions accessible without authentication, exposed SCM (Kudu) endpoints, and HTTP allowed without redirect.

Testing RBAC

az role assignment list --all --query '[].{Principal:principalName,Role:roleDefinitionName,Scope:scope}'

Look for Owner or Contributor roles assigned too broadly, users with permissions at subscription or management group level, and custom roles with overly permissive action wildcards.

Logging and Monitoring

Verify security logging is enabled:

az monitor diagnostic-settings list --resource <resource-id>

Test for activity logs with appropriate retention, diagnostic settings on critical resources, and Azure AD audit and sign-in logs enabled.

Conclusion

Azure penetration testing requires understanding tight integration with enterprise identity through Entra ID, hybrid connectivity with on-premises environments, and the extensive RBAC model. Misconfigurations in any of these areas can provide attackers with paths to broad access.

Regular security testing helps identify misconfigurations before they're exploited. On-demand testing allows teams to validate Azure configurations as they evolve, catching privilege escalation paths and identity security gaps. RedVeil's AI-powered platform can assess Azure-connected applications and help identify security issues across your cloud infrastructure.

Start testing your Azure environment with RedVeil today.