Lesson 12 — Azure Attack Chains

Welcome

Azure security weaknesses rarely exist in isolation.

A publicly exposed workload may appear to be one finding.

An excessive Azure RBAC role may appear to be another.

A privileged managed identity, weak Key Vault access, or missing diagnostic setting may each be reported separately.

However, the true business risk often becomes visible only when these weaknesses are connected into a complete attack chain.

An Azure attack chain may begin with:

A compromised user
An exposed application
A leaked service-principal credential
An internet-facing Virtual Machine
A publicly reachable Azure Function
An overly permissive role assignment
A compromised development workload

The attacker may then progress through:

Identity enumeration
Resource discovery
Workload compromise
Managed-identity abuse
Privilege escalation
Secret access
Lateral movement
Persistence
Data access
Monitoring evasion

This lesson brings together the knowledge developed throughout the Azure Cloud Penetration Testing module and teaches you how to analyse complete enterprise attack paths rather than isolated vulnerabilities.

Learning Objectives

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

Explain what an Azure attack chain is.
Distinguish between a vulnerability, attack path, and attack chain.
Identify the stages of an Azure attack chain.
Connect Microsoft Entra ID, Azure RBAC, workloads, identities, and data.
Map managed identities to connected Azure services.
Analyse cross-service and cross-subscription relationships.
Understand how privilege escalation and persistence extend an attack chain.
Identify where monitoring and detection should interrupt an attack.
Build professional Azure attack-path diagrams.
Prioritise findings based on chained business impact.
Validate attack chains using authorised, safe, and minimal techniques.
Document complete Azure attack chains in penetration testing reports.

Mission Context

You are completing the Azure assessment for CloudNova Technologies.

During earlier lessons and assessment activities, your team identified:

A publicly accessible Azure Function
A development group with Contributor access
A user-assigned managed identity
A production Key Vault
Azure Storage containing deployment artefacts
A service principal used by CI/CD
Broad VNet peering
Several permanent Azure role assignments
Incomplete Key Vault and Function App logging

Individually, each issue presents security risk.

The customer now wants to understand whether these weaknesses can be combined into a realistic attack chain that could affect production applications and sensitive business data.

Your objective is to:

Identify the initial access point
Map every identity and resource relationship
Determine how privilege could increase
Identify reachable secrets and data
Evaluate possible persistence
Review available monitoring
Explain the business impact
Recommend controls that break the chain

All analysis and validation must remain within the authorised Rules of Engagement.

What Is an Azure Attack Chain?

An Azure attack chain is a sequence of connected weaknesses, permissions, identities, and resources that allows an attacker to progress from an initial position to a higher-impact objective.

A simplified chain may look like this:

Initial access
    ↓
Identity or workload compromise
    ↓
Azure enumeration
    ↓
Resource control
    ↓
Managed identity abuse
    ↓
Privilege escalation
    ↓
Secret or data access
    ↓
Persistence
    ↓
Business impact

An attack chain demonstrates how multiple lower-level weaknesses combine into a serious enterprise risk.

Vulnerability Versus Attack Path Versus Attack Chain

Vulnerability

A vulnerability is an individual weakness.

Example:

Azure Function permits anonymous access

Attack Path

An attack path connects one weakness to another resource or privilege.

Example:

Anonymous Azure Function
        ↓
Function uses privileged managed identity
        ↓
Managed identity can access Key Vault

Attack Chain

An attack chain connects several stages from initial access to business impact.

Example:

Anonymous Azure Function
        ↓
Application logic abused
        ↓
Managed identity accessed
        ↓
Key Vault secret retrieved
        ↓
Database credential obtained
        ↓
Production database accessed
        ↓
Persistent application credential created

Attack chains provide the clearest explanation of real organisational risk.

Why Attack Chains Matter

A traditional vulnerability list may include:

Public Function App
Excessive managed-identity permissions
Broad Key Vault access
Missing Key Vault logging
Long-lived application credential

Each finding may receive a separate severity.

However, together they may create a critical attack chain.

Public workload
+
Privileged identity
+
Sensitive secret access
+
Missing detection
=
Critical enterprise compromise path

