(This is Part 3 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 third tactic described in the MITRE ATT&CK framework for Kubernetes - Persistence)
In the last post, we saw the techniques in the Execution tactic of the MITRE ATT&CK framework for Kubernetes. Let’s look at the next tactic, Persistence 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.
In a post exploitation scenario, one of the key tactics that attackers use is to maintain access to the target that was compromised. Most commonly this is done by planting a backdoor (for example, SSH key add to ~/.ssh/authorized_keys, or adding another user to the system etc.). In the world of Kubernetes, additional options are available to an attacker to maintain access.
Attackers can use Kubernetes controllers to ensure persistence by starting new containers as DaemonSets or Deployments. This will ensure a constant number of containers will always run which will allow attackers to access the cluster at their will. To keep a low footprint, backdoor access would usually be triggered using an outbound connection. For example, a process would periodically request an attacker IP to connect to. Once made available, a reverse shell would be triggered giving the attacker access to the cluster.
hostPath volume mounts a directory or a file from the host to the container. An attacker with the ability to create a new container could potentially create one with a writable hostPath volume. The attacker could then choose to update a script within the volume and let a cron job execute it providing persistence.
A Kubernetes Job is used to create pods that perform specific tasks and then terminate the pods once the task is completed.Kubernetes CronJobs do the same but using defined schedules.
To maintain access to a compromised cluster via Kubernetes Jobs/CronJobs, an attacker would schedule tasks to run periodically and connect back to an attacker server. Based on this “callback”, an attacker could update the resource that is being requested by the Job and provide a way to get a reverse shell or an updated user token back from the cluster.
Once an attacker has executed their malicious code, in all likeliness to gain some level of access to the cluster resources, the next step attackers pick is to maintain access. Often, access is maintained to ensure the attackers are the only ones within the cluster by ensuring any other attempts to exploit weaknesses fail or provide rudimentary footholds at best.
Kubernetes has multiple native features that can be used to set up persistence within the cluster. In the next post we will see how attackers escalate privileges within the compromised environment 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.
