Cloud segmentation doesn’t break because someone simply “opens a port.” It breaks when reasonable decisions under pressure (fast delivery, interconnection between teams, cost reduction) are chained together and the final result allows lateral movement between systems that, in theory, were isolated. In real incidents, the attacker rarely gets in where you expect; they get in through an exposed point and move through internal routes that no one reviews holistically.
When we talk about VPC/VNet, security groups/NSG, route tables, peering, and separation between environments, the typical problem is not lack of knowledge: it’s lack of cross-validation. An SG rule can be “correct” in isolation, but combined with a 0.0.0.0/0 route, broad peering, or a firewall without inspection, it ends up enabling traffic that was never intended.
What went wrong: the attacker didn’t need to break segmentation, just take advantage of it
A recurring pattern: a “support” service in a less critical environment (for example, a utilities VM, a CI runner, a test instance) becomes reachable from the Internet for convenience. The initial access may be a leaked credential or an exposed panel. From there, the attacker looks for internal connectivity: they don’t need to exploit 0-days if they find network paths that already exist.
In cloud, effective segmentation depends on three aligned layers: routes (what is reachable), filters (SG/NSG/NACL), and topology (peering/transit/hubs). When one of these layers is too broad, the attacker turns a “local” access into a pivot. In enterprise it looks like “noise” at first: failed connections, internal scans, and then successful access to services that were meant only for internal consumption.
The operational consequence is usually not immediate. What’s critical is that, once inside, the attacker moves toward where there is data or control: internal databases, administration APIs, jumps to preproduction environments that share credentials, or even to production if there is connectivity “for convenience.” Poorly designed segmentation not only expands the blast radius: it drastically reduces the time the team has to detect lateral movement.
Routes and peering: the corporate shortcut that creates lateral highways
The most expensive mistake I’ve seen: treating peering (VPC Peering/VNet Peering) as if it were “just a connection” and not an expansion of the reachability domain. If two networks are paired and their route tables allow broad prefixes (for example, the entire corporate network or the entire range of another environment), segmentation becomes subordinate to “having the SG/NSG stop it.” In incidents, that translates into any single-point rules failure becoming cross-environment connectivity.
Another classic: the hub-and-spoke network (with Transit Gateway/Virtual WAN or appliances) is deployed to centralize, but transit between spokes is enabled without an explicit design of “who can talk to whom.” The result is a side effect: a development environment ends up being able to initiate connections to production services through the hub, even though nobody formally requested it.
- Peering between environments for “fast integration”: it is enabled so an app in dev can consume a service in shared-services, and months later that same peering allows exploring internal ranges and reaching pre/production if there are inherited routes.
- Route tables with prefixes that are too large: 10.0.0.0/8 is advertised “to avoid having to keep updating routes,” which breaks any attempt at microsegmentation and makes audits difficult (“everything reaches everything, except exceptions”).
- Implicit transitivity: in hub topologies, the team assumes traffic does not traverse spokes; in practice, a route propagation configuration or a rule on the appliance enables unwanted transit.
Each of these points usually arises from real pressure: reducing time-to-market, avoiding recurring changes, simplifying operations. But the consequence is predictable: when the attacker lands in the “weakest” spoke, they inherit the road map to critical assets.
Security Groups/NSG: “temporary” rules, cross-references, and the perimeter mirage
SG and NSG are powerful, but also easy to degrade over time. The typical degradation is not an openly bad rule, but a set of accumulated exceptions: “we opened this for a test,” “we allow from anywhere because the source changes,” “we reference another team’s SG so it works.” After several iterations, the permission graph stops representing intent and starts representing history.
A particularly dangerous point is cross-references (for example, SG-to-SG) that cross organizational or environment boundaries. In theory they are used to constrain (“only this group can talk to this service”), but in companies with autonomous teams they become opaque dependencies: someone expands the source SG to solve a problem and, without realizing it, expands access to several downstream services.
- Broad inbound rules for administration: allowing RDP/SSH from generic ranges (or worse, 0.0.0.0/0) “because the VPN fails” creates a direct access point to the internal network. Even if the host is “in a private subnet,” the path may exist via NAT, a poorly controlled bastion, or an accidental public IP.
- Unrestricted outbound: fully open egress on low-criticality workloads facilitates exfiltration and C2. In addition, it allows an attacker to reach internal services via existing routes even if inbound is more carefully controlled.
- Duplicate rules between SG/NSG and NACL/UDR: when trying to “compensate” with another layer without a clear model, traceability is lost. In incidents, this translates into hours lost: nobody knows which layer is allowing the traffic.
The real impact: an attacker with a foot inside can use common reconnaissance tools (port scanning, service enumeration, probes to metadata endpoints) and, if connectivity allows it, find internal surfaces that were not monitored as if they were “external.” Failed segmentation turns the “internal” into a non-existent perimeter.
Accidental exposure between environments: when dev and prod share more than you think
Separation between environments often breaks through non-obvious paths: a “temporary” peering, a route exception for a vendor, a shared subnet for tools, or a common service (logging, artifacts, CI/CD) deployed without strict boundaries. In cloud, isolation is not an emergent property: you have to design it explicitly and validate it continuously.
A typical case in corporations: shared-services becomes “no man’s land.” In the desire to centralize (internal DNS, repositories, scanners, proxies, AD/LDAP), it connects to everything. If shared-services is compromised (for example, a utilities VM with irregular patching), the attacker has a privileged springboard: credentials in memory, access tokens, and connectivity to many spokes.
There is also a recurring design mistake: assuming “dev doesn’t matter” because it does not contain sensitive data. In practice, dev often contains secrets (tokens, keys, pipelines with permissions), and also has access to repositories, images, and deployments. If dev can initiate connections to prod (even if it’s to “a specific port”), the attacker turns a cheap intrusion into a bigger incident.
How to do it in practice: validate isolation with connectivity tests and route review, not just by reading individual rules.
- Map real reachability by routes: review route tables/UDR for each subnet and verify which prefixes are advertised via peering/hub. In AWS, check effective routes per subnet and propagation in Transit Gateway if applicable. In Azure, review “Effective routes” per NIC/subnet to detect inherited UDRs or BGP propagation.
- Review effective rules, not declarative ones: identify SG/NSG that reference each other and document the graph. The operational question is not “what does this SG allow?”, but “what real sources can reach this service through existing routes?”.
- Run tests from the inside: from a controlled host in dev, try to reach internal endpoints in pre/prod (administration ports, databases, internal APIs). If there is connectivity, record the path (route + rule) that enables it and decide whether it is intentional or residual.
These validations often uncover “ghost connectivity”: access nobody remembers having requested. Fixing it significantly reduces risk, even without changing anything in the application layer.
Recommendations for corporate environments
Cloud segmentation failures that let an attacker through are usually combinations: broad routes plus unlimited peering, plus SG/NSG rules degraded over time. The attacker benefits from existing connectivity and the fact that many organizations review isolated components, not the complete system.
If you want to reduce lateral movement, focus on validating real reachability: which networks are reachable, by what path (routes/peering/hubs), and what effective rules allow it. Maintaining isolation between environments is not just “having different VPCs/VNets”: it is preventing topology and routes from turning that separation into a label.
Finally, operational discipline: every “temporary” exception in SG/NSG or routes must have an expiration date and an owner. Without that hygiene, segmentation becomes security technical debt, and that debt is exactly what an attacker exploits to move without needing sophisticated techniques.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.