Project 02 — Enterprise Azure Identity & Cloud Penetration Test

Welcome

Welcome to Project 02 — Enterprise Azure Identity & Cloud Penetration Test.

In Project 01, you assessed an AWS environment and learned how cloud attack paths can emerge from the combination of:

Identity
   +
Permission
   +
Workload
   +
Trust
   =
Privilege Path

In this project, you will apply the same thinking to Microsoft Azure.

The major difference is that Azure enterprise environments frequently connect:

Microsoft Entra ID
        ↓
Users / Groups / Applications
        ↓
Azure RBAC
        ↓
Subscriptions
        ↓
Resource Groups
        ↓
Resources
        ↓
Managed Identities
        ↓
Key Vault / Storage / Databases

This makes Azure penetration testing heavily identity-driven.

Your objective is not simply to find insecure resources.

Your objective is to understand:

Can an authorised low-privileged identity gain unintended access through Entra ID relationships, Azure RBAC, resource ownership, managed identities, application identities, or cloud trust relationships?

Mission Information

Project

Enterprise Azure Identity & Cloud Penetration Test

Platform

CloudNova

Difficulty

Intermediate → Advanced

Estimated Time

4–6 hours

Primary Skills

• Microsoft Entra ID reconnaissance

• Azure subscription discovery

• Azure resource inventory

• Azure RBAC analysis

• Role assignment review

• Scope inheritance analysis

• Managed identity assessment

• Service principal analysis

• Virtual machine security

• Network Security Group review

• Storage security

• Key Vault security

• Application identity analysis

• Privilege-path development

• Evidence collection

• Professional reporting

Mission Objective

A fictional organisation has requested an authorised assessment of its Azure environment inside CloudNova.

The organisation uses:

Corporate Identity
       ↓
Microsoft Entra ID
       ↓
Azure Subscription
       ↓
Resource Groups
       ↓
Applications
       ↓
Managed Identities
       ↓
Key Vault / Storage / Databases

The security team is concerned that:

• Azure RBAC roles may be excessive

• Resource permissions may be inherited too broadly

• Managed identities may have excessive privilege

• Developers may control workloads using privileged identities

• Application identities may expose sensitive resources

• Key Vault access may be too broad

• Azure resources may be unnecessarily exposed

• Logging or monitoring controls may be insufficient

Your task is to determine whether these weaknesses can combine into meaningful enterprise attack paths.

Starting Position

You begin with an authorised low-privileged identity.

Example:

Identity:
student@cloudnova.lab

Tenant:
CloudNova Enterprise Tenant

Subscription:
CloudNova Training Subscription

Privilege:
Limited Azure access

Objective:
Determine whether identity, RBAC, workload, or resource
relationships create a path toward sensitive Azure resources.

Rules of Engagement

Allowed:

Entra ID discovery

Subscription discovery

Resource enumeration

Azure RBAC review

Managed identity review

Service principal review

Virtual machine configuration review

Network Security Group review

Storage configuration review

Key Vault permission review

Logging review

Controlled permission validation

Evidence collection

Not allowed unless specifically required by CloudNova:

Denial of Service

Deleting Azure resources

Stopping business workloads

Changing production-like data

Disabling logs

Removing security controls

Testing external tenants

Testing third-party infrastructure

Downloading unnecessary sensitive data

Golden Rule

Use:

Minimum Necessary Validation

If Azure configuration and permission evidence already demonstrate the path, do not perform unnecessary changes merely to prove maximum impact.

Project Success Criteria

By the end of this project, produce:

Azure Architecture Diagram

Tenant & Subscription Inventory

Entra Identity Inventory

Azure RBAC Matrix

Role Assignment Map

Managed Identity Inventory

Application Identity Inventory

Virtual Machine Assessment

Network Exposure Matrix

Storage Assessment

Key Vault Assessment

Attack Path Register

Evidence Register

Findings Register

Enterprise Azure Penetration Testing Report

Phase 01 — Prepare Your Workspace

Create:

Project 02 - Enterprise Azure Pentest/
│
├── 01 Engagement
├── 02 Architecture
├── 03 Entra ID
├── 04 Subscriptions
├── 05 Azure RBAC
├── 06 Compute
├── 07 Network
├── 08 Storage
├── 09 Managed Identity
├── 10 Key Vault
├── 11 Logging
├── 12 Attack Paths
├── 13 Evidence
├── 14 Findings
├── 15 Report
└── 16 Retest

Inside 01 Engagement create:

Scope.md
Rules-of-Engagement.md
Objectives.md
Testing-Notes.md

Phase 02 — Record Scope

