Lesson 03 — Azure RBAC Exploitation

Welcome

Azure role-based access control determines who can access Azure resources, what actions they can perform, and where those permissions apply.

During an Azure penetration testing engagement, RBAC analysis is one of the most important activities because excessive or incorrectly assigned permissions can allow an attacker to:

• Access sensitive resources
• Modify cloud infrastructure
• Retrieve secrets
• Deploy malicious workloads
• Assign additional permissions
• Impersonate managed identities
• Escalate privileges
• Move laterally across subscriptions

Azure RBAC weaknesses are not always obvious.

A user may appear to have limited permissions but still control a resource that exposes credentials, runs code, or uses a highly privileged managed identity.

This lesson focuses on identifying these relationships and safely validating authorised Azure RBAC attack paths.

Learning Objectives

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

• Explain how Azure RBAC works.
• Identify the components of an Azure role assignment.
• Distinguish between Azure RBAC roles and Microsoft Entra roles.
• Understand Azure RBAC scope inheritance.
• Identify high-impact built-in roles.
• Analyse custom roles for dangerous permissions.
• Recognise common RBAC privilege-escalation paths.
• Perform authorised RBAC enumeration using Azure CLI and PowerShell.
• Safely validate excessive permissions without disrupting production.
• Document Azure RBAC findings using professional evidence standards.

Mission Context

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

During the Microsoft Entra ID assessment, you identified several users, service principals, and managed identities associated with Azure resources.

The customer has asked your team to determine whether these identities have more access than required.

Your objectives are to identify:

• Excessive role assignments
• High-risk custom roles
• Privileged access at broad scopes
• Identities capable of assigning roles
• Resources controlled by low-privileged users
• Managed identities with excessive permissions
• Privilege-escalation relationships
• Cross-subscription access paths

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

What Is Azure RBAC?

Azure role-based access control is the authorisation system used to manage access to Azure resources.

Azure RBAC answers three questions:

Who
+
Can perform what actions
+
At which scope

A role assignment contains three main components:

Security principal
+
Role definition
+
Scope

Security Principal

A security principal is the identity receiving access.

It may be:

• A user
• A group
• A service principal
• A managed identity

Example:

Security principal: cloud-engineer@gohackerscloud.com

Role Definition

A role definition describes the actions an identity is allowed or denied to perform.

Examples include:

• Reader
• Contributor
• Owner
• User Access Administrator
• Virtual Machine Contributor
• Storage Blob Data Contributor
• Key Vault Secrets Officer

A role definition may be:

• A Microsoft built-in role
• A customer-created custom role

Scope

Scope defines where the permission applies.

Azure RBAC supports the following hierarchy:

Management group
        ↓
Subscription
        ↓
Resource group
        ↓
Individual resource

Permissions assigned at a higher scope are inherited by lower scopes unless specific controls prevent the action.

For example:

Contributor at subscription scope
        ↓
Contributor access to all resource groups
        ↓
Contributor access to most resources

Azure RBAC Versus Microsoft Entra Roles

Azure RBAC and Microsoft Entra roles control different administrative areas.

Control system	Primary purpose
Microsoft Entra roles	Manage identities, applications, authentication, and tenant configuration
Azure RBAC roles	Manage Azure subscriptions, resource groups, and resources

Examples of Microsoft Entra roles include:

• Global Administrator
• Application Administrator
• Privileged Role Administrator
• Authentication Administrator

Examples of Azure RBAC roles include:

• Owner
• Contributor
• Reader
• User Access Administrator
• Virtual Machine Contributor

An identity may hold both Entra and Azure RBAC privileges.

These permissions should be assessed separately and then analysed together as part of an attack path.

Management Plane and Data Plane

Azure permissions may apply to two different areas.

Management-Plane Permissions

Management-plane permissions control Azure resource configuration.

Examples include:

• Creating a virtual machine
• Modifying a storage account
• Updating a network security group
• Assigning a managed identity
• Configuring diagnostic settings

