Control-Plane Network Isolation Failures

After this chapter you will be able to locate the network boundaries a cloud provider relies on to keep tenants apart — host↔guest channels, the peering and routing fabric, and “trusted” IP ranges — and explain, with real cases, how each one leaks.

The problem

A public cloud is a multi-tenant network. Thousands of unrelated customers run workloads on the same physical fabric, and the provider's job is to make each of them feel alone. It does this with a stack of separators: virtual networks that keep one customer's packets from reaching another's; firewall rules that say which traffic is allowed; and internal control channels — invisible to customers — that the platform uses to provision, configure, and repair their machines.

Those separators leak in recurring ways, and they leak for the same underlying reason every time. The component that enforces a boundary is usually a component the tenant can also talk to. A host-agent endpoint is reachable from inside your guest operating system and trusted by the platform that manages it. A peering attachment joins two networks and relies on an acceptance check that may not be enforced. A firewall rule that trusts a source IP is the boundary and trusts an address an attacker can borrow. Wherever one component does both jobs, every parsing quirk, every missing ownership check, every “internal only” assumption becomes an isolation bug.

Why it matters — and how it differs from a traditional pentest

In a traditional pentest you attack one customer's network. The boundaries you probe — their firewalls, their segmentation, their VPN — belong to the target, and breaking one moves you sideways inside their estate. The blast radius stops at the edge of that customer.

Attacking the provider's network isolation is different in two ways. First, the boundaries you are testing are operated by the provider and shared across every tenant, so a single failure can move you from your tenant into someone else's — or into the provider's own fabric. Second, many of these “boundaries” were never designed to be security controls at all. They are routing conveniences that defenders, and sometimes the provider's own documentation, quietly promoted to the rank of firewall. A pentester who only knows customer-side network testing will look straight past them, because in a single-tenant world they genuinely were harmless.

The methods at a glance

Three techniques, ordered by increasing subtlety.

Technique A · The host↔guest channel

What it is. Every cloud VM you have ever launched is a managed machine, and management means a wire. The provider needs to push configuration, install agents, rotate certificates, and run the occasional repair script. That requires a channel from the provider's control plane straight into your guest operating system — and any channel reachable from inside the guest is reachable by whatever code is running there, including an attacker's.

How it works. What flows over that channel is mostly VM extensions — and extensions are where the convenience turns dangerous.

NetSPI documented the WireServer protocol precisely.^[2]#184 WireServer is plain HTTP on 168.63.129.16 with no authentication — it identifies the caller purely by source IP, so any code that can route a packet to that address from the VM is, as far as WireServer is concerned, the VM's own agent. The only "credential" is the x-ms-version header naming a protocol version the endpoint accepts. That is the entire access-control story, and it is why an unprivileged process on the box can speak the protocol at all.

To see why retrieving the secrets takes several steps, start from the obstacle. The protectedSettings blob is encrypted to a per-VM key called the TenantEncryptionCert. Its private key does not sit in a file you can simply read — WireServer holds it and will only hand it back encrypted. The protocol's intended design is: the guest agent generates its own throwaway "transport" key pair, gives WireServer the public half, and WireServer returns the certificate bundle encrypted (as a PKCS#007 / CMS envelope) to that public key, so only the agent's transport private key can open it. The flaw is that WireServer never checks who supplied that transport public key — so an attacker supplies their own, and WireServer obligingly encrypts the tenant's secrets to the attacker's key. The exchange then unrolls as four requests:

The first request looks like this — note that the only thing resembling a credential is the version header:

GET /machine/?comp=goalstate HTTP/1.1
Host: 168.63.129.16
x-ms-version: 2015-04-05

An earlier, file-based form of the same primitive lives on disk.^[3]#186 On Windows, extension settings sit in RuntimeSettings\<#>.settings as JSON containing a certificate thumbprint and a base64 protectedSettings blob; NetSPI's tooling reads the file, finds the matching certificate in the local store, and decrypts it.

