Lesson 10 — Azure Privilege Escalation

Welcome

Privilege escalation occurs when an identity with limited access gains additional permissions or reaches resources beyond its intended authority.

In Microsoft Azure, privilege escalation is not limited to obtaining an administrator role.

An attacker may escalate by gaining control of:

• A privileged user
• A Microsoft Entra role
• An Azure RBAC role
• A service principal
• An application registration
• A managed identity
• A virtual machine
• An Azure Function
• An Automation Account
• A deployment pipeline
• A Key Vault
• A resource capable of executing code

Azure privilege escalation is often relationship-based.

A user may not hold a powerful role directly but may control an application, workload, group, or automation process that uses a more privileged identity.

This lesson focuses on identifying these relationships, mapping potential escalation paths, and validating them safely during an authorised Azure penetration testing engagement.

Learning Objectives

By the end of this lesson, you will be able to:

• Explain privilege escalation in an Azure environment.
• Distinguish between Microsoft Entra and Azure resource privilege.
• Identify direct and indirect privilege-escalation paths.
• Assess dangerous Microsoft Entra role relationships.
• Analyse Azure RBAC assignments and custom roles.
• Understand application ownership and credential-management risks.
• Identify managed-identity escalation paths.
• Assess privilege paths involving Virtual Machines and Azure Functions.
• Review automation and deployment mechanisms.
• Understand group-based and inherited privilege.
• Map cross-subscription and cross-environment attack paths.
• Perform authorised privilege analysis using Azure CLI and PowerShell.
• Validate escalation paths using safe, non-destructive methods.
• Document privilege-escalation findings professionally.

Mission Context

You are continuing the authorised Azure penetration test for CloudNova Technologies.

Earlier assessment activities identified:

• Several users with delegated administrative responsibilities
• Multiple Azure RBAC assignments
• Custom roles
• Service principals used by automation
• Azure Functions with managed identities
• Virtual Machines administered by operations teams
• Key Vault access assigned to workloads
• CI/CD pipelines with production deployment privileges
• Groups used to manage cloud access
• Shared identities across development and production

The customer wants to know whether a compromised low-privileged identity could gain broader access.

Your objective is to identify paths that could allow an attacker to:

• Obtain privileged Microsoft Entra access
• Gain control over Azure resources
• Assign additional roles
• Access privileged managed identities
• Modify applications or service principals
• Execute code in trusted workloads
• Retrieve sensitive credentials
• Cross from development into production
• Move between subscriptions
• Establish persistent privileged access

All testing must remain within the authorised tenant, subscriptions, identities, resources, and Rules of Engagement.

What Is Azure Privilege Escalation?

Azure privilege escalation is the process by which an identity obtains permissions beyond those originally intended.

A simplified path may look like this:

Low-privileged identity
        ↓
Control of another object
        ↓
Access to a more privileged identity
        ↓
Expanded Azure permissions
        ↓
Sensitive resource access

Privilege escalation may be:

• Direct
• Indirect
• Vertical
• Horizontal
• Cross-service
• Cross-subscription
• Cross-environment

Vertical Privilege Escalation

Vertical escalation occurs when an identity gains higher authority.

Example:

Standard user
        ↓
Ability to modify application credentials
        ↓
Authentication as privileged service principal
        ↓
Contributor or Owner access

Horizontal Privilege Escalation

Horizontal escalation occurs when an identity gains access to another identity or workload with similar apparent privilege but broader resource reach.

Example:

Developer identity
        ↓
Control of shared automation account
        ↓
Automation identity
        ↓
Access to another application environment

Direct and Indirect Privilege

Direct Privilege

Direct privilege comes from an assignment attached to the identity.

Examples include:

• Owner
• Contributor
• User Access Administrator
• Global Administrator
• Application Administrator
• Key Vault Administrator

Indirect Privilege

Indirect privilege comes from controlling something that has stronger permissions.

Examples include:

• Owning an application registration
• Managing a Virtual Machine with a privileged managed identity
• Modifying an Azure Function that accesses Key Vault
• Controlling a deployment pipeline
• Managing membership of a privileged group
• Editing an automation workflow
• Accessing a credential used by a service principal

Indirect privileges are often overlooked during access reviews.

Azure Privilege Domains

Azure privilege escalation can involve several connected control planes.

Microsoft Entra ID
        ↓
Applications and service principals
        ↓
