Lesson 05 — Azure Virtual Machines

Welcome

Azure Virtual Machines provide on-demand Windows and Linux compute resources within Microsoft Azure.

They are commonly used to host:

• Business applications
• Web servers
• Databases
• Administrative systems
• Development environments
• Security tools
• Legacy workloads
• Domain services
• Automation platforms

During an Azure penetration testing engagement, virtual machines are important because they connect several security domains:

• Azure identity
• Azure RBAC
• Virtual networking
• Operating-system security
• Managed identities
• Storage
• Secrets
• Monitoring
• Enterprise applications

A virtual machine may appear to be only one Azure resource, but control of that machine can expose credentials, tokens, application configuration, internal services, or access to additional Azure resources.

This lesson focuses on identifying and safely assessing Azure Virtual Machine attack surfaces within an authorised environment.

Learning Objectives

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

• Explain Azure Virtual Machine architecture.
• Identify Windows and Linux virtual machines within an authorised subscription.
• Assess public exposure and management access.
• Review Network Security Groups associated with virtual machines.
• Understand Azure VM authentication options.
• Review operating-system disks and data disks.
• Assess Azure VM extensions.
• Understand system-assigned and user-assigned managed identities.
• Identify common Azure VM attack paths.
• Perform authorised VM enumeration using Azure CLI and PowerShell.
• Collect evidence without unnecessarily disrupting workloads.
• Recommend practical VM security improvements.

Mission Context

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

The Azure network assessment identified several virtual machines across:

• Production
• Development
• Shared services
• Security operations
• Management networks

Some virtual machines use:

• Public IP addresses
• Azure Bastion
• SSH
• Remote Desktop Protocol
• Managed identities
• VM extensions
• Premium storage
• Azure Backup
• Microsoft Defender for Cloud
• Log Analytics

Your objective is to determine whether weaknesses in virtual-machine configuration could allow an attacker to:

• Access the operating system
• Execute unauthorised commands
• Retrieve sensitive application data
• Abuse a managed identity
• Access additional Azure resources
• Move laterally through the environment
• Establish persistence
• Avoid or weaken monitoring

All activities must remain within the authorised subscriptions, resource groups, virtual machines, testing windows, and Rules of Engagement.

Azure Virtual Machine Architecture

An Azure Virtual Machine normally consists of several connected resources.

Azure Virtual Machine
│
├── Operating-system disk
├── Data disks
├── Network interface
│   ├── Private IP address
│   ├── Public IP address, if configured
│   └── Network Security Group
├── Virtual Network and subnet
├── Managed identity, if configured
├── VM extensions
├── Boot diagnostics
├── Monitoring configuration
└── Backup configuration

A professional assessment should evaluate the complete resource relationship rather than reviewing only the VM itself.

Azure VM Components

Virtual Machine Resource

The VM resource contains information such as:

• VM name
• Region
• Resource group
• Size
• Operating-system type
• Image
• Availability configuration
• Network interface
• Disk configuration
• Identity configuration
• Extension configuration
• Security profile

Network Interface

The network interface connects the VM to an Azure Virtual Network.

It may contain:

• Private IP address
• Public IP association
• Subnet association
• Network Security Group
• IP forwarding configuration
• Accelerated networking settings
• DNS settings

The network interface is a critical part of the VM attack surface.

Operating-System Disk

The operating-system disk contains:

• Windows or Linux operating system
• System configuration
• Installed applications
• Local accounts
• Logs
• Temporary files
• Application data

Disk access should be treated as highly sensitive because it may expose credentials, configuration files, or business information.

Data Disks

Data disks may contain:

• Application data
• Databases
• Backups
• Logs
• Customer information
• Source code
• Configuration files
• Sensitive documents

A tester should determine whether disk access is appropriately restricted and protected.

Temporary Disk

Some Azure VM sizes provide a temporary local disk.

It may be used for:

• Page files
• Swap files
• Temporary processing
• Cached information

Temporary disks are not designed for persistent storage.

Sensitive information should not be intentionally stored there.

Azure VM Operating Systems

Azure supports many operating-system images, including:

• Windows Server
• Ubuntu
• Red Hat Enterprise Linux
• SUSE Linux
• Debian
• Other supported marketplace images
• Custom organisational images

Each operating system introduces its own security considerations.

Windows VM Considerations

Potential assessment areas include:

• RDP exposure
• Local administrator access
• Windows Update status
• Endpoint protection
• Windows Defender configuration
• Event logging
• PowerShell logging
• Installed services
• Domain membership
• Stored credentials
• Administrative shares
• WinRM exposure

