|
Exploit Public-Facing Application: EKS
AWS Specific Sub-Technique
Other sub-techniques of Exploit Public-Facing Application (8)
| ID | Name |
|---|---|
| T1190.A016 | EC2 Hosted Application Compromise |
| T1190.A020 | EKS |
| T1190.A019 | Overly Permissive VPC Security Groups |
AWS Specific Content
A prerequisite for this technique is that a threat actor has already identified and exploited an application-layer vulnerability in a containerized workload running on Amazon EKS, such as a file upload flaw, command injection, server-side request forgery (SSRF), or a compromised dependency in the software supply chain.
Once inside a running container, the threat actor leverages the access available to that container to perform reconnaissance, access credentials, and move laterally within the cluster environment.
In cases where a threat actor gains initial access to a container, the severity of the compromise depends on the security posture of the container workload. Specifically, containers running as root, with unrestricted access to the underlying node's instance metadata service (IMDS), or assigned overly permissive IAM roles at the note level rather than scoped pod-level roles, may provide the ability to access cluster secrets, retrieve temporary IAM credentials from the node's IMDS, and use those credentials to make API calls against other AWS services including Amazon S3.
This technique is distinct from the existing EC2 Hosted Application Compromise (T1190.A016) sub-technique in that it specifically addresses container orchestration environments where the threat actor pivots through Kubernetes RBAC, service account tokens, and pod-level IAM permissions rather than directly through the EC2 instance.
Detection
AWS Specific Content
You can use the Event history page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for actions such as
eks:DescribeCluster and eks:ListClusters originating from EKS node or ECS task IAM roles. A separate CloudTrail trail will give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions.If Amazon GuardDuty is configured within the AWS account with EKS Protection and GuardDuty EKS Runtime Monitoring enabled, findings such as Backdoor:EC2/C&CActivity.B (compromised node communicating with known C&C infrastructure), PrivilegeEscalation:Kubernetes/PrivilegedContainer (privileged container launched), and UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS (node credentials used from outside AWS) may be generated.
Amazon EKS control plane logging (specifically the audit log type) provides visibility into Kubernetes API server activity. Key indicators of potential compromise include create operations on clusterrolebindings or rolebindings (privilege escalation), get or list operations on secrets (credential access), requests from
system:anonymous or unexpected service accounts, and pod creation in kube-system or other system namespaces by non-system principals.Mitigation
AWS Specific Content
Enforce Pod Security Standards at the namespace level using the built-in Pod Security Admission controller by adding the label
pod-security.kubernetes.io/enforce: restricted to namespace metadata. When applied, the Kubernetes API server rejects any pod that does not meet the restricted profile at admission time, before the pod is scheduled. The restricted profile prevents containers from running as root (runAsNonRoot: true), blocks privilege escalation (allowPrivilegeEscalation: false), drops all Linux capabilities, and disables access to the host network, host PID, and host filesystem. Apply the restricted profile to all production namespaces and use the baseline profile (pod-security.kubernetes.io/enforce: baseline) as a minimum for any namespace. See Pod Security Standards,and Amazon EKS Pod Security Admission.Implement IAM Roles for Service Accounts (IRSA) or EKS Pod Identity rather than relying on the node's instance profile for AWS API access. To limit pod access to IMDS, enforce IMDSv2 with
HttpPutResponseHopLimit set to 1 (the default for EKS Auto Mode). Note that pods running with hostNetwork: true use the host’s network stack and will retain IMDS access for specific pods where required. Apply least-privilege IAM policies scoped to the specific resources each workload needs.Restrict pod creation permissions using RBAC. Principals that do not need to create pods should not have that permission. A principal with unrestricted pod creation may deploy a privileged pod with a hostPath volume mount, effectively gaining root access to the underlying note and any data being processed by other workloads on it.
Implement Kubernetes Network Policies to restrict pod-to-pod communication and egress traffic to only what is required.
Enable comprehensive logging: EKS control plane logging (all log types), VPC Flow Logs, CloudTrail with S3 data event logging, and GuardDuty with EKS Protection and EKS Runtime Monitoring.