Beyond kubectl get pods: Simulating Realistic Kubernetes Attack Chains

TLDR: Most Kubernetes security assessments rely on basic vulnerability scanning, which misses the complex, multi-stage attack chains that real adversaries use to compromise clusters. This post breaks down how to use the Leonidas framework to simulate realistic, MITRE ATT&CK-aligned Kubernetes attacks. By chaining together techniques like credential theft, lateral movement, and container escapes, you can finally measure your detection coverage against actual threats rather than just static misconfigurations.

Kubernetes security is often treated as a compliance checkbox. Teams run a scanner, fix a few overly permissive RBAC roles, and call it a day. But if you have spent any time in a real red team engagement, you know that a cluster is rarely compromised by a single, glaring misconfiguration. It is compromised by a series of small, seemingly innocuous actions that, when chained together, lead to full cluster takeover.

The industry is currently obsessed with static analysis. We have tools that tell us if a pod is running as root or if a service account has too many permissions. While these are necessary, they are not sufficient. They do not tell you if your SOC can actually detect an attacker who has already gained a foothold and is now attempting to dump secrets or escalate privileges. If you cannot detect the behavior, the configuration is just a suggestion.

Mapping the Attack Surface

To build a meaningful simulation, you have to stop thinking about individual vulnerabilities and start thinking about the attacker's objective. In a Kubernetes environment, the objective is almost always the same: access to the underlying cloud infrastructure or the sensitive data held within the cluster's secrets.

Attackers typically start at the container level. A compromised web application or a backdoored image provides the initial entry point. From there, they look for the service account token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. If that token is over-privileged, the attacker can query the API server to list other pods, secrets, or even deploy new, malicious workloads.

The MITRE ATT&CK Matrix for Containers provides the best framework for categorizing these behaviors. When you are planning your simulation, do not just run a script that checks for open ports. Instead, simulate the full lifecycle:

1. Initial Access: Use a leaked kubeconfig or a compromised pod to establish a connection.
2. Discovery: Enumerate the namespace to identify high-value targets.
3. Credential Access: Extract secrets or service account tokens.
4. Execution: Run commands within the cluster to move laterally or exfiltrate data.

Executing the Simulation with Leonidas

Manual simulation is tedious and hard to scale. This is where Leonidas changes the game. It is an open-source framework designed specifically for executing Kubernetes-specific attack simulations. Unlike generic tools, it allows you to define attack test cases as code, making them repeatable and easy to integrate into your CI/CD pipeline.

If you want to simulate an attacker dumping secrets, you do not need to manually craft complex kubectl commands. You define the test case in the framework, and it handles the interaction with the API server. This allows you to focus on the detection side. Can your SIEM correlate the list verb on secrets with the specific user agent or source IP? If not, you have found a gap in your monitoring that no scanner would ever reveal.

For example, a simple test case to list secrets might look like this in your simulation logic:

# Simulating secret enumeration
kubectl get secrets -n target-namespace

When you run this through a framework like Leonidas, you can trigger the event and immediately check your dashboard to see if the alert fired. If you are using Falco or Tetragon for runtime security, you can verify that your kernel-level rules are actually catching the syscalls associated with these actions.

The Blue Team Reality Check

The most critical part of this process is the "Purple" aspect. You cannot just run these attacks in a vacuum. You need to be sitting next to your SOC analysts or your platform engineers while the simulation runs.

When you execute a command to exec into a pod, ask the team: "Did you see that?" If they did not, you have identified a logging blind spot. Maybe your audit logs are not configured to capture the exec verb, or perhaps they are being sent to a storage bucket that no one is monitoring.

To get started, you must ensure your Kubernetes Audit Logs are enabled and properly configured. By default, many managed Kubernetes providers do not log everything you need. You should be looking for a policy that captures the verb, resource, and user for every request to the API server. Without this, you are flying blind.

Moving Beyond the Basics

If you are a pentester, stop delivering reports that only list "insecure configurations." Start delivering reports that show how those configurations can be exploited to achieve a specific, high-impact outcome. If you are a researcher, stop looking for the next RCE and start looking for the next way to bypass cluster-level logging.

The goal of these simulations is not to prove that your cluster is vulnerable—it is to prove that your team can respond when the inevitable happens. Start small. Pick one technique from the MITRE matrix, simulate it, and verify your detection. Then, chain it to another. By the time you have built a full, multi-stage attack chain, you will have a much clearer picture of your actual security posture than any automated scanner could ever provide.