(This is Part 6 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 sixth tactic described in the MITRE ATT&CK framework for Kubernetes - Credential Access)
In the last post, we saw the techniques in the Defense Evasion tactic of the MITRE ATT&CK framework for Kubernetes. Let’s look at the next tactic, Credential Access 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.
Once the attacker has planted their feet firmly within the cluster, escalated privileges, planted backdoors and evaded defenses, it’s time for them to move after data and credentials. We will cover data discovery and access in the next blog post while looking at the Credential Access tactic in this one.
Kubernetes, like any other software system with multiple moving parts, has data that needs protecting. This could be secrets stored as part of the cluster, database or app credentials which are part of the application or even cloud credentials for managed clusters. The Credential Access tactic of the MITRE ATT&CK framework talks about some of the techniques that an attacker could employ to steal secrets and credentials from the cluster and reuse them to move to protected systems within the cluster or outside it.
A K8S secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. An attacker with the ability to list secrets within the cluster would be able to retrieve the secret(s) and compromise additional resources accessible from their vantage point.
Secrets created using literal values, files or directories in Kubernetes get stored as base64 encoded strings within the datastore and can be readily reversed to plain text.
When Kubernetes is run in a managed environment like GKE or AKS, there is a service principal that is shared between the cloud platform and the Kubernetes cluster to allow the cluster to be managed using permissions of the cloud user.
This technique is the an overlap of the Access cloud resources and essentially covers ways by which an attacker within a cluster can gain access to credentials that would give cloud platform access.
For example, when setting up Kubernetes in Azure via AKS, if the service principal means of Authentication is chosen so that Azure Kubernetes Service can manage cloud resources attached to the cluster, then the service principal becomes accessible via the /etc/kubernetes/azure.json file on each of the nodes in the cluster. An attacker gaining access to the node would be able to elevate access to the Cloud platform by stealing these credentials.
By default, a service account is mounted to every pod in a Kubernetes cluster at /var/run/secrets/kubernetes.io/serviceaccount/ as a tmpfs file system (destroyed when pod is deleted).
This service account token is available via /var/run/secrets/kubernetes.io/serviceaccount/token.
An attacker who gains access to a pod can obtain the service account token. 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.
Developers may store tokens or credentials within environment variables or as configuration data with a pod spec. Attacker would be able to access these secrets by accessing the configuration files or by accessing the API to reveal these secrets.
Credential access is an attacker’s attempt to find secrets and tokens that can be used for movement between resources within the cluster. More often than not, credential reuse or weakly protected secrets lead to additional compromise within the cluster and the cloud platform.
In the next post we will see how attackers attempt to discover what’s present once access is obtained, privileges are escalated and credentials are stolen so that a map can be built of what else can be attacked within the cluster, 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.
