{
	"id": "8f520802-dd7f-4a8a-b5b6-2f532f3078fb",
	"created_at": "2026-04-06T00:17:25.56651Z",
	"updated_at": "2026-04-10T03:35:21.534642Z",
	"deleted_at": null,
	"sha1_hash": "d0179e3e2135b9015d4731b614040f77185a786e",
	"title": "Understanding the threat landscape for Kubernetes and containerized assets | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 282990,
	"plain_text": "Understanding the threat landscape for Kubernetes and\r\ncontainerized assets | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2025-04-23 · Archived: 2026-04-02 12:45:58 UTC\r\nThe dynamic nature of containers can make it challenging for security teams to detect runtime anomalies or pinpoint\r\nthe source of a security incident, presenting an opportunity for attackers to stay undetected. Microsoft Threat\r\nIntelligence has observed threat actors taking advantage of unsecured workload identities to gain access to resources,\r\nincluding containerized environments. Microsoft data showed that in the past year, 51% of workload identities were\r\ncompletely inactive, representing a potential attack vector for threat actors.\r\nMicrosoft released and updated the threat matrix for Kubernetes, an active knowledge base for security threats that\r\ntarget Kubernetes clusters, to systematically map the attack surface of Kubernetes. We also worked with MITRE to\r\ndevelop the ATT\u0026CK® for Containers matrix in 2021. As the adoption of containers-as-a-service among\r\norganizations rises, Microsoft Threat Intelligence continues to monitor the unique security threats that affect\r\ncontainerized environments.\r\nThreats in Kubernetes environments\r\nContainerized assets (including Kubernetes clusters, Kubernetes nodes, Kubernetes workloads, container registries,\r\ncontainer images, and more) are at risk of several different types of attacks. To fully secure containerized workloads,\r\norganizations must secure the containers and the code running within them, software dependencies and libraries,\r\ncontinuous integration and continuous delivery (CI/CD) pipelines, runtime, and more.\r\nThreats in Kubernetes environments can come from six primary areas:\r\nCompromised accounts: In cases where Kubernetes clusters are deployed in public clouds (such as Azure\r\nKubernetes Service (AKS) or Google Kubernetes Engine (GKE)), compromised cloud credentials could lead\r\nto cluster takeover, as attackers who have access to account credentials can get access to the cluster’s\r\nmanagement layer.\r\nVulnerable or misconfigured images: Images that are not updated regularly might contain vulnerabilities\r\nthat can be exploited in malicious attacks.\r\nEnvironment misconfigurations: An attacker with access to the Kubernetes API, either through exposed\r\nmanagement interfaces or lack of appropriate authentication/authorization controls, could completely take\r\ndown the server, deploy malicious containers, or hijack the entire cluster.\r\nApp-level attacks: Applications could be exploited through several typical methods, such as SQL injection,\r\ncross-site scripting, and remote file inclusion.\r\nNode-level attacks: Attackers can gain initial access through nodes (host machines that containers run on)\r\nthat run on vulnerable code or software, have open management interfaces such as SSH, or run commands\r\nfrom the cloud control plane. There is also the risk of pod escape, where a compromised pod can provide\r\naccess to the node or to other pods in the cluster.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 1 of 11\n\nUnauthorized traffic: Insecure networking between the different containers within the cluster and between\r\nthe pods and outside world could be subject to malicious traffic if not secured.\r\nFigure 1. Overview of attacks against Kubernetes environments\r\nCase study: Password spray attack leads to containers being used for cryptomining\r\nIn the past year, Microsoft Threat Intelligence has observed AzureChecker threats (tracked as Storm-1977) launching\r\npassword spray attacks against cloud tenants in the education sector. The attack involves the use of\r\nAzureChecker.exe, a Command Line Interface (CLI) tool that is being used by a wide range of threat actors.\r\nWe observed that AzureChecker.exe connected to sac-auth[.]nodefunction[.]vip to download AES-encrypted data that\r\nwhen decrypted reveals the list of password spray targets. The tool then also accepted the file accounts.txt, which\r\ncontained the username and password combinations to be used for the attack, as input. The threat actor then used the\r\ninformation from both files and posted the credentials to the target tenants for validation.\r\nMicrosoft Threat Intelligence was able to observe an instance of successful account compromise and found that the\r\nthreat actor leveraged a guest account to create a resource group within the compromised subscription. The threat\r\nactor then created more than 200 containers within the resource group and used them for cryptomining activity.  \r\nSecuring containerized environments\r\nThe following best practices can help secure containerized assets against commonly observed threats.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 2 of 11\n\nSecure code prior to deployment\r\nEnsuring that containers have secure code prior to deployment is essential to preventing issues during deployment\r\nand runtime. To facilitate this, Microsoft Defender for Cloud scans container images for vulnerabilities and\r\nmisconfigurations and alerts customers of issues before a container is deployed.\r\nDefender for Cloud DevOps also provides visibility into the security posture of the CI/CD platform. Additional best\r\npractices such as restricting access to DevOps tooling, using a secret store instead of hard-coding secrets in code or\r\ndocumentation, and using hardened DevOps workstations to build and deploy code can help prevent security issues\r\nbefore code is deployed.\r\nSecure container deployment and runtime\r\nContainer deployment refers to the phase of the lifecycle where container images are pulled from the static container\r\nregistry to be run on virtual machines hosts. During deployment, you should ensure the following best security\r\npractices:\r\nEnsure containers are immutable: Prevent patches from running containers whenever possible. As best\r\npractice, if you notice that a running container needs updates, you should rebuild the image and deploy the\r\nnew container. Introducing new code in running containers can introduce new vulnerabilities, bypass secure\r\ndevelopment lifecycle protections, as well as pose an operational risk in case a container is restarted and run\r\nagain with the original container image content without any runtime modifications.\r\nLeverage Admission Controllers: Configure policies to prevent containers from being deployed from\r\nuntrusted registries, from running out of alignment with the minimal Pod Security Standard that fits the pod\r\nrequirement (such as restricting root privileges), and from utilizing too many resources in the event of a\r\ndenial-of-service attack. These can be enforced with Azure Policy Add-On for Kubernetes.\r\nGate deployments of vulnerable images: Ensure that the containers being deployed are free of\r\nvulnerabilities and misconfigurations by running a vulnerability scan in the Build and Ship phases. Any image\r\nwith high or critical severity vulnerabilities should be blocked from deployment.\r\nContainer runtime refers to the phase of the lifecycle where containers are running on the virtual hosts. During\r\nruntime, monitor your running containers for any new vulnerabilities that might have been introduced during\r\nruntime. In cases where a container image was not scanned in build time or in registry before being deployed to the\r\ncluster, Microsoft Defender Vulnerability Management supports Azure vulnerability assessments.\r\nAdditionally, monitor each node, pod, and container during runtime for any sort of anomalous or malicious activity\r\nthat may be occurring:\r\nLook for malicious API calls and unusual activity using a monitoring system to identify any unusual\r\nKubernetes API server requests for malicious activity. Defenders can query Kubernetes API calls in Defender\r\nXDR advanced hunting using the CloudAuditEvents table.\r\nFor AKS clusters, Container Insights offers the ability to collect Syslog events from Linux nodes, to then be\r\naccessed within Azure’s built-in workbooks.\r\nDefender for Containers’ Agentless discovery for Kubernetes provides API-based discovery of Kubernetes clusters,\r\ntheir configurations, and deployments. Defender for Cloud also identifies runtime threats at both the API level and\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 3 of 11\n\nthe workload level. Additionally, organizations can use Microsoft Defender for Cloud to identify and remediate\r\nattack paths to address any potential attack vectors.\r\nSecure user accounts and permissions\r\nAttackers are increasingly using compromised identities for initial access and for establishing long-term persistence\r\nwithin an environment. If a compromised user has access to Kubernetes services, an attacker could use that identity\r\nto access those services using portal access or the command-line interface. In cases where Kubernetes clusters are\r\ndeployed in public clouds (such as AKS in Azure or GKE in Google Cloud Platform (GCP)), compromised cloud\r\ncredentials could lead to cluster takeover as attackers who have access to account credentials can get access to the\r\ncluster’s management layer.\r\nThe following recommendations, focused on requiring strong authentication to services and following the principle\r\nof least privilege, can help secure cloud credentials from compromise:\r\nUse strong authentication when exposing sensitive interfaces to the internet. For example, attacks were\r\nobserved against exposed Kubeflow and Argo workloads that were not configured to use OpenID Connect or\r\nother authentication methods.\r\nUse strong authentication methods to the Kubernetes API to help prevent attackers from gaining access to the\r\ncluster even if valid credentials such as kubeconfig were achieved. For example, in AKS use Entra ID\r\nauthentication instead of basic authentication. By using Entra ID authentication, a short-lived credential of the\r\ncluster is retrieved after authenticating to Entra ID.\r\nAvoid using the read-only endpoint of Kubelet in port 10255, which doesn’t require authentication. In newer\r\nversions of managed clusters, this port is disabled.\r\nImplement multifactor authentication (MFA).\r\nConfigure the Kubernetes role-based access controls (RBAC) for each user and service accounts to have only\r\nnecessary permissions. This applies also to other external authorization providers such as Azure RBAC in\r\nAKS.\r\nIn a managed cluster, Kubernetes credentials are often retrieved or generated by the cloud provider through\r\nAPI call. To reduce the attack surface, grant permissions to the cloud provider API only to necessary accounts.\r\nIn the case of Azure, make sure that only required identities have permissions to call:\r\n/subscriptions/resourceGroups/providers/Microsoft.ContainerService/managedClusters/listClusterUserCredential\r\nThe kubeconfig file can contain credentials of accounts that allow interaction with a cluster. By applying the\r\nleast privilege principle to all accounts, you can limit the impact of an account compromised through the\r\nkubeconfig file. To further limit misuse of the kubeconfig file, enable Microsoft Entra-based authentication to\r\nAKS and disable the local admin account, avoiding the use of the kubeconfig file altogether.\r\nThe Kubernetes project also lists the following recommendations for permissions and role assignment best practices:\r\nAvoid wildcard permissions, especially to all resources.\r\nUse RoleBinding instead of ClusterAdminBinding to give access within a namespace.\r\nAvoid adding users to the system:master group as it bypasses RBAC.\r\nUse impersonation rights for admins instead of adding to the cluster admin role. Audit and monitor when\r\nimpersonation is being done.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 4 of 11\n\nAvoid granting the escalate or bind permissions to roles when not needed, audit and monitor when escalation\r\nis being made.\r\nAvoid adding users to the system:unauthenticated group.\r\nLimit permissions to issue certificate signing requests (CSR) and certificates.\r\nAvoid granting users with create rights on service accounts/token, which could be exploited to create\r\nTokenRequests and issue tokens for existing service accounts.\r\nUsers with control over validatingwebhookconfigurations or mutatingwebhookconfigurations can control\r\nwebhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate\r\nadmitted objects\r\nSecure container images\r\nSecure the CI/CD environment. Secure code repositories and CI/CD environment by placing gates to restrict\r\nunauthorized access and modification of content. This can include enforcing RBAC permissions to access and\r\nmake changes to code, artifacts and build pipelines, ensure governed process for pull-request approval, apply\r\nbranch policies and others.\r\nApply image assurance policy to evaluate container images against vulnerabilities, malware, exposed secrets\r\nor other policies. By ensuring consistent and comprehensive image assurance policy across the build, ship,\r\nand run development stages. One approach of ensuring images pass assurance or compliance checks it to sign\r\nthe container images, so the image signature can be checked downstream when deploying to Kubernetes\r\nclusters at runtime.\r\nTake and store data backups from pod-mounted volumes for critical workloads. Ensure backup and storage\r\nsystems are hardened and kept separate from the Kubernetes environment to prevent compromise.\r\nRestrict network traffic\r\nThe Kubernetes API server is the gateway to the cluster. Restricting access to the API server, as well as restricting\r\nhow pods can communicate, can prevent unwanted access to the clusters management, even if an adversary gained\r\nvalid credentials to the cluster. The following best practices can help harden clusters against attacks.\r\nRestrict access to the API server using intrusion detection signatures, network policies, and a web application\r\nfirewall to block traffic at network boundaries to pods and services in a Kubernetes cluster. In managed\r\nclusters, cloud providers often support native built-in firewalls, which can restrict the IP addresses that are\r\nallowed to access the API server.\r\nImplement a Next-Generation Firewall (NGFW) such as Azure Firewall, which offers a solution for\r\nAKS to monitor inbound and outbound traffic. You can integrate Azure Firewall as well as several\r\nthird-party firewalls into Azure Sentinel to accumulate all logs into a centralized location. AKS also\r\nsupports Retina, a cloud-agnostic platform for analysis of Kubernetes’ workload traffic.\r\nUse Kubernetes network policies to control traffic and manage how pods communicate.\r\nAdapt a network intrusion prevention solution to a Kubernetes environment if needed, in order to route\r\nnetwork traffic destined to services through the security solution. In some cases, this can be done by\r\ndeploying a containerized version of a network intrusion prevention solution to the Kubernetes cluster\r\nand be part of the cluster network, and in some cases, routing ingress traffic to Kubernetes services\r\nthrough an external appliance, requiring that all ingress traffic only come from such an appliance.\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 5 of 11\n\nEnable Just In Time (JIT) access to the API server through Microsoft Entra conditional access. Employing JIT\r\nelevated access to the Kubernetes API server helps reduce the attack surface by allowing access only at\r\nspecific times, and through a governed escalation process. Enabling JIT access in Kubernetes is often done\r\ntogether with OpenID authentication, which includes processes and tools to manage JIT access. One example\r\nof such OpenID authentication is Azure Active Directory authentication to Kubernetes clusters. The JIT\r\napproval is performed in the cloud control plane level. Therefore, even if attackers have access to account\r\ncredentials, their access to the cluster is limited.\r\nLimit access to services over network. Avoid exposing sensitive interfaces insecurely to the internet or limit\r\naccess to it. Sensitive interfaces include management tools and applications that allow the creation of new\r\ncontainers in the cluster. Some of those services do not use authentication by default and are not intended to\r\nbe exposed. Examples of services that were exploited include Weave Scope, Apache NiFi, and more.\r\nIf services need to be exposed to the internet and are exposed using a LoadBalancer service, use IP\r\nrestriction (loadBalancerSourceRanges) when possible. This reduces the attack surface of the\r\napplication and can prevent attackers from being able to reach the sensitive interfaces.\r\nDetection details\r\nMicrosoft Defender for Cloud\r\nMicrosoft Defender for Containers provides security alerts on the cluster level and on the underlying cluster nodes by\r\nmonitoring both the control plane (the API server) and the containerized workload itself.\r\nExposed Postgres service with trust authentication configuration in Kubernetes detected (Preview)\r\nExposed Postgres service with risky configuration in Kubernetes detected (Preview)\r\nAttempt to create a new Linux namespace from a container detected\r\nA history file has been cleared\r\nAbnormal activity of managed identity associated with Kubernetes (Preview)\r\nAbnormal Kubernetes service account operation detected\r\nAn uncommon connection attempt detected\r\nAttempt to stop apt-daily-upgrade.timer service detected\r\nBehavior similar to common Linux bots detected (Preview)\r\nCommand within a container running with high privileges\r\nContainer running in privileged mode\r\nContainer with a sensitive volume mount detected\r\nCoreDNS modification in Kubernetes detected\r\nCreation of admission webhook configuration detected\r\nDetected file download from a known malicious source\r\nDetected suspicious file download\r\nDetected suspicious use of the nohup command\r\nDetected suspicious use of the useradd command\r\nDigital currency mining container detected\r\nDigital currency mining related behavior detected\r\nDocker build operation detected on a Kubernetes node\r\nExposed Kubeflow dashboard detected\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 6 of 11\n\nExposed Kubernetes dashboard detected\r\nExposed Kubernetes service detected\r\nExposed Redis service in AKS detected\r\nIndicators associated with DDOS toolkit detected\r\nK8S API requests from proxy IP address detected\r\nKubernetes events deleted\r\nKubernetes penetration testing tool detected\r\nNew container in the kube-system namespace detected\r\nNew high privileges role detected\r\nPossible attack tool detected\r\nPossible backdoor detected\r\nPossible command line exploitation attempt\r\nPossible credential access tool detected\r\nPossible Cryptocoinminer download detected\r\nPossible Log Tampering Activity Detected\r\nPossible password change using crypt-method detected\r\nPotential port forwarding to external IP address\r\nPotential reverse shell detected\r\nPrivileged container detected\r\nProcess associated with digital currency mining detected\r\nProcess seen accessing the SSH authorized keys file in an unusual way\r\nRole binding to the cluster-admin role detected\r\nSecurity-related process termination detected\r\nSSH server is running inside a container\r\nSuspicious file timestamp modification\r\nSuspicious request to Kubernetes API\r\nSuspicious request to the Kubernetes Dashboard\r\nPotential crypto coin miner started\r\nSuspicious password access\r\nPossible malicious web shell detected\r\nBurst of multiple reconnaissance commands could indicate initial activity after compromise\r\nSuspicious Download Then Run Activity\r\nAccess to kubelet kubeconfig file detected\r\nAccess to cloud metadata service detected\r\nMITRE Caldera agent detected\r\nRecent updates to Microsoft Defender for Cloud enhance its container security capabilities from development to\r\nruntime. Defender for Cloud now offers enhanced discovery, providing agentless visibility into Kubernetes\r\nenvironments, tracking containers, pods, and applications. The updates also strengthen security posture through\r\ncontinuous and granular scanning from build to runtime, helping maintain compliance and secure configurations\r\nacross the SDLC.\r\nDefender for Cloud’s native integration with Defender XDR enables threat protection with real-time monitoring,\r\nprioritizing vulnerabilities based on risk and enabling SOC analysts to detect and respond to threats faster through\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 7 of 11\n\nrich contextual insights and cloud-native response tools\r\nMicrosoft Defender for Endpoint\r\nMicrosoft Defender for Endpoint also detects threats on endpoints running container hosts, focusing on suspicious\r\nbehavior commonly observed on endpoints, including stealing locally stored credentials for accessing the cloud,\r\ndownloading and running malicious images, and privilege escalation from dockers to hosts.\r\nMicrosoft Defender External Attack Surface Management\r\nMicrosoft Defender External Attack Surface Management detects Docker and Kubernetes instances with known\r\nvulnerabilities or misconfigurations using the following alerts:\r\nASI: Open Docker Daemon API Service\r\nASI: Unauthenticated Kubelet API\r\nMicrosoft Security Copilot\r\nSecurity Copilot customers can use the standalone experience to create their own prompts or run the following pre-built promptbooks to automate incident response or investigation tasks related to this threat:\r\nIncident investigation\r\nMicrosoft User analysis\r\nThreat actor profile\r\nThreat Intelligence 360 report based on MDTI article\r\nVulnerability impact assessment\r\nNote that some promptbooks require access to plugins for Microsoft products such as Microsoft Defender XDR or\r\nMicrosoft Sentinel.\r\nHunting queries\r\nIn addition to the below hunting queries, the open-source tool KubiScan, developed by CyberArk Labs, can be used\r\nto scan clusters for risky permissions and users. Results can be used to manage RBAC within the environment and\r\neliminate unnecessary permissions; it can also be used in incident response to identify the potential exposure of\r\ncompromised users.\r\nMicrosoft Defender XDR\r\nIn addition to viewing alerts and incidents within Defender XDR, you can now use Azure Resource Manager (ARM)\r\nlogs as well as Kubernetes audits logs for further investigation using the advanced hunting capabilities.\r\nIf a hunting query provides a good indicator of malicious or unsanctioned activity in your environment, you can\r\ncreate a custom rule detection in the Defender XDR portal by going to the Advanced unting page \u003e Manage rules \u003e\r\nCreate custom detection.\r\nPrivileged pod deployment\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 8 of 11\n\nThe following query surfaces deployment of a privileged pod:\r\nCloudAuditEvents\r\n| where Timestamp \u003e ago(1d)\r\n| where DataSource == \"Azure Kubernetes Service\"\r\n| where OperationName == \"create\"\r\n| where RawEventData.ObjectRef.resource == \"pods\" and isnull(RawEventData.ObjectRef.subresource)\r\n| where RawEventData.ResponseStatus.code startswith \"20\"\r\n| extend PodName = RawEventData.RequestObject.metadata.name\r\n| extend PodNamespace = RawEventData.ObjectRef.namespace\r\n| mv-expand Container = RawEventData.RequestObject.spec.containers\r\n| extend ContainerName = Container.name\r\n| where Container.securityContext.privileged == \"true\"\r\n| extend Username = RawEventData.User.username\r\n| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace,\r\nContainerName, Username\r\nExec command\r\nThe following query identifies use of the exec command in the kube-system namespace:\r\nCloudAuditEvents\r\n| where Timestamp \u003e ago(1d)\r\n| where DataSource == \"Azure Kubernetes Service\"\r\n| where OperationName == \"create\"\r\n| where RawEventData.ObjectRef.resource == \"pods\" and RawEventData.ResponseStatus.code == 101\r\n| where RawEventData.ObjectRef.namespace == \"kube-system\"\r\n| where RawEventData.ObjectRef.subresource == \"exec\"\r\n| where RawEventData.ResponseStatus.code == 101\r\n| extend RequestURI = tostring(RawEventData.RequestURI)\r\n| extend PodName = tostring(RawEventData.ObjectRef.name)\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 9 of 11\n\n| extend PodNamespace = tostring(RawEventData.ObjectRef.namespace)\r\n| extend Username = tostring(RawEventData.User.username)\r\n| where PodName !startswith \"tunnelfront-\" and PodName !startswith \"konnectivity-\" and PodName\r\n!startswith \"aks-link\"\r\n| extend Commands = extract_all(@\"command=([^\\\u0026]*)\", RequestURI)\r\n| extend ParsedCommand = url_decode(strcat_array(Commands, \" \"))\r\n| project Timestamp, AzureResourceId , OperationName, IPAddress, UserAgent, PodName, PodNamespace,\r\nUsername, ParsedCommand\r\nCluster-admin role binding\r\nThe following query identifies the creation of cluster-admin role binding:\r\nCloudAuditEvents\r\n| where Timestamp \u003e ago(1d)\r\n| where OperationName == \"create\"\r\n| where RawEventData.ObjectRef.resource == \"clusterrolebindings\"\r\n| where RawEventData.ResponseStatus.code startswith \"20\"\r\n| where RawEventData.RequestObject.roleRef.name == \"cluster-admin\"\r\n| mv-expand Subject = RawEventData.RequestObject.subjects\r\n| extend SubjectName = tostring(Subject.name)\r\n| extend SubjectKind = tostring(Subject[\"kind\"])\r\n| extend BindingName = tostring(RawEventData.ObjectRef.name)\r\n| extend ActionTakenBy = tostring(RawEventData.User.username)\r\n| where ActionTakenBy != \"acsService\" //Remove FP\r\n| project Timestamp, AzureResourceId , OperationName, ActionTakenBy, IPAddress, UserAgent, BindingName,\r\nSubjectName, SubjectKind\r\nReferences\r\nKubiScan\r\nLearn Kubernetes Basics\r\nLearn more\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 10 of 11\n\nFor the latest security research from the Microsoft Threat Intelligence community, check out the Microsoft Threat\r\nIntelligence Blog: https://aka.ms/threatintelblog.\r\nTo get notified about new publications and to join discussions on social media, follow us on LinkedIn at\r\nhttps://www.linkedin.com/showcase/microsoft-threat-intelligence, and on X (formerly Twitter)\r\nat https://twitter.com/MsftSecIntel.\r\nTo hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat\r\nlandscape, listen to the Microsoft Threat Intelligence podcast: https://thecyberwire.com/podcasts/microsoft-threat-intelligence.\r\nSource: https://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nhttps://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://www.microsoft.com/en-us/security/blog/2025/04/23/understanding-the-threat-landscape-for-kubernetes-and-containerized-assets/"
	],
	"report_names": [
		"understanding-the-threat-landscape-for-kubernetes-and-containerized-assets"
	],
	"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": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "1ffc30fc-e99e-4d3b-a677-54aade3b7829",
			"created_at": "2025-05-29T02:00:03.222072Z",
			"updated_at": "2026-04-10T02:00:03.872869Z",
			"deleted_at": null,
			"main_name": "Storm-1977",
			"aliases": [],
			"source_name": "MISPGALAXY:Storm-1977",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434645,
	"ts_updated_at": 1775792121,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d0179e3e2135b9015d4731b614040f77185a786e.pdf",
		"text": "https://archive.orkl.eu/d0179e3e2135b9015d4731b614040f77185a786e.txt",
		"img": "https://archive.orkl.eu/d0179e3e2135b9015d4731b614040f77185a786e.jpg"
	}
}