Abuse of Amazon EKS Access Entries for Persistent Backdoor Establishment

Adversaries possessing sufficient AWS IAM permissions (eks:CreateAccessEntry and eks:DeleteAccessEntry) are leveraging Amazon EKS access entries to establish long-term persistence in Kubernetes clusters. By creating an access entry linked to their own IAM principal with high-privilege cluster-admin permissions, attackers can interact directly with the Kubernetes API to deploy backdoors, such as privileged ServiceAccounts, ClusterRoleBindings, or unauthorized DaemonSets. Once these persistent RBAC objects are established, the attacker deletes the EKS access entry to remove the CloudTrail audit trail associated with the initial grant. This technique effectively hides the method of entry while maintaining unauthorized control over the cluster through legitimate-looking Kubernetes-level resources. Defenders must monitor for short-duration grant-and-revoke cycles of EKS access entries, as this behavioral pattern is highly characteristic of this persistence strategy.

Attack Chain

1. Attacker gains AWS credentials with eks:CreateAccessEntry and eks:DeleteAccessEntry permissions.
2. Attacker calls CreateAccessEntry via the EKS API to map their IAM principal to a cluster-admin Kubernetes group.
3. Attacker connects to the target EKS cluster using the newly provisioned access.
4. Attacker performs a create operation on Kubernetes resources (e.g., ClusterRoleBindings or ServiceAccounts) to create a persistent backdoor.
5. Attacker executes further malicious commands, such as deploying rogue DaemonSets or accessing sensitive secrets within the cluster.
6. Attacker calls DeleteAccessEntry via the EKS API to remove the association between their IAM principal and the cluster.
7. The EKS access entry is removed, leaving behind the persistent Kubernetes-level backdoor while clearing the primary CloudTrail evidence of access.

Impact

Successful exploitation allows for long-term, stealthy administrative access to EKS-based Kubernetes clusters. Unauthorized access can lead to container escape, exfiltration of sensitive secrets stored in the cluster, and manipulation of workloads. The number of impacted organizations depends on the strength of IAM controls and the visibility into Kubernetes audit logs, which are often siloed from traditional cloud management logs.

Recommendation

• Implement monitoring for the EKS access entry grant-and-revoke cycle using the provided detection logic.
• Review Kubernetes audit logs for create events involving ClusterRoleBindings, RoleBindings, ServiceAccounts, or DaemonSets that coincide with suspicious EKS access entry creation.
• Audit existing Kubernetes RBAC configurations for unauthorized high-privilege service accounts or bindings.
• Restrict eks:CreateAccessEntry and eks:DeleteAccessEntry IAM permissions to only the most trusted administrative identities or automated CI/CD roles.