Pods Without Borders: Lateral Movement in Azure Kubernetes Service

Pods Without Borders: Lateral Movement in Azure Kubernetes Service

Speakers: Nishaanth Guna, Senior Consultant, MDSec

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=ECNOXCe034c

Overview

Nishaanth Guna, a senior security consultant at MDSec, presented a series of real-world attack scenarios drawn from assumed-breach assessments against large-scale Azure Kubernetes Service (AKS) environments across banking institutions and critical infrastructure. The talk demonstrated how weak or absent network policies in AKS clusters can be systematically exploited for data exfiltration, tool staging, lateral movement to domain controllers across subscriptions, and privilege escalation via over-permissioned kubelet identities. Far from theoretical, every scenario came from production engagements where clients believed their environments were secure — and were often more upset about the findings than grateful for them.

Background

▶ Watch: First objective: testing egress from pods — Azure Firewall returns HTTP 470 b... (4:00)

The Kubernetes security assessment landscape has shifted significantly. Where organizations once requested basic configuration reviews — running tools against YAML files for a one-to-two-day engagement — clients are now increasingly requesting assumed-breach scenarios to understand worst-case impact from a compromised pod. This shift reflects growing awareness that configuration compliance alone doesn't capture the real-world risk of Kubernetes deployments.

Network policies in Kubernetes control ingress and egress traffic at the pod level. By default, Kubernetes ships with no network policies — all pod-to-pod and pod-to-external communication is unrestricted. Even installing network policy engines like Calico or Cilium (the two most commonly used add-ons in AKS) doesn't generate any policies automatically; creating and maintaining policies is entirely the administrator's responsibility.

Azure introduces additional complexity. AKS supports three network policy engines — Calico, Cilium, and Azure Network Policy Manager — but critically, Azure does not support cluster-wide network policies. Every namespace must have its own independent set of ingress and egress policies, dramatically increasing the operational burden and the likelihood of gaps. Network configuration can use either overlay CNI or host networking, with the latter being necessary when pods need to communicate with other Azure VNets.

Key Findings

▶ Watch: Fastly CDN allowlist enables apt update — Debian package repos route through ... (8:00)

Egress Bypass via Azure IP Ranges

Even in environments where Azure Firewall was deployed to block outbound traffic (returning HTTP 470 status codes for unauthorized destinations), Guna discovered that traffic to Azure's own IP ranges was implicitly trusted. By hosting a storage blob in their own Azure subscription, the team exfiltrated files directly from within containers to external storage, completely bypassing the firewall. The Azure Firewall only inspected traffic destined for the internet — traffic routed to Azure service endpoints took a direct path.

Tool Staging via Allowlisted CDN Networks

Bringing offensive tools into hardened containers required creative approaches. The team discovered that Fastly CDN was allowlisted because the organization used Fastly for a legitimate purpose. The unintended consequence: deb.debian.org routes through Fastly's CDN network, meaning apt update and apt install worked perfectly — allowing installation of arbitrary tools inside production containers. Similarly, GitHub was allowlisted for developer access, enabling tools to be pulled via git clone.

Lateral Movement to Domain Controllers and Tier-0 Assets

The most devastating finding involved network reachability from within AKS pods to the broader corporate network. By examining Azure resources visible within the cluster — route tables, hubs, NSGs — Guna extracted internal IP ranges and began scanning. The results were staggering: open ports on nearly every subnet scanned, with reachability to SMB, LDAP, and other domain controller services across different subscriptions. Password spraying against these discovered services succeeded, confirming not just network reachability but actual authentication against tier-0 assets — domain controllers that were supposed to be completely isolated from the Kubernetes environment.

In a separate engagement, the team found just two live IPs from within a pod — a router and a Linux machine, both completely outside the pod network and Kubernetes perimeter. The developers were "really surprised" that the router was reachable from within the cluster.

Kubelet Identity Privilege Escalation

By default, AKS pods can reach the metadata IP (169.254.169.254) to request tokens for the kubelet's managed identity. While 70-80% of the time these identities have no meaningful permissions (or just ACR Pull for container image retrieval), Guna found several cases of dangerous over-permissioning:

• A kubelet identity with Contributor role on a different subscription entirely, likely from a reused Terraform script.
• A kubelet identity with Virtual Machine Contributor role — traced to Microsoft's own documentation recommending this permission — which enabled code execution on all VMs in the environment.

Cross-Namespace Database Access

When network policies prevented external egress, Guna pivoted to cross-namespace lateral movement within the cluster. Weak network policies combined with default credentials on a Keycloak identity federation database yielded read and write access to all clients' password hashes, MFA seeds, and session data — impacting not just the assessed organization but their downstream customers.

