Kloudle
academy

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

Riyaz Walikar
#mitreatta&ck#cloudsecurity#kubernetes
Feature image

Introduction

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

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

secrets in env

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.

dashboard pod exec

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

‍*** 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.

← Back to Academy