(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.
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.
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.
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
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
kind: Pod
metadata:
name: privileged-ubuntu
labels:
app: privileged-ubuntu
spec:
containers:
- image: ubuntu
command:
- "sleep"
- "3600"
imagePullPolicy: IfNotPresent
name: ubuntu
securityContext:
capabilities:
add: ["NET_RAW", "NET_ADMIN", "SYS_ADMIN"]
runAsUser: 0
restartPolicy: Never
hostNetwork: true
hostPID: true
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.
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.
This article is brought to you by Kloudle Academy, a free e-resource compilation, created and curated by Kloudle. Kloudle is a cloud security management platform that uses the power of automation and simplifies human requirements in cloud security. If you wish to give your feedback on this article, you can write to us here.