Malicious Code Execution and Compromised Containers: KCSA practice questions

Malicious code execution in a container is usually where a Kubernetes attack begins rather than where it ends. The CNCF Financial Services User Group attack tree for this goal describes the initial foothold as primarily a compromised application that gives access to the container, reached through a NodePort on a node or, more likely, directly from the external network, and calls it perhaps the most likely way into the environment. From there the attacker tries to load more code, using whatever the container's privilege level allows.

The companion scenario, a compromised application that leads to a foothold in a container, singles out the mounted and insecure service account token as one of the most exploited paths. A token is mounted into each Pod by default, so a compromised container hands the attacker API credentials. The threat model names strict RBAC policies and disabling automatic token mounting as key mitigations; automountServiceAccountToken: false can be set on the ServiceAccount, and a Pod-level value overrides it. The same work warns about the default network exposure of the control plane to every running container, which is why NetworkPolicies that limit what a compromised Pod can reach matter.

Malicious code can also arrive through the supply chain. If an image pull secret is obtained, the attacker may be able to poison the repository and distribute malicious code from there, and the attack tree calls compromised images a major source of exploitation. NIST SP 800-190 makes the same point about embedded malware: an image is a collection of files, so malicious files can be included intentionally or by accident, and base layers or third-party images whose full provenance is unknown are one source. It also warns against clear-text secrets embedded in images.

What a compromised container can do next depends on isolation. NIST SP 800-190 notes that a shared kernel gives a larger inter-object attack surface than hypervisors, that runtime vulnerabilities allowing container escape let malicious software attack other containers and the host, and that in most runtimes containers can reach each other and the host over the network by default, so a compromised one can scan for further weaknesses. Kubernetes documents an especially direct route: a container with access to the node's container runtime socket can launch new containers or interact with running ones, so hostPath mounts that include the socket or a parent directory should be restricted or forbidden.

Detection and containment complete the picture. NIST recommends container-aware runtime tools that flag unexpected process execution and system calls, changes to protected files and binaries, writes to unexpected locations, new network listeners, traffic to unexpected destinations and malware. It also recommends read-only root filesystems, which confine writes to defined directories that are easy to monitor and isolate any tampering; in Kubernetes that is readOnlyRootFilesystem: true. Running as non-root, dropping capabilities and disallowing privilege escalation, as the Restricted Pod Security Standard requires, further limit what injected code can do.