Document:

Cloud Provider:
Microsoft Azure

Environment:
CloudNova

Tenant:
<TENANT-ID>

Subscription:
<SUBSCRIPTION-ID>

Starting Identity:
<IDENTITY>

In Scope:
Microsoft Entra ID
Azure RBAC
Virtual Machines
Networking
Storage
Managed Identities
Key Vault
Approved Applications
Logging

Out of Scope:
Other tenants
Third-party SaaS
DoS
Destructive operations
Unapproved subscriptions

Phase 03 — Authenticate and Confirm Identity

Start by asking:

Who am I?

In the authorised CloudNova Azure environment:

az account show

Useful fields include:

Subscription Name

Subscription ID

Tenant ID

Current User

Environment

You may also review:

az account list --output table

Only interact with subscriptions explicitly included in scope.

Phase 04 — Record Starting Identity

Create:

Field	Value
Identity	student@cloudnova.lab
Tenant	<Tenant ID>
Subscription	<Subscription>
Identity Type	User
Known Role	Reader / Custom
Effective Privilege	Unknown

Again:

Effective Privilege:
Unknown

Your job is to determine it.

Phase 05 — Understand Azure Hierarchy

Azure access can exist at different scopes.

Management Group
      ↓
Subscription
      ↓
Resource Group
      ↓
Resource

Permissions assigned higher in the hierarchy may be inherited downward.

This matters enormously during penetration testing.

Phase 06 — Discover Subscriptions

Use:

az account list --output table

Record only authorised subscriptions.

Create:

Subscription	Subscription ID	Tenant	Scope
CloudNova Training	<ID>	CloudNova Tenant	In Scope

Phase 07 — Discover Resource Groups

Use:

az group list --output table

Create:

Resource Group	Region	Purpose	Criticality
rg-web	East US	Public web	High
rg-app	East US	Applications	High
rg-data	East US	Data	Critical
rg-security	East US	Security	Critical

Do not assume criticality solely from names.

Validate using architecture and purpose.

Phase 08 — Inventory Azure Resources

Use:

az resource list --output table

Create a structured inventory.

Example:

Resource	Type	Resource Group	Region	Identity
vm-web01	VM	rg-web	East US	WebIdentity
vm-app01	VM	rg-app	East US	AppIdentity
vault-prod	Key Vault	rg-data	East US	N/A
stappdata	Storage	rg-data	East US	N/A

Phase 09 — Build the Initial Architecture

Example:

Microsoft Entra ID
       │
       ├── Users
       ├── Groups
       ├── Applications
       └── Service Principals
                │
                ↓
        Azure Subscription
                │
       ┌────────┼────────┐
       ↓        ↓        ↓
     rg-web   rg-app   rg-data
       │        │        │
       ↓        ↓        ↓
     WEB01    APP01    Key Vault
                 │        │
                 └──→ Storage

Update this diagram throughout the project.

Phase 10 — Enumerate Entra Users

If permitted:

az ad user list --output table

Create:

User	Type	Purpose	Privileged?
student	User	Development	No
app-admin	User	Application admin	Review
cloud-admin	User	Azure admin	Yes

Focus on relationships, not simply usernames.

Phase 11 — Enumerate Groups

If permitted:

az ad group list --output table

Important questions:

Which Groups Exist?

Which Users Are Members?

Which Groups Have Azure Roles?

Which Groups Control Applications?

Which Groups Are Privileged?

Phase 12 — Group Membership

For a specific group, where authorised:

az ad group member list \
  --group "<GROUP-NAME>" \
  --output table

Build:

User
 ↓
Group
 ↓
Azure Role
 ↓
Scope

This creates the beginning of your privilege graph.

Phase 13 — Service Principals

Azure applications commonly use service principals.

If permitted:

az ad sp list --all --output table

Focus on:

Display Name

Application ID

Object ID

Purpose

Owners

Azure Roles

Credentials

Federation

Do not retrieve credentials unnecessarily.

Phase 14 — Application Identity Model

Understand:

Application Registration
        ↓
Service Principal
        ↓
Credential / Federation
        ↓
Azure RBAC / API Permissions
        ↓
Resource

An application identity can become as important as a human administrator.

Phase 15 — Managed Identities

Azure provides managed identities for workloads.

Two common types:

System Assigned

User Assigned

Conceptually:

Virtual Machine
      ↓
Managed Identity
      ↓
Azure RBAC
      ↓
Key Vault / Storage / Other Resource

Managed identities eliminate some static credential risks but can still be overprivileged.

Phase 16 — Identify VM Managed Identities

