This chapter covers Azure pentesting techniques, a critical skill for the CompTIA PenTest+ PT0-002 exam, specifically under Objective 3.5: Attacks and Exploits. With the widespread adoption of Microsoft Azure, understanding how to assess its security is essential for any penetration tester. Expect roughly 5-10% of exam questions to touch on cloud-specific attacks, including Azure misconfigurations, identity compromises, and privilege escalation paths. This chapter provides the technical depth needed to identify, exploit, and report Azure vulnerabilities.
Jump to a section
Imagine you are a penetration tester hired to assess the security of a large corporate headquarters. The building is Azure. You start outside (internet-facing endpoints) and try to find unlocked doors or open windows (open ports, misconfigured web apps). Once inside the lobby (authenticated to Azure AD), you have limited access—just the visitor badge (basic user permissions). To reach the executive floor (high-privilege resources), you need to steal an employee's badge (compromise a user account) or exploit a broken elevator system (vulnerability in Azure RBAC). The building has many rooms with different locks (Azure resources like VMs, storage accounts, key vaults). Some rooms have doors that automatically lock after 5 minutes (just-in-time access). Security cameras watch every hallway (Azure Monitor, Security Center). As an insider, you might find a maintenance closet with a master key ring (service principal with high privileges). You can also listen to conversations (network traffic capture) or look over shoulders (read access to logs). The goal is to find the CEO's safe (customer data) without setting off alarms (detection). This mirrors Azure pentesting: initial access, privilege escalation, lateral movement, data exfiltration, and covering tracks.
Introduction to Azure Pentesting
Azure pentesting involves assessing the security of Microsoft Azure environments, including infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and software-as-a-service (SaaS) components. Unlike traditional on-premises testing, Azure introduces unique attack surfaces such as Azure Active Directory (Azure AD), managed identities, role-based access control (RBAC), and resource-specific misconfigurations. The PT0-002 exam expects testers to understand common Azure attack vectors, including credential theft, privilege escalation, lateral movement, and data exposure.
Azure AD and Identity Attacks
Azure AD is the identity backbone of Azure. Common attacks include password spraying, MFA fatigue, and token theft. Password spraying involves trying common passwords against many accounts to avoid account lockouts. For example, an attacker might use a tool like 'SprayingToolkit' to test 10,000 accounts with the password 'Spring2024!'. Azure AD allows up to 10 failed attempts before triggering smart lockout, but an attacker can stay under this threshold. MFA fatigue attacks send repeated push notifications to a user's phone until they accidentally approve. Token theft occurs when an attacker steals a refresh token from a compromised device, allowing them to generate new access tokens without re-authentication.
Azure Resource Discovery
Before attacking, testers must discover Azure resources. Tools like 'Azurite', 'MicroBurst', and 'PowerZure' enumerate Azure subscriptions, VMs, storage accounts, and SQL databases. For example, using PowerZure:
Get-AzureTarget -SubscriptionId "xxxx-xxxx-xxxx-xxxx"This command lists all resources in a subscription. Key information includes resource names, locations, tags, and public IP addresses. Testers also look for open ports on VMs using Shodan or Azure's own Network Security Groups (NSGs). NSGs are stateful firewalls that filter traffic based on rules. A common misconfiguration is allowing inbound RDP (port 3389) from 'Internet' (0.0.0.0/0), which exposes VMs to brute-force attacks.
Exploiting Azure Storage Accounts
Azure Storage accounts are a prime target due to misconfigured access controls. The most common issue is setting the 'Allow Blob Public Access' property to 'Enabled' and then creating a container with 'Container' (anonymous read access) or 'Blob' (anonymous read access for blobs only) permissions. Using tools like 'Azure Storage Explorer' or 'AzCopy', an attacker can list and download blobs. For example:
azcopy list "https://mystorageaccount.blob.core.windows.net/mycontainer?<SAS-token>"If no SAS token is required, the URL alone grants access. Testers also look for shared access signatures (SAS) tokens in source code or configuration files. A SAS token can be reused until its expiry, which might be set to 'never'.
Privilege Escalation via RBAC
Azure RBAC defines who can do what within a subscription. A common privilege escalation path is from a 'Contributor' role to 'Owner' by exploiting managed identities or custom roles. For example, a Contributor can assign the 'Owner' role to themselves if they have 'Microsoft.Authorization/roleAssignments/write' permission, which is often included in custom roles. Another path is using the 'User Access Administrator' role to grant themselves full access. Testers use tools like 'AzureHound' to map privilege escalation paths. AzureHound collects data from Azure AD and Azure Resource Manager to identify relationships that can be exploited.
Lateral Movement with Managed Identities
Managed identities allow Azure resources to authenticate to other services without storing credentials. If a tester compromises a VM with a managed identity, they can request tokens for that identity and use them to access other resources. For example, using the Azure Instance Metadata Service (IMDS) endpoint:
curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net"This returns an access token for Key Vault. The attacker can then use the token to read secrets. The IMDS endpoint is only accessible from within the VM, so the attacker must first gain code execution on the VM.
Attacking Azure Key Vault
Azure Key Vault stores secrets, keys, and certificates. Attackers target Key Vault by exploiting misconfigured access policies. For example, if a user has 'Get' and 'List' permissions on secrets, they can retrieve all secrets. Using Azure CLI:
az keyvault secret list --vault-name myvault
az keyvault secret show --vault-name myvault --name mysecretTesters also look for Key Vault firewall settings that allow 'All networks' instead of 'Selected networks'. If the firewall is disabled, anyone with the vault URL can attempt to access secrets, though authentication is still required.
Exploiting Azure Functions and Logic Apps
Azure Functions and Logic Apps can be vulnerable to injection attacks. For example, an HTTP-triggered Function might execute user input without sanitization, leading to code injection. Testers look for Functions with anonymous authorization level (AuthLevel = anonymous). They can then call the function endpoint and inject malicious payloads. Logic Apps often store sensitive data in connection parameters, which can be retrieved if the Logic App's workflow definition is exposed.
Network Attacks: VNet Peering and NSGs
Azure Virtual Networks (VNets) can be peered, allowing resources in different VNets to communicate. If a tester compromises a resource in one VNet, they can use VNet peering to reach resources in another VNet. NSGs control inbound and outbound traffic. A common mistake is allowing all outbound traffic (0.0.0.0/0) from a VM, which enables data exfiltration. Testers use tools like 'nmap' from within a compromised VM to scan internal networks.
Using Azure CLI and PowerShell for Post-Exploitation
Once initial access is gained, testers use Azure CLI or PowerShell to enumerate and exploit. Common commands:
# List all subscriptions
Get-AzSubscription
# Get current user context
Get-AzContext
# List all VMs
Get-AzVM
# Run command on VM
Invoke-AzVMRunCommand -ResourceGroupName "rg" -VMName "vm" -CommandId "RunPowerShellScript" -ScriptPath "script.ps1"The 'Invoke-AzVMRunCommand' allows executing scripts on VMs if the tester has 'Virtual Machine Contributor' role or higher.
Azure Automation Accounts and Runbooks
Automation accounts run PowerShell or Python runbooks. If a tester gains access to an Automation account, they can create or modify runbooks to execute code on target machines using Hybrid Runbook Workers. For example, a runbook can be set to run on a specific VM and exfiltrate data. Testers look for Automation accounts with 'Run As' accounts that have high privileges.
Azure DevOps and Pipeline Attacks
Azure DevOps pipelines can contain secrets and deploy code. Testers target DevOps by compromising PAT (Personal Access Tokens) or stealing OAuth tokens. Once inside a pipeline, they can modify build tasks to inject malicious code into production. For example, a pipeline variable 'AzureServiceConnection' might hold credentials for Azure subscription access.
Detection Evasion in Azure
Azure has extensive logging via Azure Monitor, Log Analytics, and Security Center. Testers must understand what generates logs: Azure AD sign-in logs, resource logs, activity logs, and NSG flow logs. To evade detection, testers use techniques like:
Using Azure CLI from a compromised VM to reduce network-based detections.
Disabling diagnostic settings if they have 'Monitoring Contributor' role.
Using encrypted channels (HTTPS) to exfiltrate data.
Purging logs using 'az monitor diagnostic-settings delete'.
Reporting and Remediation
After testing, pentesters must document findings with clear steps to reproduce, impact, and remediation. For example: - Finding: Storage account 'storage123' has blob public access enabled. - Impact: Unauthorized users can read all blobs in container 'backups'. - Remediation: Set 'Allow Blob Public Access' to 'Disabled' and use SAS tokens for controlled access.
Exam-Relevant Tools and Commands
Memorize these tools and commands for the exam:
- PowerZure: PowerShell module for Azure post-exploitation.
- AzureHound: BloodHound-inspired tool for Azure privilege escalation paths.
- MicroBurst: Exploitation toolkit for Azure.
- Azurite: Lightweight Azure storage emulator for testing.
- Key commands: Get-AzRoleAssignment, Get-AzResource, Invoke-AzVMRunCommand.
Common Pitfalls and Exam Traps
Trap: Thinking that disabling 'Allow Blob Public Access' at the account level is enough; containers still need individual public access disabled.
Trap: Assuming managed identities are only for VMs; they can be assigned to App Services, Functions, and Logic Apps.
Trap: Confusing 'Contributor' with 'Owner'; Contributor cannot change RBAC assignments unless they have additional permissions.
Trap: Overlooking Azure AD Application permissions; an application with 'Directory.Read.All' can read all users and groups.
The exam will present scenarios where you must identify the most likely attack path. Always check the principle of least privilege and look for misconfigurations that grant excessive permissions.
Discover Azure Resources
Use tools like PowerZure or Azure CLI to enumerate all resources in a subscription. Run `Get-AzResource` to list resource groups, VMs, storage accounts, SQL databases, etc. Note public IPs, open ports, and exposed endpoints. Also enumerate Azure AD users and groups using `Get-AzureADUser`. This step establishes the attack surface.
Identify Misconfigurations
Look for common misconfigurations: storage accounts with public access, VMs with open RDP/SSH to the internet, NSGs with overly permissive rules, Key Vaults with weak access policies, and Azure AD applications with excessive permissions. Use tools like MicroBurst's 'Get-AzStorageContainer' to list public containers. Document each finding with resource IDs and affected permissions.
Exploit Identity Weaknesses
Perform password spraying against Azure AD accounts. Use a tool like 'SprayingToolkit' with a list of usernames and a common password. Stay under the lockout threshold (10 attempts per account per 30 minutes). If MFA is enabled, try MFA fatigue by sending multiple push notifications. Alternatively, steal tokens from compromised devices using token theft tools like 'TokenTactics'.
Escalate Privileges
Once you have initial access (e.g., as a Contributor), look for privilege escalation paths. Use AzureHound to map relationships. For example, if you have 'Microsoft.Authorization/roleAssignments/write' on a scope, assign yourself the Owner role. Or, if you have 'User Access Administrator', grant yourself full access. Another path: if you can modify a custom role, add permissions like '*/read' to escalate.
Lateral Movement and Data Exfiltration
Use managed identities to move laterally. From a compromised VM, request tokens via IMDS and access Key Vault secrets. Use those secrets to access other resources. Exfiltrate data by copying storage blobs using `azcopy` or downloading files via PowerShell. To avoid detection, use encrypted channels and disable diagnostic settings if possible.
In a real-world engagement, a pentester was hired to assess a large enterprise's Azure environment. The company had hundreds of subscriptions and thousands of resources. The tester started by using Service Principal authentication with a client ID and secret obtained from a source code repository (a common leak). With 'Reader' role on a subscription, they enumerated all resources and found a storage account with 'Allow Blob Public Access' enabled. Inside, they discovered a container with 'Container' permission containing backup files with database credentials. Using those credentials, they accessed an Azure SQL Database and found customer PII. This was a classic chain: leaked credentials → read access → public storage → database compromise.
Another scenario involved a company using Azure DevOps. The tester found a PAT token in a build pipeline variable. With the PAT, they accessed the Azure DevOps API and enumerated all pipelines. One pipeline had a task that deployed to an Azure Web App. The tester modified the pipeline to add a malicious script that exfiltrated the Web App's connection strings. The Web App had a managed identity with access to Key Vault, so the tester retrieved all secrets. This attack leveraged CI/CD pipeline weaknesses.
A third example: a pentester targeted a company that used Azure Virtual Desktop (AVD). They performed password spraying against AVD user accounts and gained access to a session host. From there, they used the IMDS endpoint to get a token for the session host's managed identity, which had 'Virtual Machine Contributor' on other VMs. They then used Invoke-AzVMRunCommand to execute code on a domain controller VM and extracted Active Directory hashes. This shows how Azure-specific features can be chained for lateral movement.
Common misconfigurations in production include: (1) Storage accounts with public access enabled for 'backup' containers, (2) NSGs allowing RDP from 'Any' to jump boxes, (3) Key Vault access policies granting 'Get' to all users in a subscription, (4) Azure AD applications with 'Directory.Read.All' and no admin consent required, (5) Automation accounts with 'Run As' accounts that have Owner privileges. Performance considerations: enumerating large subscriptions can be slow; use parallel queries. Always test during off-peak hours to avoid impacting production.
The PT0-002 exam (Objective 3.5) focuses on cloud-specific attacks, including Azure. Expect scenario-based questions where you must identify the correct attack step or tool. The most common wrong answers involve confusing Azure RBAC roles (e.g., thinking 'Contributor' can assign roles, which only 'Owner' and 'User Access Administrator' can do). Another trap is assuming that disabling public access at the storage account level automatically secures all containers—containers have their own public access settings. Candidates also mix up managed identities with service principals: managed identities are tied to a resource, while service principals are application identities.
Specific numbers to memorize: Azure AD smart lockout default is 10 failed attempts per account per 30 minutes. The IMDS endpoint is at 169.254.169.254. The default token expiry for managed identities is 8 hours. Key Vault firewall can allow 'All networks' or 'Selected networks'. Storage account public access is disabled by default but can be enabled.
Edge cases: (1) Azure AD B2B guest users can be attacked via password spraying if they have accounts in the tenant. (2) Azure AD Connect servers synchronize on-prem AD to Azure AD; compromising one can lead to cloud compromise. (3) Azure Lighthouse allows cross-tenant management; testers must check if delegated resources are accessible.
To eliminate wrong answers, focus on the underlying mechanism. For example, if a question asks how to access a storage account without credentials, look for 'Allow Blob Public Access' and container permission 'Container' or 'Blob'. If the question involves moving from a VM to Key Vault, think of IMDS and managed identity. Always check the principle of least privilege: the path of least resistance is often the correct answer.
Azure AD smart lockout default: 10 failed attempts per account per 30 minutes.
IMDS endpoint: 169.254.169.254 – used to obtain managed identity tokens.
Storage account public access: must be disabled at both account and container level.
Contributor cannot assign RBAC roles; only Owner and User Access Administrator can.
Key Vault firewall default: 'All networks' – change to 'Selected networks' to restrict.
Managed identity token default expiry: 8 hours.
AzureHound maps privilege escalation paths in Azure AD and Azure Resource Manager.
These come up on the exam all the time. Here's how to tell them apart.
Managed Identity
Tied to a specific Azure resource (VM, App Service, etc.).
Automatically rotates credentials; no manual secret management.
Cannot be used outside of Azure (e.g., from on-premises).
Uses the IMDS endpoint to obtain tokens.
Easier to manage; recommended for Azure resources.
Service Principal
An application identity registered in Azure AD.
Requires manual management of client secrets or certificates.
Can be used from anywhere (on-premises, other clouds).
Uses OAuth 2.0 client credentials flow to obtain tokens.
Suitable for third-party applications and automated tools.
Mistake
Disabling 'Allow Blob Public Access' at the storage account level prevents all anonymous access.
Correct
Disabling at the account level prevents new containers from being public, but existing containers with public access remain accessible until their individual public access settings are changed.
Mistake
Managed identities can only be used by VMs.
Correct
Managed identities can be assigned to many Azure resources, including App Services, Azure Functions, Logic Apps, and Container Instances.
Mistake
The Contributor role can assign roles to other users.
Correct
Contributor can create and manage resources but cannot assign permissions. Only Owner and User Access Administrator can modify RBAC assignments.
Mistake
Azure Security Center automatically detects all misconfigurations.
Correct
Security Center provides recommendations but does not detect all misconfigurations, especially those related to custom RBAC roles or complex policy violations.
Mistake
Key Vault firewall, when set to 'All networks', blocks all traffic except from allowed IPs.
Correct
'All networks' allows traffic from any IP address. To restrict, you must select 'Selected networks' and specify allowed IP ranges or virtual networks.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
PowerZure is a PowerShell module for Azure post-exploitation. To enumerate resources, first import the module: `Import-Module PowerZure`. Then run `Get-AzureTarget -SubscriptionId <id>` to list all resources. You can also use `Get-AzureVM`, `Get-AzureStorageAccount`, and `Get-AzureKeyVault` for specific resource types. Ensure you have authenticated with `Connect-AzAccount` first.
A managed identity is an Azure AD identity automatically managed by Azure and tied to a specific resource (e.g., a VM). It cannot be used outside Azure. A service principal is a manual identity created in Azure AD for an application, requiring client secrets or certificates, and can be used from anywhere. Managed identities are easier to manage and recommended for Azure resources.
First, check if the storage account has 'Allow Blob Public Access' enabled. Then list containers: `az storage container list --account-name <name>`. If a container has public access level 'Container' or 'Blob', you can list and download blobs using `az storage blob list` and `az storage blob download`. No authentication is needed beyond the URL.
MFA fatigue is an attack where the attacker repeatedly sends MFA push notifications to a user's phone until the user accidentally approves one. The attacker may have the user's password from a previous breach. This exploits user annoyance and lack of attention. Defenses include number matching in MFA prompts or requiring additional context.
AzureHound collects data from Azure AD and Azure Resource Manager to build a graph of relationships. Run `AzureHound` with appropriate permissions to gather data. Then import the output into BloodHound to visualize paths. Look for edges like 'CanAssign', 'CanExecute', or 'MemberOf' that indicate privilege escalation opportunities.
The Azure Instance Metadata Service (IMDS) endpoint is at 169.254.169.254 and is accessible only from within an Azure VM. It provides metadata about the VM, including managed identity tokens. To get a token, send a request: `curl -H "Metadata: true" "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=<resource>"`. The token can then be used to access other Azure services.
Yes, if the VM has the Azure CLI installed or you can install it. You can authenticate using the managed identity of the VM: `az login --identity`. Then you can run commands to enumerate and exploit other resources. This is often stealthier than using external tools.
You've just covered Azure Pentesting Techniques — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?