Real-world illustration · WireServing (#255)

WireServing is the cleanest demonstration that a host-agent channel reachable from an unprivileged tenant workload hands out keys to the control plane. Mandiant found that an attacker with ordinary code execution in a pod on an AKS cluster — no root, no host networking, no privileged container — could escalate to the equivalent of cluster administrator purely by talking to 168.63.129.16.^[6]#255 The crucial precondition: the cluster used Azure CNI with the “Azure” network policy, the very component meant to enforce which destinations a pod may reach — and it did not block the host-agent IP.

Frame the win as network (the pod reached the host agent) and credential (it harvested node bootstrap secrets, a far more powerful identity than a scoped workload token). The Kubernetes mechanics — kubelet, the Node Authorizer, CSR auto-signing — are dissected in Chapter 6. And the same WireServer primitive, run against a Microsoft-hosted service VM rather than a customer cluster, is what Wiz weaponised in ChaosDB to pull secrets off Microsoft's own infrastructure; that chain is Chapter 8's to tell in full.

Technique B · The routing & peering fabric

What it is. A cloud provider does not run one network — it runs a planet-scale backbone, and it lets customers attach to it: physically, with dedicated fibre, and logically, with peering between virtual networks. Each attachment is a join between two parties, and each join has a moment where consent and ownership are supposed to be checked. Those moments are the attack surface.

How it works. The routing case is about ownership — does the backbone check that you may announce the prefix you announce? The peering case is about consent — is the accept step enforced where it counts? Two real cases, one of each.

Real-world illustration · Direct Connect route injection (#235)

On 16 May 2024 a route advertised over an AWS Direct Connect public VIF was accepted by AWS without prefix-ownership validation. The observed incident was benign in intent — a customer typo in a public-VIF prefix advertisement — but its effect was real: AWS-originated traffic destined for an external IP was hijacked and blackholed, breaking Let's Encrypt certificate renewals for affected hosts.^[4]#235

The teaching point is the generalisation. If AWS will accept a BGP prefix on a public VIF without checking that the advertiser owns it, the same mechanism used deliberately is a route-injection primitive into AWS's network — interception or denial of AWS-originated traffic toward any prefix you announce. The isolation boundary that failed was the routing boundary; the provider convenience was “you can peer into our backbone”; the detection surface is path anomaly, a traceroute or mtr showing AWS-sourced traffic taking a route it should not. AWS's remediation was process, not patch — improved prefix-ownership validation for public-VIF advertisements.

Real-world illustration · Transit Gateway peering acceptance bypass (#234)

The cleanest “consent boundary bypassed” case in the corpus. Cross-region Transit Gateway peering requires the destination account to call ec2:AcceptTransitGatewayPeeringAttachment. DoiT found that the AWS Console correctly refused to let an account accept a peering it had requested itself — but the API and CLI did not enforce the same rule.^[5]#234

Disclosed by James Sheard of DoiT on 25 July 2024; AWS patched on 7 August 2024. This is a precise callback to Chapter 2's lesson about alternate endpoints: the Console and the API are two implementations of the same operation, and they enforced different rules. Whenever a UI shows a check, ask whether that check lives in the UI or in the service — a control that lives only in the front-end is a suggestion, not a boundary.

Technique C · Soft boundaries — service tags & IP allowlists

What it is. The last technique is not a bug. It is a category error — a thing defenders treat as a security control that the provider only ever built as a routing convenience. This is the chapter's unifying lesson.

How it works. The attack is a network-layer confused deputy: drive a trusted service to make a request on your behalf, and the firewall trusts the service rather than you.

Real-world illustration · Abusing service tags (#259)

Liv Matan of Tenable demonstrated, definitively, that service tags are not a security boundary.^[1]#259 More than ten Azure services let a user control the destination of an outbound request the service makes on their behalf — Application Insights availability tests, Azure DevOps, Azure Machine Learning, Logic Apps, Container Registry, Load Testing, API Management, Data Factory, Action Group, AI Video Indexer, and Chaos Studio among them.

Notably, Microsoft did not patch. Their position: service tags were never intended as a security boundary, and MSRC published updated guidance saying so explicitly, stressing that authentication is still required on the resource.^[7] “The provider fixed the docs, not the product” is itself a teaching point — sometimes the provider's honest answer is “this was never a boundary, and treating it as one was your bug.” A service-tag abuse is the packet-layer twin of the IAM confused deputy from Chapter 3: authorize the principal, not the conduit.

Attacker's checklist

Defender's mirror