For authorised VMs:

az vm list \
  --show-details \
  --query '[].{Name:name,ResourceGroup:resourceGroup,PublicIP:publicIps,PrivateIP:privateIps}' \
  --output table

For a particular VM:

az vm identity show \
  --resource-group <RESOURCE-GROUP> \
  --name <VM-NAME>

Record:

VM

Identity Type

Principal ID

User Assigned Identity

Resource Group

Phase 17 — Managed Identity Inventory

Create:

Workload	Identity	Type	Azure Role	Sensitive Access
vm-web01	WebIdentity	System	Reader	No
vm-app01	AppIdentity	System	Custom	Key Vault?
function01	ProcessorIdentity	User Assigned	Storage Contributor	Review

Phase 18 — Azure RBAC

Azure RBAC determines:

Who
 ↓
Has Which Role
 ↓
At Which Scope
 ↓
Against Which Resources

This must be analysed carefully.

Phase 19 — List Role Assignments

Use:

az role assignment list --all --output table

For focused analysis:

az role assignment list \
  --assignee <OBJECT-ID> \
  --all \
  --output table

Record:

Principal

Role

Scope

Principal Type

Inheritance

Phase 20 — Build the RBAC Matrix

Create:

Principal	Role	Scope	Inherited?	Security Question
student	Reader	Subscription	Yes	Recon only?
Developers	Contributor	rg-app	No	Can control identities?
AppIdentity	Key Vault Reader	vault-prod	No	Secret access?
Automation	Owner	rg-app	No	Why Owner?

Phase 21 — Understand Built-In Roles

Be comfortable conceptually with roles such as:

Reader

Contributor

Owner

User Access Administrator

Do not assume role names alone tell the whole story.

Custom roles may be more important.

Phase 22 — Contributor vs Owner

Conceptually:

Contributor
      ↓
Manage Resources

while:

Owner
   ↓
Manage Resources
   +
Manage Access

The exact security impact depends on scope and resource relationships.

Phase 23 — Scope Inheritance

Suppose:

Developers Group
       ↓
Contributor
       ↓
Subscription

That may mean:

Developers
       ↓
Control Many Resource Groups
       ↓
Control Workloads
       ↓
Potential Access to Their Identities

This is why scope matters.

Phase 24 — Custom Roles

List custom roles if permitted:

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

Analyse:

Actions

NotActions

DataActions

NotDataActions

AssignableScopes

Phase 25 — Privilege-Changing Capabilities

Look for capabilities that may allow an identity to control:

Role Assignments

Managed Identities

VM Extensions

Automation

Deployment Templates

Key Vault

Application Configuration

The central question remains:

Can this identity control something that operates with greater privilege?

Phase 26 — Hypothesis Example

Suppose:

Developers
    ↓
Contributor
    ↓
rg-app

Inside rg-app:

vm-app01
    ↓
Managed Identity
    ↓
AppIdentity

AppIdentity has:

Key Vault Secret Access

Potential hypothesis:

Developer
   ↓
Controls VM
   ↓
VM Uses Managed Identity
   ↓
Managed Identity
   ↓
Key Vault

This is not a confirmed attack path yet.

Phase 27 — Hypothesis Register

Create:

ID	Hypothesis	Evidence	Status
AZ-H-001	Developer may indirectly exercise AppIdentity	Contributor + VM identity	Investigate
AZ-H-002	AppIdentity may read sensitive Key Vault secrets	Role assignment	Investigate
AZ-H-003	Storage may be publicly reachable	Network config	Investigate

Phase 28 — Virtual Machine Assessment

Review:

Public IP

Private IP

Network Interface

NSG

Managed Identity

Extensions

Disk Encryption

Administrative Access

Business Purpose

Phase 29 — VM Inventory

Use:

az vm list --show-details --output table

Create:

VM	Resource Group	Public	Identity	Purpose
vm-web01	rg-web	Yes	WebIdentity	Web
vm-app01	rg-app	No	AppIdentity	App
vm-admin01	rg-admin	No	AdminIdentity	Management

Phase 30 — Network Security Groups

List:

az network nsg list --output table

For a specific NSG:

az network nsg rule list \
  --resource-group <RESOURCE-GROUP> \
  --nsg-name <NSG-NAME> \
  --output table

Phase 31 — Build Network Exposure Matrix

Source	Destination	Port	Expected	Observed
Internet	WEB01	443	Allow	Allow
Internet	APP01	3389	Deny	Allow
WEB01	APP01	443	Allow	Allow
User subnet	Key Vault	Restricted	Review	Review

Phase 32 — Administrative Exposure

