{
	"id": "4a9fc855-c452-4bf4-91c1-0a4ad7c34da8",
	"created_at": "2026-04-06T00:12:58.541171Z",
	"updated_at": "2026-04-10T03:24:17.892517Z",
	"deleted_at": null,
	"sha1_hash": "5f899ee38719ae1f42edb8c50c06c7d91526c909",
	"title": "Threat matrix for Kubernetes",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 148172,
	"plain_text": "Threat matrix for Kubernetes\r\nBy Yossi Weizman\r\nPublished: 2020-04-02 · Archived: 2026-04-05 12:34:35 UTC\r\nUpdated on May 10, 2021: An updated version of the threat matrix for containers is available here.\r\nKubernetes, the most popular container orchestration system and one of the fastest-growing projects in the history\r\nof open source, becomes a significant part of many companies’ compute stack. The flexibility and scalability of\r\ncontainers encourage many developers to move their workloads to Kubernetes. While Kubernetes has many\r\nadvantages, it also brings new security challenges that should be considered. Therefore, it is crucial to understand\r\nthe various security risks that exist in containerized environments, and specifically in Kubernetes.\r\nThe MITRE ATT\u0026CK® framework is a knowledge base of known tactics and techniques that are involved in\r\ncyberattacks. Started with coverage for Windows and Linux, the matrices of MITRE ATT\u0026CK cover the various\r\nstages that are involved in cyberattacks (tactics) and elaborate the known methods in each one of them\r\n(techniques). Those matrices help organizations understand the attack surface in their environments and make sure\r\nthey have adequate detections and mitigations to the various risks. MITRE ATT\u0026CK framework tactics include:\r\nInitial access\r\nExecution\r\nPersistence\r\nPrivilege escalation\r\nDefense evasion\r\nCredential access\r\nDiscovery\r\nLateral movement\r\nImpact\r\nWhen we in Azure Security Center started to map the security landscape of Kubernetes, we noticed that although\r\nthe attack techniques are different than those that target Linux or Windows, the tactics are actually similar. For\r\nexample, a translation of the first four tactics from OS to container clusters would look like 1. “initial access to the\r\ncomputer” becomes “initial access to the cluster”, 2. “malicious code on the computer” becomes “malicious\r\nactivity on the containers”, 3. “maintain access to the computer” becomes “maintain access to the cluster”, and 4.\r\n“gain higher privileges on the computer” becomes “gain higher privileges in the cluster”.\r\nTherefore, we have created the first Kubernetes attack matrix: an ATT\u0026CK-like matrix comprising the major\r\ntechniques that are relevant to container orchestration security, with focus on Kubernetes.\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 1 of 9\n\nAs can be seen, the matrix contains the 9 tactics listed above. Each one of them contains several techniques that\r\ncan be used by attackers to achieve different goals. Below are the descriptions of each one of the techniques.\r\n1. Initial Access\r\n1.\r\nThe initial access tactic consists of techniques that are used for gaining access to the resource. In containerized\r\nenvironments, those techniques enable first access to the cluster. This access can be achieved directly via the\r\ncluster management layer or, alternatively, by gaining access to a malicious or vulnerable resource that is\r\ndeployed on the cluster.\r\nUsing cloud credentials\r\nIn cases where the Kubernetes cluster is deployed in a public cloud (e.g., AKS in Azure, GKE in GCP, or EKS in\r\nAWS), compromised cloud credential can lead to cluster takeover. Attackers who have access to the cloud account\r\ncredentials can get access to the cluster’s management layer.\r\nCompromised images in registry\r\nRunning a compromised image in a cluster can compromise the cluster. Attackers who get access to a private\r\nregistry can plant their own compromised images in the registry. The latter can then be pulled by a user. In\r\naddition, users often use untrusted images from public registries (such as Docker Hub) that may be malicious.\r\nBuilding images based on untrusted base images can also lead to similar results.\r\nKubeconfig file\r\nThe kubeconfig file, also used by kubectl, contains details about Kubernetes clusters including their location and\r\ncredentials. If the cluster is hosted as a cloud service (such as AKS or GKE), this file is downloaded to the client\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 2 of 9\n\nvia cloud commands (e.g., “az aks get-credential” for AKS or “gcloud container clusters get-credentials” for\r\nGKE).\r\nIf attackers get access to this file, for instance via a compromised client, they can use it for accessing the clusters.\r\nVulnerable application\r\nRunning a public-facing vulnerable application in a cluster can enable initial access to the cluster. A container that\r\nruns an application that is vulnerable to remote code execution vulnerability (RCE) may be exploited. If service\r\naccount is mounted to the container (default behavior in Kubernetes), the attacker will be able to send requests to\r\nthe API server using this service account credentials.\r\nExposed dashboard\r\nThe Kubernetes dashboard is a web-based user interface that enables monitoring and managing a Kubernetes\r\ncluster. By default, the dashboard exposes an internal endpoint (ClusterIP service). If the dashboard is exposed\r\nexternally, it can allow unauthenticated remote management of the cluster.\r\n2. Execution\r\nThe execution tactic consists of techniques that are used by attackers to run their code inside a cluster.\r\nExec into container\r\nAttackers who have permissions, can run malicious commands in containers in the cluster using exec command\r\n(“kubectl exec”). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a\r\nbackdoor container, and run their malicious code remotely by using “kubectl exec”.\r\nNew container\r\nAttackers may attempt to run their code in the cluster by deploying a container. Attackers who have permissions to\r\ndeploy a pod or a controller in the cluster (such as DaemonSet \\ ReplicaSet\\ Deployment) can create a new\r\nresource for running their code.\r\nApplication exploit\r\nAn application that is deployed in the cluster and is vulnerable to a remote code execution vulnerability, or a\r\nvulnerability that eventually allows code execution, enables attackers to run code in the cluster. If service account\r\nis mounted to the container (default behavior in Kubernetes), the attacker will be able to send requests to the API\r\nserver using this service account credentials.\r\nSSH server running inside container\r\nSSH server that is running inside a container may be used by attackers. If attackers gain valid credentials to a\r\ncontainer, whether by brute force attempts or by other methods (such as phishing), they can use it to get remote\r\naccess to the container by SSH.\r\n3. Persistence\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 3 of 9\n\nThe persistence tactic consists of techniques that are used by attackers to keep access to the cluster in case their\r\ninitial foothold is lost.\r\nBackdoor container\r\nAttackers run their malicious code in a container in the cluster. By using the Kubernetes controllers such as\r\nDaemonSets or Deployments, attackers can ensure that a constant number of containers run in one, or all, the\r\nnodes in the cluster.\r\nWritable hostPath mount\r\nhostPath volume mounts a directory or a file from the host to the container. Attackers who have permissions to\r\ncreate a new container in the cluster may create one with a writable hostPath volume and gain persistence on the\r\nunderlying host. For example, the latter can be achieved by creating a cron job on the host.\r\nKubernetes CronJob\r\nKubernetes Job is a controller that creates one or more pods and ensures that a specified number of them\r\nsuccessfully terminate. Kubernetes Job can be used to run containers that perform finite tasks for batch jobs.\r\nKubernetes CronJob is used to schedule Jobs. Attackers may use Kubernetes CronJob for scheduling execution of\r\nmalicious code that would run as a container in the cluster.\r\n4. Privilege escalation\r\nThe privilege escalation tactic consists of techniques that are used by attackers to get higher privileges in the\r\nenvironment than those they currently have. In containerized environments, this can include getting access to the\r\nnode from a container, gaining higher privileges in the cluster, and even getting access to the cloud resources.\r\nPrivileged container\r\nA privileged container is a container that has all the capabilities of the host machine, which lifts all the limitations\r\nregular containers have. Practically, this means that privileged containers can do almost every action that can be\r\nperformed directly on the host. Attackers who gain access to a privileged container, or have permissions to create\r\na new privileged container (by using the compromised pod’s service account, for example), can get access to the\r\nhost’s resources.\r\nCluster-admin binding\r\nRole-based access control (RBAC) is a key security feature in Kubernetes. RBAC can restrict the allowed actions\r\nof the various identities in the cluster. Cluster-admin is a built-in high privileged role in Kubernetes. Attackers\r\nwho have permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles.\r\nhostPath mount\r\nhostPath mount can be used by attackers to get access to the underlying host and thus break from the container to\r\nthe host. (See “3: Writable hostPath mount” for details).\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 4 of 9\n\nAccess cloud resources\r\nIf the Kubernetes cluster is deployed in the cloud, in some cases attackers can leverage their access to a single\r\ncontainer in order to get access to other cloud resources outside the cluster. For example, in AKS each node\r\ncontains service principal credential that is stored in /etc/kubernetes/azure.json. AKS uses this service principal\r\nto create and manage Azure resources that are needed for the cluster operation.\r\nBy default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get\r\naccess to this service principal file (by hostPath mount, for example) can use its credentials to access or modify\r\nthe cloud resources.\r\n5. Defense evasion\r\nThe defense evasion tactic consists of techniques that are used by attackers to avoid detection and hide their\r\nactivity.\r\nClear container logs\r\nAttackers may delete the application or OS logs on a compromised container in an attempt to prevent detection of\r\ntheir activity.\r\nDelete Kubernetes events\r\nA Kubernetes event is a Kubernetes object that logs state changes and failures of the resources in the cluster.\r\nExample events are a container creation, an image pull, or a pod scheduling on a node.\r\nKubernetes events can be very useful for identifying changes that occur in the cluster. Therefore, attackers may\r\nwant to delete these events (e.g., by using: “kubectl delete events–all”) in an attempt to avoid detection of their\r\nactivity in the cluster.\r\nPod / container name similarity\r\nPods that are created by controllers such as Deployment or DaemonSet have random suffix in their names.\r\nAttackers can use this fact and name their backdoor pods as they were created by the existing controllers. For\r\nexample, an attacker could create a malicious pod named coredns-{random suffix} which would look related to the\r\nCoreDNS Deployment.\r\nAlso, attackers can deploy their containers in the kube-system namespace where the administrative containers\r\nreside.\r\nConnect from proxy server\r\nAttackers may use proxy servers to hide their origin IP. Specifically, attackers often use anonymous networks such\r\nas TOR for their activity. This can be used for communicating with the applications themselves or with the API\r\nserver.\r\n6. Credential access\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 5 of 9\n\nThe credential access tactic consists of techniques that are used by attackers to steal credentials.\r\nIn containerized environments, this includes credentials of the running application, identities, secrets stored in the\r\ncluster, or cloud credentials.\r\nList Kubernetes secrets\r\nA Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and\r\nconnection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who\r\nhave permissions to retrieve the secrets from the API server (by using the pod service account, for example) can\r\naccess sensitive information that might include credentials to various services.\r\nMount service principal\r\nWhen the cluster is deployed in the cloud, in some cases attackers can leverage their access to a container in the\r\ncluster to gain cloud credentials. For example, in AKS each node contains service principal credential. (See “4:\r\nAccess cloud resources” for more details.)\r\nAccess container service account\r\nService account (SA) represents an application identity in Kubernetes. By default, an SA is mounted to every\r\ncreated pod in the cluster. Using the SA, containers in the pod can send requests to the Kubernetes API server.\r\nAttackers who get access to a pod can access the SA token (located in\r\n/var/run/secrets/kubernetes.io/serviceaccount/token) and perform actions in the cluster, according to the SA\r\npermissions. If RBAC is not enabled, the SA has unlimited permissions in the cluster. If RBAC is enabled, its\r\npermissions are determined by the RoleBindings \\ ClusterRoleBindings that are associated with it.\r\nApplication credentials in configuration files\r\nDevelopers store secrets in the Kubernetes configuration files, such as environment variables in the pod\r\nconfiguration. Such behavior is commonly seen in clusters that are monitored by Azure Security Center. Attackers\r\nwho have access to those configurations, by querying the API server or by accessing those files on the developer’s\r\nendpoint, can steal the stored secrets and use them.\r\n7. Discovery\r\nThe discovery tactic consists of techniques that are used by attackers to explore the environment to which they\r\ngained access. This exploration helps the attackers to perform lateral movement and gain access to additional\r\nresources.\r\nAccess the Kubernetes API server\r\nThe Kubernetes API server is the gateway to the cluster. Actions in the cluster are performed by sending various\r\nrequests to the RESTful API. The status of the cluster, which includes all the components that are deployed on it,\r\ncan be retrieved by the API server. Attackers may send API requests to probe the cluster and get information about\r\ncontainers, secrets, and other resources in the cluster.\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 6 of 9\n\nAccess Kubelet API\r\nKubelet is the Kubernetes agent that is installed on each node. Kubelet is responsible for the proper execution of\r\npods that are assigned to the node. Kubelet exposes a read-only API service that does not require authentication\r\n(TCP port 10255). Attackers with network access to the host (for example, via running code on a compromised\r\ncontainer) can send API requests to the Kubelet API. Specifically querying https://[NODE IP]:10255/pods/\r\nretrieves the running pods on the node. https://[NODE IP]:10255/spec/ retrieves information about the node itself,\r\nsuch as CPU and memory consumption.\r\nNetwork mapping\r\nAttackers may try to map the cluster network to get information on the running applications, including scanning\r\nfor known vulnerabilities. By default, there is no restriction on pods communication in Kubernetes. Therefore,\r\nattackers who gain access to a single container, may use it to probe the network.\r\nAccess Kubernetes dashboard\r\nThe Kubernetes dashboard is a web-based UI that is used for monitoring and managing the Kubernetes cluster.\r\nThe dashboard allows users to perform actions in the cluster using its service account (kubernetes-dashboard) with\r\nthe permissions that are determined by the binding or cluster-binding for this service account. Attackers who gain\r\naccess to a container in the cluster, can use its network access to the dashboard pod. Consequently, attackers may\r\nretrieve information about the various resources in the cluster using the dashboard’s identity.\r\nInstance Metadata API\r\nCloud providers provide instance metadata service for retrieving information about the virtual machine, such as\r\nnetwork configuration, disks, and SSH public keys. This service is accessible to the VMs via a non-routable IP\r\naddress that can be accessed from within the VM only. Attackers who gain access to a container, may query the\r\nmetadata API service for getting information about the underlying node. For example, in Azure, the following\r\nrequest would retrieve all the metadata information of an instance: http:///metadata/instance?api-version=2019-\r\n06-01\r\n8. Lateral movement\r\nThe lateral movement tactic consists of techniques that are used by attackers to move through the victim’s\r\nenvironment. In containerized environments, this includes gaining access to various resources in the cluster from a\r\ngiven access to one container, gaining access to the underlying node from a container, or gaining access to the\r\ncloud environment.\r\nAccess cloud resources\r\nAttackers may move from a compromised container to the cloud environment. (See “4: Access cloud resources”\r\nfor details).\r\nContainer service account\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 7 of 9\n\nAttackers who gain access to a container in the cluster may use the mounted service account token for sending\r\nrequests to the API server, and gaining access to additional resources in the cluster. (See “6: Access container\r\nservice account” for more details.)\r\nCluster internal networking\r\nKubernetes networking behavior allows traffic between pods in the cluster as a default behavior. Attackers who\r\ngain access to a single container may use it for network reachability to another container in the cluster.\r\nApplications credentials in configuration files\r\nDevelopers store secrets in the Kubernetes configuration files, for example, as environment variables in the pod\r\nconfiguration. Using those credentials attackers may gain access to additional resources inside and outside the\r\ncluster. (See “6: Application credentials in configuration files” for more details.)\r\nWritable volume mounts on the host\r\nAttackers may attempt to gain access to the underlying host from a compromised container. (See “3: Writable\r\nhostPath mount” for more details.)\r\nAccess Kubernetes dashboard\r\nAttackers who have access to the Kubernetes dashboard may manage the cluster resources and also run their code\r\non the various containers in the cluster using the built-in “exec” capability of the dashboard. (See “7: Access\r\nKubernetes dashboard” for more details.)\r\nAccess tiller endpoint\r\nHelm is a popular package manager for Kubernetes maintained by CNCF. Tiller is the server-side component of\r\nHelm up to version 2.\r\nTiller exposes internal gRPC endpoint in the cluster, listens to port 44134. By default, this endpoint does not\r\nrequire authentication. Attackers may run code on any container that is accessible to the tiller’s service and\r\nperform actions in the cluster, using the tiller’s service account, which often has high privileges.\r\n9. Impact\r\nThe Impact tactic consists of techniques that are used by attackers to destroy, abuse, or disrupt the normal\r\nbehavior of the environment.\r\nData destruction\r\nAttackers may attempt to destroy data and resources in the cluster. This includes deleting deployments,\r\nconfigurations, storage, and compute resources.\r\nResource hijacking\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 8 of 9\n\nAttackers may abuse a compromised resource for running tasks. A common abuse is to use compromised\r\nresources for running digital currency mining. Attackers who have access to a container in the cluster or have\r\npermissions to create new containers may use them for such activity.\r\nDenial of service\r\nAttackers may attempt to perform a denial of service attack, which makes the service unavailable to the legitimate\r\nusers. In container clusters, this include attempts to block the availability of the containers themselves, the\r\nunderlying nodes, or the API server.\r\nUnderstanding the attack surface of containerized environments is the first step of building security solutions for\r\nthese environments. The matrix that was presented above can help organizations identify the current gaps in their\r\ndefenses’ coverage against the different threats that target Kubernetes. Azure Security Center can help you protect\r\nyour containers environment. Learn more about Azure Security Center’s support for container security.\r\nSource: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nhttps://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/"
	],
	"report_names": [
		"attack-matrix-kubernetes"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "eb3f4e4d-2573-494d-9739-1be5141cf7b2",
			"created_at": "2022-10-25T16:07:24.471018Z",
			"updated_at": "2026-04-10T02:00:05.002374Z",
			"deleted_at": null,
			"main_name": "Cron",
			"aliases": [],
			"source_name": "ETDA:Cron",
			"tools": [
				"Catelites",
				"Catelites Bot",
				"CronBot",
				"TinyZBot"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434378,
	"ts_updated_at": 1775791457,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/5f899ee38719ae1f42edb8c50c06c7d91526c909.pdf",
		"text": "https://archive.orkl.eu/5f899ee38719ae1f42edb8c50c06c7d91526c909.txt",
		"img": "https://archive.orkl.eu/5f899ee38719ae1f42edb8c50c06c7d91526c909.jpg"
	}
}