Azure RBAC
        ↓
Azure resources
        ↓
Managed identities and stored secrets
        ↓
Connected business services

A complete assessment must evaluate the relationships between these layers.

Microsoft Entra Privilege Escalation

Microsoft Entra roles control tenant-level identity and application functions.

Sensitive areas include:

• Administrative roles
• Group management
• Application registrations
• Enterprise applications
• Authentication methods
• Conditional Access
• Privileged Identity Management
• Consent and API permissions

High-Impact Microsoft Entra Roles

Examples of sensitive roles include:

• Global Administrator
• Privileged Role Administrator
• Application Administrator
• Cloud Application Administrator
• Authentication Administrator
• Privileged Authentication Administrator
• User Administrator
• Groups Administrator
• Conditional Access Administrator

The exact impact depends on:

• Role scope
• Administrative units
• Active or eligible status
• Privileged Identity Management controls
• Group ownership
• Application relationships
• Authentication policy

Application Ownership Escalation

An application owner may be able to modify an application registration.

Depending on permissions and configuration, this may include adding:

• A client secret
• A certificate
• A federated credential
• Redirect URIs
• Other application settings

Potential path:

Application owner
        ↓
New credential added
        ↓
Authentication as application
        ↓
Service principal permissions inherited
        ↓
Access to Microsoft Graph or Azure resources

The security impact depends on the application’s existing permissions and Azure role assignments.

Service Principal Escalation

Service principals are commonly used by:

• Automation
• CI/CD pipelines
• Infrastructure as code
• Monitoring platforms
• Enterprise applications
• Security tooling

A service principal may possess:

• Microsoft Graph permissions
• Azure RBAC roles
• Key Vault access
• Storage access
• Deployment privileges
• Cross-subscription access

Potential escalation path:

Low-privileged user
        ↓
Control of service-principal credential
        ↓
Authenticate as service principal
        ↓
Use assigned Azure role
        ↓
Control additional resources

Application Permissions

Applications may hold delegated or application permissions.

Application permissions are particularly sensitive because they may operate without a signed-in user.

Risk areas include permissions that allow an application to:

• Read directory information
• Modify users or groups
• Manage applications
• Access mail or files
• Change identity objects
• Perform tenant-wide operations

The tester should review:

• Granted permissions
• Administrative consent
• Credential ownership
• Sign-in activity
• Business purpose
• Current application owners

Group-Based Privilege Escalation

Azure and Microsoft Entra permissions may be assigned through groups.

A possible path is:

User
  ↓
Can modify group membership
  ↓
Privileged group
  ↓
Administrative role or Azure RBAC assignment
  ↓
Elevated access

Assessment questions include:

• Who owns the group?
• Who can modify membership?
• Is membership dynamic?
• Are guest users included?
• Is the group role-assignable?
• Are access reviews performed?
• Is the privilege active or eligible?

The ability to manage group membership may be equivalent to holding the group’s privileges.

Azure RBAC Privilege Escalation

Azure RBAC governs access to:

• Management groups
• Subscriptions
• Resource groups
• Individual resources

A role assignment combines:

Security principal
+
Role definition
+
Scope

Escalation may occur through:

• Broad built-in roles
• Dangerous custom roles
• Role-assignment permissions
• Resource control
• Managed identities
• Deployment capabilities
• Inherited access

Owner

The Owner role can manage resources and assign Azure roles.

Potential impact includes:

• Granting access to controlled identities
• Creating privileged role assignments
• Maintaining persistent access
• Modifying critical infrastructure

Owner assignments should be tightly governed and narrowly scoped.

User Access Administrator

User Access Administrator can manage access to Azure resources at the assigned scope.

Potential path:

User Access Administrator
        ↓
Create role assignment
        ↓
Grant Owner or another privileged role
        ↓
Expanded resource control

Creating or modifying role assignments must not be tested without explicit approval.

Contributor

Contributor cannot normally assign Azure RBAC roles, but it can still create serious escalation paths.

A Contributor may be able to:

• Modify Virtual Machines
• Modify Function Apps
• Change application configuration
• Deploy code
• Manage automation
• Modify storage configuration
• Control workloads using managed identities
• Access deployment artefacts

Potential path:

Contributor on resource group
        ↓
Control of Azure Function
        ↓
Function uses privileged managed identity
        ↓
Access to Key Vault or other resources

Contributor should be treated as a high-impact role in sensitive environments.