Investigate broad access to:

SSH

RDP

Database Ports

Management APIs

Administrative Web Interfaces

The question is:

Does the source network actually need access?

Phase 33 — Azure Storage

List storage accounts:

az storage account list --output table

Record:

Storage Account

Resource Group

Region

Public Network Access

Encryption

Identity Access

Phase 34 — Storage Questions

Ask:

Is Public Access Enabled?

Is Anonymous Blob Access Allowed?

Which Identities Can Read?

Which Identities Can Write?

Which Identities Can Delete?

Is Network Access Restricted?

Is Encryption Enabled?

What Data Is Stored?

Phase 35 — Public Blob Access

Do not automatically report:

Public storage = vulnerability.

Determine:

Intentional?

Sensitive?

Read?

Write?

Business Purpose?

Phase 36 — Storage RBAC

Review identities assigned roles such as:

Storage Blob Data Reader

Storage Blob Data Contributor

Storage Account Contributor

Understand the difference between:

Management Plane

and:

Data Plane

Phase 37 — Management vs Data Plane

An identity may be able to manage the storage account without necessarily reading object data directly.

Or it may have data-plane access without management control.

Always identify:

What Can Be Configured?

What Data Can Be Accessed?

Phase 38 — Key Vault Discovery

List vaults where permitted:

az keyvault list --output table

Record:

Vault Name

Resource Group

Region

Public Network Access

Authorization Model

Phase 39 — Key Vault Authorization

Azure Key Vault may use:

Azure RBAC

or

Vault Access Policies

Determine which model applies before analysing access.

Phase 40 — Key Vault Questions

Ask:

Who Can Read Secrets?

Who Can Write Secrets?

Who Can Delete Secrets?

Who Can Manage Keys?

Who Can Change Access?

Which Workloads Use the Vault?

Is Network Access Restricted?

Phase 41 — Do Not Retrieve Secrets Unnecessarily

Start with metadata and permission analysis.

Do not retrieve:

Passwords

Tokens

API Keys

Connection Strings

unless CloudNova explicitly requires controlled synthetic validation.

Phase 42 — Key Vault Attack Path

Example:

Developer
   ↓
Controls APP01
   ↓
APP01 Managed Identity
   ↓
Key Vault Secret Reader
   ↓
Application Secret
   ↓
Sensitive Service

Again:

Secret Access

may be a transition rather than the final impact.

Phase 43 — Managed Identity Security

For each managed identity ask:

Which Workload Uses It?

Who Can Control That Workload?

Which Azure Roles Are Assigned?

At Which Scope?

Can It Access Key Vault?

Can It Access Storage?

Can It Modify Resources?

Can It Control Another Identity?

Phase 44 — Workload Control

A user may have no direct sensitive-data access but may control a workload that does.

Conceptually:

Developer
   ↓
Resource Control
   ↓
Application
   ↓
Managed Identity
   ↓
Sensitive Resource

This is a major Azure attack-path pattern.

Phase 45 — Application Registrations

Where permitted:

az ad app list --output table

Review:

Application

Owners

Service Principal

Credentials

Federated Credentials

API Permissions

Never expose credential values in project notes.

Phase 46 — Application Owners

Application ownership can itself be security-sensitive.

Conceptually:

User
 ↓
Owns Application
 ↓
Application Identity
 ↓
Cloud Permissions

Determine what application ownership allows in the actual environment.

Phase 47 — Service Principal Roles

For a service principal:

Service Principal
       ↓
Azure Role Assignment
       ↓
Subscription / Resource Group / Resource

Build this into the identity graph.

Phase 48 — Enterprise Identity Graph

Example:

student
   │
   └── MemberOf ──> Developers
                       │
                       └── Contributor ──> rg-app
                                              │
                                              ↓
                                           APP01
                                              │
                                              ↓
                                         AppIdentity
                                              │
                                              └── Secret Reader ──> vault-prod

Now the path becomes easier to understand.

Phase 49 — Identify Choke Points

Potential choke points include:

Developers Contributor Role

APP01 Control

AppIdentity Privilege

Key Vault Role Assignment

Ask:

Which remediation breaks the largest number of paths with the least operational disruption?

Phase 50 — Controlled Validation Decision

Use:

Configuration Evidence
        ↓
Enough to Prove Path?
     /             \
   Yes              No
   ↓                ↓
Document      Safe Validation Possible?
                    ↓
                  Yes / No

If no safe validation exists:

Document Potential Risk

Do not create impact merely to prove a theoretical maximum.

Phase 51 — Azure Resource Locks

