Part 8 - Mapping the MITRE ATT&CK framework to your Kubernetes cluster: Lateral Movement

Posted by
Riyaz Walikar
on
February 22, 2021
· 5 min read

(This is Part 8 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 eighth tactic described in the MITRE ATT&CK framework for Kubernetes - Lateral Movement)

In the last post, we saw the techniques in the Discovery tactic of the MITRE ATT&CK framework for Kubernetes. Let's look at the next tactic, Lateral Movement 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

Lateral Movement

Once an attacker has gained access to an environment, obtained privileges to reach regions that require authentication and discovered additional areas of the environment that can be reached from their current vantage point, they attempt to move to adjoining environments using multiple offensive techniques. This tactic is termed as Lateral Movement, although many of the techniques will usually move the attacker from the current plane of attack to a horizontal as well as vertical plane of attack.

Let's take a look at the techniques that attacker's use when applying the Lateral Movement tactic to Kubernetes environments.

Access cloud resources

This technique overlaps with the "Access cloud resources" technique covered under the Privilege Escalation tactic.

Essentially, an attacker is able to use service accounts or OAuth scopes that can be used to break out of the Kubernetes environment and move to the Cloud platform layer.

For an example of how a default cluster setup with GKE provides access to extra OAuth scope which an attacker uses to gain access to GCP Storage to read files, take a look at the "Access cloud resources" technique covered under the Privilege Escalation tactic.

Container service account

This technique also has an overlap with the "Access container service account" technique covered under the Credential Access tactic.

Attackers can use the mounted service account token found at /var/run/secrets/kubernetes.io/serviceaccount/token to gain access to the Kubernetes API. If Kubernetes RBAC is not enabled, the service account token will grant the attacker full access to the cluster or with RBAC enabled, privileges would be determined by role bindings. An attacker can use this token to gain access to the cluster resources.

Container Token Access

Cluster internal networking

Kubernetes does not restrict traffic between pods in a cluster unless a NetworkPolicy has been applied. This default behavior can be exploited by attackers to reach pods running other applications once cluster access is obtained.

Kubernetes provides NetworkPolicy as a resource that can be used to implement granular access between namespaces, pods and even individual ports that are exposing services.

Applications credentials in configuration files

This technique overlaps with the the "Application credentials in configuration files" technique of the Credential Access tactic that we have written about before about.

Essentially, an attacker is able to access secrets that developers store in environment variables, app configuration files or the Kubernetes Secrets and ConfigMap store. Access to secrets allow access to additional resources that require authentication. In most cases, additional vulnerabilities or the ability to execute shell commands may be obtained via the new found access, allowing the attacker to jump networks or platform boundaries.

An example that we have covered in the Credential Access blogpost is of the following Pod yaml that contains MySQL DB credentials. An attacker can authenticate themselves to the MySQL DB store and gain access to restricted data using the new found access.

MySQL creds stored in yaml file

Writable volume mounts on the host

This technique overlaps with the "Writable hostPath mount" technique of the Persistence tactic that we have written before about.

Allowing unnecessary ability to write to volume mounts would allow an attacker to create or update files that could be used to obtain shell command execution capabilities.

Access Kubernetes dashboard

This technique overlaps with the "Access Kubernetes Dashboard" technique of the Discovery tactic that we have written before about.

An attacker who has access to the Kubernetes Dashboard may manage the cluster resources and would have the ability to run their code on the workloads running within the cluster using the "exec" functionality that the Dashboard provides.

Exec into Pod via Dashboard

Access tiller endpoint

Helm is a package manager for Kubernetes, maintained by CNCF. Much like how you can use pip or apt to install python and debian packages respectively, Helm is used to deploy resources within a Kubernetes cluster.

Tiller is the server side component of Helm, up until version 2. Helm is currently at 3.5.0 (helm version), so this technique no longer applies for versions beyond 2.

Tiller exposes an internal gRPC endpoint in the cluster which listens on port 44134. By default, this endpoint does not have RBAC. An attacker can connect to this endpoint using the helm client binary and "install" resources. For example, a Kubernetes resource can be created using a helm chart using the command helm --host tiller-deploy.kube-system:44134 install <packagename>.

Conclusion

With the Lateral Movement tactic, an attacker attempts to gain additional access moving to different resources within the cluster or finding ways to move out of the cluster into the Cloud platform plane. Multiple techniques used in the tactics covered thus far can be repurposed to move laterally within the cluster.

In the next and final post of this series, we will see the impact an attack can have on data, access and the cluster itself when we look at the Impact tactic of the MITRE ATT&CK framework.

References

More Articles

IAM Bad: Privilege Escalation using Misconfigured Policies in AWS IAM (Webinar)
Posted by
Riyaz Walikar
on
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
on
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
on
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