Attacking Azure & Azure AD, Part II

What it is

Part II of hausec's Azure/Azure AD offensive research (by the author and Andy Robbins), based on findings from real customer engagements rather than a lab. It releases PowerZure 2.0 and documents three concrete attack primitives: service-principal-based privilege escalation, crossing from Azure AD control into Azure resource control, and pivoting from cloud to on-premise via Intune.

How it works

Three chained primitives:

• Azure vs. Azure AD RBAC are separate. Roles share no definitions; a role in one does not grant it in the other. Azure's Contributor has actions: * but NotActions blocks Microsoft.Authorization/*/Write (reserved to Owner).
• Service principal escalation. An application's service principal held Global Administrator. A low-privileged user listed as an Owner of that application can add a new secret/certificate to the SP, then log into Azure PowerShell as that SP with GA rights.
• GA → Azure resource control. Per Sean Metcalf, a GA can toggle the User Access Administrator role in Azure (via portal, or an undocumented API call — PowerZure's Set-AzureElevatedPrivileges), letting them add themselves as Owner of any subscription/resource.
• Cloud → on-prem via Intune. Intune (an Azure AD resource, so governed by AAD roles) manages any enrolled device, including on-prem workstations/servers. A GA can upload PowerShell scripts that execute as SYSTEM, targeting hybrid-joined devices to reach the on-prem domain.

flowchart TD
    O[Owner on privileged App] -->|add SP secret| SP[Login as SP = Global Admin]
    SP -->|create new user + grant GA| NU[New GA user]
    NU -->|API call| UAA[User Access Administrator in Azure]
    NU -->|upload PS script to Intune| SYS[SYSTEM on hybrid-joined device]
    UAA --> AZ[Owner of any Azure resource]
    SYS --> ONPREM[On-prem AD]

Preconditions / Affected

• A user must be an Owner of an application whose service principal holds a privileged AAD role (GA).
• Cloud-to-on-prem pivot requires hybrid-joined devices enrolled in Intune and GA-level rights.

Caveats

The page states a real limitation: the User Access Administrator elevation API call cannot be executed by a service principal (confirmed via a GitHub issue). The workaround is for the SP-as-GA to create a new user, grant it GA, and run the call as that user — the escalation to Azure only works through the freshly created interactive user, not the SP directly. The fetched text cuts off mid-sentence in the Intune section, so the exact script-upload steps are not fully captured here.