How should security teams investigate an EKS privilege escalation after a CloudTrail alert shows new IAM key creation?

Why This Matters for Security Teams

An EKS privilege escalation that begins with new IAM key creation is rarely just an IAM event. It can mark the start of credential abuse, role chaining, kubeconfig manipulation, and secret harvesting inside a cluster that was assumed to be isolated. CloudTrail gives the first signal, but the investigation has to connect identity actions to Kubernetes workload activity before the attacker buries the trail. NHIMG’s research shows that over-privileged systems are far more likely to suffer incidents, which is why The 2026 Infrastructure Identity Survey is directly relevant here.

Teams often misread this as a simple key-rotation problem and miss the broader blast radius. The real question is what the new key enabled, which permissions it touched, and whether the actor used that access to pivot into EKS workloads, service accounts, or cluster-admin paths. Current guidance suggests treating identity evidence and cluster evidence as one timeline, not separate investigations. In practice, many security teams encounter the persistence phase only after pods, roles, and secrets have already been touched, rather than through intentional detection.

How It Works in Practice

Start with the IAM principal in CloudTrail and reconstruct the sequence around key creation, attachment, and use. Then pivot to the EKS-side telemetry that can show whether the actor moved from AWS identity into Kubernetes control:

• CloudTrail: CreateAccessKey, AttachUserPolicy, PutUserPolicy, AssumeRole, and sts:AssumeRoleWithWebIdentity.
• EKS audit logs: namespace discovery, pod creation, token requests, secrets reads, RBAC changes, and exec activity.
• Authenticatory and cluster identity logs: mapped IAM role, Kubernetes username, and any changes to aws-auth or access entries.

For attacker tradecraft context, compare the activity against patterns described in the MITRE ATT&CK Enterprise Matrix, especially identity abuse, privilege escalation, and lateral movement. If the environment already shows weak non-human identity discipline, NHIMG’s The 2024 Non-Human Identity Security Report helps explain why static secrets and broad workload permissions frequently become the bridge from cloud IAM into cluster control.

A strong timeline usually answers four questions: which key was created, which principal used it, which role or group was assumed next, and which Kubernetes objects were created or read after that. Look closely for service account token abuse, privileged pod specs, hostPath mounts, image pulls from unexpected registries, and secret access that does not match normal workload behaviour. Map each action to its source IP, user agent, and namespace so you can distinguish operator activity from compromise.

Use the identity controls in NIST SP 800-53 Rev 5 Security and Privacy Controls to frame the review, especially access enforcement, audit logging, and privilege management. These controls tend to break down when EKS authentication is federated through multiple roles and the cluster lacks complete audit coverage.

Common Variations and Edge Cases

Tighter forensic scoping often increases investigation time, requiring teams to balance speed against completeness. That tradeoff is especially visible when the IAM key was created by automation, a CI system, or an identity broker rather than an interactive user. Best practice is evolving here: there is no universal standard for how much trust to place in short-lived automation keys when they appear in the same window as suspicious EKS activity.

Edge cases usually include legitimate break-glass access, rotating deployment credentials, and service accounts that can legitimately create pods or read secrets. A key clue is whether the actor stayed within the expected identity path or immediately expanded into permissions they did not normally need. Also watch for cross-account role assumptions, node-role abuse, and workload identities that outlive the pod that first used them.

If the cluster uses admission controllers, policy engines, or external secrets systems, include those logs as well, because attackers often pivot through the control plane rather than the application layer. For broader NHI context, the Ultimate Guide to NHIs — Key Challenges and Risks explains why static identity assumptions fail once workloads can create, chain, and reuse credentials at machine speed. The investigation gets harder in highly automated clusters where the same account can deploy, mutate, and observe infrastructure in one execution path.

Related resources from NHI Mgmt Group

• How should security teams implement cloud IAM without creating new privilege sprawl?
• How should security teams assess privilege escalation risk in Google Cloud environments with hierarchical IAM inheritance?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?