These actions are normally represented under:

Actions
NotActions

Data-Plane Permissions

Data-plane permissions control access to the information stored inside a resource.

Examples include:

• Reading blob data
• Retrieving Key Vault secrets
• Accessing queue messages
• Reading files from storage
• Executing database operations

These actions are normally represented under:

DataActions
NotDataActions

A tester must review both management-plane and data-plane permissions.

A user may be unable to modify a storage account but still have permission to read all data stored within it.

Built-In Azure Roles

Microsoft provides many built-in Azure roles.

Some of the most important roles during an assessment include the following.

Reader

Reader can view Azure resources but cannot normally modify them.

Although it appears low risk, Reader access may reveal:

• Resource names
• Public endpoints
• Network architecture
• Managed identity configuration
• Automation components
• Tags and metadata
• Deployment relationships

Reader access can provide valuable reconnaissance information.

Contributor

Contributor can create and manage many Azure resources but cannot normally assign Azure RBAC roles.

Contributor access may still be highly privileged because the identity may be able to:

• Modify virtual machines
• Deploy extensions
• Change application settings
• Access deployment configuration
• Modify automation resources
• Assign managed identities to supported resources
• Change storage configuration

Contributor should not be treated as a low-risk role.

Owner

Owner has broad resource-management permissions and can assign Azure RBAC roles.

An Owner may be able to:

• Manage resources
• Delete resources
• Assign roles
• Grant access to other identities
• Establish persistent access

Owner assignments require strict governance and monitoring.

User Access Administrator

User Access Administrator can manage user access to Azure resources.

Depending on the assigned scope, this identity may be able to:

• Create role assignments
• Remove role assignments
• Grant access to another identity
• Escalate access indirectly

This role is especially sensitive when assigned at:

• Management group scope
• Subscription scope
• High-value resource-group scope

Virtual Machine Contributor

Virtual Machine Contributor can manage virtual machines.

Potential security implications include the ability to:

• Start or stop virtual machines
• Modify VM configuration
• Install supported extensions
• Reset access in authorised contexts
• Attach or modify storage
• Interact with managed identity configuration

The actual attack path depends on the assigned scope and connected controls.

Managed Identity Operator

Managed Identity Operator can assign an existing user-assigned managed identity to supported resources.

If the managed identity has higher privileges, this relationship may create a privilege-escalation path.

Key Vault Roles

Sensitive Key Vault roles may provide access to:

• Secrets
• Keys
• Certificates
• Key-management operations

Management-plane permissions over a Key Vault do not always provide data-plane access.

Both permission models must be reviewed.

Storage Data Roles

Storage data roles may permit:

• Reading blobs
• Writing blobs
• Deleting blobs
• Accessing queues
• Accessing file shares

A tester should distinguish between managing the storage account and accessing the data within it.

Custom Azure Roles

Organisations create custom roles when built-in roles do not meet their requirements.

A custom role contains:

• Name
• Description
• Actions
• NotActions
• DataActions
• NotDataActions
• Assignable scopes

Example structure:

{
  "Name": "Custom Application Operator",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/example-subscription-id"
  ]
}

Custom roles should be reviewed for:

• Wildcard permissions
• Role-assignment permissions
• Deployment permissions
• Compute-management permissions
• Automation permissions
• Secret or credential access
• Data-plane access
• Excessive assignable scopes

Dangerous Permission Categories

The security impact of a role depends on its exact permissions.

High-impact permission categories may include the ability to:

• Create role assignments
• Modify role definitions
• Deploy or modify virtual machines
• Install VM extensions
• Modify application settings
• Execute automation jobs
• Read deployment outputs
• Manage managed identities
• Modify function applications
• Access Key Vault secrets
• Read storage data
• Create or modify credentials
• Change networking controls
• Disable or alter monitoring

A permission should not be classified as dangerous based only on its name.

The tester should determine:

• What resource it applies to
• Which scope it covers
• Which identity holds it
• What connected resources exist
• Whether additional controls limit its use