Where relevant, identify whether critical resources have protection against accidental modification.

Resource locks can provide:

Delete Protection

Read-Only Protection

They do not replace IAM but may reduce operational risk.

Phase 52 — Logging

Azure control-plane activity should be observable.

Important sources may include:

Azure Activity Log

Microsoft Entra Sign-In Logs

Microsoft Entra Audit Logs

Azure Monitor

Resource Logs

Defender for Cloud

Microsoft Sentinel

Phase 53 — Activity Log

Where permitted:

az monitor activity-log list --max-events 20 --output table

The objective is to understand available audit visibility.

Phase 54 — Logging Questions

Ask:

Are Administrative Changes Logged?

Are Role Assignment Changes Logged?

Are Resource Changes Logged?

Are Key Vault Access Events Available?

Are Authentication Events Monitored?

Are Logs Centralised?

Who Can Modify Logging?

Phase 55 — Logging Privilege

If a development identity can modify:

Diagnostic Settings

Log Destinations

Monitoring Configuration

determine whether that capability is justified.

Do not disable logging.

Phase 56 — Microsoft Defender for Cloud

If available, assess whether security posture and recommendations are being generated.

Do not treat posture tools as a substitute for attack-path analysis.

Phase 57 — Conditional Access Context

Where relevant to the authorised lab, document identity controls such as:

MFA

Conditional Access

Privileged Identity Management

Device Requirements

Location Restrictions

A strong cloud assessment evaluates defensive identity controls as well as resource permissions.

Phase 58 — Privileged Identity Management

In enterprise Azure environments, privileged roles may be:

Eligible

Activated

Time Limited

through Privileged Identity Management.

This can reduce standing privilege.

Document whether privileged access appears permanent or controlled.

Phase 59 — Azure Attack Surface Map

Your map may now look like:

Microsoft Entra ID
│
├── student
├── Developers
├── AppIdentity
└── AutomationIdentity
       │
       ↓
Azure Subscription
│
├── rg-web
│   └── WEB01
│
├── rg-app
│   └── APP01
│        └── AppIdentity
│
├── rg-data
│   ├── Storage
│   └── Key Vault
│
└── rg-security
    └── Monitoring

Phase 60 — Attack Path 01

Example:

student
  ↓
Developers
  ↓
Contributor on rg-app
  ↓
Control APP01
  ↓
APP01 Managed Identity
  ↓
Key Vault Secret Access

Document each transition separately.

Phase 61 — Attack Path 02

Example:

Developer
   ↓
Application Ownership
   ↓
Service Principal
   ↓
Azure Role
   ↓
Sensitive Storage

Only mark as validated if the actual ownership and permission model supports it.

Phase 62 — Attack Path 03

Example:

Low-Privilege User
      ↓
Group Membership
      ↓
Broad Role Assignment
      ↓
Resource Control
      ↓
Privileged Managed Identity
      ↓
Critical Resource

This demonstrates why Azure permissions must be analysed as a graph.

Phase 63 — Attack Path Register

Create:

ID	Start	Transition	Target	Status	Risk
AZ-AP-001	student	Developer group → APP01	Key Vault	Validated	High
AZ-AP-002	App owner	Service principal	Storage	Investigate	TBD
AZ-AP-003	User	Broad RBAC	Critical workload	Validated	High

Phase 64 — Evidence Register

Use:

AZ-EV-001
Current identity

AZ-EV-002
Subscription context

AZ-EV-003
Group membership

AZ-EV-004
Role assignment

AZ-EV-005
VM managed identity

AZ-EV-006
Managed identity role

AZ-EV-007
Key Vault configuration

AZ-EV-008
Controlled synthetic validation

Phase 65 — Evidence Template

Evidence ID:
AZ-EV-005

Timestamp:
<DATE/TIME>

Resource:
vm-app01

Observation:
The virtual machine uses AppIdentity as its managed identity.

Source:
Azure resource configuration.

Attack Path:
AZ-AP-001

Sensitive Data Collected:
None

Phase 66 — Finding Example 01

AZ-001 — Developer Resource Control Creates an Indirect Path to a Privileged Managed Identity

Observation

The development group possesses resource-management permissions over an application workload operating with a managed identity that has access to sensitive Azure resources.

Attack Scenario

Compromise of a development identity could allow an attacker to influence the application workload and indirectly exercise capabilities available to the managed identity.

Impact

The weakness may expand compromise from development-level access toward sensitive production-like services.

Root Cause

Insufficient separation between workload administration and workload identity privilege.

Recommendation

Restrict who can modify privileged workloads, minimise managed-identity permissions, and separate development responsibilities from privileged resource administration.

