AWS Lateral Movement via Kubernetes Service Account Identity Exploitation

This threat involves the exploitation of Kubernetes service account (SA) identities within Amazon EKS environments. Attackers leverage the EKS IAM Roles for Service Accounts (IRSA) feature, where a projected Kubernetes token is exchanged for short-lived AWS IAM credentials via the 'AssumeRoleWithWebIdentity' API. Once an adversary gains control of a pod or a compromised service account token, they use the resulting IAM session to move laterally from the containerized environment to the AWS control plane.

Observed activity includes automated reconnaissance, unauthorized access to secret management stores (AWS Secrets Manager/Parameter Store), and modifications to IAM configurations or compute instances. Defenders should focus on identifying sessions where the initial web identity token exchange is immediately followed by a high volume of non-routine administrative API calls, distinguishing this from standard pod traffic. The scope of this threat encompasses any AWS workload utilizing IRSA that is susceptible to unauthorized token use off-cluster or within the pod.

Attack Chain

1. Initial access: Adversary gains execution capability within a Kubernetes pod, often via exploit of a web application or misconfigured service.
2. Credential acquisition: Adversary locates the projected Kubernetes service account token, typically mounted at /var/run/secrets/eks.amazonaws.com/serviceaccount/token.
3. Token exchange: Adversary uses the service account token to call the 'AssumeRoleWithWebIdentity' API, obtaining short-lived AWS IAM session credentials.
4. Reconnaissance: Adversary uses the obtained IAM session to call discovery APIs such as 'ListRoles', 'ListUsers', or 'ListBuckets' to map the AWS environment.
5. Credential access: Adversary accesses sensitive configuration data, including 'GetSecretValue' from AWS Secrets Manager or 'GetParameters' from Parameter Store.
6. Persistence: Adversary utilizes the session to perform IAM modifications, such as 'CreateAccessKey' or 'AttachRolePolicy', to ensure continued access.
7. Impact: Adversary achieves final objectives, such as data exfiltration from S3 buckets, code manipulation in Lambda, or full environment compromise.

Impact

Successful exploitation allows attackers to bypass Kubernetes-level security controls and gain significant privileges within the AWS account. This can result in the compromise of sensitive credentials, unauthorized modification of infrastructure, and potential exfiltration of proprietary data or intellectual property. The threat specifically impacts organizations running EKS with IRSA where service accounts are over-privileged or lack sufficient monitoring of control-plane activity.

Recommendation

1. Implement the detection logic described in the provided ES-QL rule to correlate 'AssumeRoleWithWebIdentity' events with subsequent high-impact administrative API calls.
2. Review AWS CloudTrail logs for unexpected usage of IRSA-issued session keys originating from IP addresses or ASNs outside of the EKS cluster's VPC or NAT gateways.
3. Enforce the principle of least privilege for IAM roles associated with service accounts; audit and restrict the policies attached to these roles to the absolute minimum required permissions.
4. Strengthen OIDC trust conditions by utilizing 'sub' and 'aud' claims to restrict role assumption to specific, verified Kubernetes namespaces and service accounts.
5. Conduct periodic audits of EKS audit logs to detect anomalous 'exec' activity or unauthorized secret access attempts within the cluster.