Custom Role Escalation

Custom roles should be reviewed in detail.

Important fields include:

• Actions
• NotActions
• DataActions
• NotDataActions
• AssignableScopes

High-impact permissions may include the ability to:

• Create role assignments
• Modify role definitions
• Deploy workloads
• Execute scripts
• Manage Virtual Machine extensions
• Modify automation
• Manage identities
• Access secret values
• Modify application settings
• Retrieve deployment information

Wildcard actions require particularly careful review.

Role Inheritance

Permissions assigned at higher scopes are inherited by lower scopes.

Management Group
        ↓
Subscription
        ↓
Resource Group
        ↓
Resource

A role assigned at management-group or subscription scope may affect a very large environment.

During an assessment, record whether access is:

• Direct
• Inherited
• Group-based
• Active
• Eligible
• Temporary
• Permanent

Managed Identity Privilege Escalation

Managed identities allow Azure workloads to authenticate to Azure services without storing traditional credentials.

They may be:

• System-assigned
• User-assigned

A compromised workload may be able to use its managed identity.

Potential path:

Compromised workload
        ↓
Managed identity context
        ↓
Azure token
        ↓
Assigned Azure permissions
        ↓
Sensitive resource access

The managed identity’s permissions determine the blast radius.

User-Assigned Managed Identity Risks

A user-assigned managed identity may be attached to multiple resources.

Risk increases when:

• The identity has broad permissions
• Development and production share the same identity
• Many users can attach the identity
• Workloads using the identity are internet-facing
• Identity usage is not monitored
• Resource administrators can assign the identity freely

Potential path:

Developer controls test VM
        ↓
Can attach privileged user-assigned identity
        ↓
VM receives privileged identity context
        ↓
Access to production Key Vault

Any validation involving identity attachment requires explicit approval.

Virtual Machine Privilege Escalation

Virtual Machine management permissions may provide paths to guest operating-system control.

Potentially sensitive capabilities include:

• VM extension management
• Access recovery
• Disk management
• Script execution
• Serial Console access
• Managed identity configuration
• Network modification

Example:

Virtual Machine management permission
        ↓
Authorised code-execution capability
        ↓
Guest operating-system access
        ↓
Managed identity or local credentials
        ↓
Additional Azure access

Production VMs must not be modified without specific approval.

Azure Function Privilege Escalation

A Function App may provide escalation when a user can:

• Modify deployed code
• Change application settings
• Access deployment credentials
• Change managed identities
• Control triggers
• Modify Key Vault references
• Invoke privileged workflows

Example:

Contributor on Function App
        ↓
Modify function code or configuration
        ↓
Function executes as managed identity
        ↓
Managed identity has production access

App Service Privilege Escalation

App Services may expose similar relationships through:

• Application settings
• Deployment slots
• Managed identities
• Publishing profiles
• Source-control integration
• Key Vault references
• SCM endpoints

Control over deployment or configuration may lead to access beyond the application itself.

Automation Account Escalation

Azure Automation Accounts may run:

• PowerShell runbooks
• Python runbooks
• Scheduled tasks
• Operational workflows
• Security automation
• Resource-management actions

They may use:

• Managed identities
• Run As accounts in older deployments
• Service principals
• Stored credentials
• Automation variables
• Certificates

Potential path:

Control of Automation Account
        ↓
Modify or start runbook
        ↓
Runbook uses privileged identity
        ↓
Resource changes across subscription

Automation validation must use isolated test runbooks and explicit approval.

Logic Apps and Workflow Automation

Logic Apps may perform privileged actions through connectors and managed identities.

Potential risk areas include:

• Weak trigger authentication
• Excessive connector permissions
• Secrets in configuration
• Publicly accessible workflows
• Privileged managed identities
• Ability to modify workflow definitions

Example:

Weakly protected trigger
        ↓
Logic App executed
        ↓
Privileged connector or managed identity
        ↓
Sensitive action performed

Deployment-Based Escalation

Azure deployments may use:

• ARM templates
• Bicep
• Terraform
• Deployment scripts
• CI/CD pipelines
• Azure DevOps
• GitHub Actions

A deployment identity may have broad permissions.

Potential path:

Developer modifies infrastructure code
        ↓
Pipeline deploys automatically
        ↓
Privileged pipeline identity
        ↓
Production resource modified

Assessment questions include:

• Who can modify pipeline code?
• Which branches deploy to production?
• Are approvals required?
• What permissions does the pipeline identity hold?
• Are environments separated?
• Are credentials federated or long-lived?
• Are deployment actions monitored?

Deployment Script Escalation

Deployment scripts can execute code as part of infrastructure deployment.

Potential risk:

Permission to modify deployment
        ↓
Deployment script changed
        ↓
Script executes with privileged identity
        ↓
Additional Azure access

The tester should analyse feasibility without altering production deployment code.

Key Vault-Based Escalation

Key Vault access can provide credentials for:

• Databases
• Applications
• Service principals
• Storage Accounts
• Third-party services
• Automation platforms

Potential path:

Managed identity
        ↓
Key Vault Secrets User
        ↓
Service-principal credential
        ↓
Authenticate as privileged application

The privilege of the retrieved credential may be greater than the privilege of the identity accessing the vault.

Storage-Based Escalation

Azure Storage may contain:

• Deployment packages
• Function content
• Scripts
• Templates
• Configuration files
• Backups
• Credentials
• Pipeline artefacts

Potential path:

Write access to deployment container
        ↓
Deployment artefact modified
        ↓
Trusted workload deploys artefact
        ↓
Code executes under privileged identity

Storage write access can be more dangerous than simple data exposure when downstream systems trust stored content.

Container and Kubernetes Escalation

Azure environments may include:

• Azure Container Registry
• Azure Kubernetes Service
• Container Apps
• Container Instances

Potential paths include:

• Pushing a modified image
• Controlling deployment configuration
• Accessing workload identities
• Retrieving Kubernetes credentials
• Modifying privileged workloads
• Abusing CI/CD deployment permissions

These areas should be assessed in their dedicated modules while still being included in the Azure privilege graph.

Cross-Subscription Privilege Escalation

An identity may have access across multiple subscriptions.

Example:

Development subscription resource
        ↓
Shared managed identity
        ↓
Production subscription role
        ↓
Production resource access

Review:

• Cross-subscription role assignments
• Shared service principals
• Shared managed identities
• Management-group inheritance
• Central automation
• Shared networking
• Central Key Vaults
• Common deployment pipelines

Cross-Environment Escalation

Production and non-production environments should maintain appropriate separation.

Potential weaknesses include:

• Shared credentials
• Shared managed identities
• Shared service principals
• Shared pipelines
• Broad network peering
• Shared Key Vaults
• Shared administrative groups
• Shared storage accounts

Example:

Development application compromised
        ↓
Shared service principal
        ↓
Production subscription access

Privileged Identity Management

Privileged Identity Management can provide just-in-time access for:

• Microsoft Entra roles
• Azure resource roles
• Privileged groups

Assessment areas include:

• Eligible versus active assignments
• Activation duration
• Approval requirements
• Multifactor authentication
• Justification
• Notifications
• Access reviews
• Permanent privileged assignments

Potential weakness:

Sensitive role permanently active
        ↓
Privileged account compromised
        ↓
Immediate administrative access

Conditional Access and Privilege

Conditional Access may protect administrative identities.

Assessment questions include:

• Are administrators covered?
• Are service accounts excluded?
• Are emergency accounts governed?
• Is strong authentication required?
• Are risky sign-ins blocked?
• Are unmanaged devices restricted?
• Are exclusions justified?

Conditional Access does not replace least privilege but can reduce identity-compromise risk.

Common Azure Privilege-Escalation Patterns

Application Owner to Privileged Service Principal

Application owner
        ↓
Credential added
        ↓
Authenticate as service principal
        ↓
Use existing Azure role

Group Owner to Privileged Role

Group owner
        ↓
Membership modified
        ↓
Group holds privileged Azure role
        ↓
Expanded access

Contributor to Managed Identity

Contributor on workload
        ↓
Control of workload execution
        ↓
Workload uses privileged managed identity
        ↓
Additional resource access

Function App Control

Function App Contributor
        ↓
Application code changed
        ↓
Code runs under managed identity
        ↓
Key Vault access

Automation Runbook Control

Automation contributor
        ↓
Runbook modified
        ↓
Privileged automation identity
        ↓
Subscription changes

Storage Artefact Modification

Storage write permission
        ↓
Trusted deployment package replaced
        ↓
Privileged workload executes package

Role-Assignment Control

User Access Administrator
        ↓
New role assignment
        ↓