Attack-chain analysis helps the customer understand:

Which weaknesses are connected
Which issue should be fixed first
Which security control would break the chain
How far an attacker could move
Which business services are affected
Whether monitoring would detect the activity

Azure Attack-Chain Domains

Azure attack chains commonly span several security domains.

Identity
    ↓
Authorisation
    ↓
Compute
    ↓
Networking
    ↓
Storage and secrets
    ↓
Automation
    ↓
Monitoring
    ↓
Business application

A complete assessment must evaluate relationships across these areas.

Common Attack-Chain Stages

Stage 1 — Initial Access

Initial access is the attacker’s first authorised simulation point or compromised asset.

Potential entry points include:

Compromised Microsoft Entra user
Leaked service-principal credential
Publicly exposed Virtual Machine
Weakly protected Azure Function
Public Storage object
Compromised CI/CD repository
Guest account
Exposed application secret
Insecure partner integration

The initial access point determines the attacker’s starting permissions.

Stage 2 — Identity Context

The attacker identifies the active identity.

Examples include:

Human user
Guest user
Service principal
Managed identity
Application identity
Virtual Machine local identity
Function App identity
Automation identity

Important questions include:

Which tenant does the identity belong to?
Which subscriptions can it access?
Which groups contain the identity?
Which Entra roles are assigned?
Which Azure RBAC roles are assigned?
Which applications or workloads does it own?

Stage 3 — Enumeration

The attacker identifies accessible Azure objects.

Potential enumeration targets include:

Subscriptions
Resource groups
Role assignments
Applications
Service principals
Managed identities
Virtual Machines
Function Apps
Storage Accounts
Key Vaults
Virtual Networks
Automation Accounts
Deployment resources

Enumeration transforms initial access into a map of potential attack paths.

Stage 4 — Resource Control

The attacker identifies resources they can manage or influence.

Examples include:

Contributor access to a Function App
Virtual Machine management permissions
Storage write access
Automation runbook modification
Logic App workflow control
Application ownership
Pipeline modification
Group ownership

Resource control may provide indirect access to a stronger identity.

Stage 5 — Privilege Escalation

The attacker uses an identity or resource relationship to gain more access.

Examples include:

Contributor on Function App
        ↓
Function runs with privileged managed identity

Application owner
        ↓
Credential added
        ↓
Authentication as service principal

Group owner
        ↓
Privileged group membership changed
        ↓
Inherited role access

Stage 6 — Secret or Credential Access

High-value secrets may be discovered through:

Key Vault
Function App settings
Virtual Machine files
Deployment variables
Storage objects
Automation credentials
Pipeline secrets
Application certificates

A retrieved credential may provide access to a more privileged identity or external business system.

Stage 7 — Lateral Movement

Lateral movement occurs when access expands to additional resources or environments.

Examples include:

Development to production
One subscription to another
Function App to Key Vault
Virtual Machine to Storage
Managed identity to Azure SQL
Service principal to multiple resource groups
Peered network to internal application

Stage 8 — Persistence

Persistence may be established through:

Additional application credential
Guest account
Privileged group membership
Azure RBAC assignment
Federated identity credential
Modified Function App
Automation schedule
Pipeline workflow
Managed identity attachment

During an authorised assessment, persistence should generally be proven analytically or within an isolated test environment.

Stage 9 — Collection or Business Impact

The attacker reaches the final objective.

Potential business impact includes:

Sensitive-data access
Production application control
Secret exposure
Resource modification
Service disruption
Regulatory impact
Intellectual-property theft
Customer-data compromise
Persistent administrative access

Stage 10 — Detection and Response

The final stage examines whether the organisation can detect and contain the chain.

Review:

Sign-in logging
Azure Activity Logs
Resource logs
Key Vault audit logs
Function App telemetry
Storage logs
Defender alerts
Sentinel analytics
Incident-response procedures

Attack-Chain Relationship Model

A useful Azure relationship model is:

Identity
  ↓
Permission
  ↓
Scope
  ↓
Controlled resource
  ↓
Attached identity or credential
  ↓
Connected service
  ↓
Sensitive data or business process

Every step should be supported by evidence.

