Lesson 04 — Azure Network Enumeration

Welcome

Azure networking connects identities, applications, virtual machines, storage services, databases, Kubernetes clusters, and external users.

During an Azure penetration testing engagement, network enumeration helps you understand:

Which resources are exposed to the internet
How Azure workloads communicate
Where segmentation exists
Which security controls regulate traffic
Whether private services are reachable
How an attacker could move between connected resources

Azure environments may appear strongly protected from the outside while still containing weak internal trust relationships.

A publicly exposed virtual machine, permissive Network Security Group, unnecessary peering connection, or poorly controlled private endpoint may create an entry point into a much larger environment.

This lesson focuses on authorised, non-destructive enumeration of Azure network architecture and attack paths.

Learning Objectives

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

Explain the main components of Azure networking.
Identify Azure Virtual Networks and subnets.
Understand Network Security Groups and effective security rules.
Identify public IP addresses and internet-facing resources.
Review VNet peering relationships.
Understand private endpoints and service endpoints.
Identify common Azure network misconfigurations.
Perform authorised network enumeration using Azure CLI and PowerShell.
Map potential network attack paths.
Document Azure network findings using professional evidence standards.

Mission Context

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

The customer operates several Azure environments:

Production
Development
Shared services
Security operations
Identity services
Remote administration

The organisation uses:

Azure Virtual Networks
Multiple subnets
Network Security Groups
Public IP addresses
Azure Load Balancers
Application Gateway
Azure Firewall
VNet peering
Private Endpoints
VPN Gateway
ExpressRoute
Azure Bastion

Your objective is to determine whether the network architecture exposes unnecessary services or creates unsafe paths between environments.

All testing must remain within the authorised tenant, subscriptions, resource groups, IP ranges, and Rules of Engagement.

Azure Networking Overview

Azure networking provides logical connectivity between cloud resources.

A simplified architecture may look like this:

Internet
   │
   ▼
Public IP / Load Balancer / Application Gateway
   │
   ▼
Azure Virtual Network
   │
   ├── Web Subnet
   │     └── Web Servers
   │
   ├── Application Subnet
   │     └── Application Services
   │
   ├── Database Subnet
   │     └── Databases
   │
   └── Management Subnet
         └── Bastion / Administrative Systems

Azure networks may also connect to:

Other Azure VNets
On-premises networks
Partner environments
Managed services
Private endpoints
Internet-facing services

Understanding these relationships is essential for identifying attack paths.

Azure Virtual Networks

An Azure Virtual Network, or VNet, is a logical network boundary within Azure.

A VNet contains:

Address space
Subnets
Routing configuration
DNS configuration
Security controls
Peering relationships
Gateway connections
Private endpoints

Example:

VNet: prod-vnet
Address space: 10.10.0.0/16

├── web-subnet        10.10.1.0/24
├── app-subnet        10.10.2.0/24
├── data-subnet       10.10.3.0/24
└── management-subnet 10.10.4.0/24

During enumeration, record:

VNet name
Resource group
Address space
Region
DNS settings
Subnets
Peerings
Connected gateways
Security controls

Subnets

A subnet divides a VNet into smaller network segments.

Subnets may be used to separate:

Web workloads
Application workloads
Databases
Administrative systems
Kubernetes nodes
Private endpoints
Security appliances

A penetration tester should determine whether subnet separation is supported by effective traffic restrictions.

A separate subnet does not automatically provide security.

Security depends on:

Network Security Groups
Route tables
Firewalls
Service configuration
Peering
Private connectivity

Network Security Groups

A Network Security Group, or NSG, filters inbound and outbound traffic.

An NSG can be associated with:

A subnet
A network interface

NSGs contain security rules based on:

Source
Source port
Destination
Destination port
Protocol
Priority
Allow or deny action

Example:

Priority: 100
Source: Internet
Destination: Any
Port: 22
Protocol: TCP
Action: Allow

This rule may expose SSH access to the internet.

NSG Rule Processing

Azure evaluates rules based on priority.

Lower numbers are processed first.

Example:

Priority 100 — Allow TCP 22 from Internet
Priority 200 — Deny all inbound

The first matching rule is applied.

A tester should review:

Custom rules
Default rules
Rule priorities
Broad source ranges
Broad destination ranges
Management ports
Outbound access
Effective rules

Default NSG Rules

Azure includes default NSG rules.

Typical inbound defaults include:

AllowVNetInBound
AllowAzureLoadBalancerInBound
DenyAllInBound

Typical outbound defaults include:

AllowVnetOutBound
AllowInternetOutBound
DenyAllOutBound

Custom rules may override these defaults due to higher priority.

Do not assume the presence of a deny-all default rule means the workload is secure.

Effective Security Rules

A network interface may inherit rules from:

The subnet NSG
The network interface NSG

Effective security rules represent the combined result.

During an assessment, review effective rules rather than only individual NSG configurations.

This helps identify cases where:

A subnet rule permits traffic
A network interface rule adds additional access
A broad rule overrides intended restrictions
A management port becomes exposed

Common Management Ports

High-risk exposure may include:

Service	Common port
SSH	22
RDP	3389
WinRM HTTP	5985
WinRM HTTPS	5986
SMB	445
SQL Server	1433
MySQL	3306
PostgreSQL	5432
Kubernetes API	6443
Elasticsearch	9200
Redis	6379

The presence of an open port is not automatically a vulnerability.

Risk depends on:

Source restrictions
Authentication
Service configuration
Patch status
Exposure duration
Business purpose
Monitoring coverage

Public IP Addresses

Azure Public IP resources provide internet-routable addresses.

They may be associated with:

Virtual machines
Load balancers
Application Gateway
VPN Gateway
Azure Firewall
Bastion
Other Azure services

During enumeration, identify:

Public IP address
Associated resource
Allocation method
DNS name
SKU
Region
Exposure purpose

An unused or undocumented public IP may indicate:

Forgotten infrastructure
Development resources
Shadow IT
Incomplete decommissioning
Unnecessary attack surface

Publicly Exposed Azure Resources

Not every public Azure service uses a standalone Public IP resource.

Other internet-facing services may include:

App Service
Azure Functions
Storage Accounts
Azure SQL
API Management
Azure Container Apps
AKS ingress
Front Door
Application Gateway
Public load balancers

A complete assessment combines Azure resource enumeration with authorised external validation.

Azure Load Balancer

Azure Load Balancer distributes Layer 4 traffic.

Review:

Frontend IP configuration
Backend pools
Health probes
Load-balancing rules
Inbound NAT rules
Public or internal configuration

Potential risks include:

Unexpected public frontend
Exposed administrative services
Broad NAT rules
Weak backend segmentation
Insecure health probe design

Azure Application Gateway

Application Gateway provides Layer 7 routing and may include Web Application Firewall capabilities.

Review:

Public frontend
Listeners
Backend pools
HTTP settings
TLS configuration
WAF mode
WAF policy
Rewrite rules
Health probes

Security concerns may include:

WAF operating only in detection mode
Weak TLS configuration
Public administrative endpoints
Insecure backend communication
Misconfigured routing rules

Azure Firewall

Azure Firewall is a managed network security service.

Review:

Firewall policies
Network rules
Application rules
DNAT rules
Threat intelligence settings
Logging
Rule priorities
Source and destination ranges

Potential risks include:

Broad allow rules
Unrestricted outbound access
Overly permissive DNAT
Missing logs
Weak rule ownership
Temporary rules left active

Route Tables

Azure route tables control traffic forwarding.

Routes may direct traffic to:

Virtual appliances
Internet
VPN gateways
VNet gateways
Other network paths

Review:

Custom routes
Next-hop type
Associated subnets
Forced tunnelling
Internet routes
Security-appliance bypasses

Misconfigured routes may allow:

Bypass of monitoring
Direct internet access
Traffic exposure
Unintended lateral movement
Asymmetric routing

VNet Peering

VNet peering connects Azure Virtual Networks.

Types include:

Regional VNet peering
Global VNet peering

Peering may provide private connectivity between environments.

Review:

Local VNet
Remote VNet
Address spaces
Peering status
Traffic forwarding
Gateway transit
Remote gateway usage

Potential risks include:

Production connected to development
Shared services connected too broadly
Weak segmentation between business units
Transitive trust assumptions
Unrestricted forwarded traffic

Peering Is Not Automatically Transitive