Azure RBAC Inheritance

Role assignments are inherited from parent scopes.

Example:

Management group
└── Owner assignment
    └── Subscription
        └── Resource group
            └── Virtual machine

An Owner assignment at management-group scope may affect every included subscription and resource.

Broad-scope assignments increase both operational convenience and security risk.

During an assessment, record whether access is:

• Directly assigned
• Inherited
• Assigned through a group
• Assigned through Privileged Identity Management
• Temporarily activated
• Permanently active

Group-Based Role Assignments

Azure roles may be assigned to Microsoft Entra groups.

This means privilege can be gained through:

User
  ↓
Group membership
  ↓
Azure role assignment
  ↓
Resource access

Assessment questions include:

• Who can add members to the group?
• Who owns the group?
• Is group membership reviewed?
• Is the group dynamic?
• Does the group contain guest users?
• Is the assignment active or eligible?
• Does the group have access at broad scope?

Group ownership may be as important as the role assignment itself.

Privileged Identity Management

Azure RBAC assignments may be managed through Microsoft Entra Privileged Identity Management.

Assignments may be:

• Active
• Eligible
• Permanent
• Time-limited

Activation controls may include:

• Multifactor authentication
• Business justification
• Approval
• Limited activation duration
• Notification
• Audit logging

A tester should identify whether privileged access is permanently active when it could be eligible and time-limited.

Common RBAC Privilege-Escalation Patterns

Azure RBAC escalation often involves chaining permissions rather than using one obvious privileged role.

Role-Assignment Control

User Access Administrator
        ↓
Ability to create role assignment
        ↓
Higher privilege assigned to controlled identity
        ↓
Expanded access

Validation of this path must be explicitly authorised because role changes can affect production access.

Resource Control to Managed Identity Abuse

Contributor on compute resource
        ↓
Control of resource configuration
        ↓
Resource uses privileged managed identity
        ↓
Identity token accessible from workload context
        ↓
Access to additional Azure services

The presence of the relationship should be documented before any controlled validation.

Virtual Machine Control

Virtual Machine Contributor
        ↓
Ability to modify VM configuration
        ↓
Code execution path through approved management feature
        ↓
Access to VM environment
        ↓
Discovery of managed identity or stored credentials

Production systems should not be modified unless specifically approved.

Automation Resource Control

Contributor on automation resource
        ↓
Ability to modify automation workflow
        ↓
Workflow runs as privileged identity
        ↓
Access to additional resources

Examples may include:

• Automation accounts
• Deployment pipelines
• Logic Apps
• Function Apps
• Runbooks
• Deployment scripts

Application Configuration Control

Control of App Service or Function App
        ↓
Ability to change application configuration
        ↓
Access to secrets or identity context
        ↓
Additional Azure access

The tester should review how application code, settings, identities, and secrets interact.

Deployment Permission Abuse

Deployment-management permission
        ↓
Ability to create or modify deployment
        ↓
Deployment runs with privileged access
        ↓
Resource or secret exposure

Review:

• ARM deployments
• Deployment scripts
• Infrastructure-as-code pipelines
• Deployment outputs
• Template parameters

Custom Role Modification

Permission to modify role definition
        ↓
Custom role expanded
        ↓
Additional actions become available
        ↓
Privilege escalation

This is a high-impact permission and should be tightly controlled.

Cross-Scope Escalation

An identity may have limited access at one scope but control a resource connected to another scope.

Example:

Contributor on resource group A
        ↓
Control of workload using managed identity
        ↓
Managed identity has access to resource group B
        ↓
Cross-resource access

The tester should analyse the privileges of both:

• The human or application identity
• The identities attached to controlled resources

Azure RBAC Enumeration Methodology

A structured RBAC assessment should follow these stages.

Stage 1 — Confirm Identity Context

Record:

• Signed-in identity
• Tenant ID
• Subscription ID
• Active subscription
• Authorised scope

