Escalate from SSJI to EKS

What this lab covers

You begin as an external attacker against an exposed Node.js customer portal. You work from an access-control flaw into server-side JavaScript injection and gain code execution inside a Kubernetes pod.

From inside the pod you enumerate Kubernetes permissions, cross a namespace boundary through misconfigured RBAC, and abuse the cluster's IAM integration to obtain AWS credentials and reach sensitive data. The value is in seeing how each ordinary weakness links to the next.

It assumes basic web exploitation, core Kubernetes concepts such as pods, namespaces and service accounts, and intro-level AWS IAM.

How server-side JavaScript injection is abused

Server-side JavaScript injection happens when user input reaches a JavaScript evaluation context on the server, through an unsafe eval, a vulnerable template engine or a sandbox that does not hold. The input is then executed by the Node.js runtime with the privileges of the application process.

In a containerized application that means code execution inside the pod, where the mounted service account token and the Kubernetes API become the immediate next target. Access-control gaps such as insecure direct object references often sit alongside injection flaws and provide the context needed to reach the vulnerable code path.

From a pod, the cluster's identity model does the rest of the work. Permissive role bindings allow movement between namespaces, and an IAM integration such as IRSA can exchange a Kubernetes service account for real cloud credentials.

How to detect this in your own environment

Treat any server-side use of eval or an unsandboxed template engine on untrusted input as a finding, and monitor application logs for the errors and unusual responses that injection attempts produce.

Alert on secret reads, exec into containers and cross-namespace access by workload identities that do not normally perform them, and on service accounts assuming cloud roles at unexpected times.

Enable Kubernetes audit logging and CloudTrail, and ship both somewhere queryable, so the enumeration and role assumptions that follow a pod compromise are visible during an investigation.

How to prevent it

Never evaluate untrusted input as code. Use safe template rendering, validate and encode input, and keep application dependencies patched so known injection sinks are closed.

Scope RBAC and service accounts to the least each workload needs, and avoid cluster-wide or cross-namespace grants unless a workload genuinely requires them.

Scope IRSA roles narrowly so a compromised pod inherits as little cloud access as possible, and restrict which service accounts can assume which roles.

Real-world context

Real attacks against Kubernetes rarely start with a zero-day. An exposed application is compromised and the attacker escalates through misconfigurations across the app, cluster and cloud layers. Red Hat's research into Kubernetes adoption and security reports that misconfiguration is the most commonly cited Kubernetes security incident, experienced by nearly 60 percent of respondents in the preceding year, which is exactly the chain this lab reproduces.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1613 Container and Resource Discovery, T1552 Unsecured Credentials and T1078 Valid Accounts.

Applying this at work

• Audit your services for server-side eval and unsandboxed template rendering on user input, and remove or sandbox them.
• Enumerate which service accounts can read secrets, exec into containers or reach other namespaces, and reduce each grant.
• Review your IRSA mappings and tighten the trust and permissions on every role a service account can assume.
• Enable Kubernetes audit logging and CloudTrail and confirm both reach a system you can query during an incident.
• Rehearse the full chain from application foothold to cloud access so your detection and response cover every hop.

Frequently asked questions

What is server-side JavaScript injection?

It is a flaw where user-supplied input is executed as JavaScript on the server, typically through an unsafe eval, a vulnerable template engine or a broken sandbox. The result is code execution with the privileges of the application, which inside a cluster means a shell in the pod.

What is IRSA and why does it matter here?

IRSA, IAM Roles for Service Accounts, maps a Kubernetes service account to an AWS IAM role through OIDC so pods can call AWS without static keys. It is convenient, but if a role is scoped too broadly a compromised pod inherits that cloud access, which is how a cluster foothold becomes a cloud one.

Is a Kubernetes cluster a security boundary?

Not on its own. Ordinary permissions can lead to secrets, to other namespaces or to cloud credentials, so a namespace should not be treated as a wall that contains a compromise without additional controls.

Do I need my own cluster to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Kubernetes Attack and Defense Bootcamp, Professional Edition (KRTP) covers Kubernetes attack paths end to end, including application-to-pod compromise, RBAC abuse, IRSA and the route from a cluster into the cloud account behind it.