What are the signs that an AWS account has been used for privilege escalation and persistence in EKS?

Why This Matters for Security Teams

privilege escalation in EKS is rarely a single event. It usually starts with an initial identity foothold, then moves through IAM changes, role assumption, Kubernetes RBAC abuse, and persistent workload access. Because AWS and Kubernetes logs sit in different planes, attackers can look like routine operators unless teams correlate IAM, CloudTrail, and EKS control-plane activity. NHI Management Group research shows that Ultimate Guide to NHIs — Key Challenges and Risks documents how widespread excessive privilege and weak rotation make this kind of drift easier to exploit. The OWASP NHI guidance also helps frame why service identities, not just human users, are often the real blast-radius driver.

In AWS, persistence often hides inside apparently legitimate automation, such as new access keys for a deployment role, a broader policy attachment, or a pod created with permissions far beyond its workload need. That is why signs of escalation must be read as a chain, not isolated alerts. A role that suddenly assumes into cluster-admin context, followed by secret enumeration and privileged pod creation, is far more significant than any one action alone. In practice, many security teams encounter EKS persistence only after an attacker has already converted one compromised credential into repeatable cluster access.

How It Works in Practice

The most useful way to investigate EKS privilege escalation is to follow the identity path from AWS to Kubernetes and back again. Start with CloudTrail for IAM and STS events, then pivot into EKS audit logs for role mappings, kube-api requests, and workload creation. Look for new IAM users, new access keys, policy attachments that introduce broad actions, and assume-role activity that lands in a cluster-admin or infrastructure role. Then check whether those credentials were used to create pods, mount service account tokens, list secrets, or deploy a DaemonSet, Job, or init container that can survive normal cleanup.

• Unexpected IAM key creation for an existing role, especially outside change windows
• New trust relationships or policy edits that widen who can assume a role
• STS role assumption followed by Kubernetes API actions from the same principal
• Secrets enumeration, secret dumping, or token use that exceeds normal application behaviour
• Privileged pod specs, hostPath mounts, hostNetwork use, or escalation-capable security contexts

For control design, current guidance suggests pairing least privilege with runtime verification. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 both reinforce that static entitlements should be tightly bounded and continuously reviewed, while MITRE ATT&CK is useful for mapping the post-compromise sequence you are trying to detect. A practical EKS investigation also benefits from checking whether a workload identity was reused across environments, because that often turns a one-time compromise into durable persistence. These controls tend to break down in highly automated CI/CD environments because legitimate deployments can mimic attacker behaviour unless change tickets, pipeline identity, and cluster audit trails are correlated together.

Common Variations and Edge Cases

Tighter EKS and IAM monitoring often increases alert volume, so organisations have to balance investigative depth against the noise created by deployment automation. That tradeoff is real, especially in clusters where platform engineering, GitOps, and security tooling all use similar roles and service accounts.

One common edge case is an attacker who never creates a new user at all. Instead, they steal an existing role session, then pivot through Kubernetes RBAC to mount secrets or create a pod that inherits enough trust to stay resident. Another variation is abuse of node IAM roles, where the attacker works from a compromised node or daemonset rather than a normal namespace workload. There is no universal standard for how much pod-level privilege is “acceptable” in every environment, so current guidance suggests treating host-level capabilities, long-lived tokens, and cross-namespace secret access as high-risk exceptions that need explicit justification. The same is true for service accounts that are reused across multiple workloads or clusters.

When the environment includes ephemeral build agents, autoscaling nodes, or frequent redeployments, persistence may show up as a modified deployment artifact rather than a classic backdoor. In those cases, compare the live pod spec, IAM trust policy, and secret access patterns against your deployment baseline. 230 Million AWS Environment Compromise is useful for understanding how quickly cloud identity abuse can spread once one path is opened, while OWASP Non-Human Identity Top 10 helps structure the review of overprivileged and poorly governed machine identities.

Related resources from NHI Mgmt Group

• Why does a compromised DNS or registrar account create such a large privilege-escalation risk in cloud admin workflows?
• Why do cross-account roles increase privilege escalation risk in AWS?
• Cross-Organization Privilege Escalation
• How should teams respond when a service account token is exposed?