(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
- Part 1 - Initial access
- Part 2 - Execution
- Part 3 - Persistence
- Part 4 - Privilege escalation
- Part 5 - Defense evasion
- Part 6 - Credential access
- Part 7 - Discovery
- Part 9 - Impact
(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.
## 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.
### 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.
### 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.
### 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
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.