If VNet A peers with VNet B, and VNet B peers with VNet C, VNet A does not automatically reach VNet C.

However, routing appliances, gateways, and forwarded traffic settings may create extended connectivity.

The tester should validate actual paths rather than relying on assumptions.

Private Endpoints

A Private Endpoint assigns a private IP address to an Azure service.

It may provide private access to:

Storage Accounts
Key Vault
Azure SQL
App Service
Container Registry
Other managed services

Review:

Connected service
Private IP address
Subnet
DNS integration
Approval state
Public network access
Associated NSG controls

A service using a Private Endpoint may still permit public access if public network access has not been disabled.

Service Endpoints

Service Endpoints allow a subnet to access supported Azure services through the Azure backbone.

They do not assign the service a private IP address.

A tester should distinguish between:

Private Endpoints
Service Endpoints
Public access restrictions

Misunderstanding these controls can create false assumptions about exposure.

Private DNS Zones

Private DNS zones support name resolution for private services.

Review:

Zone names
VNet links
Auto-registration settings
DNS records
Private endpoint integration
Cross-environment name resolution

Incorrect DNS configuration may:

Expose internal naming
Break intended private routing
Redirect traffic unexpectedly
Enable access from unintended VNets

Azure Bastion

Azure Bastion provides browser-based RDP and SSH access without directly exposing management ports on virtual machines.

Review:

Bastion deployment
Public IP association
Connected VNet
Supported access method
Logging
Administrative permissions
Whether direct RDP or SSH remains exposed

A Bastion deployment does not improve security if virtual machines still expose management ports publicly.

VPN Gateway

VPN Gateway connects Azure networks to:

On-premises environments
Remote users
Other networks

Review:

Connection type
Local network gateway
Address ranges
Authentication method
Shared keys
Point-to-site configuration
Diagnostic logging
Connected routes

Potential risks include:

Overlapping address spaces
Excessive on-premises reachability
Weak authentication
Broad client address pools
Missing monitoring

ExpressRoute

ExpressRoute provides private connectivity between Azure and external networks.

Review:

Connected circuits
Peerings
Advertised routes
Gateway configuration
Redundancy
Network segmentation
Monitoring

ExpressRoute is private connectivity, but it is not automatically secure against lateral movement.

Network Watcher

Azure Network Watcher provides diagnostic capabilities such as:

Topology
IP flow verification
Next-hop analysis
Packet capture
NSG flow logs
Connection troubleshooting

Use of active diagnostic features must be authorised.

Packet capture, in particular, may collect sensitive information and should not be enabled without explicit approval.

Common Azure Network Misconfigurations

Public Management Exposure

Internet
   ↓
Public IP
   ↓
NSG allows 0.0.0.0/0
   ↓
RDP or SSH

Risk increases when authentication or patching is weak.

Overly Permissive NSG Rules

Examples include:

Any source
Any destination
Any port
Any protocol
Broad internal address ranges
Temporary access rules left active

Weak Environment Segmentation

Development VNet
      ↓
Broad peering
      ↓
Production VNet

A compromise in a lower-trust environment may create a path toward production.

Unrestricted Outbound Access

Unrestricted outbound connectivity may support:

Data exfiltration
Command-and-control traffic
Malware downloads
Access to unauthorised services

Public Access Alongside Private Endpoint

Private Endpoint configured
        +
Public network access enabled
        =
Service still reachable publicly

Broad Peering Relationships

A shared services network may become a central lateral-movement path if connected too broadly.

Missing Flow Logging

Without network telemetry, security teams may be unable to investigate:

Scanning
Unexpected connections
Lateral movement
Data exfiltration
Management access

Azure Network Enumeration Methodology

A structured assessment should follow these stages.

Stage 1 — Confirm Scope

Record:

Tenant ID
Subscription ID
Authorised resource groups
Authorised VNets
Authorised IP ranges
External-testing permissions
Prohibited resources

Stage 2 — Inventory VNets

Identify:

VNet names
Address spaces
Regions
Resource groups
DNS settings

Stage 3 — Inventory Subnets

Record:

Subnet names
CIDR ranges
NSG associations
Route-table associations
Service endpoints
Private endpoints
Delegations

Stage 4 — Review NSGs

Identify:

Inbound rules
Outbound rules
Rule priorities
Broad source ranges
Management-port exposure
Effective rules

Stage 5 — Identify Public Exposure

Map:

Public IP addresses
Load balancers
Application gateways
Public virtual machines
Public application services
Public storage endpoints
Public database endpoints

Stage 6 — Review Connectivity

Assess:

VNet peering
VPN connections
ExpressRoute
Bastion
Private endpoints
Service endpoints
DNS links

Stage 7 — Review Routing

Identify:

Route tables
Custom routes
Security appliances
Internet paths
Forwarded traffic

Stage 8 — Build Attack Paths

Create network relationship maps.

Internet
   ↓
Public application
   ↓
Application subnet
   ↓
Peered shared-services VNet
   ↓
Management service

Stage 9 — Validate Safely

Validation should:

Use authorised targets only
Avoid aggressive scanning
Respect testing windows
Apply rate limits
Avoid service interruption
Record all connections
Stop immediately if instability is observed

Authorised Azure CLI Enumeration

Confirm the active Azure context:

az account show --output table

List Virtual Networks:

az network vnet list --output table

Display details for a VNet:

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

List subnets:

az network vnet subnet list \
  --resource-group "<authorised-resource-group>" \
  --vnet-name "<authorised-vnet-name>" \
  --output table

List Network Security Groups:

az network nsg list --output table

Display NSG rules:

az network nsg rule list \
  --resource-group "<authorised-resource-group>" \
  --nsg-name "<authorised-nsg-name>" \
  --output table

List public IP addresses:

az network public-ip list --output table

List network interfaces:

az network nic list --output table

List VNet peerings:

az network vnet peering list \
  --resource-group "<authorised-resource-group>" \
  --vnet-name "<authorised-vnet-name>" \
  --output table

List route tables:

az network route-table list --output table

List private endpoints:

az network private-endpoint list --output table

List load balancers:

az network lb list --output table

List Application Gateways:

az network application-gateway list --output table

List Azure Firewalls:

az network firewall list --output table

Only query resources within the authorised assessment scope.

Authorised Azure PowerShell Enumeration

List Virtual Networks:

Get-AzVirtualNetwork

List Network Security Groups:

Get-AzNetworkSecurityGroup

List public IP addresses:

Get-AzPublicIpAddress

List network interfaces:

Get-AzNetworkInterface

List route tables:

Get-AzRouteTable

List load balancers:

Get-AzLoadBalancer

List Application Gateways:

Get-AzApplicationGateway

List Azure Firewalls:

Get-AzFirewall

List private endpoints:

Get-AzPrivateEndpoint

Review only authorised subscriptions and resource groups.

External Validation

Where explicitly authorised, external validation may include:

DNS resolution
TLS inspection
Service banner review
Limited port validation
HTTP response analysis
Public endpoint confirmation

Avoid:

Broad internet scanning
Aggressive service probing
Password attacks
Denial-of-service techniques
Unapproved vulnerability exploitation

External testing must follow the Rules of Engagement.

Attack-Path Analysis

Azure network findings should be analysed as relationships.

Public VM to Internal Resources

Internet
   ↓
Public VM
   ↓
Permissive NSG
   ↓
Compromised workload
   ↓
Access to internal subnet
   ↓
Connected Azure services

Development-to-Production Peering

Compromised development workload
        ↓
Broad VNet peering
        ↓
Production application subnet
        ↓
Sensitive service access

Public Service with Backend Trust

Public application endpoint
        ↓
Backend application service
        ↓
Private database connection
        ↓
Sensitive data exposure

Private Endpoint with Public Access

Private Endpoint
        +
Public network access
        ↓
Service reachable from two paths
        ↓
Unexpected external exposure

Safe Validation Principles

Network validation should use the least disruptive method possible.

Preferred order:

Review Azure configuration.
Confirm resource relationships.
Review effective security rules.
Identify intended business use.
Perform limited authorised connectivity checks.
Avoid unnecessary service interaction.
Record evidence.
Stop if unexpected impact occurs.

Configuration evidence may be sufficient without actively connecting to a production service.

Actions Requiring Explicit Approval

Do not perform the following without specific authorisation:

Modifying NSG rules
Changing route tables
Enabling packet capture
Starting broad port scans
Modifying peering
Changing public network access
Disconnecting VPN or ExpressRoute
Enabling or disabling firewall rules
Modifying DNS
Accessing production management interfaces
Testing denial-of-service conditions

Evidence Collection

For each network finding, record:

Subscription ID
Resource group
VNet name
Subnet name
Address range
NSG name
Rule name
Rule priority
Source
Destination
Port
Protocol
Associated resource
Public IP
Peering relationship
Validation method
Business impact
Recommended remediation

Do not expose sensitive internal IP ranges or architecture details in a public portfolio.

Example Finding

Finding Title

Public RDP Access to Production Virtual Machine

Observation

A production virtual machine is assigned a public IP address, and its Network Security Group permits TCP port 3389 from the internet.

Evidence

Source: 0.0.0.0/0
Destination: Production VM
Destination port: 3389
Protocol: TCP
Action: Allow

Business Impact

An internet-based attacker can directly reach the RDP service.

This increases exposure to:

Credential attacks
Exploitation of unpatched services
Account lockouts
Unauthorised administrative access

Recommendation

Remove the public IP where possible.
Use Azure Bastion or approved private connectivity.
Restrict access to authorised administrative ranges.
Enforce multifactor authentication.
Monitor administrative sign-ins.
Apply just-in-time access controls.
Review the VM’s patch and endpoint-security status.

Risk Rating Considerations

The severity of a network finding depends on:

Internet exposure
Port or protocol
Authentication controls
Resource sensitivity
Network position
Segmentation
Connected resources
Monitoring coverage
Exploitability
Business impact

A public test service may present limited risk.

A public management interface connected to production systems may present critical risk.

Remediation Principles

Common Azure network recommendations include:

Remove unnecessary public IP addresses.
Restrict management access.
Apply least-privilege NSG rules.
Separate production and development networks.
Review VNet peering regularly.
Restrict outbound traffic.
Use Azure Firewall where appropriate.
Enable network logging.
Review route tables.
Use private endpoints for sensitive services.
Disable public network access when private access is required.
Use Bastion, VPN, or ExpressRoute for administration.
Apply just-in-time VM access.
Monitor network-control changes.
Document approved connectivity.

Evidence and Portfolio Outcome

Create an Azure Network Enumeration Report containing:

Environment Overview

Tenant ID
Subscription ID
Authorised resource groups
Azure regions
Testing boundaries

Network Inventory

Document:

VNets
Address spaces
Subnets
NSGs
Route tables
Public IPs
Peerings
Private endpoints
Gateways
Security appliances

Exposure Summary

Identify:

Internet-facing services
Management-port exposure
Broad NSG rules
Public services
Unexpected outbound access

Attack-Path Diagram

Create one safe, hypothetical network attack path.

Example:

Internet
  ↓
Public VM
  ↓
Application subnet
  ↓
VNet peering
  ↓
Shared services

Recommendations

Provide prioritised remediation guidance based on business risk.

Key Takeaways

Azure network enumeration identifies connectivity, exposure, and trust relationships.
A VNet or subnet does not automatically provide security.
Network Security Groups must be reviewed through effective rules.
Public IP addresses are only one source of external exposure.
VNet peering can create lateral-movement paths.
Private Endpoints do not automatically disable public access.
Routing, DNS, and gateways influence actual network reachability.
Configuration review should come before active validation.
Network findings should be evaluated as connected attack paths.
All testing must remain authorised, controlled, and non-disruptive.

Knowledge Check

What is the purpose of an Azure Virtual Network?
What is the difference between a VNet and a subnet?
How does NSG rule priority work?
Why should effective security rules be reviewed?
What risks can arise from broad VNet peering?
What is the difference between a Private Endpoint and a Service Endpoint?
Why can public access remain possible after a Private Endpoint is configured?
What role do route tables play in Azure connectivity?
Why does Azure Bastion not automatically remove all management exposure?
What is the safest order for validating a network finding?

Next Lesson

➡️ Lesson 05 — Azure Virtual Machines

In the next lesson, you will examine Azure Virtual Machine architecture, public exposure, authentication, disk security, extensions, managed identities, metadata access, administrative controls, and common authorised attack paths involving Azure compute workloads.