Controlled identity receives elevated role

Custom Role Modification

Role-definition write permission
        ↓
Custom role expanded
        ↓
Additional actions available

Azure Privilege-Escalation Assessment Methodology

Stage 1 — Confirm Scope

Record:

• Tenant ID
• Management groups
• Subscription IDs
• Authorised identities
• Authorised resources
• Permitted validation actions
• Prohibited permission changes

Stage 2 — Inventory Identities

Identify:

• Users
• Groups
• Guest users
• Service principals
• Managed identities
• Privileged administrators
• Pipeline identities
• Automation identities

Stage 3 — Inventory Role Assignments

Review:

• Microsoft Entra roles
• Azure RBAC roles
• Group-based assignments
• Inherited assignments
• Active and eligible assignments
• Custom roles

Stage 4 — Review Object Control

Determine who can manage:

• Groups
• Applications
• Service principals
• Managed identities
• Virtual Machines
• Function Apps
• Automation Accounts
• Logic Apps
• Storage Accounts
• Key Vaults
• Deployment pipelines

Stage 5 — Review Credentials and Secrets

Assess:

• Application credentials
• Certificates
• Federated credentials
• Publishing profiles
• Storage keys
• Key Vault secrets
• Pipeline secrets
• Automation credentials

Do not retrieve sensitive values unless explicitly authorised.

Stage 6 — Map Identity-to-Resource Relationships

Create relationships such as:

User
  ↓
Group
  ↓
Azure role
  ↓
Resource
  ↓
Managed identity
  ↓
Key Vault

Stage 7 — Identify Candidate Escalation Paths

For every candidate path, determine:

• Starting identity
• Existing permissions
• Controlled object
• Intermediate identity
• Target privilege
• Required action
• Expected business impact

Stage 8 — Validate Analytically

Before technical validation:

• Confirm role permissions
• Confirm assignment scope
• Confirm resource relationship
• Confirm identity permissions
• Review available logs
• Determine whether final exploitation is necessary

Stage 9 — Validate Safely

Where approved:

• Use test identities
• Use isolated resources
• Use temporary assignments
• Avoid production secrets
• Avoid destructive actions
• Record every step
• Remove changes immediately
• Confirm logging

Stage 10 — Report the Complete Chain

Document:

• Initial access level
• Intermediate permissions
• Controlled resources
• Final privilege
• Business impact
• Detection opportunities
• Remediation priorities

Authorised Azure CLI Enumeration

Confirm the active identity and subscription:

az account show --output table

List accessible subscriptions:

az account list --output table

Display the signed-in user:

az ad signed-in-user show

List role assignments visible to the current identity:

az role assignment list \
  --all \
  --output table

List assignments for the current user:

CURRENT_USER_ID=$(az ad signed-in-user show --query id -o tsv)

az role assignment list \
  --assignee "$CURRENT_USER_ID" \
  --all \
  --output table

List custom Azure roles:

az role definition list \
  --custom-role-only true \
  --output table

Display custom-role permissions:

az role definition list \
  --custom-role-only true \
  --output json

List groups visible to the authorised identity:

az ad group list --output table

List application registrations:

az ad app list --output table

List service principals:

az ad sp list --output table

List user-assigned managed identities:

az identity list --output table

List Virtual Machines and their identities:

az vm list \
  --query "[].{Name:name,ResourceGroup:resourceGroup,Identity:identity}" \
  --output json

List Function Apps:

az functionapp list --output table

List Automation Accounts:

az automation account list --output table

Only enumerate authorised identities and resources.

Authorised Azure PowerShell Enumeration

Confirm the active Azure context:

Get-AzContext

List subscriptions:

Get-AzSubscription

List Azure role assignments:

Get-AzRoleAssignment

List custom roles:

Get-AzRoleDefinition |
    Where-Object { $_.IsCustom -eq $true }

Display a specific role:

Get-AzRoleDefinition -Name "<authorised-role-name>"

List user-assigned managed identities:

Get-AzUserAssignedIdentity

List Virtual Machines:

Get-AzVM

List Function Apps:

Get-AzFunctionApp

List Automation Accounts:

Get-AzAutomationAccount

Use approved Microsoft Graph tooling for authorised directory-role, group, application, and service-principal analysis.

Do not modify identities, credentials, or role assignments unless explicitly authorised.

Privilege-Graph Documentation

For each candidate escalation path, create a graph containing:

Starting identity
        ↓
Current permission
        ↓
Controlled object
        ↓
Intermediate identity or credential
        ↓
Target permission
        ↓
Affected resource
        ↓
Business impact

Example:

Developer
  ↓
Contributor on Function App
  ↓
Can modify function code
  ↓
Function uses managed identity
  ↓
Managed identity has Key Vault access
  ↓
Production database credential exposed

Safe Validation Strategy

Use the least disruptive evidence available.

Preferred order:

1. Confirm identity and scope.
2. Confirm role assignment.
3. Review role definition.
4. Confirm control of the intermediate object.
5. Confirm privileges of the attached identity.
6. Map the reachable target.
7. Determine business impact.
8. Use a test resource when technical proof is required.
9. Avoid final escalation where analytical evidence is sufficient.
10. Clean up and verify monitoring.

When Analytical Evidence Is Sufficient

The final escalation action may not be necessary when the tester can prove:

• The starting identity controls the resource.
• The resource executes under a privileged identity.
• The privileged identity has documented access to the target.
• The required action is technically feasible.
• The potential impact is clear.

Avoid performing unnecessary high-risk actions merely to produce a screenshot.

Actions Requiring Explicit Approval

Do not perform the following without specific written authorisation:

• Create or remove role assignments
• Modify Microsoft Entra administrative roles
• Add users to privileged groups
• Add application credentials
• Modify service principals
• Attach managed identities
• Modify custom roles
• Deploy code to production
• Install VM extensions
• Start Automation runbooks
• Modify Logic Apps
• Change pipeline workflows
• Retrieve production secrets
• Export certificates
• Access production data
• Disable monitoring
• Modify Conditional Access
• Activate privileged roles
• Change authentication methods
• Establish persistent access

Logging and Detection

Privilege-escalation activity may appear in:

• Azure Activity Logs
• Microsoft Entra audit logs
• Microsoft Entra sign-in logs
• Privileged Identity Management logs
• Application sign-in logs
• Service-principal sign-in logs
• Key Vault audit logs
• Function App deployment logs
• Virtual Machine extension records
• Automation job logs
• CI/CD audit logs
• Microsoft Defender alerts
• Microsoft Sentinel incidents

Detection Opportunities

Security teams should monitor for:

• New Owner assignments
• New User Access Administrator assignments
• Custom role changes
• New application credentials
• Service-principal permission changes
• Privileged group membership changes
• Managed-identity attachment
• Function App code or configuration changes
• VM extension deployment
• Automation runbook changes
• Key Vault role changes
• Privileged Identity Management activation
• Diagnostic-setting removal
• Conditional Access modification

Evidence Collection

For each privilege-escalation finding, record:

• Starting identity
• Identity type
• Existing role
• Assignment scope
• Controlled object
• Relevant permission
• Intermediate identity
• Intermediate identity permissions
• Target resource
• Final potential privilege
• Validation method
• Evidence source
• Detection coverage
• Business impact
• Remediation recommendation

Never include:

• Passwords
• Access tokens
• Client secrets
• Private keys
• Full connection strings
• Sensitive customer data
• Unredacted production credentials

Example Finding

Finding Title

Function App Contributor Can Use a Privileged Managed Identity to Access Production Secrets

Observation

A development operations group has Contributor access to an Azure Function App.

The Function App uses a user-assigned managed identity with Key Vault Secrets User access to a production Key Vault.

Members of the development operations group can modify the Function App configuration and deployed code.

Potential Attack Path

Development operations user
        ↓
Contributor on Function App
        ↓
Modify Function App execution
        ↓
Function runs as user-assigned managed identity
        ↓
Managed identity accesses production Key Vault
        ↓
Production secrets exposed

Business Impact

Compromise of a development operations account could provide indirect access to production credentials and connected services.

This breaks environment separation and increases the impact of a lower-trust identity compromise.

Recommendation

• Remove production Key Vault access from the shared managed identity.
• Use separate managed identities for development and production.
• Restrict Function App administrative access.
• Replace Contributor with a narrowly scoped custom role.
• Restrict who can attach user-assigned managed identities.
• Monitor Function App deployment and configuration changes.
• Alert on unusual Key Vault secret retrieval.
• Rotate potentially exposed secrets.
• Perform regular identity and resource access reviews.

Risk Rating Considerations

The severity of a privilege-escalation finding depends on:

• Starting privilege
• Required actions
• Number of steps
• Authentication controls
• Target privilege
• Scope of access
• Resource sensitivity
• Cross-environment impact
• Credential exposure
• Persistence potential
• Monitoring coverage
• Ease of exploitation
• Business impact

An indirect path to a test resource may present moderate risk.

A short path from a low-privileged identity to production Owner access may present critical risk.

Remediation Principles

Common Azure privilege-escalation recommendations include:

• Apply least privilege.
• Reduce role-assignment scope.
• Remove unused privileged assignments.
• Use Privileged Identity Management.
• Replace permanent privilege with eligible access.
• Require approval and strong authentication.
• Separate Microsoft Entra and Azure administration.
• Review application owners.
• Remove unused service-principal credentials.
• Prefer managed or federated identities.
• Separate production and non-production identities.
• Restrict managed-identity attachment.
• Review custom roles for dangerous permissions.
• Separate deployment administration from production ownership.
• Protect CI/CD pipelines.
• Require production deployment approval.
• Restrict Function App, App Service, VM, and Automation management.
• Protect Key Vault and storage permissions.
• Review privileged group ownership.
• Monitor role and credential changes.
• Alert on workload-identity use.
• Perform periodic privilege-path reviews.
• Maintain environment separation.
• Document business ownership for every privileged identity.

Evidence and Portfolio Outcome

Create an Azure Privilege Escalation Assessment containing:

Identity Inventory

Document:

• Users
• Groups
• Service principals
• Managed identities
• Privileged administrators
• Automation identities
• Pipeline identities

Privilege Inventory

Document:

• Microsoft Entra roles
• Azure RBAC roles
• Custom roles
• Assignment scope
• Direct or inherited access
• Active or eligible status

Resource-Control Review

Document identities that can control:

• Virtual Machines
• Function Apps
• App Services
• Automation Accounts
• Logic Apps
• Storage Accounts
• Key Vaults
• Deployment pipelines

Attack-Path Analysis

For each candidate path, record:

• Starting identity
• Existing privilege
• Controlled object
• Intermediate identity
• Target privilege
• Business impact

Attack-Path Diagram

Create one safe hypothetical escalation path.

User
  ↓
Contributor on workload
  ↓
Workload managed identity
  ↓
Key Vault access
  ↓
Privileged application credential

Detection Review

Document whether security teams can detect:

• Role changes
• Credential additions
• Managed-identity changes
• Resource deployment
• Secret retrieval
• Privileged sign-ins
• Logging changes

Recommendations

Provide prioritised remediation guidance based on escalation feasibility and business impact.

Key Takeaways

• Azure privilege escalation is often relationship-based.
• Direct role assignments provide only part of the privilege picture.
• Application ownership may provide control over privileged service principals.
• Group ownership can indirectly grant administrative access.
• Contributor permissions can create escalation through controlled workloads.
• Managed identities connect resource compromise to additional Azure services.
• Deployment pipelines and automation systems are privileged attack surfaces.
• Storage and Key Vault access may expose credentials with greater permissions.
• Cross-subscription and cross-environment relationships must be reviewed.
• Privileged Identity Management can reduce permanent privilege.
• Analytical evidence may be sufficient without performing the final escalation.
• Testing must remain authorised, controlled, minimal, and reversible.
• Findings should document the complete path from initial identity to business impact.

Knowledge Check

1. What is the difference between direct and indirect privilege?
2. How can application ownership create a privilege-escalation path?
3. Why can group ownership be equivalent to privileged access?
4. Why is Contributor considered a high-impact role?
5. How can a managed identity expand the impact of workload compromise?
6. What risk is associated with user-assigned managed identities?
7. How can control of a Function App lead to additional Azure access?
8. Why are Automation Accounts and deployment pipelines sensitive?
9. How can storage write access lead to code execution?
10. What is the purpose of Privileged Identity Management?
11. Why should production and development identities be separated?
12. When may analytical evidence be sufficient to prove an escalation path?
13. Which logs help detect privilege-escalation activity?
14. What information should be included in a privilege-escalation finding?

Next Lesson

➡️ Lesson 11 — Azure Persistence

In the next lesson, you will examine how attackers may attempt to maintain authorised simulated access through identities, applications, service principals, credentials, role assignments, managed identities, automation, workloads, and other Azure resources, along with the controls required to detect and prevent persistent access.