Linux VM Considerations

Potential assessment areas include:

• SSH exposure
• Password-based authentication
• Root login configuration
• SSH key management
• Sudo permissions
• Package updates
• Running services
• File permissions
• Cron jobs
• System logs
• Secrets in configuration files
• Cloud-init configuration

VM Public Exposure

A virtual machine may be internet-accessible through:

• A directly associated public IP
• A public load balancer
• An inbound NAT rule
• Application Gateway
• Azure Firewall DNAT
• A public reverse proxy
• Another internet-facing workload

Do not assume a VM is private simply because it does not have a public IP directly attached.

Public Exposure Assessment

Review:

• Public IP addresses
• Load-balancer rules
• Inbound NAT rules
• Application Gateway backend membership
• Firewall DNAT rules
• Network Security Group rules
• Effective network rules
• Route tables
• Internet-facing services

Common VM Management Services

Service	Common port
SSH	22
RDP	3389
WinRM HTTP	5985
WinRM HTTPS	5986
SMB	445
HTTP	80
HTTPS	443

An open management port is not automatically a vulnerability.

Risk depends on:

• Source restrictions
• Authentication strength
• Multifactor authentication
• Patch status
• Just-in-time access
• Monitoring
• Business purpose
• Exposure duration

Azure VM Authentication

Azure VM access may use:

• Local username and password
• SSH key
• Microsoft Entra-based sign-in
• Azure Bastion
• VPN or private connectivity
• Just-in-time access
• Administrative recovery features

Password-Based Access

Password authentication introduces risks such as:

• Weak passwords
• Password reuse
• Shared credentials
• Brute-force exposure
• Poor rotation
• Undocumented accounts

Password use should be restricted and protected by layered controls.

SSH Key Authentication

SSH keys provide stronger access than password-only authentication when managed correctly.

Review:

• Key strength
• Key ownership
• Key rotation
• Shared private keys
• Orphaned keys
• Keys belonging to former staff
• Keys embedded in deployment templates
• Root login configuration

Microsoft Entra Sign-In

Microsoft Entra-based VM sign-in can centralise identity controls.

Assessment considerations include:

• Role assignments
• Multifactor authentication
• Conditional Access
• Device requirements
• Administrative scope
• Sign-in logging

Centralised identity does not remove the need for least privilege.

Azure Bastion

Azure Bastion allows browser-based SSH or RDP access without directly exposing VM management ports.

Review:

• Whether direct public SSH or RDP still exists
• Who can access Bastion
• Which VNets are connected
• Session logging and monitoring
• Administrative permissions
• Business justification

Just-in-Time VM Access

Just-in-time access can restrict management ports until an approved request temporarily opens access.

Assessment questions include:

• Is JIT enabled for sensitive VMs?
• Which ports are managed?
• Which source addresses are permitted?
• How long does access remain open?
• Are approvals required?
• Are requests logged and reviewed?

Network Security Groups

A VM may be protected by Network Security Groups associated with:

• Its network interface
• Its subnet
• Both

Review effective rules for:

• SSH
• RDP
• WinRM
• SMB
• Database ports
• Administrative web interfaces
• Application services
• Outbound access

Example risk:

Internet
   ↓
NSG allows TCP 22 from 0.0.0.0/0
   ↓
Linux VM
   ↓
Password authentication enabled

Azure VM Images

Virtual machines may be created from:

• Microsoft marketplace images
• Partner images
• Shared Image Gallery
• Azure Compute Gallery
• Managed images
• Custom organisational images

Image-related risks include:

• Outdated packages
• Embedded credentials
• Unnecessary software
• Weak default configuration
• Sensitive files
• Preconfigured local accounts
• Insecure agents
• Missing endpoint protection

Custom images should be treated as part of the software supply chain.

Azure VM Disks

Azure VM disks may be:

• Operating-system disks
• Data disks
• Managed disks
• Unmanaged legacy disks
• Encrypted disks
• Snapshots

Disk Security Questions

Review:

• Disk encryption
• Key-management method
• Public access settings
• Export permissions
• Snapshot access
• Backup protection
• Access through Azure RBAC
• Sensitive data classification
• Disk-retention requirements

Disk Snapshots

Snapshots can expose complete copies of VM disks.

Potential risks include:

• Excessive snapshot permissions
• Forgotten snapshots
• Old copies containing credentials
• Insecure sharing
• Poor lifecycle management
• Data retained after VM deletion

