{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/products/elastic-kubernetes-service/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Elastic Kubernetes Service"],"_cs_severities":["medium"],"_cs_tags":["cloud","kubernetes","persistence"],"_cs_type":"advisory","_cs_vendors":["Amazon"],"content_html":"\u003cp\u003eAdversaries possessing sufficient AWS IAM permissions (\u003ccode\u003eeks:CreateAccessEntry\u003c/code\u003e and \u003ccode\u003eeks:DeleteAccessEntry\u003c/code\u003e) 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 \u003ccode\u003eServiceAccounts\u003c/code\u003e, \u003ccode\u003eClusterRoleBindings\u003c/code\u003e, or unauthorized \u003ccode\u003eDaemonSets\u003c/code\u003e. 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains AWS credentials with \u003ccode\u003eeks:CreateAccessEntry\u003c/code\u003e and \u003ccode\u003eeks:DeleteAccessEntry\u003c/code\u003e permissions.\u003c/li\u003e\n\u003cli\u003eAttacker calls \u003ccode\u003eCreateAccessEntry\u003c/code\u003e via the EKS API to map their IAM principal to a cluster-admin Kubernetes group.\u003c/li\u003e\n\u003cli\u003eAttacker connects to the target EKS cluster using the newly provisioned access.\u003c/li\u003e\n\u003cli\u003eAttacker performs a \u003ccode\u003ecreate\u003c/code\u003e operation on Kubernetes resources (e.g., \u003ccode\u003eClusterRoleBindings\u003c/code\u003e or \u003ccode\u003eServiceAccounts\u003c/code\u003e) to create a persistent backdoor.\u003c/li\u003e\n\u003cli\u003eAttacker executes further malicious commands, such as deploying rogue \u003ccode\u003eDaemonSets\u003c/code\u003e or accessing sensitive secrets within the cluster.\u003c/li\u003e\n\u003cli\u003eAttacker calls \u003ccode\u003eDeleteAccessEntry\u003c/code\u003e via the EKS API to remove the association between their IAM principal and the cluster.\u003c/li\u003e\n\u003cli\u003eThe EKS access entry is removed, leaving behind the persistent Kubernetes-level backdoor while clearing the primary CloudTrail evidence of access.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement monitoring for the EKS access entry grant-and-revoke cycle using the provided detection logic.\u003c/li\u003e\n\u003cli\u003eReview Kubernetes audit logs for \u003ccode\u003ecreate\u003c/code\u003e events involving \u003ccode\u003eClusterRoleBindings\u003c/code\u003e, \u003ccode\u003eRoleBindings\u003c/code\u003e, \u003ccode\u003eServiceAccounts\u003c/code\u003e, or \u003ccode\u003eDaemonSets\u003c/code\u003e that coincide with suspicious EKS access entry creation.\u003c/li\u003e\n\u003cli\u003eAudit existing Kubernetes RBAC configurations for unauthorized high-privilege service accounts or bindings.\u003c/li\u003e\n\u003cli\u003eRestrict \u003ccode\u003eeks:CreateAccessEntry\u003c/code\u003e and \u003ccode\u003eeks:DeleteAccessEntry\u003c/code\u003e IAM permissions to only the most trusted administrative identities or automated CI/CD roles.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-08-26T13:55:24Z","date_published":"2026-08-26T13:55:24Z","id":"https://feed.craftedsignal.io/briefs/2026-08-eks-persistence/","summary":"Adversaries with EKS administrative permissions may exploit EKS access entries to temporarily grant themselves cluster-admin access, establish persistent Kubernetes RBAC backdoors, and delete the access entry to conceal their activity.","title":"Abuse of Amazon EKS Access Entries for Persistent Backdoor Establishment","url":"https://feed.craftedsignal.io/briefs/2026-08-eks-persistence/"}],"language":"en","title":"CraftedSignal Threat Feed - Elastic Kubernetes Service","version":"https://jsonfeed.org/version/1.1"}