|
EKS Modification - Workload Integrity Degradation
AWS Specific Technique
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 and has obtained Kubernetes API credentials with permissions to modify cluster configuration resources.
Threat actors may modify internal EKS cluster configuration, such as mutating admission webhooks, init containers in pod templates, or ConfigMaps, so that newly created pods are compromised at startup. This establishes persistence that survives individual container restarts and allows the threat actor to move laterally across namespaces as new workloads are deployed. In multi-tenant EKS environments, this technique enables the threat actor to compromise workloads belonging to other tenants within the same cluster.
Detection
AWS Specific Content
Amazon EKS control plane audit logs are the primary detection source for this technique. Monitor for update or patch operations on mutatingwebhookconfigurations, validatingwebhookconfigurations, and configmaps in system namespaces. Monitor for modifications to pod templates in deployments, statefulsets, or daemonsets that add unexpected init containers or volume mounts.
If Amazon GuardDuty is configured with EKS Runtime Monitoring, findings related to unexpected process execution within containers or network connections to malicious IPs may be generated.
This technique does not have unique CloudTrail management event API calls. The lateral movement occurs within the Kubernetes control plane, viewable with EKS control plane audit logging.
Mitigation
AWS Specific Content
Apply least-privilege RBAC policies that restrict access to
mutatingwebhookconfigurations, validatingwebhookconfigurations, and configmaps in system namespaces to only designated cluster administrators. Implement Kubernetes Network Policies to restrict pod-to-pod communication across namespaces, limiting communication within the cluster.In multi-tenant EKS environments, use namespace-level isolation with dedicated service accounts, network policies, and RBAC boundaries per tenant. Consider separate clusters for workloads with different trust levels.
Implement IAM Roles for Service Accounts (IRSA) or EKS Pod Identity to scope AWS API permissions to individual workloads rather than relying on node-level IAM roles. This limits the blast radius when a single workload is compromised.