Phase 67 — Finding Example 02

AZ-002 — Managed Identity Has Excessive Key Vault Access

Observation

A managed identity associated with an application workload possesses Key Vault permissions beyond its documented operational requirement.

Impact

Compromise of the workload could expose secrets used by unrelated services and expand the blast radius.

Recommendation

Limit the managed identity to explicitly required secrets and operations and continuously review workload identity access.

Phase 68 — Finding Example 03

AZ-003 — Azure RBAC Assignment Is Broader Than Operationally Required

Observation

A role assignment grants resource-management authority at a broader Azure scope than required.

Impact

Compromise of the affected identity may provide control over unrelated resources and increase opportunities for privilege chaining.

Recommendation

Move the assignment to the narrowest appropriate resource or resource-group scope and review inherited permissions.

Phase 69 — Finding Example 04

AZ-004 — Administrative Azure Resource Is Exposed to Broad Network Sources

Observation

An administrative service associated with an Azure-hosted system is reachable from network ranges broader than required for legitimate administration.

Risk

Broad exposure increases the likelihood of credential attacks or exploitation of management services.

Recommendation

Restrict administration to approved private management paths, trusted networks, or identity-aware access mechanisms.

Phase 70 — Finding Example 05

AZ-005 — Key Vault Access Is Not Sufficiently Segmented Across Workloads

Observation

Multiple workloads share access to sensitive secrets without clear operational necessity.

Impact

Compromise of one workload may provide access to credentials or secrets used by unrelated systems.

Recommendation

Implement per-workload identities and narrowly scoped secret access.

Phase 71 — Positive Controls

Document controls that worked.

Examples:

Privileged MFA Enabled
        ✓

Key Vault Network Restrictions
        ✓

Critical VM Has No Public IP
        ✓

Activity Logging Enabled
        ✓

Privileged Role Requires PIM Activation
        ✓

Phase 72 — Root Cause Themes

Potential themes:

Broad Azure RBAC

Weak Scope Governance

Overprivileged Managed Identities

Weak Separation of Duties

Excessive Application Ownership

Inconsistent Secret Governance

Insufficient Network Segmentation

Phase 73 — Risk Prioritisation

Consider:

Initial Access Required

Role Scope

Resource Criticality

Managed Identity Privilege

Data Sensitivity

Attack Path Length

Business Impact

Detection

Compensating Controls

Phase 74 — Remediation Priorities

Immediate

Break validated critical identity paths

Reduce unnecessary Key Vault access

Restrict excessive resource control

Restrict broad administrative network exposure

Short Term

Review Azure RBAC

Review managed identities

Review application owners

Review service principals

Improve workload isolation

Strategic

Implement Privileged Identity Management

Strengthen least privilege

Adopt recurring identity governance

Improve cloud attack-path reviews

Centralise security telemetry

Implement stronger separation of duties

Phase 75 — Remediation Matrix

Finding	Immediate	Long-Term	Owner
AZ-001	Restrict workload modification	Separation of duties	Cloud Platform
AZ-002	Reduce vault access	Managed identity governance	App Team
AZ-003	Narrow RBAC scope	Periodic access review	IAM
AZ-004	Restrict NSG	Secure management architecture	Network
AZ-005	Separate secret access	Secret governance	Security

Phase 76 — Retest

Before:

Developer
   ↓
APP01
   ↓
AppIdentity
   ↓
Key Vault

After:

Developer
   ↓
Required APP01 Administration
   ✓

Developer
   ↓
Sensitive Key Vault Path
   X

Retest the actual relationship.

Phase 77 — Retest Status

Use:

Resolved

Partially Resolved

Not Resolved

Risk Accepted

Phase 78 — Final Identity Architecture

Example:

Microsoft Entra ID
│
├── student
│    │
│    └── Developers
│           │
│           └── Contributor → rg-app
│
├── AppIdentity
│    │
│    └── Key Vault Secret Reader → vault-prod
│
└── AutomationIdentity
     └── Deployment Role → rg-app


rg-app
│
└── APP01
     └── AppIdentity

rg-data
│
├── vault-prod
└── st-prod

Phase 79 — Final Attack Narrative

A professional narrative might read:

The assessment began with an authorised low-privileged Microsoft Entra identity. Azure RBAC analysis identified that the identity inherited Contributor-level resource control through a development group at the application resource-group scope. The affected application workload operated using a managed identity with access to sensitive Key Vault resources. This created an indirect privilege path in which compromise of the development identity could potentially influence a workload with higher-value access. The attack path resulted from the combination of broad resource-management permissions and excessive managed-identity privilege.