Identity-Centred Attack Chains

Azure attacks commonly begin with identity compromise.

Example — User to Application to Subscription

Compromised user
        ↓
User owns application registration
        ↓
New credential can be added
        ↓
Authenticate as service principal
        ↓
Service principal has Contributor access
        ↓
Production resources can be modified

Key assessment questions:

Is the user still a legitimate owner?
What permissions does the service principal hold?
Can application credentials be added?
Are credential changes monitored?
Is production access justified?

Managed-Identity Attack Chains

Managed identities frequently connect workload compromise to additional Azure services.

Example — Function App to Key Vault

Public Function App
        ↓
Function execution compromised
        ↓
System-assigned managed identity
        ↓
Key Vault Secrets User
        ↓
Production database credential
        ↓
Database access

Important controls include:

Function authentication
Input validation
Managed-identity least privilege
Key Vault scope
Secret rotation
Function and Key Vault logging

Virtual Machine Attack Chains

Virtual Machines combine network, operating-system, identity, and storage risks.

Example — Public VM to Subscription Resources

Public RDP or SSH
        ↓
Operating-system compromise
        ↓
Managed identity available
        ↓
Managed identity has Contributor access
        ↓
Additional Azure resources modified

Potential control points include:

Remove public management access
Use Azure Bastion
Apply just-in-time access
Harden the guest operating system
Reduce managed-identity permissions
Monitor token and resource activity

Storage-Centred Attack Chains

Azure Storage may expose data, credentials, or trusted deployment artefacts.

Example — Public Container to Service Principal

Public Blob container
        ↓
Deployment backup discovered
        ↓
Service-principal credential exposed
        ↓
Authenticate as service principal
        ↓
Access to production subscription

Example — Storage Write to Code Execution

Storage Blob Data Contributor
        ↓
Write access to deployment package
        ↓
Trusted Function App loads package
        ↓
Code executes as managed identity
        ↓
Key Vault access

Storage write permissions should be analysed in relation to every downstream consumer.

Key Vault-Centred Attack Chains

Key Vault often acts as the bridge between one compromised workload and another business system.

Example — VM to Key Vault to Database

Compromised Virtual Machine
        ↓
Managed identity
        ↓
Key Vault secret access
        ↓
Database connection string
        ↓
Production database

Example — Application Owner to Key Vault

Application owner
        ↓
Application credential added
        ↓
Service principal authentication
        ↓
Key Vault Secrets User
        ↓
Production credentials

Azure Function Attack Chains

Azure Functions can create powerful chains because they combine public endpoints, application logic, identities, and automation.

Example — Public Function to Resource Modification

Anonymous HTTP Function
        ↓
Weak input validation
        ↓
Privileged backend operation invoked
        ↓
Function managed identity
        ↓
Azure Resource Manager
        ↓
Production resource modified

Example — Function Configuration to Secret Exposure

Function App Contributor
        ↓
Read or modify application configuration
        ↓
Key Vault reference or secret discovered
        ↓
Connected service accessed

Automation Attack Chains

Automation Accounts and Logic Apps may execute privileged actions on a schedule.

Example — Runbook Modification

Automation Contributor
        ↓
Runbook modified
        ↓
Scheduled execution
        ↓
Automation managed identity
        ↓
Subscription-level resource control

Example — Logic App Trigger Abuse

Weakly protected HTTP trigger
        ↓
Logic App executed
        ↓
Privileged connector
        ↓
Sensitive business action

CI/CD Attack Chains

Deployment systems frequently hold broad privileges.

Example — Repository to Production

Developer modifies pipeline workflow
        ↓
Protected branch controls missing
        ↓
Pipeline executes
        ↓
Federated deployment identity
        ↓
Production Azure resources modified

Example — Pipeline Secret Exposure

Pipeline log or variable exposed
        ↓
Service-principal credential obtained
        ↓
Production deployment role used
        ↓
Persistent resource created

Cross-Environment Attack Chains

Development environments often have weaker controls but may share privileged identities with production.

Example

Development Function App compromised
        ↓
Shared user-assigned managed identity
        ↓
Production Key Vault access
        ↓
