January 13, 2021

Part 3 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Persistence

This is the third part of a nine part series on the MITRE ATT&CK framework for Kubernetes, covering the Persistence tactic with examples.

Table of Contents

Introduction

Persistence

     Backdoor container

     Writable hostPath mount

     Kubernetes CronJob

Conclusion

References

Introduction

(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.

Kubernetes ATT&CK matrix

Persistence

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.

Backdoor container

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.

Writable hostPath mount

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.

Kubernetes CronJob

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.

Conclusion

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.

References

***

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.

Written by:
Riyaz Walikar

Riyaz Walikar

Chief Hacker

Riyaz is a security evangelist, offensive security expert and researcher with over a decade of experience in the cyber security industry. His passion to break into some of the most well defended networks and systems in his career spanning 15 years has earned him a lot respect within the security industry. He has led Security Assessment and Penetration Testing teams at Pricewaterhouse Coopers (PwC) and Appsecco, and the Product Security Team at Citrix before co-founding Kloudle. Riyaz now specializes in cloud native, container and cloud security in general, helping build an easy to use security management platform to help companies enhance their visibility in the cloud, identify security misconfigurations and automate remediation for security gaps enabling compliance and operational security in multi-cloud environments. He is also an avid speaker and trainer and presents his research and findings at security conferences and community meetups around the world including BlackHat USA, BH Europe, BH Asia, nullcon and OWASP AppsecUSA.Specialties: Cloud (AWS, GCP, Azure, IBM, Others) Security, Cloud-Native Security, Kubernetes, Container Security, Web Application Security, Network and System Penetration Testing, Wireless Network Security, Malware Analysis and Reverse Engineering, Threat Modelling, Windows Forensics, Security Code Review, Vulnerability Research, Exploit Development and Reverse Engineering. Certifications: CKA, CKAD, OSCP

Read more