The K8's Attack Surface

In our previous blog, The K8s Attack Surface: An Examination of a Growing Threat, we demonstrated how an attacker breaches a Kubernetes (K8s) pod-to-node barrier to gain root access. Chaining a remote exploit like React2Shell (CVE-2025-55182) with a local privilege escalation (LPE) vulnerability like Copy Fail (CVE-2026-31431) lets an attacker bypass the application's initial security layer, break out of the container, and land directly on the host node with full administrative privileges.

A compromised worker node acts as a launchpad to the rest of the cluster. Once an attacker has root access, they pivot to full cluster enumeration. By mapping the infrastructure, harvesting cluster-wide credentials, and manipulating control-plane APIs, the attacker can exfiltrate secrets or establish long-term persistence.

Once an attacker reaches the worker node, subsequent control-plane enumeration and lateral movement generate observable network activity. Unlike local execution, these API requests and east-west communications are visible to out-of-band platforms like ExtraHop RevealX, enabling detection of cluster reconnaissance, credential harvesting, and attempts to exfiltrate Kubernetes secrets or other sensitive data.

Analyzing these Linux vulnerabilities alongside recent kernel escalations maps the exact steps required to establish pod access, break container boundaries, and enumerate infrastructure post-compromise. This technical analysis demonstrates why out-of-band monitoring with ExtraHop RevealX provides the essential visibility needed to uncover the API anomalies and east-west traffic patterns that accompany such exploit chains.

A Compromised K8s Worker Node - The Attacker’s Blast Radius

When an attacker gains root access to a K8s worker node, the resulting blast radius (Image 1) immediately encompasses the host’s cryptographic identity and local administrative boundaries. Although control-plane admission controls limit a node's scope, a compromised host still gives an attacker significant access to the surrounding cluster.

Taking control of a node grants an attacker immediate access to three key assets:

• The Kubelet Identity: Client certificates and kubeconfig that authenticate the Kubelet daemon to the primary API server.
• Local Container Runtimes: Provides the attacker direct socket access (such as containerd.sock) to inspect, alter, or execute commands inside any container on the host, bypassing the API server.
• Neighboring Pod Secrets: Access to every secret, token, and ConfigMap mounted by any pod currently scheduled or running on that specific node.

The Reconnaissance Phase: Extracting Cluster Credentials

After securing host root access, the attacker searches the local system for high-privilege tokens. An attacker can harvest these credentials to probe the cluster API through four phases:

1. Extract the Kubelet Kubeconfig
2. Cluster Enumeration and RBAC Discovery
3. Harvesting Kubernetes Secrets
4. Escape to the Cloud Provider

Phase 1: Extract the Kubelet Kubeconfig

Prerequisite: Root access to the host node.

Objective: Steal the worker node’s identity to open an unauthorized session with the API server.

The Kubelet must authenticate to communicate with the API server. Reading /var/lib/kubelet/kubeconfig exposes the node’s client certificate data or bearer tokens (system:node:node-name). By stealing this file, an attacker can masquerade as a legitimate node, pivoting from local host exploitation to direct control-plane manipulation from outside the container.

To authenticate to an Amazon EKS cluster, an attacker first needs four key details: the API server endpoint, the CA certificate, the authentication configuration, and the cluster name (Image 2). Once authenticated, the adversary initiates cluster-wide enumeration by harvesting EKS credentials to map worker nodes and fingerprint host operating systems and runtimes. Although these activities may mimic standard administrative functions, they constitute a systematic reconnaissance phase designed to map cluster topology and uncover exploitable software versions. A successful execution validates that the hijacked session possesses the necessary RBAC permissions to list nodes and retrieve sensitive environment details.

With these details, the attacker can request an authentication token to start querying the API server for secrets, ConfigMaps, and cluster metadata. After authenticating, running the curl command essentially pulls the same information as kubectl get nodes, revealing all connected nodes for further lateral movement (Image 3).

Phase 2: Cluster Enumeration and RBAC Discovery

Prerequisite: Read access to the Kubelet runtime directory.

Objective: Enumerate namespaces, identify pods of interest, and dump secrets.

By default, K8s mounts secrets, config maps, and tokens directly into running pods using memory-backed filesystems (tmpfs). But on the host node itself, the Kubelet undercuts this security by storing those same secrets in plain text inside its runtime directory.