Snapshot access should be limited and monitored.

Disk Encryption

Azure VM disks may use platform-managed or customer-managed keys.

Assessment considerations include:

• Whether encryption is enabled
• Which key-management model is used
• Key Vault access
• Key rotation
• Separation of duties
• Recovery procedures
• Monitoring of key operations

Encryption reduces storage risk but does not prevent access through an already compromised VM.

Azure VM Extensions

VM extensions provide post-deployment configuration and management capabilities.

Examples include:

• Custom Script Extension
• Azure Monitor Agent
• Microsoft Antimalware
• Dependency Agent
• Domain join extensions
• Desired State Configuration
• Access-management extensions

Extensions may run with high operating-system privileges.

Extension Security Risks

Potential risks include:

• Scripts containing credentials
• Secrets included in command-line parameters
• Publicly accessible script locations
• Unverified script content
• Excessive Azure RBAC permissions
• Old or unused extensions
• Extension configuration exposing sensitive data
• Ability to install extensions on privileged VMs

Control of VM extensions can sometimes provide an authorised code-execution path.

Any validation involving extension deployment must receive explicit approval.

Custom Script Extension

The Custom Script Extension can download and execute scripts inside a VM.

Security review should consider:

• Script source
• Storage location
• Authentication
• Integrity validation
• Embedded secrets
• Command parameters
• Logging
• Cleanup
• Who can modify the extension

A script stored in a public or weakly protected location may create a supply-chain risk.

Managed Identities

An Azure VM may have:

• A system-assigned managed identity
• One or more user-assigned managed identities

The identity allows the VM to request tokens for authorised Azure services without storing traditional credentials in application code.

System-Assigned Managed Identity

A system-assigned identity is tied to the lifecycle of one Azure resource.

If the VM is deleted, the identity is also removed.

User-Assigned Managed Identity

A user-assigned identity is a separate Azure resource.

It can be associated with multiple workloads.

This flexibility increases the importance of monitoring where the identity is attached and what permissions it holds.

Managed Identity Attack Paths

A compromised VM may provide access to its managed identity context.

Example:

Publicly exposed VM
        ↓
Operating-system compromise
        ↓
Access to managed identity context
        ↓
Token requested for authorised Azure service
        ↓
Key Vault or Storage access

The security impact depends on the identity’s assigned permissions.

A managed identity with broad access can turn a single VM compromise into a larger Azure compromise.

Azure Instance Metadata Service

Azure workloads can access instance metadata from within the authorised VM environment.

Metadata may include information about:

• VM identity
• Subscription
• Resource group
• Region
• Network
• Compute configuration
• Managed identity context

Metadata access should only be tested from authorised workloads.

The metadata service should never be queried through unapproved server-side request forgery or production exploitation.

Safe Metadata Review

Within an authorised lab VM, basic instance metadata may be reviewed with an approved request similar to:

curl -H Metadata:true \
  "http://169.254.169.254/metadata/instance?api-version=2021-02-01"

Only perform this inside a VM that is explicitly included in the assessment.

Do not collect access tokens unless the engagement specifically authorises managed-identity validation.

Boot Diagnostics

Boot diagnostics may store:

• Serial console logs
• Boot screenshots
• Startup information
• Troubleshooting data

Review:

• Whether diagnostics are enabled
• Storage protection
• Access controls
• Retention
• Sensitive information exposure

Diagnostic data can sometimes reveal system names, configuration details, or errors.

Azure Serial Console

Azure Serial Console can provide administrative access to supported VMs.

Review:

• Who has permission to use it
• Role assignments
• Logging
• Operational purpose
• Emergency-access procedures

Testing console access can affect production systems and requires explicit authorisation.

Azure VM Agent

The Azure VM Agent supports communication between Azure and the guest operating system.

It is used by:

• Extensions
• Password reset functions
• Monitoring
• Configuration tools

Assessment considerations include:

• Agent health
• Agent version
• Installed extensions
• Extension permissions
• Monitoring coverage

VM Access Recovery Features

Azure supports administrative recovery capabilities for authorised operators.

Depending on permissions and configuration, administrators may be able to:

• Reset local access
• Update SSH configuration
• Deploy repair mechanisms
• Use extensions
• Access serial console features

These capabilities are sensitive because an identity with resource-management permissions may gain operating-system access.

Do not validate recovery features against production VMs without explicit approval.

Operating-System Security Assessment

