[![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/gke-autopilot-vulnerabilities/) * [Japanese](https://unit42.paloaltonetworks.com/ja/gke-autopilot-vulnerabilities/) * [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/ "Threat Research") * [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/ "Cloud Cybersecurity Research") [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/) # Container Escape to Shadow Admin: GKE Autopilot Vulnerabilities ![Clock Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-clock.svg) 13 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:March 8, 2022 * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-category.svg) Categories: * [Cloud Cybersecurity Research](https://unit42.paloaltonetworks.com/category/cloud-cybersecurity-research/) * [Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) * [Vulnerabilities](https://unit42.paloaltonetworks.com/category/vulnerabilities/) * ![Tags Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-tags-grey.svg) Tags: * [Containers](https://unit42.paloaltonetworks.com/tag/containers/) * [![Download Icon](https://unit42.paloaltonetworks.com/wp-content/themes/unit42-v6/dist/images/icons/icon-download.svg)](https://unit42.paloaltonetworks.com/gke-autopilot-vulnerabilities/?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/gke-autopilot-vulnerabilities/?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=Container%20Escape%20to%20Shadow%20Admin:%20GKE%20Autopilot%20Vulnerabilities&body=Check%20out%20this%20article%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fgke-autopilot-vulnerabilities%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%2Fgke-autopilot-vulnerabilities%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%2Fgke-autopilot-vulnerabilities%2F&title=Container%20Escape%20to%20Shadow%20Admin:%20GKE%20Autopilot%20Vulnerabilities "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%2Fgke-autopilot-vulnerabilities%2F&text=Container%20Escape%20to%20Shadow%20Admin:%20GKE%20Autopilot%20Vulnerabilities "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%2Fgke-autopilot-vulnerabilities%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=Container%20Escape%20to%20Shadow%20Admin:%20GKE%20Autopilot%20Vulnerabilities%20https%3A%2F%2Funit42.paloaltonetworks.com%2Fgke-autopilot-vulnerabilities%2F "Share in Mastodon") ## **Executive Summary** In February 2021, Google announced [Autopilot](https://cloud.google.com/blog/products/containers-kubernetes/introducing-gke-autopilot), a new mode of operation in [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine) (GKE). With Autopilot, Google provides a "hands-off" Kubernetes experience, managing cluster infrastructure for the customer. The platform automatically provisions and removes nodes based on resource consumption and enforces secure Kubernetes best practices out of the box. In June 2021, Unit 42 researchers disclosed several vulnerabilities and attack techniques in GKE Autopilot to Google. Users able to create a pod could have abused these to (1) escape their pod and compromise the underlying node, (2) escalate privileges and become full cluster administrators, and (3) covertly persist administrative access through backdoors that are completely invisible to cluster operators. An attacker who obtained an initial foothold on an Autopilot cluster, for example, through a compromised developer's account, could have exploited these issues to escalate privileges and become a "shadow administrator," with the ability to covertly exfiltrate secrets, deploy malware or cryptominers and disrupt workloads. Following our disclosure, Google fixed the reported issues, deploying patches universally across GKE. All Autopilot clusters are now protected. This blog provides a technical analysis of the issues, as well as mitigations for preventing similar attacks against Kubernetes and GKE environments. For a high-level overview of the issues, please refer to our blog on the Palo Alto Networks site, [Unit 42 Discloses Newly Discovered Vulnerabilities in GKE Autopilot](https://www.paloaltonetworks.com/blog/2022/03/gke-autopilot-vulnerabilities). Palo Alto Networks customers receive protections from the issues discussed below through the Kubernetes admission control and auditing features of [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud). |------------------------|---------------------------------------------------------------------------------------------------------------------------------------| | Affected Product | Google Kubernetes Engine (GKE) Autopilot | | Related Unit 42 Topics | [Container Escape](https://unit42.paloaltonetworks.com/tag/containers/), [Cloud](https://unit42.paloaltonetworks.com/category/cloud/) | ## **Background on GKE Autopilot** Autopilot is a new mode of operation in GKE, providing what Google describes as a "hands-off" Kubernetes experience. In GKE Standard, customers manage their cluster infrastructure and pay per node. With GKE Autopilot, Google takes care of cluster infrastructure, and customers only pay for their running pods. This allows customers to focus on their applications, cutting operational costs. In a nutshell, managed cluster infrastructure means Google automatically: 1. Provisions and adjusts the number of nodes according to your pods' resource consumption. 2. Enforces a built-in policy to ensure the cluster adheres to secure best practices and can be safely managed by Google. Below is a simplified diagram of Autopilot's architecture. Components unique to Autopilot are colored in green and shown with a number corresponding to their role from the list above. Unlike GKE Standard, where nodes are visible as Compute Engine VMs, Autopilot nodes are completely managed by Google, thus colored in green. ![A simplified diagram of Autopilot's architecture. Components unique to Autopilot are colored in green and shown with a number corresponding to their role from the list above. Unlike GKE Standard, where nodes are visible as Compute Engine VMs, Autopilot nodes are completely managed by Google, thus colored in green.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-15.png) Figure 1. GKE Autopilot architecture. As seen in Figure 1, two components enforce Autopilot's policy. First is an [OPA Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/) validating admission webhook, an open-source project widely used for policy enforcement in Kubernetes. The second is a proprietary Kubernetes authorization mode named GKEAutopilot, which Google implemented by modifying the Kubernetes source code. The built-in policy serves two [purposes](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#limits): (a) prevent users from accessing cluster components managed by Google, like nodes; and (b) uphold secure Kubernetes best practices. For example, Autopilot forbids running privileged containers, fulfilling both (a) and (b). ![GKE Autopilot's built-in policy prevents users from accessing cluster components managed by Google and upholds secure Kubernetes best practices.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-16.png) Figure 2. Autopilot's built-in policy prevents privileged containers (Gatekeeper). Autopilot's policy goes beyond preventing container escapes. Figures 3, 4, and 5 highlight a few interesting examples. [GKE's documentation](https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-overview#limits) lists every limit enforced by the policy. ![GKE Autopilot's policy goes beyond preventing container escapes. This screenshot shows how the kube-system namespace is managed.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-17.png) Figure 3. The kube-system namespace is managed, customers are limited to read-only access. ![GKE Autopilot's policy goes beyond preventing container escapes. This screenshot shows how users cannot list or create mutating admission webhooks.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-18.png) Figure 4. Users cannot list or create mutating admission webhooks. ![GKE Autopilot's policy goes beyond preventing container escapes. This screenshot shows how External IP services are denied to protect against CVE-2020-8554.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-19.png) Figure 5. External IP services are denied to protect against CVE-2020-8554. Reading the error messages in the Figures above, you can see that Gatekeeper prevented the operations in Figures 2 and 5, while the GKEAutopilot authorization mode prevented the operations in Figures 3 and 4. ## **Attack Surfaces Unique to GKE Autopilot** Autopilot's built-in policy blocks several exploitation paths out of the box, providing better security posture compared to standard Kubernetes or GKE Standard. That being said, it also creates attack surfaces unique to Autopilot: 1. Administrators may rely on Autopilot's policy to prevent risky configurations. If attackers can somehow circumvent that policy, they may escalate privileges via methods customers expect to be blocked, like deploying a privileged container. 2. Autopilot administrators aren't fully privileged, restricted by the built-in policy from accessing nodes and certain privileged Kubernetes APIs. If attackers can bypass Autopilot's policy, they may gain higher privileges than administrators, opening the door for invisible backdoors. The following sections present vulnerabilities, privilege escalation techniques and persistence methods we identified that fall under these attack surfaces. Chained together, they allow a restricted user who can create a pod to (1) compromise nodes, (2) escalate privileges to an unrestricted cluster administrator and (3) install invisible and persistent backdoors to the cluster. ## **Masquerading as Allowlisted Workloads to Compromise Nodes** Our research began at the [following paragraph]() in Autopilot's documentation: "Our intent is to prevent unintended access to the node virtual machine. We accept submissions to that effect through the Google Vulnerability Reward Program (VRP)..." This seemed like an interesting challenge, and so we created an Autopilot cluster and started looking around. Autopilot installed OPA Gatekeeper onto the cluster along with several policies (called "constraints" in Gatekeeper terminology) in charge of preventing risky configurations like privileged containers. The cluster also had a [Custom Resource Definition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD) that seemed interesting, named allowlistedworkloads. ![In searching for GKE Autopilot vulnerabilities, we noted that Autopilot installs a CRD named allowlistedworkloads, as shown here.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-20.png) Figure 6. Autopilot installs a Custom Resource Definition (CRD) named allowlistedworkloads As shown earlier in Figure 2, Autopilot forbids pod configurations that could allow container escapes. To support add-ons that require some level of node access, Autopilot created a notion of allow-listed workloads. If a container matches an allow-listed workload, it's permitted to use the privileged features specified in the allowlistedworkload configuration. In June, the only allow-listed workloads were Datadog agents. ![In June, the only allow-listed workloads were Datadog agents.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-21.png) Figure 7. Datadog agent allowlistedworkload Below is the allow-listed workload configuration for one of the Datadog agents that caught our attention. If a container specifies the listed command and image, it's allowed to mount the listed host paths in read-only volumes. ![The screenshot shows the allow-listed workload configuration for one of the Datadog agents that caught our attention while searching for GKE Autopilot vulnerabilities.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-22.png) Figure 8. One of the allowlistworkloadconfiguration examples for Datadog agents. The issue here is insufficient verification. Only checking the command and image isn't enough to ensure the container runs Datadog code. Using the following PodSpec, a container can masquerade as the Datadog agent while running attacker-controlled code, and abuse the exposed host volumes to break out. ![Using the PodSpec shown here, a container can masquerade as the Datadog agent while running attacker-controlled code, and abuse the exposed host volumes to break out.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-23.png) Figure 9. Masquerading as the Datadog agent. In the video below, a malicious user deploys a pod masquerading as the Datadog agent. The pod takes over its underlying node through the following steps: 1. Abuse the mounted containerd socket to create a privileged container that mounts the host filesystem. 2. Have that privileged container install a systemd service that spawns a reverse shell from the node to an attacker-controlled machine. *Video 1. Masquerading as an allowlistedworkload to compromise the underlying node.* ## **Impact of Node Compromise** An attacker who can create a pod may exploit this issue to create malicious containers that escape and take over their underlying nodes. Autopilot users expect the platform to prevent this kind of attack, and will be caught off-guard. Node compromise opens up the following attack vectors: 1. The attacker immediately gains control over neighboring pods and their service account tokens, potentially escalating privileges and spreading to other [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/). 2. The attacker can query the node's [instance metadata endpoint](https://cloud.google.com/compute/docs/metadata/overview) for an access token. By default, this token provides read access to cloud storage in the customer's project. 3. Since Autopilot administrators cannot access nodes, attackers may abuse this issue to install covert malware or cryptominers on them. However, Autopilot automatically scales nodes, so ensuring malware persists isn't straightforward. 4. The attacker gains access to the underlying Kubelet credentials, allowing visibility to nearly all cluster objects. Finally, because Autopilot only bills per running pods, crafty users could have abused this issue to cut some costs, running some workloads directly on nodes. We advise reducing bills in more legitimate ways. ## **Escalating to Unrestricted Administrators** Following the trajectory of a motivated intruder, we looked for reliable methods of escalating this container escape into a full cluster takeover. By compromising a node, attackers can steal the service account tokens of neighboring pods. Naturally, it would make sense to target nodes hosting pods with powerful service accounts. These may be pods deployed by the user, or more interestingly, system pods deployed natively in all Autopilot clusters. After examining the built-in policy, we discovered that **Autopilot completely exempts kube-system service accounts** . This made kube-system pods the most interesting targets, as stolen tokens could be used freely without worrying about the policy. ![After examining the built-in policy, we discovered that Autopilot completely exempts kube-system service accounts.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-24.png) Figure 10. Autopilot's policy exempts kube-system service accounts in line 3. To search for powerful pods in Autopilot, we created [sa-hunter](https://github.com/twistlock/sa-hunter), a Python tool that maps pods' service accounts to their Kubernetes permissions (i.e. roles and clusterroles). Existing tools link service accounts to their permissions, but don't show whether any pods actually use a given service account. Figure 11 shows an example output of sa-hunter: ![An example output of sa-under, which searches for powerful pods in Autopilot.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-25.png) Figure 11. sa-hunter output, linking running pods to their permissions. sa-hunter found two powerful kube-system pods installed by default: stackdriver-metadata-agent-cluster-level and metrics-server. Both pods can update existing deployments, as shown in Figure 12. This privilege may appear innocent at first glance, but it is enough to escalate to full cluster admin. Interestingly, these pods are also deployed by default in GKE Standard, **making the following privilege escalation technique relevant to all GKE clusters, Standard and Autopilot**. ![Privileged role assigned to the metrics-server pod can update deployments.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-26.png) Figure 12. Privileged role assigned to the metrics-server pod can update deployments. After taking over a node hosting either the stackdriver-metadata-agent-cluster-level or metrics-server pod, an attacker can harvest their service account token from the node filesystem. Armed with that token, the attacker can attain the privileges of any service account in the cluster with three simple steps: 1. Update an existing deployment's service account to the target service account. There are a number of preinstalled deployments, any one of which can be used for this step. 2. Add a malicious container to that deployment. 3. Have that malicious container retrieve the target service account token mounted in the container at /run/secrets/kubernetes.io/serviceaccount/token. ![Abusing deployment update privileges to obtain any service account's token.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-27.png) Figure 13. Abusing deployment update privileges to obtain any service account's token. For this to be a meaningful privilege escalation, the attacker would need to target a powerful service account. The kube-system namespace offers a number of preinstalled, extremely powerful service accounts to choose from. The clusterrole-aggregation-controller (CRAC) service account is probably the leading candidate, as it can add arbitrary permissions to existing cluster roles. ![The clusterrole-aggregation-controller service account can escalate cluster roles.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-28.png) Figure 14. The clusterrole-aggregation-controller service account can escalate cluster roles. After using the technique illustrated in Figure 13 to obtain CRAC's token, the attacker can update the cluster role binded to CRAC to possess all privileges. At this point, the attacker is effectively cluster admin, and is also exempt from Autopilot's policy (as seen in Figure 10). ![The clusterrole-aggregation-controller's token can add admin privileges to itself.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-29.png) Figure 15. The clusterrole-aggregation-controller's token can add admin privileges to itself. Rewinding, if the attacker wants to chain this privilege escalation technique with the container escape discussed earlier, he needs to somehow schedule his breakout pod on a node hosting either the stackdriver-metadata-agent-cluster-level or metrics-server pod. Although Autopilot rejects pods that have nodeSelectors, it does permit the simplest form of node assignment --- the [nodeName](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodename) field. The nodeName field assures the breakout pod will land on the target node as long as it has adequate resources for another pod. Even if there's no room on the target node, the attacker still has a couple of options. He can either (1) watch the target node and wait for a pod to be deleted; or (2) create pods to trigger a node scale up, tricking Autopilot's autoscaler into redistributing workloads so that a powerful pod ends up on an emptier node. ## **Full Chain: Invisible Backdoors via Mutating Admission Webhooks** Video 2 shows the full attack chain, combining the container escape with the privilege escalation route built into GKE. Following exploitation, the attacker has higher privileges than Autopilot administrators, as he's exempt from the built-in policy (as seen in Figure 10). **This level of access can be abused to install invisible and persistent backdoors** in the form of [mutating admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook). Mutating admission webhooks receive any objects created or updated in the cluster, including pods and secrets. If that's not scary enough, these webhooks can also arbitrarily mutate any received object, making them a ridiculously powerful backdoor. As shown earlier in Figure 4, Autopilot administrators cannot list mutating admission webhooks, and thus will never see this backdoor. ![Before the fixes, an attacker could have exploited GKE Autopilot vulnerabilities to become a shadow administrator through an invisible mutating admission webhook.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-30.png) Figure 16. Becoming a shadow administrator through an invisible mutating admission webhook. *Video 2. Escalating from pod creation to an unrestricted administrator and an invisible backdoor*. ![A malicious mutating admission webhook installed by abusing the reported GKE vulnerabilities and attack techniques. Note that seeing the backdoor required the unrestricted admin token acquired in the attack.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/03/word-image-31.png) Figure 17. A malicious mutating admission webhook installed by abusing the reported issues. Note that seeing the backdoor required the unrestricted admin token acquired in the attack. ## **Full Chain: Impact** Before the fixes, attackers could have exploited the presented issues to transform a limited breach into a full cluster takeover on any Autopilot cluster. Using webhooks that are invisible to users, attackers can covertly persist their administrative access, effectively becoming "shadow administrators." At that point, they could have covertly exfiltrated secrets, deployed malware or cryptominers, and disrupted workloads. ## **Other Issues** During our research we found two additional issues that allow node compromise, but with lower impact. The first involves two service account names in the default namespace that were exempt from Autopilot's policy: csi-attacher and otelsvc. If an attacker gained control over the default namespace, it would have been possible to create these service accounts to bypass the built-in policy. The attacker could then create privileged pods to compromise nodes, and use the discussed privilege escalation technique to take over the entire cluster. The second attack exploited [CVE-2020-8554](https://unit42.paloaltonetworks.com/cve-2020-8554/) through Load Balancer services to compromise nodes, but required admin privileges to exploit. The attack scenario here is an attacker who has already compromised an Autopilot cluster and is looking to bypass the built-in policy to establish a covert backdoor. ## **Fixes and Mitigations** Following our advisory and over the course of the last several months, Google deployed numerous fixes and mitigations to GKE Autopilot. These prevent the reported attack and harden the platform against similar exploits. 1. Cluster administrators can now list, view and even create mutating admission webhooks, preventing their abuse as invisible backdoors. 2. Google hardened the verification process of allowlistedworkloads. 3. Policy enforcement moved from OPA Gatekeeper to Google's policy controller, allowing customers to deploy their own Gatekeeper instance. Customers can now enforce their own policy on top of the built-in one. As defense-in-depth and to mitigate possible future issues, we recommend deploying the same policies you would have deployed to GKE standard. 4. The built-in policy is no longer visible. 5. The csi-attacher and otelsvc service accounts are no longer exempt from Autopilot's policy. 6. Google [open-sourced a policy for OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/general/noupdateserviceaccount) that restricts the powerful kube-system pods abused in the attack. The policy prevents these pods from assigning a new service account to an existing pod. See GKE's [hardening guide](https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster#restrict_self_modify) for more information. We highly recommend reading [Google's official advisory](https://cloud.google.com/anthos/clusters/docs/security-bulletins#gcp-2022-009), which describes the issues from Google's perspective and lists their mitigations. ## **Preventing Similar Attacks on Kubernetes Environments** The presented attack can be classified as a Kubernetes privilege escalation, where an attacker with limited access obtains broader permissions over a cluster. This kind of follow-on attacker activity must start from an initial breach: a malicious image in your cluster supply chain, a vulnerable publicly exposed service, stolen credentials or an insider threat. Securing your cluster's software supply chain, identities and external perimeter can reduce the chances of such breaches occurring in your clusters. Sophisticated attackers may still find creative ways to infiltrate clusters. Proactively solving common misconfigurations, like Kubelets that allow unauthenticated access, can significantly reduce the internal attack surface available to an intruder. Security controls such as NetworkPolicies and PodSecurityStandards further restrict and demoralize malicious actors. In the presented attack chain, the attacker only had to compromise one node to take over the entire cluster. The underlying issue wasn't the node's permissions, but those of the powerful pods it hosted, which included the ability to update deployments. This permission and others may appear somehow restricted at first glance, but are equivalent to cluster admin. **Powerful pods are still common in production clusters**: natively installed by the underlying Kubernetes platform or introduced through popular open-source add-ons. If a node hosting a powerful pod is compromised, the attacker can easily harvest the pod's powerful service account token to spread in the cluster. Tackling powerful pods is complex, mostly because their permissions may be rightfully needed. The first step is detection --- identifying whether powerful pods exist in your cluster. We hope [sa-hunter](https://github.com/twistlock/sa-hunter) can help with that, and we plan to release additional tools that focus on automating detection of powerful pods. If you identified powerful pods in your cluster, we recommend taking one of the approaches below: 1. If you manage the powerful pod, consider whether it's possible to strip unnecessary privileges from its service account, or scope them to specific namespaces or resource names. 2. If these pods are part of an external solution, reach out to the relevant cloud provider or project to pursue reducing the pod's privileges. If the pod is deployed by a managed Kubernetes service, it may be possible for them to replace it with a control plane controller. 3. Some Kubernetes permissions are too broad, meaning the pod in question may not require access to the dangerous operations its permissions expose. In that case, it may be possible to implement a policy (e.g. via OPA Gatekeeper) that prevents the pod from performing certain dangerous operations, or even better, restricts the pod to a set of allowed and expected operations. 4. Use [Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/), [NodeAffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) or [PodAntiAffinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) rules to isolate powerful pods from untrusted or publicly exposed ones, ensuring they don't run on the same node. As an example for the third approach, the following Rego policy can stop the presented privilege escalation attack. The attack abused system pods who can update deployments to replace the service account of an existing deployment to a powerful one. Inspecting the source code of these powerful pods revealed they don't need the ability to change the service account of deployments they update. The policy below capitalizes on that and forbids these pods from unexpectedly updating deployments' service accounts. [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) users on GKE are encouraged to import this policy as an [admission rule](https://docs.paloaltonetworks.com/prisma/prisma-cloud/21-04/prisma-cloud-compute-edition-admin/access_control/open_policy_agent.html#:~:text=Prisma%20Cloud%20provides%20a%20dynamic,to%20Defender%2C%20which%20enforces%20them.) set on Alert. match\[{"msg": msg}\] { input.request.object.kind == "Deployment" request\_by\_powerful\_dep\_update\_sa(input.request.userInfo.username) old\_spec := input.request.oldObject.spec.template.spec new\_spec := input.request.object.spec.template.spec new\_service\_account := is\_updating\_the\_service\_account(old\_spec, new\_spec) msg := sprintf("SA '%v' may be compromised, it unexpectedly tried to replace the serviceaccount of 'deployment/%v:%v' to '%v'", \[input.request.userInfo.username, input.request.object.metadata.namespace, input.request.object.metadata.name, new\_service\_account\]) } request\_by\_powerful\_dep\_update\_sa(username) { # metrics-server pod on GKE username == "system:serviceaccount:kube-system:metrics-server" } { # stackdriver pod on older GKE clusters username == "system:serviceaccount:kube-system:metadata-agent" } is\_updating\_the\_service\_account(oldspec, newspec) = new\_service\_account { oldspec.serviceAccountName != newspec.serviceAccountName new\_service\_account := newspec.serviceAccountName } { not has\_key(oldspec, "serviceAccountName") new\_service\_account := newspec.serviceAccountName } has\_key(obj, k) { \_ = obj\[k\] } |----------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | match\[{"msg": msg}\] { input.request.object.kind == "Deployment" request\_by\_powerful\_dep\_update\_sa(input.request.userInfo.username) old\_spec := input.request.oldObject.spec.template.spec new\_spec := input.request.object.spec.template.spec new\_service\_account := is\_updating\_the\_service\_account(old\_spec, new\_spec) msg := sprintf("SA '%v' may be compromised, it unexpectedly tried to replace the serviceaccount of 'deployment/%v:%v' to '%v'", \[input.request.userInfo.username, input.request.object.metadata.namespace, input.request.object.metadata.name, new\_service\_account\]) } request\_by\_powerful\_dep\_update\_sa(username) { # metrics-server pod on GKE username == "system:serviceaccount:kube-system:metrics-server" } { # stackdriver pod on older GKE clusters username == "system:serviceaccount:kube-system:metadata-agent" } is\_updating\_the\_service\_account(oldspec, newspec) = new\_service\_account { oldspec.serviceAccountName != newspec.serviceAccountName new\_service\_account := newspec.serviceAccountName } { not has\_key(oldspec, "serviceAccountName") new\_service\_account := newspec.serviceAccountName } has\_key(obj, k) { \_ = obj\[k\] } | ## **Conclusion** As organizations migrate to Kubernetes, attackers follow suit. Recent malware samples like [Silocape](https://unit42.paloaltonetworks.com/siloscape/) indicate adversaries are evolving beyond simple techniques into advanced Kubernetes tailored attacks. Against sophisticated attackers, solely securing the cluster's perimeter may not be enough. We encourage defenders to adopt policy and audit engines that enable detection and prevention of follow-on, "stage 2" attacker activities, and we hope this research can highlight how those may look. [Prisma Cloud](https://www.paloaltonetworks.com/prisma/cloud) customers are encouraged to enable our Kubernetes [admission control](https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/access_control/open_policy_agent.html) and [auditing](https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/audit/kubernetes_auditing.html) features aimed at tackling this threat. We'd like to thank Google for their cooperation in resolving these issues, the bounty reward and their [wonderful policy](https://bughunters.google.com/about/rules/6625378258649088#:~:text=We%20understand%20that%20some%20of%20you%20are%20not%20interested%20in%20money.%20We%20offer%20the%20option%20to%20donate%20your%20reward%20to%20an%20established%20charity.%20If%20you%20do%20so%2C%20we%20will%20double%20your%20donation%20-%20subject%20to%20our%20discretion.%20Any%20rewards%20that%20are%20unclaimed%20after%2012%20months%20will%20be%20donated%20to%20a%20charity%20of%20our%20choosing.) that doubles bounties donated to charity. Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the [Cyber Threat Alliance](https://www.cyberthreatalliance.org/). ### **Additional Resources** * [GKE Autopilot documentation](https://www.google.com/search?q=gke+autotpilot&oq=gke+autotpilot&aqs=chrome..69i57.1414j0j7&sourceid=chrome&ie=UTF-8) * [sa-hunter](https://github.com/twistlock/sa-hunter) * [Siloscape: First Known Malware Targeting Windows Containers to Compromise Cloud Environments](https://unit42.paloaltonetworks.com/siloscape/) * [Protecting Against an Unfixed Kubernetes Man-in-the-Middle Vulnerability (CVE-2020-8554)](https://unit42.paloaltonetworks.com/cve-2020-8554/) Back to top ### Tags * [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers") [Threat Research Center](https://unit42.paloaltonetworks.com "Threat Research") [Next: New Linux Vulnerability CVE-2022-0492 Affecting Cgroups: Can Containers Escape?](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/ "New Linux Vulnerability CVE-2022-0492 Affecting Cgroups: Can Containers Escape?") ### Table of Contents * ### Related Articles * [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") * [Understanding Current Threats to Kubernetes Environments](https://unit42.paloaltonetworks.com/modern-kubernetes-threats/ "article - table of contents") * [Cloud Threats on the Rise: Alert Trends Show Intensified Attacker Focus on IAM, Exfiltration](https://unit42.paloaltonetworks.com/2025-cloud-security-alert-trends/ "article - table of contents") ## Related Resources ![Pictorial representation of a group of people interacting with a dynamic 3D holographic display of colorful, undulating data waves on a table.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/09/11_Myth-Busting_Overview_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/08/Insights-icon-white.svg)Insights](https://unit42.paloaltonetworks.com/category/insights/) August 4, 2026 [#### The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software](https://unit42.paloaltonetworks.com/frontier-ai-vulnerability-burst/) * [AI](https://unit42.paloaltonetworks.com/tag/ai/ "AI") * [Frontier AI](https://unit42.paloaltonetworks.com/tag/frontier-ai/ "Frontier AI") * [Vulnerability Exploitation](https://unit42.paloaltonetworks.com/tag/vulnerability-exploitation/ "Vulnerability Exploitation") [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/frontier-ai-vulnerability-burst/ "The Frontier AI Vulnerability Burst: Industrializing Autonomous Zero-Day Discovery in Open-Source Software") ![Pictorial representation of AI-enabled autonomous cyberattacks. A digital illustration depicting abstract, interconnected data streams in vibrant colors on a dark blue background](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/07/AdobeStock_992950050-3-782x440.jpeg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/06/icon-threat-research.svg)Threat Research](https://unit42.paloaltonetworks.com/category/threat-research/) July 30, 2026 [#### Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks](https://unit42.paloaltonetworks.com/autonomous-ai-cyber-attack-campaign/) * [ChatGPT](https://unit42.paloaltonetworks.com/tag/chatgpt/ "ChatGPT") * [Claude code](https://unit42.paloaltonetworks.com/tag/claude-code/ "Claude code") * [CVEs](https://unit42.paloaltonetworks.com/tag/cves/ "CVEs") [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/autonomous-ai-cyber-attack-campaign/ "Chinese-Speaking Threat Actor Harnesses AI Models for Autonomous Cyberattacks") ![Pictorial representation of three zero-day vulnerabilities in Siemens ROX II OT switches. Digital illustration of a global network featuring interconnected lines and nodes over a map of the world, highlighted with neon lights and digital elements.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/07/03_Vulnerabilities_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/) July 17, 2026 [#### Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy](https://unit42.paloaltonetworks.com/siemens-rox-ii-zero-day-vulnerabilities/) * [Command injection](https://unit42.paloaltonetworks.com/tag/command-injection/ "Command injection") * [CVE-2025-40947](https://unit42.paloaltonetworks.com/tag/cve-2025-40947/ "CVE-2025-40947") * [CVE-2025-40948](https://unit42.paloaltonetworks.com/tag/cve-2025-40948/ "CVE-2025-40948") [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/siemens-rox-ii-zero-day-vulnerabilities/ "Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy") ![Pictorial representation of bucket hijacking technique for cloud data exfiltration. Digital illustration of Europe map highlighting network connections and nodes, depicted as glowing points and lines on a dark blue background, emphasizing major cities and connectivity across the continent.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/09_Cloud_cybersecurity_research_Overview_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/) June 22, 2026 [#### The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/) * [AWS](https://unit42.paloaltonetworks.com/tag/aws/ "AWS") * [Bucket hijacking](https://unit42.paloaltonetworks.com/tag/bucket-hijacking/ "bucket hijacking") * [Cloud data exfiltration](https://unit42.paloaltonetworks.com/tag/cloud-data-exfiltration/ "cloud data exfiltration") [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/cloud-bucket-hijacking-risks/ "The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration") ![Pictorial representation of Vertex AI model uploads. Close-up view of a digital wall displaying various glowing icons, representing a high-tech network interface.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/AdobeStock_1270203474-1-786x354.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/) June 16, 2026 [#### Pickle in the Middle -- Hijacking Vertex AI Model Uploads for Cross-Tenant RCE](https://unit42.paloaltonetworks.com/hijacking-vertex-ai-model/) * [Bucket squatting](https://unit42.paloaltonetworks.com/tag/bucket-squatting/ "bucket squatting") * [Google Cloud](https://unit42.paloaltonetworks.com/tag/google-cloud/ "Google Cloud") * [Joblib](https://unit42.paloaltonetworks.com/tag/joblib/ "joblib") [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/hijacking-vertex-ai-model/ "Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE") ![Pictorial representation of Cloud Logging services for defense evasion. A vibrant digital illustration depicting a glowing, neon blue cloud symbol positioned over a circuit board landscape. The cloud symbolizes cloud computing technology, and the landscape features intricate electronic circuits with glowing lines and nodes, suggesting high-tech data transfer and connectivity.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/11_Cloud_cybersecurity_research_Overview_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/) June 9, 2026 [#### Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility](https://unit42.paloaltonetworks.com/cloud-logging-defense-evasion/) * [AWS CloudTrail](https://unit42.paloaltonetworks.com/tag/aws-cloudtrail/ "AWS CloudTrail") * [Cloud logging](https://unit42.paloaltonetworks.com/tag/cloud-logging/ "cloud logging") * [Defense evasion](https://unit42.paloaltonetworks.com/tag/defense-evasion/ "defense evasion") [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/cloud-logging-defense-evasion/ "Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility") ![Pictorial representation of PAN-OS CVE-2026-0257. A vibrant city skyline at night, with tall skyscrapers and glowing digital beams extending into the sky, suggesting advanced technology and connectivity.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/06/07_Vulnerabilities_1920x900-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) June 9, 2026 [#### Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257](https://unit42.paloaltonetworks.com/active-exploitation-of-pan-os-cve-2026-0257/) * [CVE-2026-0257](https://unit42.paloaltonetworks.com/tag/cve-2026-0257/ "CVE-2026-0257") * [Vulnerability](https://unit42.paloaltonetworks.com/tag/vulnerability/ "vulnerability") [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/active-exploitation-of-pan-os-cve-2026-0257/ "Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257") ![Pictorial representation of ROADtools framework in the cloud. An Asian man wearing glasses sits in front of a computer screen. Reflecting in the glasses are lines indicating analysis. Bright blue city lights illuminate the rest of the image.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/10_Cloud_cybersecurity_research_Overview_1920x900-1-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/) May 22, 2026 [#### Paved With Intent: ROADtools and Nation-State Tactics in the Cloud](https://unit42.paloaltonetworks.com/roadtools-cloud-attacks/) * [Curious Serpens](https://unit42.paloaltonetworks.com/tag/curious-serpens/ "Curious Serpens") * [Entra ID](https://unit42.paloaltonetworks.com/tag/entra-id/ "Entra ID") * [Microsoft Azure](https://unit42.paloaltonetworks.com/tag/microsoft-azure/ "Microsoft Azure") [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/roadtools-cloud-attacks/ "Paved With Intent: ROADtools and Nation-State Tactics in the Cloud") ![Pictorial representation of CVE-2026-30300. Digital illustration of a map of North America with interconnected glowing lines and dots symbolizing network connections across the continent.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/06_Vulnerabilities_1920x900-3-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) May 6, 2026 [#### Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution](https://unit42.paloaltonetworks.com/captive-portal-zero-day/) * [CVE-2026-0300](https://unit42.paloaltonetworks.com/tag/cve-2026-0300/ "CVE-2026-0300") * [EarthWorm](https://unit42.paloaltonetworks.com/tag/earthworm/ "EarthWorm") * [PAN-OS](https://unit42.paloaltonetworks.com/tag/pan-os/ "PAN-OS") [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/captive-portal-zero-day/ "Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution") ![Pictorial representation of a severe Linux vulnerability. Close-up of a woman wearing glasses and focusing intently on a computer screen.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/05/05_Vulnerabilities_1920x900-2-1-786x368.jpg) [![category icon](https://unit42.paloaltonetworks.com/wp-content/uploads/2024/07/top-threats.svg)High Profile Threats](https://unit42.paloaltonetworks.com/category/top-cyberthreats/) May 5, 2026 [#### Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years](https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/) * [Containers](https://unit42.paloaltonetworks.com/tag/containers/ "Containers") * [CVE-2026-31431](https://unit42.paloaltonetworks.com/tag/cve-2026-31431/ "CVE-2026-31431") * [Kubernetes](https://unit42.paloaltonetworks.com/tag/kubernetes/ "Kubernetes") [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/cve-2026-31431-copy-fail/ "Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years") * ![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)