Part 2: Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Execution

Posted by
Riyaz Walikar
January 11, 2021
· 4 min read

(This is Part 2 of a 9 part blog series that explains the Kubernetes MITRE ATT&CK like Threat Matrix created by Microsoft from an attacker perspective and attempts to provide how real world attackers use the techniques covered in the framework to gain access, execute, persist and explore Kubernetes cluster environments.)

Use this index to navigate to and read the rest of the posts in this series

(This blog post discusses the second tactic described in the MITRE ATT&CK framework for Kubernetes - Execution)

In the last post, we saw the techniques in the Initial Access tactic of the MITRE ATT&CK framework for Kubernetes. Let's look at the next tactic, Execution and the techniques that attackers use within this tactic. For reference, here's the framework that Microsoft created as a visual cue to the overall tactics and techniques that attackers use when attacking a Kubernetes cluster.

Kubernetes ATT&CK matrix


The execution tactic consists of techniques that an attacker may employ to run their code within a cluster after initial access has been obtained. Attackers may run code by gaining access to a running container via an application vulnerability, start a new container or simply identify and use SSH private keys to jump to a node and gain access to the pods running on them.

Exec into container

In cases where the kubeconfig file is compromised or the user token has been leaked, attackers may gain the ability to simply kubectl exec commands in a container. Based on how egress is configured (default Internet access from container), attacker may then be able to exfiltrate data as well.

bash/cmd inside container

If a container is configured to run startup bash scripts or .bat files (Windows) and these files are read of a storage that does not restrict user access, then an attacker would be able to update a startup script and add malicious commands to it. Lot of documented one lin commands based on what libraries and software is present on the target are available that could allow an attacker to gain a reverse shell

New container

Based on the level of access obtained and namespace restriction, an attacker may be able to simply deploy a new pod or even a new controller and run their malicious code via an exec after the deployment succeeds.

Additionally, it may even be possible for attackers to run a privileged container that would be able to access the host. An example yaml is shown below (use only for testing)

apiVersion: v1
: Pod
name: privileged-ubuntu
app: privileged-ubuntu
 - image: ubuntu
     - "sleep"
     - "3600"
imagePullPolicy: IfNotPresent
: ubuntu
runAsUser: 0
restartPolicy: Never
: true
hostPID: true

Privileged Ubuntu

Application exploit (RCE)

Very similar in terms of gaining initial access to the cluster using an application vulnerability, a Remote Code Execution exploits are upgraded to two way duplex communication channels using a stable reverse shell from within the container.

SSH server running inside container

In rare cases (read "Enterprise requirement"), there may be a SSH server running inside a container which could be exposed to the Internet. Attacker's may gain access to the SSH service via another vulnerability within the container or by attacking the SSH service itself. Key reuse and weak password's are a common gateway to compromising SSH.


Once attackers have managed to get a foothold within a Kubernetes cluster, the next tactic of code execution is triggered. Attackers run their malicious code using already running containers, new Deployments/DaemonSets, exploiting weaknesses in network aware services and web apps that could be used to execute commands on the underlying container. Once code is executed attackers focus on tactics that will give them additional access, allow for them to persist or evade defenses that may have been setup within the cluster.

This post showed how the MITRE ATT&CK framework for Kubernetes discusses the Execution tactic and what techniques attackers use to execute their code within a cluster. In the next post, we shall see how attackers attempt to persist within a cluster using techniques that rely on native features while using the framework as our guide.


More Articles

IAM Bad: Privilege Escalation using Misconfigured Policies in AWS IAM (Webinar)
Posted by
Riyaz Walikar
May 6, 2021

A walkthrough of the slides covered as part of our Star Wars Day special webinar on IAM policy misconfigurations that can lead to privilege escalations and a takeover of the target AWS account.

Read More
DeveloperWeek Europe 2021 - Walkthrough of the Talk slides and Audience Questions
Posted by
Riyaz Walikar
April 29, 2021

A walkthrough of the slides covered as part of the DeveloperWeek Europe 2021 virtual conference, attack details and answers to questions that were asked during the talk.

Read More
Who else is in your pod? - Walkthrough of the KubeSec Enterprise Online Talk
Posted by
Riyaz Walikar
April 8, 2021

A walkthrough of the slides covered during the KubeSec Enterprise Online 2021 talk with details of the attacks covered and tips and tricks to harden your Kubernetes cluster.

Read More

Ready to give Kloudle a try?

We help you monitor and prevent any data breaches.

Let's Talk