Attackers exploit this gap to move laterally. Once they compromise a worker node, they simply scrape the API for service account tokens belonging to any other pod on that machine. Land on a node shared with a highly privileged pod – like an ingress controller, security agent, or a CI/CD runner-and the attacker instantly steals its identity.

Using an authenticated bearer token and the cluster CA certificate, the attacker queries the Kubernetes API to enumerate namespaces and workloads (Image 4), identifying the threat-research namespace and its running react2shell pod (Image 5). Following the namespace enumeration, the attacker identifies the other pods, services, deployments, and ConfigMaps for the namespace (Images 6-13).

Phase 3: Harvesting Kubernetes Secrets

Prerequisite: Authorization to read Secrets or access to projected pod credentials on the compromised node.

Objective: Collect application credentials and service account tokens for lateral movement.

Once reconnaissance identifies high-value namespaces and workloads, the attacker begins collecting credentials. Kubernetes stores Secrets as API objects and projects them into running pods through memory-backed volumes. If the compromised identity possesses permission to read Secrets, the Kubernetes API returns the entire Secret object, including base64-encoded values.

The attacker enumerates Secrets within the target namespace (Images 14, 15) before retrieving specific Secret objects of interest. Although command-line processing may display only field names or selected attributes, the complete Secret—including usernames, passwords, certificates, or API keys—has already been returned to the authenticated client (Images 16, 17). These credentials can then be used to access dependent applications, databases, or external services.

Phase 4: Escape to Cloud Provider

Prerequisite: Host access on a cloud-managed Kubernetes worker node.

Objective: Leverage the node's cloud identity to expand beyond Kubernetes.

Following successful compromise of a worker node, the attacker evaluates whether the underlying cloud instance metadata service (IMDS) is accessible (Image 18). Managed Kubernetes worker nodes frequently possess cloud identities that permit interaction with cloud-native services such as object storage, container registries, load balancers, and key management systems.

If the cloud provider's metadata service is reachable and the node's IAM role is over-privileged, the attacker can inherit the node's cloud identity and extend operations beyond the Kubernetes cluster into the surrounding cloud environment. Conversely, if IMDSv2 enforcement is enabled (Image 19), unauthenticated metadata requests are rejected, reducing the likelihood of direct metadata abuse.

Table 1: Instance metadata response codes.

Expanding Beyond the Kubernetes Cluster: If a compromised worker node carries an overly permissive IAM role, an attacker can hijack that identity to interact directly with your cloud provider’s management APIs.

Depending on the permissions assigned to the instance profile, an attacker could treat your AWS environment like an open buffet. A compromised role could allow them to:

• Dump object storage in Amazon S3.
• Download or poison container images in Amazon ECR.
• Extract configuration secrets from AWS Systems Manager Parameter Store.
• Harvest encryption key metadata from AWS KMS.
• Access managed databases and backups through Amazon RDS.

A poorly configured IAM role might even grant access to other EKS clusters, allowing the attacker to harvest authentication tokens for completely different environments. Without strictly enforced least-privilege policies, a single compromised worker node can hand an attacker the keys to your entire cloud infrastructure.

In this specific incident, cloud-level access controls held the line, and the attacker was completely blocked from expanding their reach into the broader cloud resources.

Overcoming Node Restriction Controls

To prevent a compromised worker node from taking over a cluster, K8s environments enforce the NodeRestriction admission plugin. This control operates on the principle of workload isolation: a node is quarantined, permitted only to modify its own Node API object and the specific Pod objects bound to it.

Although the write capability is locked down, NodeRestriction does not limit read patterns equally across all resources. The matrix below contrasts what an attacker can still map out using a hijacked node identity versus what the cluster actually blocks.

Table 2: Node Identity Permitted and Restricted Actions

Adversarial Pivot: Attackers blocked by NodeRestriction can turn the compromised host into a reconnaissance post to move laterally. They scan for pods running with hostNetwork: true, which bypass standard container network isolation and share the host’s network namespace. These pods expose a pathway between the restricted container environment and the underlying host or cloud infrastructure. The attacker also searches for service accounts belonging to cluster monitoring tools that inadvertently possess cluster-wide GET or LIST privileges.

Defensive Architectures: Mitigating Post-Escape Enumeration

Once a container escape happens, cluster survival depends entirely on blast radius mitigations. Defending the cluster requires severing the pathways connecting host-level access to the control plane.