This is stronger than:

Contributor role is vulnerable.

Phase 80 — Enterprise Azure Report Structure

Create:

Enterprise Azure Penetration Testing Report

1. Executive Summary

2. Engagement Objectives

3. Scope

4. Rules of Engagement

5. Tenant & Subscription Overview

6. Azure Architecture

7. Methodology

8. Asset Inventory

9. Entra Identity Assessment

10. Azure RBAC Assessment

11. Application Identity Assessment

12. Managed Identity Assessment

13. Compute Assessment

14. Network Security Assessment

15. Storage Assessment

16. Key Vault Assessment

17. Logging & Monitoring Assessment

18. Attack Paths

19. Validated Findings

20. Positive Security Observations

21. Root Cause Themes

22. Remediation Roadmap

23. Retest Plan

24. Evidence Appendix

Phase 81 — Executive Summary Questions

Answer:

What Was Tested?

Which Identity Paths Matter Most?

Could Low Privilege Expand?

Which Sensitive Resources Became Reachable?

Which Controls Worked?

Which Controls Failed?

What Should Be Fixed First?

Phase 82 — Final Deliverables

Complete:

Project 02 - Enterprise Azure Pentest/
│
├── 01 Engagement
│   ├── Scope.md
│   ├── Rules-of-Engagement.md
│   └── Objectives.md
│
├── 02 Architecture
│   ├── Initial-Azure-Architecture.md
│   └── Final-Azure-Architecture.md
│
├── 03 Entra ID
│   ├── User-Inventory.md
│   ├── Group-Inventory.md
│   ├── Application-Inventory.md
│   └── Service-Principal-Inventory.md
│
├── 04 Subscriptions
│   └── Resource-Inventory.md
│
├── 05 Azure RBAC
│   ├── Role-Assignment-Matrix.md
│   ├── Custom-Role-Review.md
│   └── Scope-Inheritance-Map.md
│
├── 06 Compute
│   └── VM-Assessment.md
│
├── 07 Network
│   └── NSG-Matrix.md
│
├── 08 Storage
│   └── Storage-Assessment.md
│
├── 09 Managed Identity
│   └── Managed-Identity-Map.md
│
├── 10 Key Vault
│   └── Key-Vault-Assessment.md
│
├── 11 Logging
│   └── Logging-Assessment.md
│
├── 12 Attack Paths
│   └── Attack-Path-Register.md
│
├── 13 Evidence
│   └── Evidence-Register.md
│
├── 14 Findings
│   └── Findings-Register.md
│
├── 15 Report
│   └── Enterprise-Azure-Pentest-Report.md
│
└── 16 Retest
    └── Retest-Report.md

Phase 83 — Student Submission Checklist

ENGAGEMENT

[ ] Scope documented
[ ] Starting identity documented
[ ] Tenant documented
[ ] Subscription documented
[ ] ROE understood
[ ] Stop conditions understood

ENTRA ID

[ ] Users inventoried
[ ] Groups inventoried
[ ] Group membership reviewed
[ ] Applications reviewed
[ ] Service principals reviewed
[ ] Privileged identities identified

AZURE RESOURCES

[ ] Resource groups inventoried
[ ] Resources inventoried
[ ] Architecture mapped
[ ] Critical assets identified

RBAC

[ ] Role assignments reviewed
[ ] Scope inheritance analysed
[ ] Custom roles reviewed
[ ] Broad roles identified
[ ] Resource-control relationships mapped

MANAGED IDENTITIES

[ ] Managed identities inventoried
[ ] Workloads mapped to identities
[ ] Identity permissions reviewed
[ ] Sensitive-resource access reviewed
[ ] Workload-control paths reviewed

COMPUTE

[ ] VMs inventoried
[ ] Public exposure reviewed
[ ] Administrative exposure reviewed
[ ] VM identities reviewed

NETWORK

[ ] NSGs inventoried
[ ] Network rules reviewed
[ ] Segmentation reviewed
[ ] Management exposure reviewed

STORAGE

[ ] Storage accounts reviewed
[ ] Public access reviewed
[ ] Data-plane roles reviewed
[ ] Management-plane roles reviewed
[ ] Encryption reviewed

KEY VAULT

[ ] Vaults inventoried
[ ] Authorization model identified
[ ] Secret access reviewed
[ ] Key access reviewed
[ ] Workload relationships reviewed
[ ] No unnecessary secret values collected

LOGGING

[ ] Activity logging reviewed
[ ] Entra logging considered
[ ] Diagnostic configuration reviewed
[ ] Security monitoring reviewed
[ ] Logging modification permissions reviewed