Production database credential

Security boundaries should separate:

Development
Testing
Staging
Production
Shared services
Security operations

Cross-Subscription Attack Chains

Attackers may move across subscriptions through shared identities or inherited roles.

Identity compromised in subscription A
        ↓
Same identity has role in subscription B
        ↓
Production resource access

Review:

Management-group inheritance
Shared service principals
Shared managed identities
Central automation
Shared security tooling
Shared deployment pipelines
Shared Key Vaults

Network-Enabled Attack Chains

Network connectivity can expand the impact of a workload compromise.

Example — Development to Production

Development VM compromised
        ↓
Broad VNet peering
        ↓
Production internal service reachable
        ↓
Application credential reused
        ↓
Production service accessed

A network path alone may not be sufficient.

The chain may also require:

Authentication
Service exposure
Credential access
Application weakness
Weak segmentation

Persistence Within an Attack Chain

Persistence increases the durability of the compromise.

Example

Service principal compromised
        ↓
New certificate added
        ↓
Original user password reset
        ↓
Application certificate still valid
        ↓
Azure access continues

Workload Persistence Example

Function App modified
        ↓
Timer trigger added
        ↓
Function executes periodically
        ↓
Managed identity maintains resource access

Persistence validation must be authorised, reversible, and preferably confined to test resources.

Monitoring Gaps Within Attack Chains

A monitoring gap may allow one or more stages to remain invisible.

Example:

Public Function invoked
        ↓
Managed identity accesses Key Vault
        ↓
Key Vault diagnostics disabled
        ↓
No event reaches Sentinel
        ↓
Secret access remains undetected

A monitoring gap increases:

Time to detection
Attacker dwell time
Investigation difficulty
Business impact
Persistence opportunity

Attack-Chain Kill Points

A kill point is a security control that can interrupt the chain.

Example chain:

Compromised developer
        ↓
Application ownership
        ↓
Service-principal credential
        ↓
Contributor access
        ↓
Function App modification
        ↓
Managed identity
        ↓
Key Vault secret

Potential kill points include:

Remove unnecessary application ownership.
Use federated credentials instead of long-lived secrets.
Reduce the service principal’s Azure role.
Restrict Function App administration.
Reduce managed-identity Key Vault permissions.
Separate development and production.
Alert on application credential creation.
Alert on Function App deployment.
Alert on Key Vault access.

The strongest remediation plan breaks the chain at several stages.

Attack-Chain Evidence Standard

Each attack-chain step should include:

Starting object
Permission or weakness
Controlled object
Required action
Resulting access
Evidence
Detection source
Business impact
Recommended control

Example:

Step	Relationship	Evidence
1	User owns application	Application ownership record
2	Application has service principal	Enterprise application record
3	Service principal has Contributor	Azure RBAC assignment
4	Contributor controls Function App	Function App scope
5	Function uses managed identity	Function identity configuration
6	Identity accesses Key Vault	Key Vault role assignment

Attack-Chain Validation Strategy

Azure attack chains should be validated using the least disruptive evidence available.

Level 1 — Configuration Evidence

Confirm:

Identity relationship
Role assignment
Scope
Resource ownership
Managed identity
Connected service
Relevant permission

Level 2 — Read-Only Validation

Where authorised:

List accessible resources
Read metadata
Confirm identity context
Confirm permission visibility
Review logs

Level 3 — Isolated Technical Validation

Use:

Test identities
Test resources
Test secrets
Dedicated lab subscriptions
Temporary reversible changes

Level 4 — Controlled Enterprise Validation

Only where explicitly approved:

Execute a limited test action
Confirm detection
Validate business impact without exposing production data
Remove changes immediately

The final step of the chain may not need to be executed when the complete relationship is already proven.

When Analytical Proof Is Sufficient

Analytical evidence may be sufficient when:

The starting identity’s permission is confirmed.
Control of the intermediate resource is confirmed.
The attached identity’s privilege is confirmed.
The target resource is identified.
The required actions are technically supported.
Business impact is clear.

Avoid unnecessary retrieval of secrets, modification of workloads, or creation of persistence.

Azure Attack-Chain Assessment Methodology