Azure configuration review should be combined with guest operating-system assessment where authorised.

Windows Review Areas

• Local users and groups
• Administrator membership
• Patch status
• Running services
• Installed software
• Firewall configuration
• Event logs
• Endpoint protection
• PowerShell logging
• Scheduled tasks
• Credential storage
• Domain membership

Linux Review Areas

• Users and groups
• Sudo permissions
• SSH configuration
• Package updates
• Running services
• Listening ports
• File permissions
• Cron jobs
• System logs
• Kernel version
• Security modules
• Application secrets

Guest-level testing requires valid authorisation and approved access credentials.

VM Secrets and Sensitive Configuration

Sensitive information may exist in:

• Environment variables
• Application configuration files
• Deployment scripts
• Shell history
• PowerShell history
• Cloud-init files
• Scheduled tasks
• Service configuration
• CI/CD agents
• Local backups
• Mounted file systems
• Diagnostic logs

The tester should avoid unnecessarily opening or copying sensitive information.

Evidence should demonstrate risk with the minimum data required.

Azure VM Monitoring

Virtual-machine telemetry may include:

• Azure Activity Logs
• Azure Monitor metrics
• Log Analytics
• Azure Monitor Agent
• Microsoft Defender for Cloud
• Windows Event Logs
• Linux syslog
• Endpoint detection and response
• NSG flow logs

Assessment questions include:

• Are all critical VMs monitored?
• Are logs centralised?
• Is endpoint protection active?
• Are administrative actions alerted?
• Are sign-ins monitored?
• Are extension deployments detected?
• Is logging retained long enough?
• Are security alerts investigated?

Microsoft Defender for Servers

Microsoft Defender for Servers may provide:

• Security recommendations
• Vulnerability insights
• Endpoint integration
• Threat detection
• File-integrity monitoring
• Just-in-time access support

Review whether:

• Relevant subscriptions are covered
• Agents are healthy
• Recommendations are addressed
• Alerts are integrated with security operations
• Exceptions are documented

Common Azure VM Misconfigurations

Public SSH or RDP Exposure

Internet
   ↓
Public IP
   ↓
Permissive NSG
   ↓
SSH or RDP

Excessive VM Management Permissions

A user with broad VM-management permissions may be able to alter configuration or invoke sensitive management features.

Privileged Managed Identity

Compromised VM
        ↓
Managed identity
        ↓
Broad subscription permissions
        ↓
Access to additional Azure resources

Insecure VM Extension

Extension downloads public script
        ↓
Script content modified
        ↓
Privileged execution inside VM

Secrets in Configuration

Application settings, scripts, or local files may contain:

• Passwords
• API keys
• Database strings
• Service-principal secrets
• Storage keys

Unencrypted or Poorly Governed Disks

Weak disk and snapshot controls may expose data outside the running VM.

Missing Monitoring

Without guest-level and Azure-level telemetry, compromise may remain undetected.

Shared Administrative Accounts

Shared local accounts reduce accountability and complicate incident investigation.

Azure VM Enumeration Methodology

A structured VM assessment should follow these stages.

Stage 1 — Confirm Scope

Record:

• Tenant ID
• Subscription ID
• Authorised resource groups
• Authorised VMs
• Approved operating-system access
• Testing windows
• Prohibited actions

Stage 2 — Inventory Virtual Machines

Document:

• VM name
• Resource group
• Region
• Operating system
• VM size
• Power state
• Network interface
• Public exposure
• Identity configuration

Stage 3 — Review Networking

Identify:

• Private IP
• Public IP
• VNet and subnet
• Network Security Groups
• Effective rules
• Load-balancer relationships
• Bastion availability

Stage 4 — Review Identity

Identify:

• System-assigned managed identity
• User-assigned managed identities
• Azure RBAC assignments
• Microsoft Entra login configuration
• Administrative access groups

Stage 5 — Review Disks

Assess:

• OS disk
• Data disks
• Encryption
• Snapshots
• Backup
• Access controls

Stage 6 — Review Extensions

Document:

• Installed extensions
• Publisher
• Version
• Purpose
• Auto-upgrade status
• Sensitive configuration
• Ownership

Stage 7 — Review Monitoring

Identify:

• Azure Monitor Agent
• Log Analytics workspace
• Defender coverage
• Endpoint protection
• Diagnostic settings
• Alerting

Stage 8 — Build Attack Paths

Connect the VM to other resources.

Internet exposure
        ↓
Virtual machine
        ↓
