Resource Hijacking: Compute Hijacking - EKS

AWS Specific Content

A prerequisite for this technique is that a threat actor has already gained access to a running container within an Amazon EKS cluster or has obtained Kubernetes API credentials with permissions to create or modify workloads.

Threat actors may deploy cryptomining containers within a compromised EKS cluster to hijack compute resources. After gaining initial access through an application-layer vulnerability, the threat actor escalates privileges within the cluster typically by accessing overly permissive service account tokens or creating new cluster role bindings and then deploys pods running cryptomining software.

Threat actors may also modify cluster configuration using mutating admission webhooks, which can inject additional containers or environment variables into pods at admission time, so that newly created pods are compromised at startup. This establishes persistence that survives individual container restarts. The cost of the compute resources is attributed to the compromised account.

This technique is related to the existing Compute Hijacking - ECS (T1496.A006) and Compute Hijacking - EC2 Use (T1496.A008) techniques. The distinction is that EKS compute hijacking involves Kubernetes-specific escalation paths RBAC abuse, cluster role bindings, webhook manipulation that are not present in EC2 or ECS hijacking scenarios.