ATTACK PATHS

[ ] Hypotheses documented
[ ] Hypotheses separated from findings
[ ] Identity relationships mapped
[ ] Attack paths developed
[ ] Minimum necessary validation used
[ ] Choke points identified

REPORTING

[ ] Evidence register completed
[ ] Findings register completed
[ ] Positive controls documented
[ ] Root causes identified
[ ] Remediation prioritised
[ ] Final report completed
[ ] Retest plan completed

Phase 84 — Skills You Should Demonstrate

After this project, you should be able to explain:

How do you begin an Azure penetration test?

What is the relationship between Microsoft Entra ID and Azure RBAC?

How does Azure scope inheritance work?

Why can Contributor-level access matter?

Why are managed identities important?

How can workload control create indirect privilege?

How are service principals different from human identities?

How do application owners affect cloud security?

How do you assess Key Vault access?

What is the difference between Azure management-plane and data-plane access?

How do you evaluate Storage Account exposure?

How do you assess Network Security Groups?

Why is Privileged Identity Management valuable?

How do you build an Azure identity attack path?

How do you validate privilege safely?

Phase 85 — Interview Story

You should be able to explain the project like this:

In a CloudNova Azure enterprise lab, I started with a low-privileged Microsoft Entra user and first mapped the tenant, subscription, resource groups, and identities. I analysed Azure RBAC and discovered that the user inherited resource-management access through a development group. One application workload under that scope operated using a managed identity with access to a sensitive Key Vault. I documented the user-to-group-to-RBAC-to-workload-to-managed-identity relationship as an attack path, validated only the minimum evidence required, and recommended narrower RBAC scope, reduced managed-identity privilege, and separation of duties. I then designed a retest to verify that the identity path had been broken.

That demonstrates:

Entra ID
   +
Azure RBAC
   +
Managed Identity
   +
Attack-Path Analysis
   +
Professional Reporting

Key Takeaways

Project 02 is about learning to view Azure as an enterprise identity graph.

Remember:

Start with the current Entra identity.

Understand the tenant and subscription before analysing individual resources.

Azure RBAC always has a scope.

Permissions assigned higher in the hierarchy may inherit downward.

Contributor access can be security-sensitive even without direct access-management privilege.

Human identities and machine identities must be analysed together.

Managed identities reduce static credentials but can still be overprivileged.

Who controls a workload can be as important as what the workload can access.

Application ownership and service principals are part of the attack surface.

Key Vault access can create hidden attack paths.

Management-plane and data-plane permissions are different.

Public Azure resources must be evaluated in context.

Network Security Groups should enforce intentional trust boundaries.

Privileged Identity Management can reduce standing privilege.

A role assignment is not automatically a finding.

A hypothesis must be validated before becoming a finding.

Use minimum necessary proof.

Attack paths explain business risk better than isolated permission findings.

Report effective controls as well as weaknesses.

Retest the complete identity path after remediation.

Your Azure penetration testing methodology is:

Scope
  ↓
Establish Entra Identity
  ↓
Map Tenant
  ↓
Map Subscription
  ↓
Inventory Resources
  ↓
Map Users & Groups
  ↓
Analyse Azure RBAC
  ↓
Analyse Scope Inheritance
  ↓
Map Applications & Service Principals
  ↓
Map Managed Identities
  ↓
Assess Compute
  ↓
Assess Network
  ↓
Assess Storage
  ↓
Assess Key Vault
  ↓
Assess Logging
  ↓
Build Identity Graph
  ↓
Develop Hypotheses
  ↓
Validate Attack Paths
  ↓
Collect Evidence
  ↓
Analyse Risk
  ↓
Report
  ↓
Remediate
  ↓
Retest

What’s Next?

➡️ Project 03 — Google Cloud IAM & Workload Security Assessment

In the next CloudNova project, you will move from Azure’s:

Entra ID
   +
Azure RBAC
   +
Managed Identities

into Google Cloud’s:

Organisation Hierarchy
        +
Cloud IAM
        +
Service Accounts
        +
Workload Identity

You will assess:

• Google Cloud organisations

• Folders

• Projects

• IAM bindings

• Built-in and custom roles

• Service accounts

• Service-account impersonation relationships

• Compute workloads

• Serverless workloads

• Cloud Storage

• Secret Manager

• Network exposure

• Audit logging

• Workload identities

• Enterprise privilege paths

The next core question becomes:

Can human identities, inherited IAM permissions, service accounts, and workload relationships combine into a path toward sensitive Google Cloud resources?