[![Logo](https://www.paloaltonetworks.com/wp-content/uploads/2021/07/PANW_Parent.png)](https://www.paloaltonetworks.com/) [![Unit42 Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/unit42-logo-white.svg)](https://unit42.paloaltonetworks.com/) Menu * [Tools](https://unit42.paloaltonetworks.com/tools/) * [ATOMs](https://unit42.paloaltonetworks.com/atoms/) * [Security Consulting](https://www.paloaltonetworks.com/unit42) * [About Us](https://unit42.paloaltonetworks.com/about-unit-42/) * [**Under Attack?**](https://start.paloaltonetworks.com/contact-unit42.html) English * [English](https://unit42.paloaltonetworks.com/kubernetes-privilege-escalation/) * [Japanese](https://unit42.paloaltonetworks.com/ja/kubernetes-privilege-escalation/) * [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/ "Threat Research") * [Learning Hub](https://unit42.paloaltonetworks.com/category/learning-hub/ "Learning Hub") [Learning Hub](https://unit42.paloaltonetworks.com/category/learning-hub/) # Mitigating RBAC-Based Privilege Escalation in Popular Kubernetes Platforms ![Clock Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-clock.svg) 9 min read Related Products [![Prisma Cloud icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/prisma_RGB_logo_Icon_Color.png)Prisma Cloud](https://unit42.paloaltonetworks.com/product-category/prisma-cloud/ "Prisma Cloud") * ![Profile Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-profile-grey.svg) By: * [Yuval Avrahami](https://unit42.paloaltonetworks.com/author/yuval-avrahami/) * ![Published Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-calendar-grey.svg) Published:January 27, 2023 * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-category.svg) Categories: * [Learning Hub](https://unit42.paloaltonetworks.com/category/learning-hub/) * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-tags-grey.svg) Tags: * [Cloud Security](https://unit42.paloaltonetworks.com/tag/cloud-security/) * [Container escape](https://unit42.paloaltonetworks.com/tag/container-escape/) * [Containers](https://unit42.paloaltonetworks.com/tag/containers/) * [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/) * [Privilege escalation](https://unit42.paloaltonetworks.com/tag/privilege-escalation/) * [![Download Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-download.svg)](https://unit42.paloaltonetworks.com/kubernetes-privilege-escalation/?pdf=download&lg=en&_wpnonce=279fa6c5e6 "Click here to download") * [![Print Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-print.svg)](https://unit42.paloaltonetworks.com/kubernetes-privilege-escalation/?pdf=print&lg=en&_wpnonce=279fa6c5e6 "Click here to print") Share![Down arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/down-arrow.svg) * ![Link Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-share-link.svg) * [![Link Email](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-sms.svg)](mailto:?subject=Mitigating%20RBAC-Based%20Privilege%20Escalation%20in%20Popular%20Kubernetes%20Platforms&body=Check%20out%20this%20article%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F "Share in email") * [![Facebook Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-fb-share.svg)](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F "Share in Facebook") * [![LinkedIn Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-linkedin-share.svg)](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F&title=Mitigating%20RBAC-Based%20Privilege%20Escalation%20in%20Popular%20Kubernetes%20Platforms "Share in LinkedIn") * [![Twitter Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-twitter-share.svg)](https://twitter.com/intent/tweet?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F&text=Mitigating%20RBAC-Based%20Privilege%20Escalation%20in%20Popular%20Kubernetes%20Platforms "Share in Twitter") * [![Reddit Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-reddit-share.svg)](https://www.paloaltonetworks.com//www.reddit.com/submit?url=https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F&ts=markdown "Share in Reddit") * [![Mastodon Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-mastodon-share.svg)](https://mastodon.social/share?text=Mitigating%20RBAC-Based%20Privilege%20Escalation%20in%20Popular%20Kubernetes%20Platforms%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fkubernetes-privilege-escalation%2F "Share in Mastodon") ## Executive Summary Prisma Cloud and Unit 42 recently released a [report examining the use of powerful credentials](https://www.paloaltonetworks.com/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms) in popular Kubernetes platforms, which found most platforms install privileged infrastructure components that could be abused for privilege escalation. We're happy to share that, as of today, all platforms mentioned in our report have addressed built-in node-to-admin privilege escalation. However, it's possible third party add-ons might reintroduce the issue. In the research we presented at [KubeCon EU and BlackHat USA](https://www.youtube.com/watch?v=PGsJ4QTlKlQ), we found that in half the platforms, any container escape had previously allowed for a full cluster compromise because all nodes hosted admin-equivalent credentials. Most of the platforms mentioned in our report made their infrastructure unprivileged by default, while one did so through an optional add-on. Stripping permissions is often complex, and we recognize fixing this is no small matter. We'd like to thank Azure Kubernetes Service (AKS), AWS Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), RedHat OpenShift Container Platform, Antrea and Calico for working to harden their access control. We provide a short recap of our research and look into the different mitigations the platforms implemented to address privilege escalation and powerful permissions in Kubernetes. If you're interested in evaluating your own cluster's Role Based Access Control (RBAC) posture, try [rbac-police](https://github.com/PaloAltoNetworks/rbac-police), our open-source RBAC analyzer for Kubernetes. [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) users can catch Kubernetes misconfigurations like excessive RBAC permissions before they're deployed to the cluster via the [Cloud Code Security](https://www.paloaltonetworks.com/prisma/cloud/cloud-code-security) (CCS) module. In the runtime phase, users can rely on the built-in [admission controller for Kubernetes](https://docs.paloaltonetworks.com/prisma/prisma-cloud/21-04/prisma-cloud-compute-edition-admin/access_control/open_policy_agent) to enforce policies that alert on suspicious activity in their clusters, including Kubernetes privilege escalation. | **Related Unit 42 Topics** | [Privilege Escalation](https://unit42.paloaltonetworks.com/tag/privilege-escalation/), [Cloud Security](https://unit42.paloaltonetworks.com/tag/cloud-security/), [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/), [Containers](https://unit42.paloaltonetworks.com/tag/containers/), [Container Escape](https://unit42.paloaltonetworks.com/tag/container-escape/) | |----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ## **Recap: Powerful Permissions Everywhere** Kubernetes managed services, distributions and add-ons install a set of system pods into our cluster to manage its infrastructure and enable core functions such as networking, DNS and logging. Commonly, these pods are deployed via [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) that distribute them onto every node in the cluster. If those DaemonSets' permissions are loosely granted, they could inadvertently spread powerful credentials throughout the cluster. This could be abused for privilege escalation, as shown in Figure 1. ![Image 1 is a diagram showing how a threat actor exploits DaemonSet credentials to spread in a cluster. It shows the escaped container, api server, and the pods.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-1.png) Figure 1. An attacker who escaped a container exploits the credentials of a powerful DaemonSet to spread in the cluster. To understand the prevalence of powerful DaemonSets, we analyzed popular Kubernetes platforms---managed services, distributions and container network interfaces (CNIs)---to identify privileged infrastructure components. We found that**most platforms ran powerful DaemonSets**, installing privileged credentials onto every node in the cluster. As shown in Figure 2, in half the platforms, those credentials were admin-equivalent, allowing a single container escape to compromise the entire cluster. ![Image 2 is a pie chart showing the percentage of platforms where a container escape led to a complete cluster takeover. 50% of credentials used were admin equivalent, with the some prerequisites and no prerequisites splitting the remainder.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-2.png) Figure 2. Percentage of platforms where a container escape allowed a complete cluster takeover. We believe powerful DaemonSets became common for three main reasons: 1. **Historically, Kubernetes clusters weren't secured by default** . In environments where crucial components like Kubelets allowed unauthenticated access, maintaining a least-privileged RBAC posture wasn't a priority. The infrastructure built then set a precedent for powerful DaemonSets. 2. **Some Kubernetes permissions are simply too broad** . This means they authorize a large set of operations. Often, granting a service account the ability to perform a necessary but sensitive operation implicitly authorizes it to perform other, potentially harmful operations. RBAC is not a great model for many of these use cases, and an attribute-based access control model that matches some attribute of the principal to some attribute of the resource would often make more sense. 3. **Certain** **permissions appear benign, but are in fact quite powerful** . If someone believes a permission is harmless, they won't have second thoughts about granting it. For example, the ability to update the status of pods implicitly allows deleting pods that are part of ReplicaSets. ## Mitigation After identifying a powerful DaemonSet, we reached out to the relevant platform and started a discussion on mitigation. The response was extremely positive -- the teams understood the issue and wanted to resolve it. Mitigations were developed, tested and deployed in recent months. And as of today, all of the privilege escalation attacks we identified are resolved. Thanks to the work done by the different platforms, the Kubernetes landscape is a safer one, where nodes aren't admins by default. In the following sections, we'll highlight the different approaches platforms took to address powerful DaemonSets in their offerings. ## **Strip Permissions** The simplest way to address a risky permission is to remove it. A number of platforms identified certain risky permissions that weren't explicitly necessary, and they removed them. Some permissions were made safe by scoping them down to certain [resourceNames](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#referring-to-resources) or subresources. For example, Cilium found that the "delete pods" permission wasn't explicitly necessary for their DaemonSet to operate correctly, and they [removed it](https://github.com/cilium/cilium/pull/19053). Openshift was able to [strip the "update nodes" permission](https://github.com/openshift/cluster-network-operator/pull/1350) from their software-defined network (sdn) DaemonSet, because the function that relied on it could be replaced with an unprivileged implementation. ## Restrict via Admission Control A common use case for DaemonSets is local node management, where each DaemonSet pod manages its local node. Unfortunately, Kubernetes doesn't support scoping down a DaemonSet pod's permissions to its local node. Thus every pod in the DaemonSet must be authorized to manage all nodes, not just its local one. This allows attackers who take over a node to abuse the credentials of the local DaemonSet pod to compromise other nodes and spread in the cluster. Both AKS and EKS ran a DaemonSet that had pods that needed to update their local node. Unfortunately, the only way built in to Kubernetes to grant this permission was to permit every pod in the DaemonSet to update every node in the cluster. An attacker who compromised a node could abuse the DaemonSet's token to [taint](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) other nodes, allowing it to steal pods. This attack is carried out in three steps, illustrated in Figure 3. 1. Add a NoSchedule taint to every node in the cluster beside the compromised one, making the compromised node the only available node in the cluster. 2. Add a NoExecute taint to the node hosting the target pod to force Kubernetes to evict it and delete its pods. 3. Kubernetes recreates the target pod, and can now only schedule it on the one available node in the cluster, which is the compromised node. ![Image 3 is a diagram showing how a threat actor compromises a node to taint other nodes in three steps. Step 1, the left column, is where the actor uses NoSchedule to taint pods in a node. Step 2, the middle column, is where the NoExecute Tain is added to the node hosting the target pod. Kubernetes then evicts the target pod and deletes its pods. In step 3, the right column, Kubernetes recreates the target pot, which is in a compromised node.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-3.png) Figure 3. Abusing a DaemonSet's "update nodes" permission to manipulate taints in order to steal pods. The DaemonSets on EKS and AKS needed the "update nodes" permission, so simply removing it wasn't a valid solution. Instead, both platforms were able to mitigate the attack using custom [validating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks). ### EKS - Restrict by Operation In EKS, the aws-node DaemonSet needed to update certain node attributes, but not taints. So if an aws-node pod unexpectedly attempts to taint a node, it's likely an attack. The EKS team implemented a validating admission webhook that intercepts node update requests, and blocks attempts to manipulate taints that are issued by the aws-node service account. You can see this in action in Figure 4, below. ![Image 4 is a screenshot of many lines of code where EKS is preventing the aws-node pod from tainting nodes.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-4.png) Figure 4. EKS prevents the aws-node pod from tainting nodes. ### AKS - Restrict by Target AKS had a slightly more difficult situation to contend with. Their cloud-node-manager DaemonSet does taint nodes, so blocking taints altogether wasn't a valid option. To be exact, each cloud-node-manager only needed to taint its hosting node. AKS used that to mitigate the attack. They wrote a validating admission webhook that intercepts node update requests, and identifies which cloud-node-manager pod issued the request. If a cloud-node-manager pod attempts to update a node that isn't its hosting one, the request is denied. As shown in Figure 5, if an attacker attempts to abuse a cloud-node-manager pod's credentials, they are denied. ![Image 5 is a screenshot of many lines of code demonstrating am attacker denied attempts to abuse a cloud-node-manager pod's credentials.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-5.png) Figure 5. AKS prevents the cloud-node-manager pod from tainting other nodes. To function correctly, this admission webhook must know which pod issued the request, not only which service account. This is possible thanks to a recent Kubernetes enhancement, [bound service account tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md#summary). In the past, a token only referenced the service account it represents. Now, a pod's service account token also includes a claim that specifies the pod the token was issued for. Admission controllers can use that claim to identify which pod a request originated from. This webhook nicely demonstrates how bound tokens enable node-local authorization for DaemonSet pods. It's possible that in the future, Kubernetes would have built-in support for that functionality, without the need for a custom admission webhook. ## **Move Privileged Functionality Elsewhere** To carry out privileged tasks, someone in the cluster needs to possess powerful credentials. Because DaemonSets' credentials are widely distributed, they're not the best fit for carrying out privileged tasks. Several platforms addressed powerful DaemonSets by having control plane controllers or non-DaemonSet pods carry out privileged tasks instead. DaemonSets' powerful permission could then be removed. For example, in GKE clusters running Dataplane v2 the anted DaemonSet was authorized to update pods and nodes for certain tasks. These permissions are risky, and could also be abused for a number of privilege escalation attacks. By having the control plane take care of pod and node updates, GKE was able to remove these powerful permissions from the anted DaemonSet. ## **Recommendations** Even when the underlying Kubernetes infrastructure is configured to maintain appropriate privilege boundaries, add-ons and applications that are misconfigured with excessive permissions can still re-introduce the same attack paths to a cluster. Below are best practices for hardening your cluster's RBAC posture and preventing intracluster privilege escalation. * Follow the principle of least-privilege. Only grant explicitly required permissions. When possible, scope down permissions to specific namespaces, resources names, or subresources. * Add guardrails to your Kubernetes Infrastructure-as-Code (IaC) continuous integration/continuous delivery (CI/CD) pipelines. This will prevent developers from unintentionally granting powerful permissions to service accounts. [Checkov](https://www.checkov.io/), an open-source IaC scanner, [supports a number of Kubernetes checks](https://docs.bridgecrew.io/docs/ensure-roles-and-clusterroles-that-grant-permissions-to-bind-rolebindings-or-clusterrolebindings-are-minimized) that alert on excessive RBAC permissions, as shown below in Figure 6. * Routinely review your RBAC posture. This allows you to identify potential threats and overly powerful identities. Ensure powerful permissions aren't granted to less trusted or publicly exposed pods. Consider using automated tools like [rbac-police](https://github.com/PaloAltoNetworks/rbac-police). * Refrain from assigning tasks requiring privileged credentials to DaemonSets. Control plane controllers or deployments are preferable in this instance. * Separate resources and workloads requiring different trust levels into different namespaces. * Use [admission control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to implement fine grained authorization for permissions that cannot be expressed in RBAC. When possible, implement a safe operation allowlist to block unexpected and malicious requests from powerful service accounts. * Isolate powerful pods on separate nodes from untrusted or publicly-exposed ones using scheduling constraints like [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/), [NodeAffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) rules, or [PodAntiAfinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#types-of-inter-pod-affinity-and-anti-affinity) rules. ![Image 6 is a screenshot of many lines of code where Chekhov, a cloud CL infrastructure scanner, alerts on a ClusterRole configured with powerful permissions. It has warned of on over-powered role.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/01/word-image-126770-6.png) Figure 6: Checkov alerts on a ClusterRole configured with powerful permissions. Your cluster's threat model should be taken into account when implementing industry best practices. Kubernetes is a platform for building platforms, meaning a cluster's threat model varies heavily depending on its architecture. The above guidelines tackle intracluster privilege escalation. If you're building clusters with different trust levels, intracluster privilege is a major threat. Below are a few examples for clusters hosting different trust levels: * Multitenant clusters hosting possibly malicious tenants/workloads * Running different teams on a single cluster * Deploying multiple applications across a large cluster On the other hand, if you're running small clusters that are each dedicated to a single application, then it makes more sense to invest in segregating those clusters from one another and from external services. When the cluster doesn't host different trust levels, preventing privilege escalation inside it shouldn't be a top priority. That being said, **detecting** privilege escalation attacks can still help identify breaches. ## **Conclusion** Maintaining a secure RBAC posture in Kubernetes is complex, both for platforms and users. When leading platforms enforce hardened defaults, it's easier for Kubenetes users to adopt secure architectures. We'd like to thank each of the platforms mentioned in this blog for taking the difficult problem of unprivileged infrastructure head on, and coming up with creative implementations to solve it. We recommend Kubernetes users and platforms automate the detection of RBAC misconfigurations in their CI/CD pipelines through tools like [Checkov](https://www.checkov.io/) and [rbac-police](https://github.com/PaloAltoNetworks/rbac-police). For managed services, even when an infrastructure component requires risky permissions, a validating admission webhook might be able to prevent misuse. See our report, [Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms](https://www.paloaltonetworks.com/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms), for more information. [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) users are encouraged to read the report's "Prisma Cloud" section to learn how Prisma's [Kubernetes IaC scanning capabilities](https://www.paloaltonetworks.com/prisma/cloud/cloud-code-security) and the built-in [admission controller for Kubernetes](https://docs.paloaltonetworks.com/prisma/prisma-cloud/21-04/prisma-cloud-compute-edition-admin/access_control/open_policy_agent) can tackle the challenges of securing Kubernetes identities. ## **Additional Resources** * [Kubernetes Privilege Escalation: Excessive Permissions in Popular Platforms](https://www.paloaltonetworks.com/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms) * [Trampoline Pods: Node to Admin PrivEsc Built Into Popular K8s Platforms](https://www.youtube.com/watch?v=PGsJ4QTlKlQ) * [Privileged pod escalations in Kubernetes and GKE](https://security.googleblog.com/2022/05/privileged-pod-escalations-in.html) * [Checkov](https://www.checkov.io/) * [rbac-police](https://github.com/PaloAltoNetworks/rbac-police) Back to top ### Tags * [Cloud Security](https://unit42.paloaltonetworks.com/tag/cloud-security/ "Cloud Security") * [Container escape](https://unit42.paloaltonetworks.com/tag/container-escape/ "container escape") * [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers") * [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/ "Kubernetes") * [Privilege escalation](https://unit42.paloaltonetworks.com/tag/privilege-escalation/ "privilege escalation") [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") [Next: Chinese PlugX Malware Hidden in Your USB Devices?](https://unit42.paloaltonetworks.com/plugx-variants-in-usbs/ "Chinese PlugX Malware Hidden in Your USB Devices?") ### Table of Contents * ### Related Articles * [Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy](https://unit42.paloaltonetworks.com/siemens-rox-ii-zero-day-vulnerabilities/ "article - table of contents") * [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/ "article - table of contents") * [Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/ "article - table of contents") ## Related Threat Research Resources ![Pictorial representation of post-exploitation identity misuse in SPIFFE/SPIRE. Close-up of a person wearing glasses, with computer code reflected in the lenses.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/12_Security-Technology_Category_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) September 10, 2026 [#### The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE](https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/) * [API](https://unit42.paloaltonetworks.com/tag/api/ "API") * [Cryptographic](https://unit42.paloaltonetworks.com/tag/cryptographic/ "cryptographic") * [JSON](https://unit42.paloaltonetworks.com/tag/json/ "JSON") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/kubernetes-spiffe-spire-identity-spoofing/ "The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE") ![Pictorial representation of a pay-per-install threat group campaign prodiving infection service for spreading malware. A close-up of a computer circuit board with a central microchip is depicted. Red digital data streams in the form of glowing binary numbers and arrows appear to flow in and out of the chip, symbolizing data processing and transfer. The scene is illuminated with a futuristic blue and red glow.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/04_Malware_Category_1920x900-6-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) September 9, 2026 [#### Untracked Nightmares: The Threats Hiding Behind Commodity Infrastructure](https://unit42.paloaltonetworks.com/ppi-network-malware-campaign-analysis/) * [ARKTunnel](https://unit42.paloaltonetworks.com/tag/arktunnel/ "ARKTunnel") * [C2](https://unit42.paloaltonetworks.com/tag/c2/ "C2") * [CL-CRI-1171](https://unit42.paloaltonetworks.com/tag/cl-cri-1171/ "CL-CRI-1171") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ppi-network-malware-campaign-analysis/ "Untracked Nightmares: The Threats Hiding Behind Commodity Infrastructure") ![Pictorial representation of attackers using AI tools to target Latin American organizations. A vibrant cityscape with silhouettes of numerous people walking along a bustling street. The scene is illuminated by bright urban lights and digital-like particles, creating a dynamic and futuristic atmosphere.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/AdobeStock_768915868-2-1-786x373.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) September 3, 2026 [#### Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America](https://unit42.paloaltonetworks.com/ai-tool-use-targeting-latam-orgs/) * [Agentic AI](https://unit42.paloaltonetworks.com/tag/agentic-ai/ "Agentic AI") * [ChatGPT](https://unit42.paloaltonetworks.com/tag/chatgpt/ "ChatGPT") * [CL-CRI-1131](https://unit42.paloaltonetworks.com/tag/cl-cri-1131/ "CL-CRI-1131") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ai-tool-use-targeting-latam-orgs/ "Attackers Expose Ongoing AI Tool Use Targeting Organizations in Latin America") ![Pictorial representation of a woman in glasses viewing a reflection of a monitor screen. The reflection features multicolored numbers, arrows, and graphs.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/07_Opinion_Overview_1920x900-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/08/Insights-icon-white.svg)Insights](https://unit42.paloaltonetworks.com/category/insights/) September 2, 2026 [#### An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation](https://unit42.paloaltonetworks.com/ai-assisted-cyber-attack-inside-a-unit-42-investigation/) * [Agentic AI](https://unit42.paloaltonetworks.com/tag/agentic-ai/ "Agentic AI") * [Frontier AI](https://unit42.paloaltonetworks.com/tag/frontier-ai/ "Frontier AI") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ai-assisted-cyber-attack-inside-a-unit-42-investigation/ "An AI-Assisted Cyber Attack: Inside a Unit 42 Investigation") ![Pictorial representation of vishing campaigns in Microsoft Teams. A digital image of a skull formed by blue binary code on a black background, with scattered ones and zeros and digital noise, symbolizes how stealthy prompt injection attacks can exploit AI logic to bypass security controls.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/01_Malware_Category_1920x900-5-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 31, 2026 [#### Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams](https://unit42.paloaltonetworks.com/spring-ring-voice-phishing-campaigns/) * [Cloaked Ursa](https://unit42.paloaltonetworks.com/tag/cloaked-ursa/ "Cloaked Ursa") * [Entra ID](https://unit42.paloaltonetworks.com/tag/entra-id/ "Entra ID") * [Microsoft Teams](https://unit42.paloaltonetworks.com/tag/microsoft-teams/ "Microsoft Teams") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/spring-ring-voice-phishing-campaigns/ "Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams") ![Pictorial representation of AI-enabled malware. A vibrant digital interface displaying various icons and graphs, resembling a futuristic network or data analysis dashboard. The scene is illuminated with glowing lights and patterns.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/AdobeStock_1270203474-2-1-786x368.png) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 25, 2026 [#### The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution](https://unit42.paloaltonetworks.com/ai-enabled-malware-analysis/) * [Backdoor](https://unit42.paloaltonetworks.com/tag/backdoor/ "backdoor") * [Bitcoin](https://unit42.paloaltonetworks.com/tag/bitcoin/ "Bitcoin") * [DLL hijacking](https://unit42.paloaltonetworks.com/tag/dll-hijacking/ "DLL hijacking") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ai-enabled-malware-analysis/ "The State of AI-Enabled Malware August 2026: From Brand Abuse to Agentic Execution") ![Pictorial representation of identity abuse through trusted communication channels. Close-up view of a digital screen displaying a glitched and pixelated image of a skull-like shape.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/02_Malware_Category_1920x900-2-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 20, 2026 [#### Identity Abuse Through Trusted Communication Channels](https://unit42.paloaltonetworks.com/communication-channel-identity-risks/) * [Authentication](https://unit42.paloaltonetworks.com/tag/authentication/ "authentication") * [Identity theft](https://unit42.paloaltonetworks.com/tag/identity-theft/ "identity theft") * [Malware](https://unit42.paloaltonetworks.com/tag/malware/ "malware") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/communication-channel-identity-risks/ "Identity Abuse Through Trusted Communication Channels") ![Pictorial representation of Kimwolf botnet malware family. Digital screen with a warning sign reading "Malware." The background features lines of computer code and graphics, creating a sense of cybersecurity threat.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/07_Malware_Category_1920x900-3-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 11, 2026 [#### Kimwolf v7: An Evolution of the Kimwolf Botnet](https://unit42.paloaltonetworks.com/kimwolf-v7-botnet-malware/) * [Android APK](https://unit42.paloaltonetworks.com/tag/android-apk/ "Android APK") * [Ethereum](https://unit42.paloaltonetworks.com/tag/ethereum/ "Ethereum") * [HTTP](https://unit42.paloaltonetworks.com/tag/http/ "HTTP") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/kimwolf-v7-botnet-malware/ "Kimwolf v7: An Evolution of the Kimwolf Botnet") ![Pictorial representatiom pf Aeternum's blockchain C2. A close-up of a computer circuit board with a central microchip is depicted. Red digital data streams in the form of glowing binary numbers and arrows appear to flow in and out of the chip. The scene is illuminated with a futuristic blue and red glow.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/04_Malware_Category_1920x900-4-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 10, 2026 [#### The Permanent Threat: Analyzing Aeternum's Blockchain-Based C2 Operations and Communications](https://unit42.paloaltonetworks.com/aeternum-blockchain-c2-analysis/) * [Aeternum](https://unit42.paloaltonetworks.com/tag/aeternum/ "Aeternum") * [Infection chain](https://unit42.paloaltonetworks.com/tag/infection-chain/ "infection chain") * [JSON](https://unit42.paloaltonetworks.com/tag/json/ "JSON") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/aeternum-blockchain-c2-analysis/ "The Permanent Threat: Analyzing Aeternum’s Blockchain-Based C2 Operations and Communications") ![Pictorial representation of Token-jacking. A person types on a laptop with multiple digital interface elements projected, including an "AI" icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/08/AdobeStock_1246251272-2-786x369.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) August 6, 2026 [#### Token Jacking: Cybercriminals Could Be Stealing Your AI Resources](https://unit42.paloaltonetworks.com/ai-token-jacking/) * [AI API](https://unit42.paloaltonetworks.com/tag/ai-api/ "AI API") * [AI gateway](https://unit42.paloaltonetworks.com/tag/ai-gateway/ "AI gateway") * [API keys](https://unit42.paloaltonetworks.com/tag/api-keys/ "API keys") [Read now ![Right arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-right-arrow-withtail.svg)](https://unit42.paloaltonetworks.com/ai-token-jacking/ "Token Jacking: Cybercriminals Could Be Stealing Your AI Resources") * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) * ![Slider arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/slider-arrow-left.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ![Enlarged Image]() ![Newsletter](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/03/unit42-footer-subscribe-desktop.png) ![UNIT 42 Small Logo](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/palo-alto-logo-small.svg) Get updates from Unit 42 ## Peace of mind comes from staying ahead of threats. Subscribe today. Your Email Subscribe for email updates to all Unit 42 threat research. By submitting this form, you agree to our [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use "Terms of Use") and acknowledge our [Privacy Statement.](https://www.paloaltonetworks.com/legal-notices/privacy "Privacy Statement") This site is protected by reCAPTCHA and the Google [Privacy Policy](https://policies.google.com/privacy) and [Terms of Service](https://policies.google.com/terms) apply. Invalid captcha! Subscribe ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) ![loader](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-loader.svg) {#footer} Products and Services * [AI-Powered Network Security Platform](https://www.paloaltonetworks.com/network-security) * [Secure AI by Design](https://www.paloaltonetworks.com/ai-security) * [Prisma AIRS](https://www.paloaltonetworks.com/ai-security/prisma-airs) * [AI Access Security](https://www.paloaltonetworks.com/sase/ai-access-security) * [Cloud Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions) * [Advanced Threat Prevention](https://www.paloaltonetworks.com/network-security/advanced-threat-prevention) * [Advanced URL Filtering](https://www.paloaltonetworks.com/network-security/advanced-url-filtering) * [Advanced WildFire](https://www.paloaltonetworks.com/network-security/advanced-wildfire) * [Advanced DNS Security](https://www.paloaltonetworks.com/network-security/advanced-dns-security) * [Enterprise Data Loss Prevention](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention) * [Enterprise IoT Security](https://www.paloaltonetworks.com/network-security/enterprise-device-security) * [Medical IoT Security](https://www.paloaltonetworks.com/network-security/medical-device-security) * [Industrial OT Security](https://www.paloaltonetworks.com/network-security/ot-security-solution) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security) * [Next-Generation Firewalls](https://www.paloaltonetworks.com/network-security/next-generation-firewall) * [Hardware Firewalls](https://www.paloaltonetworks.com/network-security/hardware-firewall-innovations) * [Software Firewalls](https://www.paloaltonetworks.com/network-security/software-firewalls) * [Strata Cloud Manager](https://www.paloaltonetworks.com/network-security/strata-cloud-manager) * [SD-WAN for NGFW](https://www.paloaltonetworks.com/network-security/sd-wan-subscription) * [PAN-OS](https://www.paloaltonetworks.com/network-security/pan-os) * [Panorama](https://www.paloaltonetworks.com/network-security/panorama) * [Secure Access Service Edge](https://www.paloaltonetworks.com/sase) * [Prisma SASE](https://www.paloaltonetworks.com/sase) * [Application Acceleration](https://www.paloaltonetworks.com/sase/app-acceleration) * [Autonomous Digital Experience Management](https://www.paloaltonetworks.com/sase/adem) * [Enterprise DLP](https://www.paloaltonetworks.com/sase/enterprise-data-loss-prevention) * [Prisma Access](https://www.paloaltonetworks.com/sase/access) * [Prisma Browser](https://www.paloaltonetworks.com/sase/prisma-browser) * [Prisma SD-WAN](https://www.paloaltonetworks.com/sase/sd-wan) * [Remote Browser Isolation](https://www.paloaltonetworks.com/sase/remote-browser-isolation) * [SaaS Security](https://www.paloaltonetworks.com/sase/saas-security) * [AI-Driven Security Operations Platform](https://www.paloaltonetworks.com/cortex) * [Cloud Security](https://www.paloaltonetworks.com/cortex/cloud) * [Cortex Cloud](https://www.paloaltonetworks.com/cortex/cloud) * [Application Security](https://www.paloaltonetworks.com/cortex/cloud/application-security) * [Cloud Posture Security](https://www.paloaltonetworks.com/cortex/cloud/cloud-posture-security) * [Cloud Runtime Security](https://www.paloaltonetworks.com/cortex/cloud/runtime-security) * [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) * [AI-Driven SOC](https://www.paloaltonetworks.com/cortex) * [Cortex XSIAM](https://www.paloaltonetworks.com/cortex/cortex-xsiam) * [Cortex XDR](https://www.paloaltonetworks.com/cortex/cortex-xdr) * [Cortex XSOAR](https://www.paloaltonetworks.com/cortex/cortex-xsoar) * [Cortex Xpanse](https://www.paloaltonetworks.com/cortex/cortex-xpanse) * [Unit 42 Managed Detection \& Response](https://www.paloaltonetworks.com/cortex/managed-detection-and-response) * [Managed XSIAM](https://www.paloaltonetworks.com/cortex/managed-xsiam) * [Next-Generation Identity Security](https://www.paloaltonetworks.com/idira) * [Privileged Access Management](https://www.paloaltonetworks.com/idira/human/privileged-access-management) * [Identity and Access Management](https://www.paloaltonetworks.com/idira/human/identity-and-access-management) * [Endpoint Privilege Manager](https://www.paloaltonetworks.com/idira/human/endpoint-privilege-manager) * [Identity Governance](https://www.paloaltonetworks.com/idira/human/identity-governance) * [Workforce Password Management](https://www.paloaltonetworks.com/idira/human/workforce-password-management) * [Agentic Identities](https://www.paloaltonetworks.com/idira/agentic) * [Secrets Management](https://www.paloaltonetworks.com/idira/machine/secrets-management) * [Unified Secrets Governance](https://www.paloaltonetworks.com/idira/machine/unified-secrets-governance) * [Application Credentials Delivery](https://www.paloaltonetworks.com/idira/machine/application-credentials-delivery) * [Vendor Privileged Access](https://www.paloaltonetworks.com/idira/human/vendor-privileged-access) * [Threat Intel and Incident Response Services](https://www.paloaltonetworks.com/unit42) * [Prepare for Emerging Risks](https://www.paloaltonetworks.com/unit42/frontier-ai-defense) * [Strengthen Your Defenses](https://www.paloaltonetworks.com/unit42/strengthen-your-defenses) * [Build Your Security Strategy](https://www.paloaltonetworks.com/unit42/build-your-security-strategy) * [Understand the Adversary](https://www.paloaltonetworks.com/unit42/threat-intelligence) * [Respond to a Cyber Attack](https://www.paloaltonetworks.com/unit42/respond) Company * [About Us](https://www.paloaltonetworks.com/about-us) * [Careers](https://jobs.paloaltonetworks.com/en/) * [Contact Us](https://www.paloaltonetworks.com/company/contact-sales) * [Corporate Responsibility](https://www.paloaltonetworks.com/about-us/corporate-responsibility) * [Customers](https://www.paloaltonetworks.com/customers) * [Investor Relations](https://investors.paloaltonetworks.com/) * [Location](https://www.paloaltonetworks.com/about-us/locations) * [Newsroom](https://www.paloaltonetworks.com/company/newsroom) Popular Links * [Blog](https://www.paloaltonetworks.com/blog/) * [Communities](https://www.paloaltonetworks.com/communities) * [Content Library](https://www.paloaltonetworks.com/resources) * [Cyberpedia](https://www.paloaltonetworks.com/cyberpedia) * [Event Center](https://events.paloaltonetworks.com/) * [Manage Email Preferences](https://start.paloaltonetworks.com/preference-center) * [Products A-Z](https://www.paloaltonetworks.com/products/products-a-z) * [Product Certifications](https://www.paloaltonetworks.com/legal-notices/trust-center/certifications) * [Report a Vulnerability](https://www.paloaltonetworks.com/security-disclosure) * [Sitemap](https://www.paloaltonetworks.com/sitemap) * [Tech Docs](https://docs.paloaltonetworks.com/) * [Unit 42](https://unit42.paloaltonetworks.com/) * [Do Not Sell or Share My Personal Information](https://panwedd.exterro.net/portal/dsar.htm?target=panwedd) ![Palo Alto Networks Logo](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/pan-logo-dark.svg) * [Privacy](https://www.paloaltonetworks.com/legal-notices/privacy) * [Trust Center](https://www.paloaltonetworks.com/legal-notices/trust-center) * [Terms of Use](https://www.paloaltonetworks.com/legal-notices/terms-of-use) * [Documents](https://www.paloaltonetworks.com/legal) Copyright © 2026 Palo Alto Networks. All Rights Reserved * [![Youtube](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/youtube-black.svg)](https://www.youtube.com/user/paloaltonetworks) * [![Podcast](https://www.paloaltonetworks.com/content/dam/pan/en_US/images/icons/podcast.svg)](https://www.paloaltonetworks.com/podcasts/threat-vector) * [![Facebook](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/facebook-black.svg)](https://www.facebook.com/PaloAltoNetworks/) * [![LinkedIn](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/linkedin-black.svg)](https://www.linkedin.com/company/palo-alto-networks) * [![Twitter](https://www.paloaltonetworks.com/etc/clientlibs/clean/imgs/social/twitter-x-black.svg)](https://twitter.com/PaloAltoNtwks) * EN Select your language ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg) ![Close button](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/close-modal.svg) ### Default Heading Read the article ![Right Arrow](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/right-arrow.svg) Seekbar ![Play](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-play-icon.svg) ![Pause](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/player-pause-icon1.svg) ![Volume](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-volume.svg) Volume ![Minimize](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-minimize.svg)