Stage 2 — Enumerate Role Assignments

Identify assignments for:

• Current user
• Groups
• Service principals
• Managed identities
• Privileged administrators

Stage 3 — Review Role Definitions

For each relevant role, review:

• Actions
• NotActions
• DataActions
• NotDataActions
• Assignable scopes

Stage 4 — Map Scope and Inheritance

Determine whether the role applies at:

• Management-group level
• Subscription level
• Resource-group level
• Resource level

Stage 5 — Identify Controlled Resources

Determine which resources the identity can:

• Read
• Modify
• Delete
• Execute against
• Assign identities to
• Retrieve data from

Stage 6 — Analyse Identity Relationships

Review:

• Group membership
• Resource-managed identities
• Service-principal permissions
• Automation identities
• Application ownership

Stage 7 — Build Candidate Attack Paths

Create a relationship map.

Identity
  ↓
Role assignment
  ↓
Scope
  ↓
Controlled resource
  ↓
Attached identity or secret
  ↓
Higher-value resource

Stage 8 — Safely Validate

Validation should:

• Remain within scope
• Avoid destructive changes
• Use test resources where possible
• Be approved before permission changes
• Produce clear evidence
• Include immediate cleanup

Authorised Azure CLI Enumeration

Confirm the current Azure context:

az account show --output table

List accessible subscriptions:

az account list --output table

List role assignments visible to the current identity:

az role assignment list --all --output table

List role assignments for the currently signed-in 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 assignments at the active subscription scope:

SUBSCRIPTION_ID=$(az account show --query id -o tsv)

az role assignment list \
  --scope "/subscriptions/$SUBSCRIPTION_ID" \
  --include-inherited \
  --output table

Display a role definition:

az role definition list \
  --name "Contributor" \
  --output json

List custom role definitions:

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

Display detailed custom-role permissions:

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

List resource groups:

az group list --output table

List Azure resources visible to the current identity:

az resource list --output table

Only query resources within the authorised assessment scope.

Authorised Azure PowerShell Enumeration

Confirm the active context:

Get-AzContext

List accessible subscriptions:

Get-AzSubscription

List role assignments:

Get-AzRoleAssignment

List assignments for a specific object:

Get-AzRoleAssignment -ObjectId "<authorised-object-id>"

List available role definitions:

Get-AzRoleDefinition

Display a specific role:

Get-AzRoleDefinition -Name "Contributor"

List custom roles:

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

Do not make role changes unless the engagement explicitly permits controlled validation.

Understanding Effective Access

An identity’s effective access may come from several sources:

Direct assignment
+
Group assignment
+
Inherited assignment
+
Privileged Identity Management activation
+
Resource-specific data role

The visible role name alone may not represent the full permission set.

A complete assessment should review all relevant assignments and scopes.

Safe Validation Strategy

RBAC escalation findings should be validated using the least disruptive method available.

Preferred order:

1. Confirm permission from role definition.
2. Confirm assignment and scope.
3. Identify the controlled resource.
4. Determine the potential impact analytically.
5. Use an isolated test resource where possible.
6. Obtain approval before changing roles or workloads.
7. Record all actions.
8. Remove test changes immediately.

In many enterprise engagements, clear proof of permission and attack-path feasibility may be sufficient without performing the final escalation action.

Actions Requiring Explicit Approval

The following activities should not be performed without specific authorisation:

• Creating role assignments
• Removing role assignments
• Modifying custom roles
• Deploying code to production resources
• Installing VM extensions
• Resetting VM credentials
• Changing managed identities
• Accessing production secrets
• Disabling logs or alerts
• Modifying network controls
• Deleting or stopping resources

Evidence Collection

For each RBAC finding, record:

• Identity display name
• Identity object ID
• Identity type
• Role name
• Role definition ID
• Assignment ID
• Scope
• Whether access is inherited
• Relevant actions or data actions
• Controlled resource
• Potential escalation relationship
• Validation method
• Business impact
• Recommended remediation