Stage 1 — Define the Starting Position

Record:

Starting identity
Starting resource
Existing credentials
Current Azure role
Authorised scope
Known limitations

Stage 2 — Enumerate Relationships

Identify:

Group membership
Application ownership
Role assignments
Managed identities
Storage access
Key Vault access
Network connectivity
Pipeline access
Automation control

Stage 3 — Identify High-Value Targets

Targets may include:

Privileged identities
Production subscriptions
Key Vaults
Storage Accounts
Databases
CI/CD systems
Security tooling
Customer data
Management infrastructure

Stage 4 — Build Candidate Paths

Create several candidate paths.

Identity
  ↓
Permission
  ↓
Resource
  ↓
Managed identity
  ↓
Secret
  ↓
Target

Stage 5 — Confirm Every Relationship

For each step, confirm:

Permission exists
Scope applies
Object is controlled
Identity is attached
Target access is valid
No missing assumption remains

Stage 6 — Evaluate Detection

For each step, identify:

Expected log source
Expected alert
Retention
SOC visibility
Investigation capability

Stage 7 — Assess Business Impact

Determine whether the chain can affect:

Confidentiality
Integrity
Availability
Regulatory obligations
Customer trust
Financial operations
Production services

Stage 8 — Prioritise Kill Points

Identify controls that break:

Initial access
Escalation
Lateral movement
Secret access
Persistence
Detection evasion

Stage 9 — Validate Safely

Use the minimum proof required.

Stage 10 — Report the Complete Chain

Document both technical and business impact.

Authorised Azure CLI Enumeration

Confirm the current Azure context:

az account show --output table

List accessible subscriptions:

az account list --output table

List visible Azure role assignments:

az role assignment list \
  --all \
  --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 Function Apps:

az functionapp list --output table

List Virtual Machines:

az vm list --output table

List Storage Accounts:

az storage account list --output table

List Key Vaults:

az keyvault list --output table

List Automation Accounts:

az automation account list --output table

List Virtual Networks:

az network vnet list --output table

Review role assignments for an authorised principal:

az role assignment list \
  --assignee "<authorised-principal-id>" \
  --all \
  --output table

Review Function App identity:

az functionapp identity show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-function-app>"

Review Virtual Machine identity:

az vm identity show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-vm-name>"

Only enumerate objects within the authorised scope.

Authorised Azure PowerShell Enumeration

Confirm the Azure context:

Get-AzContext

List subscriptions:

Get-AzSubscription

List Azure role assignments:

Get-AzRoleAssignment

List user-assigned managed identities:

Get-AzUserAssignedIdentity

List Function Apps:

Get-AzFunctionApp

List Virtual Machines:

Get-AzVM

List Storage Accounts:

Get-AzStorageAccount

List Key Vaults:

Get-AzKeyVault

List Automation Accounts:

Get-AzAutomationAccount

List Virtual Networks:

Get-AzVirtualNetwork

Use approved Microsoft Graph PowerShell commands for authorised review of:

Users
Groups
Applications
Service principals
Owners
Administrative roles
Authentication methods
Consent grants

Attack-Chain Diagram Template

Use the following format:

Initial Access
    ↓
Starting Identity
    ↓
Existing Permission
    ↓
Controlled Resource
    ↓
Intermediate Identity
    ↓
Privilege Escalation
    ↓
Sensitive Service
    ↓
Persistence
    ↓
Business Impact

Example Attack Chain 01 — Public Function to Production Database

Public Azure Function
        ↓
Weak application authentication
        ↓
Function execution influenced
        ↓
System-assigned managed identity
        ↓
Key Vault Secrets User
        ↓
Production database credential
        ↓
Database access

Security Weaknesses

Public endpoint
Weak authentication
Excessive managed-identity permission
Broad Key Vault access
Credential-based database access

Monitoring Requirements

Function invocation logs
Application Insights
Managed-identity sign-ins
Key Vault audit logs
Database authentication logs
Sentinel correlation

Kill Points

Require Entra authentication.
Apply application-level authorisation.
Reduce managed-identity permissions.
Restrict Key Vault secret scope.
Replace stored database credentials with identity-based access.
Alert on unusual secret retrieval.