• Strict Node Tainting and Workload Separation: Isolating sensitive components (like payment processing or administrative tooling) into dedicated node pools using taints and tolerations prevents attackers from harvesting high-privilege tokens on compromised general-purpose nodes.
• Implement IMDSv2 with Hop-Count Restrictions: Requiring session tokens for cloud metadata endpoints and restricting the network hop count to one. This prevents containers from reaching the cloud IAM layer if the host's bridge networking configuration is exposed.
• Enforce Least Privilege RBAC for System Add-ons: Third-party charts (such as logging, tracing, or service meshes) often introduce risk. Auditing their associated cluster roles to eliminate wildcards (*) grants and excessive permissions (such as nodes/proxy read access) closes the loopholes attackers exploit to bypass logging mechanisms.

Conclusion: The Illusion of Container Isolation

The rapid escalation from a single application vulnerability to a full-scale cluster compromise underscores the difficulty for defenders. Standard container boundaries are not impenetrable security barriers. Chaining a pre-authentication RCE like React2Shell with a kernel-level LPE like Copy Fail dissolves pod isolation security. The compromised worker node becomes a staging ground loaded with harvested Kubelet identities, exposed cloud metadata, and lateral pivot points.

Defending against these sophisticated post-escape enumeration tactics requires a fundamental shift to an assume-breach mentality at the node level. Implementing strict workload separation, crippling IMDS exposure, and aggressively scoping RBAC are baseline requirements, not optional hardening steps.

Preventative controls alone cannot stop a highly motivated attacker from probing the edges of their compromised access. Attackers will map the cluster topology. They will move laterally. When they do, they generate distinct, anomalous traffic patterns. Recognizing that node compromise is often a matter of "when" rather than "if," maintaining an independent, tamper-proof line of visibility becomes the ultimate requirement for securing modern K8s environments.

ExtraHop RevealX: Detecting Post-Compromise Kubernetes Activity

Container escape marks the point where endpoint-centric defenses begin to lose visibility. Once an attacker gains root access to a worker node, they can tamper with host logging, disable local security tooling, or execute directly against the Kubernetes API using stolen credentials. RevealX maintains visibility because it derives detections from decrypted network traffic and API communications rather than software executing on the compromised host. This architectural separation allows RevealX to observe the attack chain even when the underlying node can no longer be trusted.

Detecting Control Plane Enumeration

Following theft of the Kubelet kubeconfig or a service account token, attackers begin interacting directly with the Kubernetes API server. Rather than issuing the predictable watch and heartbeat requests associated with normal node operation, reconnaissance generates bursts of authenticated GET and LIST operations targeting namespaces, nodes, pods, deployments, ConfigMaps, and Secrets. RevealX identifies these deviations by baselining expected API communication patterns and surfacing authenticated enumeration that differs from established Kubernetes behavior.

Identifying Cluster Reconnaissance

Once authenticated, attackers rapidly inventory the environment to understand cluster topology and identify high-value workloads. Enumeration of namespaces is typically followed by requests for pods, services, deployments, ConfigMaps, and Secret metadata across multiple namespaces. Although each request is individually legitimate, the sequence and breadth of these queries form a reconnaissance pattern rarely exhibited by production workloads. RevealX correlates these API interactions into a single behavioral narrative instead of treating them as isolated events.

Detecting Secret Access and Credential Harvesting

Credential collection represents a measurable transition from reconnaissance to exploitation. RevealX observes authenticated requests retrieving Kubernetes Secret objects and correlates them with the originating workload, node identity, and subsequent communications. When Secret retrieval is immediately followed by new authenticated sessions, access to previously unseen services, or additional control-plane activity, RevealX links these events into a coherent attack progression rather than independent alerts.

Monitoring East-West Expansion

After establishing a foothold, attackers typically pivot toward additional workloads or infrastructure within the cluster. RevealX continuously analyzes east-west communications between namespaces and node pools, identifying unexpected service discovery, abnormal connection patterns, and communications that violate established workload relationships. These behavioral detections expose lateral movement even when traffic occurs entirely inside the Kubernetes cluster.

Observing Cloud Identity Expansion

In cloud-managed Kubernetes environments, compromise often extends beyond the cluster itself. When a node's cloud identity is used to access cloud-native services, RevealX provides visibility into those outbound communications, correlating Kubernetes API activity with subsequent interactions involving cloud management services, object storage, container registries, or other infrastructure APIs. This correlation enables defenders to recognize when an initially localized node compromise begins expanding into the surrounding cloud environment.