Detection Evasion with BusyBox and Netcat

In multiple production environments, BusyBox containers were deployed (either forgotten by developers or maintained for legitimate use). BusyBox ships with netcat pre-installed, which can be abused for reverse shells and port scanning. Critically, Guna noted that netcat-based port scanning did not trigger Microsoft Defender alerts, while Nmap scans were immediately flagged as network scanning activity. This detection gap means that an attacker who avoids well-known tools and sticks to utilities already present in production containers can conduct extensive reconnaissance without generating a single alert.

Client Resistance to Remediation

Guna candidly shared that one client was "pissed" at the findings and initially attempted to avoid remediation, arguing that fixing the issues would require a full architectural rework of their Kubernetes infrastructure. After extended back-and-forth discussions, the client agreed to implement basic monitoring and DNS-based traffic blocking — insufficient from Guna's perspective, but better than nothing. The engagement typically lasted three to four weeks with two consultants working in parallel. This resistance pattern highlights a structural challenge: organizations invest in assumed-breach testing but then balk at the architectural changes the results demand. The typical assessment runs two to four weeks minimum with the engagement scope and complexity driving the timeline.

Demo / Proof of Concept

▶ Watch: Password spraying from a pod succeeds against tier-0 domain controller assets (12:00)

Guna presented screenshots from actual engagements (with client details redacted) showing:

• The curl command used to exfiltrate files to an attacker-controlled Azure storage blob.
• The exfiltrated file appearing in the storage blob console.
• Nmap output showing open ports across corporate subnets reachable from within pods.
• Successful password spray results against domain controllers.
• The Keycloak database contents with password hashes and MFA seeds.

Network architecture diagrams illustrated each attack path, showing how traffic flowed around Azure Firewall via Azure service endpoints and how pods reached corporate networks through VNet peering and site-to-site VPN connections that lacked pod-level network policy restrictions.

Defensive Implications

▶ Watch: Cross-namespace attack yields read/write on Keycloak database with all client... (18:00)

• Implement explicit deny-all egress network policies in every namespace. AKS's lack of cluster-wide network policy support means this must be done per-namespace, but it's the only way to prevent unrestricted outbound communication.
• Do not implicitly trust traffic to cloud provider IP ranges. Azure Firewall's inability to inspect traffic to Azure service endpoints creates a blindspot that attackers will exploit for exfiltration via storage blobs.
• Audit CDN and service allowlists for unintended consequences. Allowlisting Fastly means allowlisting Debian package repositories. Allowlisting GitHub means allowlisting arbitrary tool downloads. Apply principle of least privilege to network allowlists.
• Restrict metadata API access. Block pod access to 169.254.169.254 unless explicitly required, and audit kubelet identity permissions for over-provisioning — especially Contributor and VM Contributor roles.
• Ensure ACR repositories contain only images relevant to each cluster. If production and staging images share an ACR, ACR Pull permissions leak cross-environment access.
• Remove BusyBox containers from production. If they must remain, understand that netcat provides reverse shell and scanning capabilities that evade Defender detection.
• Enforce DNS monitoring despite the volume challenge. DNS-based exfiltration and C2 communication are viable when all other egress is blocked.
• Apply Azure Policy across all clusters to enforce baseline security configurations consistently.
• Test with assumed-breach scenarios, not just configuration reviews. Multiple clients in these engagements had passed configuration reviews but failed spectacularly under adversarial testing.

Key Takeaways

• AKS clusters with missing or incomplete network policies provide unrestricted lateral movement — not just within the cluster, but to domain controllers, routers, and tier-0 assets across the corporate network.
• Azure Firewall can be bypassed for exfiltration by routing traffic to attacker-controlled Azure services (storage blobs) via implicitly trusted Azure IP ranges.
• CDN and service allowlists create unintended ingress paths for tool staging, including package managers and Git repositories.
• Kubelet identity over-permissioning is common, often caused by Terraform script reuse or following Microsoft's own documentation recommendations.
• Netcat in BusyBox containers evades Defender detection while Nmap triggers immediate alerts — defenders should not assume their detection covers all scanning tools.
• Clients often resist fixing these issues, citing the need for full architectural rework. Persistent engagement is required to drive remediation.

About the Speaker(s)

Nishaanth Guna (Nish) is a senior security consultant at MDSec, specializing in cloud-native and Kubernetes security assessments. His work spans assumed-breach scenarios against banking institutions, critical infrastructure, and large enterprises. He has extensive hands-on experience with AKS, network policy bypass, and cloud-to-on-premise lateral movement techniques.