Example Attack Chain 02 — Developer to Production Subscription

Compromised developer
        ↓
Owner of application registration
        ↓
New application credential added
        ↓
Authenticate as service principal
        ↓
Contributor on production subscription
        ↓
Function App or VM modified
        ↓
Production workload controlled

Security Weaknesses

Unnecessary application ownership
Long-lived application identity
Broad production Contributor role
Weak environment separation

Kill Points

Remove unnecessary owners.
Separate development and production applications.
Use workload identity federation.
Reduce production scope.
Require privileged deployment workflow.
Alert on credential additions.

Example Attack Chain 03 — Public VM to Key Vault

Internet
    ↓
Public SSH or RDP
    ↓
Virtual Machine compromised
    ↓
Managed identity context
    ↓
Production Key Vault
    ↓
Application secret
    ↓
Connected business service

Kill Points

Remove public management access.
Use Bastion and JIT access.
Harden the guest operating system.
Reduce managed-identity permissions.
Restrict Key Vault networking.
Alert on unusual secret access.

Example Attack Chain 04 — Storage Artefact to Function Execution

Storage write permission
        ↓
Function deployment package modified
        ↓
Function App loads package
        ↓
Code runs under managed identity
        ↓
Azure resource access

Kill Points

Restrict storage write permissions.
Protect deployment artefacts.
Validate package integrity.
Separate deployment storage.
Use signed and approved pipelines.
Monitor package and deployment changes.

Example Attack Chain 05 — Automation Persistence

Automation Contributor
        ↓
Runbook modified
        ↓
Recurring schedule
        ↓
Privileged managed identity
        ↓
Production changes
        ↓
Persistent access

Kill Points

Restrict runbook modification.
Require approval.
Reduce automation identity permissions.
Monitor schedule changes.
Alert on unusual automation jobs.
Use source-controlled deployments.

Detection Mapping

Every attack-chain step should be mapped to expected telemetry.

Attack stage	Expected telemetry
User sign-in	Microsoft Entra sign-in logs
Application credential added	Microsoft Entra audit logs
Azure role used	Azure Activity Log and resource activity
Function modified	Azure Activity Log and deployment logs
Managed identity used	Managed-identity sign-in and resource logs
Key Vault secret accessed	Key Vault audit logs
Storage object accessed	Storage resource logs
VM extension deployed	Azure Activity Log and guest telemetry
Persistence created	Entra audit, Azure Activity, workload logs

Reporting Azure Attack Chains

A professional attack-chain finding should include:

Finding Title

Use a title that describes the complete path.

Example:

Development Application Ownership Enables Production Key Vault Access Through a Privileged Function Managed Identity

Executive Summary

Explain the chain in business language.

Starting Position

Document the attacker’s initial level of access.

Attack Path

Show every technical step.

Evidence

Provide evidence for each relationship.

Business Impact

Explain what could be compromised.

Detection Assessment

Explain which activities are logged or missed.

Recommendations

Identify immediate and strategic fixes.

Remediation Priority

Recommend which control should be implemented first.

Example Finding

Finding Title

Public Azure Function Provides Indirect Access to Production Credentials

Observation

An internet-accessible Azure Function is protected only by a function key.

The Function App uses a managed identity with permission to retrieve secrets from a production Key Vault.

The Key Vault stores a production database credential.

Key Vault diagnostic logging is not enabled.

Attack Chain

Function key exposed or endpoint abused
        ↓
Azure Function invoked
        ↓
Function executes with managed identity
        ↓
Managed identity retrieves Key Vault secret
        ↓
Production database credential obtained
        ↓
Production database accessed
        ↓
Key Vault access remains undetected

Business Impact

Compromise of the Function endpoint or its key could provide access to production credentials and the connected database.

The missing Key Vault audit telemetry may prevent timely detection and investigation.

Recommendations

Replace function-key-only access with Microsoft Entra authentication.
Apply application-level authorisation.
Reduce the managed identity’s Key Vault permissions.
Scope access to only the required test or production secret.
Replace stored database credentials with identity-based database access where possible.
Enable Key Vault audit logging.
Integrate events with Microsoft Sentinel.
Rotate the database credential.
Review all Function App keys.
Monitor unusual Function invocation and Key Vault access.