Operating-system access
        ↓
Managed identity
        ↓
Key Vault or Storage

Stage 9 — Validate Safely

Prefer:

• Configuration review
• Read-only enumeration
• Test resources
• Approved accounts
• Minimal evidence
• Reversible actions

Authorised Azure CLI Enumeration

Confirm the Azure context:

az account show --output table

List virtual machines:

az vm list --output table

Display detailed VM information:

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

Display VM power state:

az vm get-instance-view \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-vm-name>" \
  --output table

List network interfaces:

az network nic list --output table

Display a specific network interface:

az network nic show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-nic-name>"

List public IP addresses:

az network public-ip list --output table

List managed disks:

az disk list --output table

List snapshots:

az snapshot list --output table

List VM extensions:

az vm extension list \
  --resource-group "<authorised-resource-group>" \
  --vm-name "<authorised-vm-name>" \
  --output table

Display VM identity configuration:

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

List role assignments associated with the VM identity where authorised:

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

Only query authorised resources.

Authorised Azure PowerShell Enumeration

List Azure Virtual Machines:

Get-AzVM

Display VM status:

Get-AzVM `
    -ResourceGroupName "<authorised-resource-group>" `
    -Name "<authorised-vm-name>" `
    -Status

List network interfaces:

Get-AzNetworkInterface

List managed disks:

Get-AzDisk

List snapshots:

Get-AzSnapshot

List VM extensions:

Get-AzVMExtension `
    -ResourceGroupName "<authorised-resource-group>" `
    -VMName "<authorised-vm-name>"

Display role assignments for an authorised managed identity:

Get-AzRoleAssignment `
    -ObjectId "<managed-identity-principal-id>"

Do not modify VM configuration unless the engagement explicitly permits it.

Guest-Level Validation

Guest operating-system testing may be performed only when:

• The VM is explicitly in scope
• Valid credentials have been provided
• The Rules of Engagement allow guest access
• The testing window is approved
• Business owners have been informed
• Monitoring teams understand the activity

Preferred activities include:

• System inventory
• Patch review
• Service review
• Local permission assessment
• Configuration review
• Log review
• Security-agent validation

Avoid destructive testing or unapproved privilege escalation.

Safe Validation Principles

Use the least disruptive validation method.

Preferred order:

1. Review Azure resource configuration.
2. Review network exposure.
3. Review role assignments.
4. Review managed-identity permissions.
5. Review extensions.
6. Review disk and snapshot controls.
7. Use an isolated lab VM for technical validation.
8. Access the guest operating system only when authorised.
9. Collect minimal evidence.
10. Clean up all approved test artefacts.

Actions Requiring Explicit Approval

Do not perform the following without specific authorisation:

• Starting or stopping production VMs
• Restarting or redeploying VMs
• Resetting credentials
• Installing VM extensions
• Running custom scripts
• Attaching or detaching disks
• Creating disk snapshots
• Exporting disks
• Modifying managed identities
• Changing NSG rules
• Changing public IP configuration
• Accessing production secrets
• Disabling monitoring or endpoint protection
• Altering backups
• Modifying application data

Attack-Path Analysis

Azure VM findings should be analysed as connected relationships.

Public VM to Managed Identity

Public management interface
        ↓
Compromised VM account
        ↓
Operating-system access
        ↓
Managed identity context
        ↓
Access to Azure service

VM Contributor to Guest Access

Azure identity
        ↓
VM management permissions
        ↓
Authorised management capability
        ↓
Operating-system control
        ↓
Application or credential access

VM Extension Attack Path

Control of VM extension configuration
        ↓
Privileged script execution
        ↓
Guest operating-system access
        ↓
Access to local configuration or identity

Snapshot Exposure

Permission to create or access snapshot
        ↓
Copy of VM disk
        ↓
Offline configuration review
        ↓
Sensitive data exposure

Development VM to Production

Compromised development VM
        ↓
Shared credentials or connected identity
        ↓
Peered production network
        ↓
Production resource access

Evidence Collection

For each VM finding, record:

• Subscription ID
• Resource group
• VM name
• VM resource ID
• Region
• Operating-system type
• VM image
• Private IP
• Public IP
• VNet and subnet
• Network Security Group
• Management ports
• Managed identity
• Azure RBAC assignments
• Extensions
• Disk configuration
• Monitoring status
• Backup status
• Validation method
• Business impact
• Recommended remediation

Avoid including passwords, private keys, tokens, or sensitive customer data in reports.

Example Finding

