# New attack vectors in EKS

EKS Pod Identity Agent traffic on 169.254.170.23 is plaintext HTTP, so a hostNetwork pod can sniff JWT tokens and IAM credentials of co-located pods.

- Payout: Research
- Severity: high
- Program: Amazon EKS
- Credited: Wiz Research
- Disclosed: 2024-02-09
- Write-up quality: 7/10
- Original: https://www.wiz.io/blog/new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-new-attack-vectors-emerge-via-recent-eks-access-entries-and-pod-identity-features
- Tags: domain:cloud impact:internal-access impact:privesc kind:research platform:threat-intel sev:high tech:aws tech:kubernetes technique:chained technique:recon vuln:info-disclosure vuln:privilege-escalation

**Target:** EKS Pod Identity Agent endpoint 169.254.170.23 and EKS Access Entries API
**Root cause:** The Pod Identity Agent exchanges JWT tokens for IAM credentials over unauthenticated plaintext HTTP on a link-local endpoint reachable from any pod sharing the host network namespace; Access Entries API also lets IAM principals with CreateAccessEntry/AssociateAccessPolicy self-grant cluster-admin.
**Steps:**
1. Compromise or deploy a pod with hostNetwork: true on a worker node.
2. Run `tcpdump -A -ni any -s0 "host 169.254.170.23" -w output.cap` to capture traffic to the Pod Identity Agent.
3. Inspect pcap: HTTP GET from co-located pod contains plaintext JWT in Authorization header; response contains AccessKeyId/SecretAccessKey/Token.
4. Export captured credentials as AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN and call AWS APIs as the pod's IAM role.
5. Cloud-to-cluster: with eks:CreateAccessEntry + eks:AssociateAccessPolicy, run `aws eks create-access-entry` then `aws eks associate-access-policy --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy` to gain cluster-admin.
**How found:** Reasoned about the Pod Identity Agent architecture (DaemonSet, link-local HTTP endpoint) and hypothesized that hostNetwork pods share the namespace and can passively capture the token/credential exchange; validated with tcpdump and Wireshark.
**Exploitation:** Attacker with a hostNetwork pod sniffs the plaintext JWT/credential exchange between co-located pods and the Pod Identity Agent, then uses the harvested temporary IAM credentials to access S3/DynamoDB and other cloud resources, enabling cluster-to-cloud lateral movement and repudiation.
**Escalation:** Harvested pod-identity credentials can be chained with IRSA/Pod Identity roles of other pods on the node; conversely compromised IAM principals with CreateAccessEntry/AssociateAccessPolicy escalate to cluster-admin and then abuse pod identities.
**Insight:** Any pod with hostNetwork:true shares the node's network namespace and can passively sniff link-local metadata/credential endpoints (169.254.170.23, 169.254.169.254) — check for hostNetwork pods and plaintext credential exchanges rather than only IMDS SSRF.