Risk Rating Considerations

The severity of an Azure attack chain depends on:

Starting privilege
Number of required steps
Ease of exploitation
Public exposure
Authentication controls
Privilege gained
Data sensitivity
Cross-environment reach
Persistence capability
Monitoring coverage
Business criticality
Regulatory impact
Availability impact

Several medium-severity weaknesses may combine into a critical attack chain.

Remediation Strategy

Attack-chain remediation should follow a layered approach.

Break Initial Access

Remove unnecessary public exposure.
Require strong authentication.
Patch workloads.
Protect credentials.
Restrict guest access.

Reduce Privilege

Apply least privilege.
Reduce assignment scope.
Separate environments.
Review application ownership.
Restrict managed identities.

Protect Secrets and Data

Limit Key Vault access.
Use private connectivity.
Rotate exposed credentials.
Prefer identity-based access.
Protect Storage permissions.

Prevent Persistence

Review application credentials.
Monitor group and role changes.
Protect automation.
Secure CI/CD.
Remove unused identities.

Improve Detection

Enable diagnostic settings.
Centralise logs.
Alert on privileged changes.
Monitor workload identities.
Validate Sentinel coverage.

Evidence and Portfolio Outcome

Create an Enterprise Azure Attack-Chain Assessment containing:

Environment Overview

Document:

Tenant
Subscriptions
Environments
Major resource groups
Key business services

Starting Positions

Identify potential starting identities and workloads.

Identity and Permission Map

Document:

Users
Groups
Applications
Service principals
Managed identities
Azure roles
Assignment scopes

Resource Relationship Map

Document relationships between:

Virtual Machines
Function Apps
Storage Accounts
Key Vaults
Automation
Networks
Pipelines
Databases

Attack Chains

Document at least three hypothetical chains.

For each chain include:

Starting point
Required permissions
Intermediate resources
Escalation
Target
Persistence opportunity
Monitoring coverage
Business impact

Kill-Point Analysis

For each chain, identify:

Preventive control
Least-privilege control
Network control
Secret-management control
Detection control
Incident-response action

Executive Summary

Explain the most significant chain in non-technical business language.

Recommendations

Prioritise remediation according to which changes break the greatest number of attack paths.

Key Takeaways

Azure risks become clearer when weaknesses are connected into attack chains.
A vulnerability is one weakness; an attack chain demonstrates complete business impact.
Identity is commonly the starting point and central connection between Azure services.
Managed identities may connect workload compromise to sensitive resources.
Storage, Key Vault, automation, and CI/CD can create powerful cross-service paths.
Development and production relationships must be carefully separated.
Persistence and monitoring gaps increase the durability and impact of an attack.
Every attack-chain step should be supported by evidence.
Analytical proof should be preferred over unnecessary exploitation.
Remediation should break the chain at several stages.
Several moderate findings may combine into a critical enterprise risk.
Professional reporting must explain the chain in both technical and business terms.

Knowledge Check

What is the difference between a vulnerability, attack path, and attack chain?
Why are Azure attack chains often identity-centred?
How can a managed identity connect two Azure services?
Why can Contributor access create serious attack paths?
How can Storage write access lead to code execution?
How can application ownership lead to production access?
Why should development and production identities be separated?
How can VNet peering contribute to lateral movement?
How does persistence increase the impact of an attack chain?
Why do monitoring gaps increase business risk?
What is an attack-chain kill point?
When is analytical evidence sufficient?
Which evidence should support every attack-chain step?
Why can several medium findings combine into a critical risk?
Which logs would help investigate a Function-to-Key-Vault attack chain?
What should be included in an enterprise attack-chain report?

Next Lesson

➡️ Lesson 13 — Enterprise Azure Pentesting Projects

In the next lesson, you will apply Azure identity, RBAC, networking, Virtual Machine, Storage, Key Vault, Function App, monitoring, privilege-escalation, persistence, and attack-chain knowledge through structured enterprise Azure penetration testing projects.