How Azure Networking Quietly Enables Lateral Movement

Thu, 30 Apr 2026 00:00:00 +1100

Most Azure estates don’t feel flat.

They have hubs, spokes, subnets, and diagrams that suggest intent and order. On paper, things look segmented. Contained. Reasonable.

Yet once something unwanted lands inside, movement often feels frictionless like walking through an open-plan office where every door politely steps aside.

That isn’t because someone forgot a firewall rule.
It’s because Azure networking is doing exactly what it was designed to do.

The Mental Model

Common assumption:
Internal Azure networks are segmented unless you explicitly connect them.

Why it breaks:
Azure optimises for reachability, symmetry, and operational correctness. Once you create connectivity, Azure assumes you meant it, and it works hard to preserve stable, symmetric paths between everything involved.

East–west movement isn’t an attacker trick.
It’s an architectural outcome.

How It Really Works

Let’s talk about behaviour, not marketing diagrams.

Symmetric hub routing is the real enabler

Azure VNet peering itself is non‑transitive. On its own, it doesn’t flatten anything.

Transitivity appears when architects (often correctly, at the time):

Centralise routing through a hub
Introduce Azure Firewall or NVAs
Apply default UDRs (0.0.0.0/0) from spokes to the hub
Expect symmetric paths for reliability and troubleshooting

At that point, the hub stops being a boundary and becomes a routing fabric.

Once symmetry is restored, spoke‑to‑spoke reachability isn’t an accident it’s the inevitable result of a design optimised for correctness.

Azure preserves paths aggressively

Azure system routes and platform behaviour:

Prefer the most specific prefix
Preserve return paths when they exist
Avoid blackholing traffic unless explicitly instructed

This is excellent for application uptime.
It’s also excellent for internal exploration.

If a packet can get there and come back, Azure will try very hard to keep that path stable.

A Hard Admission

I’ve implemented symmetric hub routing myself more than once.

It solved real problems:

Predictable traffic flows
Fewer asymmetric failures
Easier troubleshooting at 2am

What I underestimated wasn’t the firewall or the rules.
It was how completely Azure erased any remaining sense of internal boundary once symmetry was restored.

The design was correct.
The blast radius was just larger than I intended.

Real‑World Impact

This isn’t theoretical. It changes outcomes.

Design
Symmetric hub routing collapses routing domains. Once in a spoke, the rest of the estate becomes discoverable by default.

Reliability
The same paths that propagate traffic propagate failures security incidents and outages share infrastructure.

Security
Lateral movement becomes a question of which routes exist, not which controls failed.

Cost
Broad east–west flows quietly consume firewall throughput and bandwidth even during normal operation.

Practical anchor:
This should change when and how freely, you restore routing symmetry in your designs.

Implementation Example

The “standard” hub‑and‑spoke pattern

flowchart LR SpokeA --> Hub SpokeB --> Hub Hub --> SpokeA Hub --> SpokeB Hub --> SharedServices SharedServices --> Hub

No direct peering between spokes.
Yet full spoke‑to‑spoke reachability exists via the hub.

The UDR that makes it inevitable

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


resource spokeRouteTable 'Microsoft.Network/routeTables@2023-09-01' = {
 name: 'rt-spoke-default'
 location: resourceGroup().location
 properties: {
 routes: [
 {
 name: 'default-to-hub'
 properties: {
 addressPrefix: '0.0.0.0/0'
 nextHopType: 'VirtualAppliance'
 nextHopIpAddress: '10.0.0.4' // Hub firewall or NVA
 }
 }
 ]
 }
}

This single route:

Restores symmetry
Makes the hub a transit router
Removes natural routing boundaries between spokes

Operationally clean.
Architecturally expansive.

Gotchas & Edge Cases

Peering flags don’t save you
AllowForwardedTraffic = false doesn’t help once routing is reintroduced elsewhere.
Gateway transit magnifies the effect
Shared gateways flatten routing domains even further.
Private Endpoints don’t change this
They reduce exposure, not reachability. Routes still define movement.

Guidance for Future Designs

This isn’t about banning hubs or symmetry. It’s about intent.

Treat routing symmetry as privileged

In Azure, symmetric routing is not neutral.
It is a privileged capability that should be granted deliberately and narrowly.

If symmetry isn’t required, let paths fail closed.

Design routing domains, not just VNets

VNets and spokes are implementation details.
Routing domains define blast radius.

If two workloads don’t need to talk both ways, they don’t belong in the same routing domain regardless of how tidy the diagram looks.

Make hubs earn their reach

Centralised hubs trade convenience for scale including the scale of failure.

Every east–west path enabled by a hub should be justified.
“Operational simplicity” alone is not a sufficient reason.

Defer symmetry, don’t default to it

Today, I treat symmetric hub routing as an optimisation to be earned late not a baseline assumed early.

That single shift changes how networks age under pressure.

🍺

Brewed Insight: Azure rewards correctness and connectivity.
Restraint is something you have to design against the platform on purpose.

Azure VNet on Brewed in the Cloud by Chris Hailes