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

How to trace the first access path behind the key creation alert

Start with the cloudtrail event window, then build outward from the principal ARN that created the key. Correlate that identity with adjacent CloudTrail activity, EKS audit logs, and authenticator events so you can tell whether the key was created by an already-compromised user, a delegated role, or a chain that moved from cloud control plane access into the cluster.

The most important early judgement is whether the key creation is the origin of the problem or just one step in a wider compromise. If you can align the timestamp with subsequent user creation, policy attachment, role assumption, or namespace activity, you usually get a better answer than investigating the IAM event in isolation.

For the access path itself, the investigation should treat the cloud identity and the cluster identity as one timeline, not two separate incidents. The point is to show how a valid API action turned into interactive reach inside EKS, because that is usually where privilege escalation becomes operationally useful to an attacker.

Which events usually show that escalation has crossed into the cluster

Look for the sequence that connects control-plane access to Kubernetes actions: new IAM access key creation, followed by policy or trust changes, then role assumption, then pod creation or modification, and finally access to Kubernetes Secrets or other sensitive configuration. A cluster compromise is rarely proven by one log line alone; it is proven by a chain of actions that fits a single operator or automation path.

Review EKS audit events for changes to service accounts, cluster roles, role bindings, and workloads that request elevated permissions. If the cloud identity used to create the key later appears in authenticator logs or in a mapped role used by kubectl, that is a strong sign the actor moved from AWS-side access into Kubernetes-side privilege.

Use the event sequence to distinguish initial access from persistence. Key creation may be the first durable foothold, but the more telling evidence is whether the actor used that foothold to create additional identities, widen permissions, or plant workloads that survive a password or session reset.

Why this pattern matters for containment and recovery

This investigation is not just about finding a bad key. It is about understanding whether the attacker can still authenticate, whether they reached cluster-level permissions, and whether they copied material that would let them return later. That makes credential scope, session validity, and workload access just as important as the original alert.

Teams often underestimate how quickly a cloud identity event can become a cluster event. Once an actor can assume a role that has EKS visibility or namespace write access, they may be able to create new pods, query mounted secrets, or pivot through service-linked permissions that look harmless in isolation.

In practice, the key question is whether the observed activity produced new trusted access paths. If the answer is yes, then the investigation should expand to every identity, role, and secret touched by that path, because persistence usually comes from the expanded trust boundary rather than from the original key alone.

Risk and Threat Considerations

New IAM key creation during an EKS incident often means the actor has already achieved enough privilege to maintain access outside the session that first triggered detection. The risk is not limited to AWS account abuse; the same identity may be able to move into the cluster, harvest Secrets, and create durable workloads that outlive the original alert window.

Failure mechanism: The attacker uses valid cloud credentials to create or reuse an access path, then leverages attached policies or assumed roles to reach Kubernetes objects, workloads, or secrets that enable lateral movement and persistence.

Impact: The environment can shift from a single compromised identity to a multi-layer compromise involving AWS IAM, EKS access, and sensitive application data, which raises both containment effort and the likelihood of re-entry after remediation.

Practitioner Guidance

What to verify: Confirm whether the key creation was followed by policy attachment, trust-policy edits, role assumption, or new cluster access within the same alert window. If those actions line up, treat the key as part of an active intrusion chain rather than as an isolated IAM hygiene issue.

Decision rule: If the same principal can reach both AWS control-plane actions and EKS-authenticated activity, prioritise containment of that identity and blast-radius assessment before spending time on root-cause theories. The investigation should answer “what did this identity reach?” before “how was it first obtained?”

What practitioners underestimate: Secrets access is often the most important pivot point, because once an attacker can read mounted or referenced credentials, the compromise can continue even after the original IAM key is revoked. Preserve the relevant logs and object state long enough to reconstruct that downstream access path.

Practitioner takeaway: The useful endpoint is not “a key was created,” but “how far that key let the actor travel.” Build the timeline so you can prove whether the compromise stopped at IAM or expanded into EKS persistence and secret exposure.

Related resources from NHI Mgmt Group

• Escalation
• 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?
• How should security teams investigate ransomware when an initial alert only shows a suspicious executable?