Finding Title

Production Virtual Machine Uses an Excessively Privileged Managed Identity

Observation

A production application VM has a system-assigned managed identity with broad access to multiple Key Vault and Storage resources.

The VM is administered by a larger operations group than required.

Potential Attack Path

Compromised operations account
        ↓
Administrative access to production VM
        ↓
Access to managed identity context
        ↓
Retrieval of sensitive Key Vault secrets
        ↓
Access to connected production services

Business Impact

Compromise of the VM or an authorised administrator could provide access to credentials, application secrets, and sensitive business data across multiple Azure services.

Recommendation

• Reduce the managed identity’s permissions.
• Scope access to only required resources.
• Separate VM administration from secret access.
• Apply Privileged Identity Management.
• Restrict guest operating-system access.
• Monitor token and Key Vault activity.
• Review whether separate identities are required for different applications.

Risk Rating Considerations

The severity of a VM finding depends on:

• Internet exposure
• Management-port exposure
• Authentication strength
• Operating-system security
• Azure RBAC permissions
• Managed-identity privileges
• Data sensitivity
• Network position
• Connected resources
• Extension-control permissions
• Monitoring coverage
• Business criticality

A public VM in an isolated training subscription presents different risk from a privileged VM in a production shared-services network.

Remediation Principles

Common Azure VM security recommendations include:

• Remove unnecessary public IP addresses.
• Restrict SSH and RDP access.
• Use Bastion, VPN, or private access.
• Enable just-in-time management access.
• Use Microsoft Entra-based authentication where appropriate.
• Apply strong multifactor authentication.
• Disable password-based SSH where feasible.
• Patch operating systems regularly.
• Use approved hardened images.
• Protect disks and snapshots.
• Apply least privilege to managed identities.
• Remove unused VM extensions.
• Protect extension scripts and configuration.
• Enable endpoint protection.
• Centralise guest and Azure logs.
• Monitor administrative actions.
• Enable backup for critical workloads.
• Review local administrator accounts.
• Separate production and development administration.
• Perform regular vulnerability assessments.

Evidence and Portfolio Outcome

Create an Azure Virtual Machine Security Assessment containing:

VM Inventory

Document:

• VM name
• Resource group
• Operating system
• Region
• Private and public IPs
• Network controls
• Business purpose

Access Review

Document:

• SSH or RDP exposure
• Bastion usage
• Authentication method
• Administrative groups
• Azure RBAC permissions
• Just-in-time access

Identity Review

Document:

• System-assigned identity
• User-assigned identities
• Role assignments
• Accessible Azure resources

Storage Review

Document:

• OS disk
• Data disks
• Encryption
• Snapshots
• Backup
• Access controls

Extension Review

Document:

• Extension name
• Publisher
• Purpose
• Security observations
• Ownership

Attack-Path Diagram

Create one safe, hypothetical VM attack path.

Example:

Public VM
  ↓
Operating-system compromise
  ↓
Managed identity
  ↓
Key Vault
  ↓
Application secret

Recommendations

Provide prioritised remediation guidance based on business risk.

Key Takeaways

• Azure Virtual Machines combine cloud-resource security and guest operating-system security.
• Public exposure may exist through several Azure networking components.
• VM-management permissions can be highly sensitive.
• Disks and snapshots may contain valuable data.
• VM extensions can execute privileged configuration inside the guest.
• Managed identities can connect VM compromise to additional Azure resources.
• Monitoring should cover both Azure control-plane actions and guest activity.
• Configuration review should come before intrusive testing.
• Findings should be evaluated as complete attack paths.
• All validation must remain authorised, minimal, and reversible.

Knowledge Check

1. Which Azure resources normally support a Virtual Machine?
2. Why is a VM without a directly attached public IP not necessarily private?
3. What is the purpose of Azure Bastion?
4. What security risks are associated with VM extensions?
5. How can a managed identity expand the impact of VM compromise?
6. Why should VM disk snapshots be treated as sensitive?
7. What is the difference between system-assigned and user-assigned managed identities?
8. Which logs are useful for investigating Azure VM activity?
9. Why should VM-management permissions be assessed alongside operating-system access?
10. What is the safest approach to validating a VM attack path?

Next Lesson

➡️ Lesson 06 — Azure Storage Security

In the next lesson, you will examine Azure Storage Accounts, Blob Storage, Azure Files, access keys, shared access signatures, identity-based access, public exposure, network restrictions, data-plane permissions, and common authorised storage attack paths.