Avoid placing secrets, access tokens, or sensitive data in reports or portfolios.

Example Finding

Finding Title

Excessive Contributor Access to Production Application Resource Group

Observation

A standard operations group holds the Contributor role over a production resource group containing a Function App configured with a privileged managed identity.

Potential Attack Path

Operations group member
        ↓
Contributor on production resource group
        ↓
Control of Function App configuration
        ↓
Function App uses privileged managed identity
        ↓
Managed identity can retrieve Key Vault secrets

Business Impact

A compromised group member could potentially use control of the application resource to gain access to sensitive secrets and connected services.

Recommendation

• Replace Contributor with a narrowly scoped custom role.
• Restrict application-management permissions.
• Reduce the managed identity’s access.
• Separate workload administration from secret access.
• Use Privileged Identity Management for elevated operations.
• Monitor changes to the Function App and managed identity.

Risk Rating Considerations

The severity of an RBAC finding depends on:

• Role permissions
• Assignment scope
• Identity type
• Authentication strength
• Resource sensitivity
• Data-plane access
• Available escalation path
• Monitoring coverage
• Ease of validation
• Potential business impact

A Contributor assignment on an isolated lab resource may be low risk.

The same assignment on a production resource group containing privileged workloads may be critical.

Remediation Principles

Common Azure RBAC recommendations include:

• Apply least privilege.
• Reduce assignment scope.
• Remove unused assignments.
• Replace broad built-in roles where appropriate.
• Review custom-role actions.
• Separate management-plane and data-plane access.
• Use Privileged Identity Management.
• Require approval for privileged activation.
• Review group ownership and membership.
• Audit service-principal permissions.
• Restrict managed-identity permissions.
• Monitor role-assignment changes.
• Perform regular access reviews.
• Avoid permanent Owner assignments where possible.

Evidence and Portfolio Outcome

Create an Azure RBAC Assessment Report containing:

Environment Context

• Tenant ID
• Subscription ID
• Authorised scope
• Test identity

Role Assignment Inventory

Document:

• Identity
• Identity type
• Role
• Scope
• Direct or inherited access
• Active or eligible assignment

Custom Role Review

For each custom role, record:

• Actions
• DataActions
• Assignable scopes
• High-risk permissions
• Business purpose

Attack-Path Analysis

Create one safe, hypothetical path.

Example:

User
  ↓
Group membership
  ↓
Contributor role
  ↓
Controlled workload
  ↓
Managed identity
  ↓
Key Vault access

Recommendations

Provide prioritised remediation guidance based on business risk.

Key Takeaways

• Azure RBAC controls access to Azure resources.
• Every assignment combines a principal, role, and scope.
• Permissions may be direct, inherited, or group-based.
• Management-plane and data-plane access must be reviewed separately.
• Contributor access can create serious attack paths even without role-assignment permissions.
• Custom roles require detailed permission analysis.
• Managed identities can connect controlled resources to higher privileges.
• Azure RBAC escalation is often relationship-based.
• Validation must remain authorised, minimal, and reversible.
• Reporting should explain the complete business impact, not just the role name.

Knowledge Check

1. What three components form an Azure role assignment?
2. What is the difference between an Azure RBAC role and a Microsoft Entra role?
3. How does scope inheritance work in Azure?
4. What is the difference between Actions and DataActions?
5. Why can Contributor access create a privilege-escalation path?
6. Why is User Access Administrator considered highly sensitive?
7. How can a managed identity connect two otherwise separate scopes?
8. What should be reviewed inside a custom role definition?
9. Why should group ownership be assessed alongside group-based role assignments?
10. What is the safest approach to validating an Azure RBAC escalation path?

Next Lesson

➡️ Lesson 04 — Azure Network Enumeration

In the next lesson, you will learn how to identify Azure Virtual Networks, subnets, Network Security Groups, public endpoints, private connectivity, peering relationships, and network paths during an authorised Azure penetration testing engagement.