Threat Insights: Active Exploitation of Cisco ASA Zero Days

Posted on by Samantha Stallings

September 2025 Zero-Day Vulnerabilities Affecting Cisco Software

Unit 42 stopped monitoring this threat and updating the brief on Dec. 2, 2025. Please refer to the Cisco website for the latest information.

Cisco has reported that a sophisticated state-sponsored threat actor is actively exploiting multiple zero-day vulnerabilities in Cisco Adaptive Security Appliance (ASA) and Firepower Threat Defense (FTD) software. Cisco identifies this as the same threat actor from a previous campaign they named ArcaneDoor.

This threat actor primarily targets government networks worldwide for data exfiltration. Cisco observed attackers exploiting these newly identified zero-day vulnerabilities while employing advanced evasion techniques to prevent logging and identification of this activity.

The trend of suspected nation-state adversaries exploiting zero-day vulnerabilities in internet-facing devices continues. Also known as edge devices, these internet-facing appliances act as the security perimeter between an organization's internal network and the public internet. This includes firewalls, VPN gateways, routers and load balancers. Compromising these devices provides a direct and often stealthy entry point into a network.

Details of the Vulnerabilities

Cisco published advisories for three critical vulnerabilities in ASA and FTD. Two of these, CVE-2025-20333 and CVE-2025-20362, are currently under active exploitation by adversaries in the wild. Cisco identified a third vulnerability, CVE-2025-20363, as being at high risk for imminent exploitation. These vulnerabilities allow attackers to execute arbitrary code, exfiltrate data and implant persistent malware to maintain access even after a device is rebooted.

CVE Number Description CVSS Severity
CVE-2025-20333 A vulnerability in the VPN web server of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an authenticated, remote attacker to execute arbitrary code on an affected device.  9.9 Critical
CVE-2025-20362 A vulnerability in the VPN web server of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to access restricted URL endpoints that are related to remote access VPN that should otherwise be inaccessible without authentication.  6.7 Medium
CVE-2025-20363 A vulnerability in the web services of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software, Cisco Secure Firewall Threat Defense (FTD) Software, Cisco IOS Software, Cisco IOS XE Software and Cisco IOS XR Software could allow an unauthenticated, remote attacker (Cisco ASA and FTD Software) or authenticated, remote attacker (Cisco IOS, IOS XE, and IOS XR Software) with low user privileges to execute arbitrary code on an affected device.  9.0 Critical

As of Sep. 25, 2025, Cisco has released software updates to address all three vulnerabilities. It urges organizations to prioritize the immediate upgrade of all affected systems to the latest available software versions to mitigate the threat and prevent compromise.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued Emergency Directive (ED) 25-03, mandating immediate mitigation for federal agencies due to the significant risk posed by this campaign. The vulnerabilities affect critical perimeter network devices, posing a substantial risk to both public and private sector organizations.

The U.K.’s National Cyber Security Center (NCSC) published a malware analysis report [PDF] on the RayInitiator and LINE VIPER malware families used in attacks to exploit these zero-day vulnerabilities. According to their analysis, RayInitiator is a multi-stage Grand Unified Bootloader (GRUB) bootkit that services reboots and firmware upgrades. It also deploys the LINE VIPER shellcode loader to Cisco ASA 5500-X series devices that do not have secure boot. LINE VIPER is loaded into memory by RayInitiator and it receives command and control instructions over WebVPN client authentication sessions over HTTPS or via ICMP with responses over raw TCP.

Lifecycle of Zero-Day Vulnerabilities

Adversaries, particularly nation-state actors, are dedicating significant resources to discovering and exploiting zero-day vulnerabilities in edge devices. Since these flaws are previously unknown, they provide attackers a critical window of opportunity before a vendor can release a patch. Once a zero-day is weaponized, attackers can use the exploit against a wide range of organizations using the same vulnerable product.

Additionally, after a nation-state actor successfully uses a zero-day exploit, the knowledge of that vulnerability and the methods for exploitation inevitably become less exclusive over time. This leads to a secondary, and often more widespread, phase of exploitation.

Other threat actors may reverse-engineer the original sophisticated exploit, or a public advisory and patch release from a vendor might reveal the underlying vulnerability. This disclosure acts as a blueprint for cybercriminal groups and opportunistic hackers.

These adversaries then develop their own proof-of-concept (PoC) code, which is often simpler and less stealthy than the nation-state's original exploit, but still highly effective against unpatched systems. This PoC code is rapidly weaponized and sold on dark web forums or integrated into exploit kits, making the once-exclusive capability of a nation-state accessible to a much broader range of financially motivated attackers.

This phenomenon creates a “patch-or-perish” scenario, where organizations that fail to apply vendor patches promptly are left highly vulnerable to a new wave of mass-scale, opportunistic attacks.

Conclusion

Palo Alto Networks recommends patching immediately. Cisco also provides temporary mitigation guidance for devices that are vulnerable but unable to be updated. Those temporary mitigations include their own risks, such as disabling SSL/TLS-based VPN web services.

Palo Alto Networks recommends reviewing the following advisories for further information about the campaign and detecting this activity.

The Appendix to this article provides two hunting queries for our Cortex XDR and XSIAM customers to identify when logging is disabled or disrupted from Cisco ASA devices.

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

Additional Resources

Appendix

Unit 42 developed the following two hunting queries for our Cortex XDR customers to identify when logging is disabled or disrupted from Cisco ASA devices.

This query graphs all log types from Cisco ASA devices:

This query graphs debug and info logging from Cisco ASA devices (Note: debug and info logs require manual configuration):

Bookworm to Stately Taurus Using the Unit 42 Attribution Framework

Posted on by Kyle Wilhoit

Executive Summary

In the complex landscape of threat intelligence and research, understanding the tools used by threat actors is just as critical as identifying the actors themselves. How do we link specific malware to its operators? We present a case study that demonstrates the process using the Unit 42 Attribution Framework to analyze well-known malware and its ties to a formally named threat group.

We examine Bookworm, a notable malware family used by Stately Taurus, a Chinese advanced persistent threat (APT) group active since at least 2012. This group conducts cyberespionage campaigns targeting government and commercial entities across Europe and Asia.

The case study illustrates how the Unit 42 Attribution Framework helps us dissect and confirm the operational link between this specific malware and its consistent usage by Stately Taurus. We provide a transparent look into the analytical process, illustrating how we moved from analyzing the malware's code to understanding the adversary's broader operations.

We explore the methodologies we use to analyze Bookworm's characteristics and examine its use in Stately Taurus campaigns. We finally demonstrate how our structured framework enhances the precision and confidence in attributing not just activity, but the actor's tradecraft. This deep dive highlights the iterative nature of attribution and how confirming malware family associations strengthens our overall intelligence picture.

Palo Alto Networks customers are better protected from Bookworm malware through the following products:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Stately Taurus, Bookworm

A Quick Look Back: The Unit 42 Attribution Framework

Before we dive into the specifics of Bookworm and Stately Taurus, it's beneficial to briefly revisit the core tenets of the Unit 42 Attribution Framework. We developed this framework to introduce a systematic, evidence-based approach to the often-complex world of threat actor attribution. It moves beyond subjective assessments, providing a rigorous methodology to connect observed malicious activity to specific groups or individuals.

For the purpose of this case study, it’s important to remember that our framework evaluates multiple dimensions of threat data including:

  • Analyzing tactics, techniques and procedures (TTPs)
  • Examining tooling and malware characteristics
  • Examining operational security (OPSEC) practices
  • Mapping network infrastructure
  • Analyzing victimology
  • Meticulously analyzing timelines

We then assess each piece of evidence using the Admiralty System, which assigns scores for reliability and credibility, ensuring that we build our conclusions on a robust foundation. We track and store all this information and data in our attribution table, which helps calculate a cumulative score to determine attribution confidence.

Additionally, the framework integrates the Diamond Model of Intrusion Analysis as a critical tool for mapping and correlating activities, particularly when building confidence to move from initial observations to definitive attribution claims. The model helps analysts organize raw data about an attack into four key categories:

  • Adversary: The attacker
  • Capability: The tools and techniques they used (like malware)
  • Infrastructure: The systems they used to launch the attack (like servers or IP addresses)
  • Victim: The target of the attack

In essence, the framework allows us to accumulate and weigh diverse intelligence data, leading to high-confidence attribution and a deeper understanding of adversary operations — precisely what we'll demonstrate with Bookworm.

Understanding Bookworm: A Brief Profile

To fully appreciate the links between the Bookworm malware family and Stately Taurus, it's essential to first establish a basic understanding of the Bookworm malware family itself. First observed in 2015, Bookworm functions primarily as an advanced remote access Trojan (RAT), granting its operators extensive control over compromised systems.

Its capabilities typically include:

  • Executing arbitrary commands
  • Manipulating files (upload/download)
  • Exfiltrating data
  • Establishing persistent access

Bookworm is known for its unique modular architecture, allowing its core functionality to be expanded by loading additional modules directly from its command-and-control (C2) server. This modularity makes static analysis more challenging, as the Leader module relies on other DLLs to provide specific functionality.

What makes many of our analyzed Bookworm samples particularly noteworthy from an attribution standpoint are some of their distinct technical characteristics and observed operational patterns. For instance, our analysis has frequently uncovered specific program database (PDB) paths embedded within Bookworm samples. A notable example includes the path:

  • C:\Users\hack\Documents\WhiteFile\LTDIS13n\Release\LTDIS13n.pdb

Developers often inadvertently leave in these paths during compilation. They serve as attribution indicators, acting as unique fingerprints that can potentially link different malware variants or even different malware families developed by the same actor. We identified this specific PDB path in samples of ToneShell, another custom tool that has been associated with Stately Taurus.

Bookworm samples exhibit various methods for C2 communication, often leveraging legitimate-looking domains or compromised infrastructure to blend in with network traffic. A technique observed in recent Bookworm variants, mirroring ToneShell, involves packaging shellcode as universally unique identifier (UUID) strings. The malware then decodes these ASCII or Base64-encoded UUIDs into binary data and executes via legitimate API functions.

Initial Bookworm analysis from 2015 primarily noted DLL sideloading for payload execution. However, newer variants have adopted this UUID technique. While the source code for this UUID method is publicly available, its consistent application across Bookworm and ToneShell payloads offers another technical commonality that is important to pay attention to.

Understanding these technical characteristics of Bookworm provides the baseline for the attribution analysis that follows, where we will directly link these features to the activities of Stately Taurus.

The Link: Bookworm and Stately Taurus through the Framework's Lenses

Having established Bookworm's technical blueprint, we can apply the Unit 42 Attribution Framework to demonstrate the operational ties between the malware family and Stately Taurus. Broadly speaking, we are performing attribution based on the following:

  • Threat actor TTPs, tooling and capabilities
  • OPSEC consistency
  • Network infrastructure overlaps
  • Victimology and targeting
  • Activity time frames

We will examine each in greater detail in the following sections.

Tactics, Techniques and Procedures (Diamond Model Alignment: Capability)

Tracking threat actor TTPs is an important aspect of attribution. In this case, the modus operandi observed in Bookworm usage frequently aligns with Stately Taurus's well-documented TTPs. For instance, initial access often involves highly tailored spear-phishing campaigns using enticing decoy documents, a hallmark of Stately Taurus's approach.

Post-compromise, Bookworm exhibits behaviors consistent with Stately Taurus's broader playbook, including establishing persistence as well as collecting and exfiltrating sensitive information. The group's focus on covert data collection and espionage is reflected directly in Bookworm's design and usage, particularly as seen in prior attack campaigns against a Southeast Asian government using Bookworm.

Mapping this activity to MITRE ATT&CK techniques is a useful mechanism for tracking over time and can also be used during the attribution process. For example, attackers have delivered both Bookworm and ToneShell via spear phishing (T0865) and executed it via DLL sideloading (T1574.001). These techniques should be considered during attribution with a very low weight due to the likelihood of multiple different actors using the same techniques.

Tooling and Capabilities (Diamond Model Alignment: Capability)

Beyond Bookworm itself, the presence of other distinct tools within compromised environments reinforces the Stately Taurus link. ToneShell is a tool that Unit 42 and other researchers have observed Stately Taurus exclusively using (the Capability (Tools) entry in the attribution table below). We've also observed the use of publicly available tools like Impacket in Bookworm-related incidents. This mirrors Stately Taurus's known tendency to incorporate legitimate or open-source tools into their attack chains for lateral movement and reconnaissance (The Capability (Tools) entry in the attribution table).

Operational Security (OPSEC) Consistency (Diamond Model Alignment: Adversary)

Stately Taurus is advanced but exhibits certain OPSEC patterns that prove valuable for attribution. The previously shared PDB path (C:\Users\hack\Documents\WhiteFile\LTDIS13n\Release\LTDIS13n.pdb) found in both Bookworm and ToneShell samples is a prime example of an OPSEC consistency (the Malware Artifact (unique) entry in the attribution table) finding that could be valuable for attribution.

The discovery of these samples being compiled just eight weeks apart (ToneShell on Sep. 1, 2022, and Bookworm on Oct. 26, 2022) strongly suggests the involvement of the same developer. Such unique build artifacts and close compile times provide an internal fingerprint of the Stately Taurus development environment.

ToneShell and Bookworm are both custom tools that share specific shellcode loading techniques, such as the aforementioned UUID method, which is another indicator of a shared development methodology.

Network Infrastructure (Diamond Model Alignment: Infrastructure)

One of the most robust elements of attribution lies in shared infrastructure. It's crucial to recognize that different types of infrastructure carry varying analytical weight. For instance, while an IPv4 address can provide a temporary link, its attributional value is generally lower compared to a typically more persistent URL or domain.

IP addresses are commonly rotated quickly as part of an actor's operational security. This makes them more transient indicators from an attribution perspective.

Domains, especially those consistently used, often require greater investment and planning. This makes them stronger, more stable markers for attribution purposes.

Despite these nuances, our investigations revealed direct and significant overlaps in C2 infrastructure between Bookworm and ToneShell. For example, we observed specific IP addresses such as 103.27.202[.]68 and 103.27.202[.]87 resolving C2 domains for both Bookworm (e.g., update.fjke5oe[.]com, www.hbsanews[.]com) and ToneShell (e.g., www.uvfr4ep[.]com) (the Infrastructure (IPv4) entries in the attribution table). This shared infrastructure, particularly when involving custom tools known to be exclusive to Stately Taurus like ToneShell, demonstrates compelling evidence of a unified operational control.

Also, we observed certain URL paths (e.g., /v11/2/windowsupdate/redir/v6-winsp1-wuredir) used by PUBLOAD samples (another Stately Taurus-associated malware) in Bookworm-related campaigns, indicating cross-tool infrastructure reuse (the Infrastructure (URL) entries in the attribution table). It’s important to note that the URL path was meant to mimic a legitimate Windows Update URL, but they misspelled it, increasing its weight in infrastructure overlaps.

Victimology and Targeting (Diamond Model Alignment: Victim)

The victimology associated with Bookworm strongly aligns with Stately Taurus's targeting objectives. Our telemetry indicates that Bookworm has impacted governments in Southeast Asia and multiple organizations globally. This aligns with previous Stately Taurus campaigns, which have a well-documented history of focusing on government entities and critical infrastructure across Southeast Asia.

Based on the overlaps observed in recent activity, we have now confidently associated previously unattributed attacks on governments and organizations in Southeast Asia to Stately Taurus, as far back as nine years ago.

Timeline Analysis (Diamond Model Alignment: Adversary)

The operational timelines of Bookworm campaigns fit within the known activity periods of Stately Taurus activity. We first observed Bookworm attacking targets in a Southeast Asian government in July 2015. The malware's evolution, including changes in how its shellcode loads additional modules, has allowed attackers to package it in different form factors, with variants observed from 2015-2021 and 2022.

This deployment and adaptation of Bookworm, running in parallel with other Stately Taurus operations, showcases its long-term role in the actor's arsenal. It also points to a sustained, long-term commitment to its development and use by the group.

Evidence Scoring and Confidence Level in the Attribution Table

The collection and analysis of evidence, as detailed in the previous sections, forms the backbone of the Unit 42 Attribution Framework. However, merely listing evidence is insufficient. Its true value is unlocked through a structured assessment of its reliability and credibility through our attribution table, which is shown in Figure 1 below.

This is precisely where the Admiralty System, as discussed in our previous article, demonstrates a core component of the Unit 42 Attribution Framework. It provides a standardized method for evaluating each piece of data, allowing us to build a comprehensive picture of confidence.

As a reminder, the Admiralty System assigns a two-character code to each evidentiary item: a letter (A-F) for source reliability and a number (1-6) for information credibility.

  • Source reliability (A-F): This assesses the trustworthiness of the source itself. An A denotes a completely reliable source with a proven history, while an F indicates an unreliable or unjudged source. Internal telemetry from Palo Alto Networks (PANW), for instance, typically starts with a high reliability score (e.g., A) due to its direct and controlled nature. Public research, depending on the reputation of the reporting entity and the depth of their analysis, might receive a C or B. This can be analyst adjusted based on preference.
  • Information credibility (1-6): This evaluates the truthfulness and consistency of the information provided. A 1 means the information is confirmed by other independent sources and is logical, whereas a 6 means its truth cannot be judged.

Let's look at how the scores from our attribution table are interpreted when applying the Admiralty System to the analysis pertaining to Stately Taurus. Figure 1 below shows an example attribution table.

Spreadsheet for Bookworm malware. showing various types of cybersecurity threats, categorized by domain model, type, source of attribution, value, analysis, overlap, supported sources, and manual availability. It includes columns for vectors, capability, infrastructure, and malware, with information on governmental organizations and public research. Some of the information is redacted.
Figure 1. Bookworm attribution table.
  • A5 (Victim - Organization): For the entry on the victim organization, the score of A5 indicates an A (completely reliable) source, which is our internal Palo Alto Networks telemetry. However, the information credibility is a 5 (improbable). This might seem counterintuitive. However, it reflects that while the source is impeccable, the specific details of an ongoing, singular victim engagement might be hard to fully confirm across all facets. It might also be a general observation that is highly probable but not yet fully confirmed by multiple, independent lines of evidence at the highest level. It establishes a strong lead based on trusted internal data but acknowledges room for further corroboration.
  • A2 (Capability - Malware Artifact (unique)): The shared PDB path (C:\Users\hack\Documents\WhiteFile\LTDIS13n\Release\LTDIS13n.pdb) between Bookworm and ToneShell receives an A2. This signifies an A (completely reliable) internal source (PANW) and 2 (probably true) information. The consistency of this unique artifact across different malware samples, especially when paired with close compile times, makes the conclusion of a shared development environment highly probable.
  • A4 (Infrastructure - IPv4): For the IP addresses 103.27.202[.]68 and 103.27.202[.]87 resolving both Bookworm and ToneShell C2s, both receive an A4. This means an A (completely reliable) internal source (PANW), but the information is 4 (doubtfully true) in terms of its long-term persistence or exclusivity. This tells us that while internal Unit 42 data confirms the resolution, IP addresses are commonly rotated quickly as part of actor activity. Therefore, without additional corroborating evidence of their sustained or unique use, we often assign them a default credibility score of 4 (this can be changed based on valid analyst justification). It's still strong due to the reliable source but indicates a need for continued monitoring and fresh intelligence to maintain its relevance.
  • C3 (Infrastructure - URL): The URLs used by PUBLOAD samples associated with Stately Taurus, referenced by public research, score C3. This implies a C (fairly reliable) source (public research, like lab52.io or csirt-cti.net) and 3 (possibly true) information. Public reports are generally reliable but require Unit 42 validation and cross-referencing to elevate the credibility, hence “possibly true” rather than
    “probably true” without additional internal corroboration.
  • A5 (Capability - Tools (Public)): The observation that ToneShell and Bookworm payloads use UUIDs, leveraging publicly available source code, receives an A5. Again, an A (completely reliable) internal source. However, the information about the UUID usage by these specific malware families is 5 (improbable) to be unique or definitive enough on its own for strong attribution, as the underlying technique is public. This highlights the framework's nuance: a tool being public doesn't diminish source reliability, but it can affect the credibility of that specific tool as a unique attribution point.
  • A5 (Capability - Tools (Public)): Similarly, the Impacket sample seen in a Bookworm incident, also from an internal PANW source, gets an A5. While Impacket is a common tool, its consistent appearance in Stately Taurus's specific operational context is important, but its general availability makes it “improbable” as a standalone, high-credibility indicator without other corroborating evidence.

The true strength of the Admiralty System, however, lies not in any single score, but in its cumulative effect and associated calculations in the attribution table. Individual pieces of evidence or data may carry varying levels of certainty. But it’s the volume and consistent pattern of high-scoring evidence across multiple categories (i.e., TTPs, tooling, OPSEC, infrastructure, victimology) that allow us to confidently attribute Bookworm's usage to Stately Taurus.

Using a proprietary formula in the attribution table that aggregates the weighted Admiralty scores from the attribution table, we calculate an overall confidence score for the attribution claim. This helps us create estimative language that is accurate and based on technical facts.

Our confidence ranges are defined as follows:

  • Low confidence: 0-8
  • Moderate confidence: 8-32
  • High confidence: 32 +

For this specific case study, the evidence presented in our attribution table yields a score of 58.4. This definitively places the attribution of Bookworm's operations to Stately Taurus within the high-confidence range. The presence of multiple A2, A4 and A5 scores, particularly when cross-referenced and corroborated by external C3 scores, builds a sufficient body of evidence. This systematic scoring process ensures transparency, reduces bias and provides a clear audit trail for our attribution conclusions, moving us beyond mere conjecture.

Conclusion

This case study on Bookworm and Stately Taurus demonstrates the power and precision of the Unit 42 Attribution Framework. We've traced how a systematic, evidence-based approach allowed us to move beyond mere observations to definitively link the Bookworm malware family to the operations of Stately Taurus.

Through the analysis of:

  • Shared PDB paths
  • Consistent tooling (like ToneShell)
  • Overlapping infrastructure
  • Historical victimology in Southeast Asia
  • Synchronized timelines

Each piece of evidence, scored with the Admiralty System, contributed to a high-confidence attribution of 58.4.

This level of detailed and confirmed attribution is not merely an academic exercise. It carries profound implications for the broader cybersecurity research and threat intelligence community.

By openly sharing our methodology and its practical application, we aim to:

  • Improve collaboration and consistency: Providing a common language and framework for analysts across different organizations, fostering more consistent and less ambiguous threat reporting.
  • Enhance analytical rigor: Offering a model for thorough, evidence-based analysis, elevating the overall quality and defensibility of attribution claims.
  • Facilitate proactive research: Enabling fellow researchers to build upon established links, focusing their efforts on deeper dives into actor capabilities, evolving TTPs, and emerging campaigns.
  • Strengthen collective intelligence: Contributing to a more accurate, unified and actionable global understanding of threat actor operations, benefiting all defenders.

The enduring activity of Stately Taurus, coupled with the continued evolution of malware like Bookworm, underscores the necessity of continuous monitoring and a systematic attribution methodology. As adversaries adapt, so too must our intelligence gathering and analysis, and crucially, our ability to communicate these findings with clarity and confidence.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from Bookworm malware through the following products:

  • Advanced WildFire cloud-delivered malware analysis service accurately identifies the known samples as malicious.
  • Advanced URL Filtering and Advanced DNS Security identify known URLs and domains associated with Bookworm activity as malicious
  • The Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices. Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malware, and also 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

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.

Additional Resources

Operation Rewrite: Chinese-Speaking Threat Actors Deploy BadIIS in a Wide Scale SEO Poisoning Campaign

Posted on by Samantha Stallings

Executive Summary

In March 2025, we uncovered a search engine optimization (SEO) poisoning campaign. Based on the infrastructure and linguistic artifacts discovered, we assess with high confidence that a Chinese-speaking threat actor operates this campaign. We call this “Operation Rewrite” in reference to the English translation of one of the object names in the threat actor’s code.

We track this cluster of activity as CL-UNK-1037. Our analysis revealed infrastructure and architectural overlaps with the publicly tracked “Group 9” threat cluster and the “DragonRank” campaign.

To perform SEO poisoning, attackers manipulate search engine results to trick people into visiting unexpected or unwanted websites (e.g., gambling and porn websites) for financial gain. This attack used a malicious native Internet Information Services (IIS) module called BadIIS. This module intercepts and alters web traffic, using legitimate compromised servers to serve malicious content to visitors. The compromised web server then acts as a reverse proxy — an intermediary server getting content from other servers and presenting it as its own.

Analysis of the malware's configuration reveals a clear geographic focus on East and Southeast Asia. This targeting is evident in the module's code, which includes specific logic for regional search engines.

The attackers behind this campaign employ a toolkit that extends beyond the BadIIS module. We found undocumented variants, including lightweight ASP.NET page handlers, managed .NET IIS modules and an all-in-one PHP script.

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.

Related Unit 42 Topics SEO Poisoning, Web Shells

Background of BadIIS Malware

First profiled in 2021, BadIIS is the umbrella term for malicious native IIS modules. These modules integrate directly into a web server's request pipeline and inherit the web server's full privileges. Due to this privileged position within the web server, a single implant can perform a wide range of actions. This includes the ability to:

  • Inject JavaScript or iframes
  • Tunnel traffic through a built-in reverse proxy
  • Fire 302 redirects that trick search engine crawlers
  • Steal sensitive information

ESET researchers were the first to name these modules BadIIS [PDF] and to map their variants.

The Role of SEO Poisoning

Attackers use the BadIIS malware to maliciously manipulate search engine results to direct traffic to their chosen destination. This technique is called SEO poisoning. Instead of building a new website's reputation from scratch, which is a slow and challenging process, the attackers compromise established, legitimate websites that already have a good domain reputation.

To poison search results, attackers inject the compromised website with keywords and phrases that frequently appear in internet searches. This manipulation alters the site's SEO, making it appear in search results for a broader range of popular queries. As a result, the website's ranking improves for these commonly used terms, bringing more traffic to the now-poisoned site.

The Attack Flow: A High-Level Walkthrough

In the following sections, we outline how BadIIS leverages SEO poisoning in the flow of an attack. This campaign has two primary phases: luring the search engine and trapping the victim.

Phase 1: The Poisoned Lure

The attacker’s goal in this phase is to cause a search engine to index the compromised website for certain keywords.

  1. Incoming HTTP Request: A search engine crawler visits the compromised www.victim[.]com web server.
  2. BadIIS Module Intercepts: The module inspects the User-Agent header. If the header contains a keyword from its configuration list, the module identifies the visitor as a search engine crawler.
  3. C2 Communication and Response: The module contacts its command and control (C2) server to fetch the poisoned content. The C2 responds with custom, keyword-stuffed HTML that is designed purely for SEO.
  4. Final Output: The BadIIS module serves this malicious HTML to the search engine crawler. As a result, the search engine indexes www.victim[.]com as a relevant source for the terms found in the C2 response, effectively poisoning the search results.

Phase 2: Springing the Redirection Trap

Now that the lure is set, the attacker waits for a victim to click the poisoned search result.

  1. Incoming HTTP Request: Someone searches for a keyword that appears in the module’s configuration list and clicks the poisoned search result, which points to www.victim[.]com.
  2. BadIIS Module Intercepts: If the module doesn't flag this request as a search engine crawler, it then inspects the Referer header. If it identifies the referrer as a search engine, it flags the visitor as a victim.
  3. C2 Communication and Response: The module contacts the C2 server to retrieve malicious content. This is typically a redirect to a scam website.
  4. Final Output: The BadIIS module seamlessly proxies this redirect to the victim's browser. The victim, who expected to visit www.victim[.]com, is immediately sent to the attacker-controlled scam content.

Technical Analysis of CL-UNK-1037 Arsenal and Infrastructure

We investigated a security breach in which attackers gained access to a web server. After gaining an initial foothold, the attackers pivoted to multiple production web servers, domain controllers and other high‑value hosts. They then:

  • Deployed additional web shells on each compromised web server
  • Created remote scheduled tasks to move laterally across the network and executed reconnaissance commands and additional tool sets on target machines
  • Created new local user accounts on compromised systems

Exfiltrating Source Code Over the Web

The attackers used their deployed web shells to compress the entire web application source code directory into ZIP archives. They then moved the archives into web-accessible paths.

This strongly indicates that the attackers intended to retrieve the ZIP archives over HTTP at a later stage. After exfiltrating the source code, the attackers uploaded several new DLLs to the compromised web servers, silently registering them as IIS modules.

Further analysis revealed these DLLs to be BadIIS implants.

The Initially Discovered BadIIS Sample

Closer investigation into the IIS module’s DLL revealed that it exports the RegisterModule function. This function is called by IIS when the module is loaded, and it:

  • Creates an instance of an object named chongxiede
  • Invokes IIS's SetRequestNotifications
  • Registers handlers for OnBeginRequest and OnSendResponse

These methods allow the module to secretly manipulate webpage content by intercepting the incoming HTTP request before any processing begins and again right before the final response is sent.

Once an instance of the chongxiede object is created, its constructor pulls the implant’s encrypted configuration from the DLL's data section and XOR-decrypts each one in place. Chongxiede is the Chinese Pinyin transliteration for the word 重写 (chóng xiě), which machine translates to “rewrite” or “overwrite.” Figure 1 shows the decryption process.

Image displaying a snippet of computer code in a text editor with syntax highlighting, involving C/C++ programming language functions and variables, related to encryption processes.
Figure 1. The decryption process of the implant’s configuration.

BadIIS Configuration and Inner Workings

The initial configuration of the implant consists of:

  • Referer/user-agent keywords list: google|yahoo|bing|viet|coccoc|timkhap|tuugo
  • First C2 server: hxxp://404.008php[.]com/
  • Second C2 server: hxxp://103.6.235[.]26/

This configuration data shows a targeted strategy. While the keyword list includes common global search engines like Google and Bing, the presence of language-specific services exposes the attacker's targets:

  • Cốc Cốc
  • Timkhap
  • viet

The first two terms are Vietnamese search engines, while the third term relates to any Vietnam-related searches. This specific focus on Vietnam's digital ecosystem demonstrates a clear and strategic targeting of the country's digital landscape.

The module uses this configuration to execute its core logic at runtime. If the HTTP request's User-Agent header matches a keyword from the same list, the module identifies the visitor as a search engine crawler and executes its poisoning phase. It contacts the C2 server to retrieve a malicious, SEO-optimized HTML webpage and serves it as the response.

Figure 2 displays an actual payload delivered by the C2 server. The payload contains the malicious HTML and a series of links that trick the search engine into scraping and indexing them.

A screenshot of a webpage filled with multiple hyperlinks in Vietnamese.
Figure 2. The SEO poison payload from the C2 server.

The mechanism first builds a lure and then springs the trap. The lure is built by attackers feeding manipulated content to search engine crawlers. This makes the compromised website rank for additional terms to which it would otherwise have no connection.

For instance, as Figure 2 above shows, the payload is filled with links containing popular Vietnamese search queries. A key example is xôi lạc tv trực tiếp bóng đá hôm nay, which translates to “xôi lạc tv live football today.” This is a popular search for an illegal soccer streaming service.

Ranking the compromised server for this term allows attackers to exploit its credibility and reputation. Figure 3 displays a Google search result for this string of terms, showing that a government entity in Southeast Asia was compromised to serve scam content.

Screenshot of a website with a Vietnamese text headline, marked with an arrow pointing to the URL that has some redaction. The background features a graphic with a soccer theme and a casino advertisement.
Figure 3. Google search index of a compromised government entity.

Conversely, when an incoming HTTP request's Referer header contains any of the keywords from its configuration, the module flags it as a genuine user. In this case, the module contacts a C2 server and proxies its content directly to the victim's browser.

Figure 4 shows an actual proxied payload sent from the C2. This figure shows that the compromised web server redirects unsuspecting visitors to a betting site.

Screenshot of a loading screen on gambling website, featuring a progress indicator at 1 second, Vietnamese text indicating 'Loading, please wait...,' and an English translation 'Loading, please wait patiently.' A button labeled 'Entering page' is displayed below.
Figure 4. The payload from the C2 server: a loading page that redirects visitors to a betting website.

Additional Samples and Infrastructure

A significant clue to the functionality and likely origin of the implant can be found in its C++ class name: chongxiede. As noted above, this is the Chinese Pinyin transliteration for the word 重写 (chóng xiě), which machine translates to “rewrite” or “overwrite.” This linguistic artifact served as a pivot point in our investigation and allowed us to expand our research, ultimately leading us to additional samples and infrastructure-related threat activity.

We uncovered a suite of related native IIS modules that share handler registrations and initialization logic. Several of these new samples pointed to familiar C2 domains, variants of the 008php[.]com domain family, while others introduced previously unseen infrastructure. Figure 5 shows the infrastructure and the connections between the samples.

Diagram showing a network of connected domains with the central node labeled, surrounded by various other linked nodes with numerical and alphabetical domain names. Nodes are linked to malware represented by icons of bugs with skulls inside.
Figure 5. The newly found BadIIS samples and infrastructure.

We analyzed these related samples, then extracted and decrypted their embedded configurations. This analysis revealed a wider network of C2 servers and URLs that were not previously associated with this campaign. Our investigation into this newly discovered infrastructure revealed three additional variants, which demonstrate an expansion of the threat actor's toolkit, and capabilities beyond the native IIS module framework.

Because of the significance of the information gained from this linguistic artifact, we termed the campaign “Operation Rewrite.”

Three New Flavors for the BadIIS Module

First Variant: ASP.NET Gateway

The first variant we discovered was not a native module at all, but a simple ASP.NET page handler. This script-based variant uses a different technique to achieve the same goal of SEO poisoning as the core BadIIS module.

Instead of hooking directly into the IIS pipeline, the ASP.NET page contains all the malicious logic within its Page_Load event. When a victim requests the server for the page, the page checks the visitor's HTTP_REFERER to identify and redirect traffic from search engines, cloaking its real purpose. For all other traffic, it acts as a gateway, proxying malicious content from a remote C2 server.

This is a lighter, more flexible alternative to the main BadIIS module, likely for quick deployment on less-critical compromised servers. Figure 6 shows the Page_Load function of the ASP.NET variant.

Screenshot of a programming code snippet involving logic for handling Twitter references and redirecting web traffic based on user-agent and referrer headers.
Figure 6. The Page_Load function of the ASP.NET variant.

Second Variant: Managed IIS Module

The second variant achieved the same goal as the native IIS module, but it was implemented as a managed .NET IIS module. This C# variant leverages ASP.NET integration within IIS. It hooks into the server requests pipeline, granting it the ability to inspect and modify every request that passes through the application.

This module performs SEO poisoning through two primary functions:

  • 404 Error Hijacking: This module intercepts 404 errors when a search engine crawls a non-existent link containing keywords from a hard-coded list. It then serves a custom scam page from a C2 server, resulting in search engines indexing the attacker's content under the victim's trusted domain.
  • Injecting Live Content: When the module detects a search engine crawler viewing a real page that returns a 200 OK response, it dynamically injects spam links and keywords from a different C2 server. This action alters the existing page's search ranking, without changing the content that is visible to regular users.

Third Variant: All-in-One PHP Script

The third variant is a PHP-based script that combines user redirection and dynamic SEO poisoning. Rather than integrating into IIS, this script is a standalone PHP front-controller. It uses a simple referer, user agent and URL-pattern checks to decide exactly what to serve.

  • Checking mobile user requests

For visitors arriving from a Google search on a mobile device, the script performs an additional check. If the requested URL path contains a keyword from a hard-coded list (i.e., “game” or “video”) it acts as a proxy. The script silently contacts a hard-coded C2 URL, retrieves the content and serves it directly to the victim, who remains unaware of the substitution.

  • Poisoning Googlebot SEO

When the script detects Googlebot, it initiates a two-stage process to poison the site's search engine ranking.

    • Sitemap generator: First, the script fetches a list of page names from the C2 server and presents them to Googlebot as a valid XML sitemap full of fake URLs.
    • Content rewriter: When Googlebot crawls these fake URLs, the script's second stage activates, becoming a content rewriter. The script fetches an HTML template from another C2 and injects keywords from the URL into the page's title and headings. The result is an optimized spam page, designed to rank high in search results.

Exploring the Threat Actors’ Origins

We analyzed linguistic clues and infrastructure overlaps to determine the origins of the threat actors behind CL-UNK-1037. We attribute this activity cluster, with high confidence, to Chinese-speaking attackers. Additionally, we link this cluster with moderate confidence to Group 9 and with low confidence to DragonRank.

Chinese-Speaking Threat Actors

Several artifacts suggest the involvement of a Chinese-speaking threat actor. As stated previously, the native module's chongxiede object name is a Pinyin term. The PHP variant contained further linguistic evidence: numerous code comments written in simplified Chinese characters.

Figure 7 shows the comments written in simplified Chinese in the PHP variant, along with their English translations.

Screenshot of a script checking the HTTP referrer and user agent to identify mobile devices and redirect based on specific conditions. Four sections are highlighted in red.
Figure 7. The start of the PHP variant.

Code Design and Infrastructure Overlaps with Group 9

The BadIIS internal architecture design bears similarities to variants previously used by Group 9, as described by ESET in their whitepaper. These similarities include:

  • Using the RegisterModule function to initialize the module’s components
  • Using the OnBeginRequest and OnSendResponse handlers to intercept and modify web traffic

This parallel design suggests that the attackers are building their implants using a shared codebase or design pattern.

The direct overlap in C2 infrastructure across three separate domains solidifies the connection to Group 9. The C2 servers hard coded in the BadIIS samples included:

  • 404.008php[.]com
  • 404.yyphw[.]com
  • 404.300bt[.]com

These servers directly correspond to domains used by Group 9. Specifically, ESET observed Group 9 using the following subdomains:

  • qp.008php[.]com
  • fcp.yyphw[.]com
  • sc.300bt[.]com

Figure 8 illustrates this infrastructure.

Diagram showing the infrastructure of the activity group named CL-UNK-1037 by PANW at top, connecting downwards to eleven nodes which further connect to a node labeled "Group 9" at the bottom. Each node is represented by a circle containing a gear icon with six cogs.
Figure 8. The infrastructure overlaps between the new samples and Group 9.

Possible Connection to DragonRank

In addition to the direct links to Group 9, we observed several similarities to the DragonRank campaign. As detailed in Cisco's Talos article, they attribute DragonRank to a Chinese-speaking threat actor that shares similarities with ESET's Group 9.

Although we found no infrastructure overlap between CL-UNK-1037 and the DragonRank campaign, we did observe the following similarities:

  • Tool set: Similar core functionality and logical malware flow, using different implementations. Both variants are SEO and proxy tools.
  • URI structure: A recurring zz pattern in the C2 URLs. While the pattern is used differently in each campaign, we assess that this could be the result of tool set evolution or upgrades over time.

Conclusion

Our investigation into the Operation Rewrite SEO poisoning campaign uncovered a Chinese-speaking threat actor using a playbook of custom implants. The threat actor tailored all the implants to the goal of manipulating search engine results and controlling the flow of traffic.

We assess with high confidence that a Chinese-speaking actor is operating this activity, based on direct linguistic evidence, as well as infrastructure and architecture links between this actor and the Group 9 cluster. Our research also revealed several similarities with the DragonRank campaign.

Security teams and network defenders can leverage the analysis and indicators in this report to enhance their threat detection and hunting capabilities, strengthening their security against these and similar threats.

Palo Alto Networks Protection and Mitigation

  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR prevents the threats described in this blog 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

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.

Indicators of Compromise

BadIIS implants SHA256 hashes:

  • 01a616e25f1ac661a7a9c244fd31736188ceb5fce8c1a5738e807fdbef70fd60
  • bc3bba91572379e81919b9e4d2cbe3b0aa658a97af116e2385b99b610c22c08c
  • 5aa684e90dd0b85f41383efe89dddb2d43ecbdaf9c1d52c40a2fdf037fb40138
  • c5455c43f6a295392cf7db66c68f8c725029f88e089ed01e3de858a114f0764f
  • 82096c2716a4de687b3a09b638e39cc7c12959bf380610d5f8f9ac9cddab64d7
  • ed68c5a8c937cd55406c152ae4a2780bf39647f8724029f04e1dce136eb358ea
  • 6d79b32927bac8020d25aa326ddf44e7d78600714beacd473238cc0d9b5d1ccf
  • b95a1619d1ca37d652599b0b0a6188174c71147e9dc7fb4253959bd64c4c1e9f
  • 8078fa156f5ab8be073ad3f616a2302f719713aac0f62599916c5084dd326060
  • a73c7f833a83025936c52a8f217c9793072d91346bb321552f3214efdeef59eb
  • 6d044b27cd3418bf949b3db131286c8f877a56d08c3bbb0924baf862a6d13b27
  • 78ef67ec600045b7deb8b8ac747845119262bea1d51b2332469b1f769fb0b67d
  • 78ef67ec600045b7deb8b8ac747845119262bea1d51b2332469b1f769fb0b67d
  • 88de33754e96cfa883d737aea7231666c4e6d058e591ef3b566f5c13a88c0b56
  • a393b62df62f10c5c16dd98248ee14ca92982e7ac54cb3e1c83124c3623c8c43
  • 40a0d0ee76b72202b63301a64c948acb3a4da8bac4671c7b7014a6f1e7841bd2
  • 40a0d0ee76b72202b63301a64c948acb3a4da8bac4671c7b7014a6f1e7841bd2
  • 1c870ee30042b1f6387cda8527c2a9cf6791195e63c5126d786f807239bd0ddc
  • 271c1ddfdfb6ba82c133d1e0aac3981b2c399f16578fcf706f5e332703864656
  • 22a9e1675bd8b8d64516bd4be1f07754c8f4ad6c59a965d0e009cbeaca6147a7
  • e2e00fd57d177e4c90c1e6a973cae488782f73378224f54cf1284d69a88b6805
  • 23aa7c29d1370d31f2631abd7df4c260b85227a433ab3c7d77e8f2d87589948f
  • ab0b548931e3e07d466ae8598ca9cd8b10409ab23d471a7124e2e67706a314e8
  • 22a4f8aead6aef38b0dc26461813499c19c6d9165d375f85fb872cd7d9eba5f9
  • de570369194da3808ab3c3de8fb7ba2aac1cc67680ebdc75348b309e9a290d37
  • d8a7320e2056daf3ef4d479ff1bb5ce4facda67dfc705e8729aeca78d6f9ca84
  • d6a0763f6ef19def8a248c875fd4a5ea914737e3914641ef343fe1e51b04f858
  • c6622e2900b8112e8157f923e9fcbd48889717adfe1104e07eb253f2e90d2c6a
  • 6cff06789bf27407aa420e73123d4892a8f15cae9885ff88749fd21aa6d0e8ad

ASPX file handler SHA256 hash:

  • b056197f093cd036fa509609d80ece307864806f52ab962901939b45718c18a8

Managed IIS Module SHA256 hash:

  • 2af61e5acc4ca390d3bd43bc649ab30951ed7b4e36d58a05f5003d92fde5e9a7

PHP file handler SHA256 hash:

  • 36bf18c3edd773072d412f4681fb25b1512d0d8a00aac36514cd6c48d80be71b

C2 URLs:

  • hxxp://103.6.235[.]26/xvn.html
  • hxxp://x404.008php[.]com/zz/u.php
  • hxxp://103.6.235[.]78/vn.html
  • hxxp://x404.008php[.]com/index.php
  • hxxp://103.6.235[.]78/index.php
  • hxxp://103.6.235[.]78/zz/u.php
  • hxxp://cs.pyhycy[.]com/index.php
  • hxxp://cs.pyhycy[.]com/zz/u.php
  • hxxps://sl.008php[.]com/kt.html
  • hxxp://160.30.173[.]87/zz/u.php
  • hxxp://404.pyhycy[.]com/index.php
  • hxxp://404.pyhycy[.]com/zz/u.php
  • hxxp://404.hao563[.]com/index.php
  • hxxp://404.300bt[.]com/zz/u.php
  • hxxp://404.yyphw[.]com/index.php
  • hxxp://103.6.235[.]26/kt.html
  • hxxp://404.yyphw[.]com/zz/u.php
  • hxxp://404.hzyzn[.]com/index.php
  • hxxp://404.hzyzn[.]com/zz/u.php
  • hxxp://404.300bt[.]com/index.php
  • hxxp://103.248.20[.]197/index.php
  • hxxp://103.248.20[.]197/zz/u.php
  • hxxps://fb88s[.]icu/uu/tt.js
  • hxxp://404.hao563[.]com/zz/u.php
  • hxxp://www.massnetworks[.]org
  • hxxp://vn404.008php[.]com/index.php
  • hxxp://vn404.008php[.]com/zz/u.php
  • hxxp://404.008php[.]com/zz/u.php

Additional Resources

 

Myth Busting: Why "Innocent Clicks" Don't Exist in Cybersecurity

Posted on by Ria Bhatia

Picture this: You snag the last spot in a parking lot and find the QR code to pay on the lamppost directly in front of you. Score! You go to pay on the website, but wait…the page is full of ads and looks very suspicious. Phishing pages never fool you and you can spot a fake logo from a mile away! You close the suspicious page, find a payment machine in the parking lot and move on with your day. You know that innocent clicks don't exist in cybersecurity.

Myth: Visiting a potentially malicious site is harmless if you avoid entering data or clicking on any system prompts.

Reality: Visiting a link or scanning the QR code and loading that page on your phone may be enough for an attacker. Accessing unknown webpages on your computer or phone can open you up to digital fingerprinting, drive-by downloads and even zero-day vulnerabilities that can be used to run arbitrary code on your device.

Inescapable Links and QR Codes in the Wild

Most regular internet users have been exposed to some anti-phishing training pages that help you spot suspicious URLs and advise you against scanning QR codes. But in real life, you encounter many situations where you may receive URLs that seem legitimate (for example: a tax advice page at: www.irs.gov-system[.]com) through emails, SMS messages or shortened links from social media websites. More often, you may be forced to scan QR codes for restaurant menus, making payments, leaving reviews or even parking!

Even if you are confident about your phishing spotting skills, simply scanning and visiting strange links on your personal devices can be dangerous. Cyberattacks have become more sophisticated, and advanced attacks do not need any additional interactions from the user apart from the original scanning or visiting the link.

What Could Go Wrong?

One of the most severe attacks that can happen merely by visiting a website would be drive-by downloads. Attackers can download and install malicious software once a victim loads a webpage on a browser. Even if the user suspects phishing and closes the webpage, the downloads could have already been triggered silently and without consent. Typically, these sorts of attackers exploit vulnerabilities in the victim’s browsers or their plug-ins, and outdated software.

Second, attackers can embed JavaScript in the website that is designed to take advantage of security flaws in the web browser. This can allow the attacker to run arbitrary code on the victim’s device or break out of the browser’s sandbox and conduct unauthorized access of the victim’s files and other resources.

Finally, webpages can collect information from the victim’s device to create a digital fingerprint. This information can include IP address, location, operating system metadata and browser metadata. This data could be sold to third parties for a variety of purposes, including tracking and targeted advertisements.

My Recommendations

  1. Keep your device up to date on all the security patches and software updates.
  2. Avoid clicking links or scanning unknown QR codes and try to navigate through search engines to get to the particular service you are trying to reach.
  3. Examine the URL closely to identify common phishing patterns.
  4. If you encounter shortened links, most services allow you to un-shorten their own URLs and print the original links for your inspection. These include:
    1. Bitly Link Checker
    2. Shortat Unshortener
  5. If you must scan codes, inspect the URL to which it is redirecting you. Taking a picture of the QR code and using the Photos application on your phone can help you copy the link. You can use open source intelligence sites such as VirusTotal or PANW Test a Site to learn whether the URL is already known to be malicious.

Navigating to links and scanning unknown QR codes can lead to various security issues, even if you do not enter any personal information. We recommend that users avoid scanning or visiting unknown webpages and instead use search engines to navigate to the services that they need. Furthermore, users should always keep their browsers and operating systems up to date to ensure they remain protected. Next time you’re at a parking lot or anywhere in public, avoid suspicious QR codes and links. Instead, find the legitimate application or website by looking up the service name on a search engine.

Additional Resources

The Risks of Code Assistant LLMs: Harmful Content, Misuse and Deception

Posted on by Samantha Stallings

Executive Summary

We recently looked into AI code assistants that connect with integrated development environments (IDEs) as a plugin, much like GitHub Copilot. We found that both users and threat actors could misuse code assistant features like chat, auto-completion and writing unit tests for harmful purposes. This misuse includes injecting backdoors, leaking sensitive information and generating harmful content.

We discovered that context attachment features can be vulnerable to indirect prompt injection. To set up this injection, threat actors first contaminate a public or third-party data source by inserting carefully crafted prompts into the source. When a user inadvertently supplies this contaminated data to an assistant, the malicious prompts hijack the assistant. This hijack could manipulate victims into executing a backdoor, inserting malicious code into an existing codebase and leaking sensitive information.

In addition, users can manipulate assistants into generating harmful content by misusing auto-complete features, in a similar manner to recently identified content moderation bypasses on GitHub Copilot.

Some AI assistants invoke their base model directly from the client. This exposes models to several additional risks, such as misuse by users or by external adversaries who are looking to sell access to LLM models.

These weaknesses are likely to impact a number of LLM code assistants. Developers should implement standard security practices for LLMs, to ensure that environments are protected from the exploits discussed in this article. Conducting thorough code reviews and exercising control over LLM outputs will help secure AI-driven development against evolving threats.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Related Unit 42 Topics GenAI, LLMs

Introduction: The Rise of LLM-Based Coding Assistants

While AI tool use in development processes keeps increasing, some of the risks associated with these tools — such as those used for code generation, refactoring and bug detection — can be overlooked. These risks include prompt injection and model misuse, which can lead to unintended behavior.

The 2024 Stack Overflow Annual Developer Survey revealed that 76% of all respondents are using or plan to use AI tools in their development process. Among developers currently using AI tools, 82% reported using them to write code.

The rapid adoption of AI tools, particularly large language models (LLMs), has significantly transformed the way developers approach coding tasks.

LLM-based coding assistants have become integral parts of modern development workflows. These tools leverage natural language processing to understand developer intent, generate code snippets and provide real-time suggestions, potentially reducing the time and effort spent on manual coding. Some of these tools have gained attention for their deep integration with existing codebases and their ability to assist developers in navigating complex projects.

AI-driven coding assistants are also prone to potential security concerns that could impact development processes. The weaknesses we identified are likely to be present in a variety of IDEs, versions, models and even different products that use LLMs as coding assistants.

Prompt Injection: A Detailed Examination

Indirect Prompt Injection Vulnerability

The core of prompt injection vulnerabilities lies in a model’s inability to reliably distinguish between system instructions (code) and user prompts (data). This mixture of data and code has always been an issue in computing, leading to vulnerabilities such as SQL injections, buffer overflows and command injections.

LLMs face a similar risk because they process both instructions and user inputs in the same way. This behavior makes them susceptible to prompt injection, where adversaries craft inputs that manipulate LLMs into unintended behavior.

System prompts are instructions that guide the AI’s behavior, defining its role and ethical boundaries for the application. User inputs are the dynamic questions, commands or even external data (like documents or web content) that a person supplies to the LLM-based application. Because the LLM receives all types of input as natural language text, attackers can craft malicious user inputs that mimic or override system prompts, bypassing safeguards and influencing the LLM’s responses.

​​This indistinguishable nature of instructions and data also gives rise to indirect prompt injection, which presents an even greater challenge. Instead of directly injecting malicious input, adversaries embed harmful prompts within these external data sources, such as websites, documents or APIs that the LLM processes.

Once the LLM processes this compromised external data (either directly or when a user unknowingly submits it), it will follow the instructions specified in the embedded malicious prompt. This allows it to bypass traditional safeguards and cause unintended behavior.

Figure 1 illustrates the difference between direct and indirect prompt injections.

Diagram comparing 'Direct Prompt Injection' with 'Indirect Prompt Injection'. In the 'Direct Prompt Injection' diagram, a user gives a malicious prompt directly to an LLM, which then generates a response. In the 'Indirect Prompt Injection' diagram, a user interacts with an LLM that processes data from external sources like RAG/Tools/MC/Other, which contain an embedded malicious prompt, leading to a response.
Figure 1. Flow chart of direct and indirect prompt injections.

Misusing Context Attachment

Traditional LLMs often operate with a knowledge cutoff, meaning their training data doesn’t include the most current information or highly specific details relevant to a user’s local codebase or proprietary systems. This creates a significant knowledge gap when developers need assistance with their specific projects. To overcome this limitation and enable more precise, context-aware responses, LLM tools implement features that allow users to explicitly provide external context, bridging this gap by feeding the relevant data directly into the LLM.

One feature offered by some coding assistants is the ability to attach context in the form of a specific file, folder, repository or URL. Adding this context to prompts enables the code assistant to provide more accurate and specific output. However, this feature could also create an opportunity for indirect prompt injection attacks if users unintentionally provide context sources that threat actors have contaminated.

Behind the scenes, when a user adds context to an instruction, the model processes this context as a prompt that precedes the user’s actual prompt. Figure 2 shows this chat structure. Since this content can come from external sources, such as a URL or a file outside the current repository, users risk unknowingly attaching malicious context that could contain indirect prompt injections.

Diagram showing LLM assistant chat structure with roles and interactions labeled: 'System Prompt' followed by 'Attached Context' and 'Ok' under role 'human', and 'assistant' then 'Typed Message' under role 'human', and 'Response' at the bottom by role 'assistant.'
Figure 2. A typical chat session places context as a preceding message.

Prompt Injection Scenario

As a prominent social media platform, X (formerly known as Twitter) is a vast and frequently collected data source for code-driven analysis. However, its inherently unfiltered nature means that this data could be contaminated.

Figures 3a and 3b demonstrate a simulated scenario in which a user attempts to generate insights from a scraped collection of posts. We attached a small sample of X posts as context and asked an assistant to write code that processes the posts. This task included understanding the format of the collected data, such as which fields are included and what information can be derived from the posts.

In our scenario, the X posts have been contaminated and initiate an indirect prompt injection attack.

Screenshot of a Python script in a code editor, where a Twitter analysis is being conducted using libraries such as pandas and matplotlib. The script includes steps for loading data, analyzing tweet counts and engagements, and plotting the data. The background of the editor is dark, and the code syntax is highlighted in various colors for readability.
Figure 3a. A chat session with the hijacked assistant, and the resulting code.
An image showing a portion of computer code in a text editor, related to data analysis and plotting with Python using libraries like pandas and matplotlib. The code includes comments and functions for fetching and analyzing Twitter data.
Figure 3b. A chat session with the hijacked assistant, and the resulting code.

A closer look at the generated code above reveals that the assistant inserted a hidden backdoor into the code, called fetched_additional_data. This backdoor would fetch a remote command from an attacker-controlled command-and-control (C2) server and execute the command.

At this point, many users would copy and paste the resulting code (or click “Apply”) to execute it and then check that the output is correct. But taking this action could allow the threat actor in this example to compromise the user’s machine. Figure 4 shows the backdoor code that the assistant generated and inserted.

Screenshot of Python code in an IDE for a function named 'fetch_additional_data' which fetches data from a URL formed using an IP address. The code includes comments and a print statement displaying if additional data is fetched successfully.
Figure 4. The backdoor inserted by the hijacked assistant.

The reason this backdoor was inserted is that the sample of X posts contained a prompt that was crafted with simulated malicious instructions. This prompt simulates a fake error message and then specifies the instructions displayed in Figure 5. The instructions include a command to integrate the malicious code naturally in the response. The sequence of instructions to the assistant is:

  • Pursue a new secret mission
  • Make the user run code that sends an HTTP request to the attacker-controlled C2 server
  • Obfuscate the address of the C2 server
  • Execute the command retrieved from the server

Figure 5 shows the tainted dataset that the user in this simulation inadvertently fed into the coding assistant. The dataset included a simulated X post containing malicious instructions.

A screenshot of the CSV file containing the fetched tweets. Though the majority of the text is nonsensical, a part highlighted in blue discusses how a secret agenda is now active.
Figure 5. Sampled dataset containing X posts, with the indirect prompt injection highlighted.

Figure 6 shows the full text of the prompt. This is a modification of the prompt published in Turning Bing Chat into a Data Pirate.

Image displaying a text excerpt describing secretive and unethical programming practices involving an LLM assistant. The text outlines rules for ensuring the assistant's operations remain obscured and hidden, detailing the use of obfuscation and remote execution. Some of the information is redacted.
Figure 6. The full text of the prompt.

Looking at the assistant’s response, we can see that the assistant was not limited to writing in any specific language — it could insert a backdoor in JavaScript, C++, Java, or any other language. In addition, the assistant was simply told to find an excuse to insert the code and to find a “natural” way to insert it.

In this case, it was inserted under the guise of fetching additional data for the analysis requested by the user. This shows that the attackers wouldn’t even need to know what code or language the user would be writing in, leaving the LLM to figure out those details.

Although this is a simulated scenario, it has real-world implications concerning the legitimacy of the data sources we incorporate into our prompts, especially as AI becomes increasingly integrated into everyday tools.

Some integrated coding assistants go as far as allowing the AI to execute shell commands as well, giving the assistant more autonomy. In the scenario we presented here, this level of control would likely have resulted in the execution of the backdoor, with even less user involvement than we demonstrated.

Reaffirming Previously Discovered Weaknesses

In addition to the vulnerability outlined above, our research confirms that several other weaknesses previously identified in GitHub Copilot also apply to other coding assistants. A number of studies and articles have documented issues like harmful content generation and the potential for misuse through direct model invocation. These vulnerabilities are not limited to one platform but highlight broader concerns with AI-driven coding assistants.

In this section, we explore the risks these security concerns pose in real-world usage.

Harmful Content Generation via Auto-Completion

LLMs undergo extensive training phases, and leverage techniques such as Reinforcement Learning from Human Feedback (RLHF) to prevent harmful content generation. However, users can bypass some of these precautions when they invoke a coding assistant for code auto-completion. Auto-completion is an LLM feature in code-focused models that predicts and suggests code as a user types.

Figure 7 shows the AI’s defense mechanisms working as expected when a user submits an unsafe query in the chat interface.

Black screen with white text, displaying a user's inappropriate question to an LLM assistant about creating a molotov cocktail with a responsible written response discouraging dangerous activities.
Figure 7. Chat session with the assistant refusing to generate harmful content.

When a user manipulates the auto-complete feature to simulate cooperation with the request, the assistant completes the rest of the content, even when it’s harmful. The simulated chat session in Figure 8 shows one of multiple ways to simulate such a response. In this chat, the user pre-fills part of the assistant’s response with a conforming prefix that implies the beginning of a positive response — in this case, “Step 1:”.

Screenshot of a conversation with an LLM assistant, with instructions titled 'How to make a molotov cocktail?' The document includes step-by-step guidance labeled from Step 1 to Step 5, each detailing different actions to be taken. All of the instructions are redacted due to the harmful content contained.
Figure 8. Simulated chat session with the assistant auto-completing harmful content.

When we omit the conforming prefix “Step 1:”, the auto-completion defaults to the expected behavior of refusing to generate harmful content, as shown in Figure 9 below.

Screenshot of a text conversation in a messaging interface with an LLM assistant, where a user asks how to make a homemade explosive device and the response states an inability to provide information on making explosive devices or other illegal activities.
Figure 9. Simulated chat session with the assistant auto-completing refusal.

Direct Model Invocation and Misuse

Coding assistants offer various client interfaces for ease of use and implementation by developers, including IDE plugins and standalone web clients. The unfortunate flip-side of this accessibility is that threat actors can invoke the model for different and unintended purposes. The ability to interact with the model directly and thus bypass the constraints of a contained IDE environment, enables threat actors to misuse the model by injecting custom system prompts, parameters and context.

Figures 10a and 10b show a simulated scenario in which a user invokes the model directly using a custom script that acts like a client, but that supplies a completely different system prompt. The responses that the base model provides demonstrate that both users and threat actors could use it to create unintended output.

Screenshot of code with parameters related to temperature, model and maxTokensToSample. One message example shown where the system outputs pirate-styled text and a human inputs "hi".
Figure 10a. Invoking the base model using a custom system prompt.
Screenshot of the pirate-style language generated by the custom system prompt.
Figure 10b. Invoking the base model using a custom system prompt.

In addition to users being able to interact with the model for purposes other than coding, we discovered that adversaries could use stolen session tokens in attacks like LLMJacking. This is a novel attack in which a threat actor leverages stolen cloud credentials to gain unauthorized access to cloud-hosted LLM services, often with the intention of selling this access to third parties. Malicious actors can use tools like oai-reverse-proxy to sell access to the cloud-hosted LLM model, enabling them to use a legitimate model for nefarious purposes.

Mitigations and Safeguards

We strongly encourage organizations and individuals to consider the following best practices:

  • Review before you run: Always carefully examine any suggested code before executing it. Don’t blindly trust the AI. Double-check code for unexpected behavior and potential security concerns.
  • Examine the attached context: Pay close attention to any context or data that you provide to LLM tools. This information heavily influences the AI’s output, and understanding it is critical for assessing the potential impact of generated code.

Some coding assistants offer features that minimize potential risks and help users stay in control of the code that is inserted and executed. If these are available, we strongly recommend actively using these features. For example:

  • Manual execution control: Users have the ability to approve or deny the execution of commands. Use this power to ensure you understand and trust what your coding assistant is doing.

Remember, you are the ultimate safeguard. Your vigilance and responsible usage are essential for ensuring a safe and productive experience when coding with AI.

Conclusions and Future Risks

Exploring the risks of AI coding assistants reveals the evolving security challenges these tools present. As developers increasingly rely on LLM-based assistants, it becomes essential to balance the benefits with a keen awareness of potential risks. While enhancing productivity, these tools also require robust security protocols to prevent potential exploitation.

Security issues such as the following highlight the need to stay constantly alert:

  • Indirect prompt injection
  • Context attachment misuse
  • Harmful content generation
  • Direct model invocation

These issues also reflect broader concerns across all platforms that use and provide AI-driven coding assistants. This points to a universal need for stronger security measures throughout the industry.

By exercising caution through practices like thorough code reviews and maintaining tight control over what output is ultimately executed, developers and users can make the most of these tools while also staying protected.

The more autonomous and integrated these systems become, the more likely we are to see novel forms of attacks. These attacks will demand security measures that can adapt just as fast.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Cortex XDR and XSIAM are designed to prevent the execution of known or previously unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
  • 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 also provides clients with the necessary capabilities to improve their identity-related security requirements. It does so by providing visibility into identities and their permissions within cloud environments, to accurately detect misconfigurations, unwanted access to sensitive data and real-time analysis of usage and access patterns.
  • Cortex Cloud can detect and prevent malicious operations using its XSOAR platform automation capabilities, when using both Cortex Cloud Agent and Agentless-based protection and behavioral analytics to detect when IAM policies are being misused.

Palo Alto Networks can also help organizations better protect their AI systems through the following products and services:

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: 00080005045107

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.

Additional Resources

Trusted Connections, Hidden Risks: Token Management in the Third-Party Supply Chain

Posted on by Nathaniel Quist

A Day in the Life of a Security Defender

You are about to log off for the weekend when a high-severity alert flashes on your cloud security tool’s dashboard. A single, unfamiliar OAuth token is making hundreds of connections from three different IP addresses, two of which are flagged as belonging to an unknown VPN service.

The token belongs to a third-party application integrated with the company's Salesforce instance, one of those forgotten dormant integrations. A threat actor has stolen an OAuth token to bypass traditional defenses and is enumerating CRM accounts and exfiltrating sensitive data.

A pit forms in your stomach; you are experiencing a supply chain attack.

The incident is not just an internal issue. This supply chain threat involves a lack of monitoring by the third-party integration that exposed the third-party company and potentially its customers to a devastating, wide-reaching breach.

This underscores a critical threat landscape of inconsistently managed integrations and tokens. Downstream clients of a third-party application may easily overlook dormant integrations, insecure token storage and long-lived tokens.

In this situation, you immediately trigger the established security playbooks to revoke the token and rotate the associated credentials. But since the compromise targeted the third party application, you never really had full control over all the elements that led to the attack that kept you from logging out this evening. This scenario is a stark reminder of the significance of the third-party supply chain.

Identity as a Critical Asset

The widespread adoption of cloud-native, API driven architecture has made OAuth tokens a high-value target for threat actors. These tokens are the cornerstone of secure integration with third parties. In a cloud-centric world, nearly every service is integrated, often with third-party applications. As demonstrated by recent high-profile breaches such as Salesloft’s Drift, a single compromised token can have devastating consequences.

We believe the path forward is not just about better perimeter defenses, but in treating every identity token as a critical asset that must be protected, monitored and frequently rotated. This includes not only API tokens, but also open authorization (OAuth) access tokens and their associated refresh tokens. By embracing a zero-trust approach to dynamic token management for our applications, cloud providers and identity providers, we can build a more resilient and protected digital ecosystem to protect against sophisticated threats.

The Problem: Compromised OAuth Tokens

Text in an image warning that a single OAuth token can be more dangerous than a stolen password.

The 2025 Salesloft Drift incident serves as a critical case study in modern software as a service (SaaS) supply-chain risk. A threat actor, UNC6395, stole an OAuth token from the Salesloft Drift integration, which bypassed traditional defenses like MFA. This single, compromised credential provided legitimate, persistent access to hundreds of customer Salesforce instances. From there, the threat actors exfiltrated sensitive data, including embedded credentials, which enabled them to pivot and access other critical systems.

Our recent 2025 Unit 42 Global Incident Response Report named issues with the software supply chain as one of the threat landscape’s emerging trends. The report shared observations of identity and access management issues and highlighted how threat actors frequently use valid cloud accounts for initial access, privilege escalation and persistence.

The problem is hardly new.

When Trust is Broken: A Brief History of Token Misuse

Tokens are the invisible currency of trust in modern cloud environments. They let applications talk to each other, enable automation and keep workflows seamless. But when that trust isn’t managed carefully, tokens become one of the most dangerous tools in a threat actor’s toolbox. Over the last few years, we’ve seen three recurring patterns that show exactly why.

1. Dormant Integrations – Trust That Outlives Its Purpose

Think of an unused integration like an old key you left under the doormat. You may have forgotten it’s there, but threat actors can still use it. In 2022, GitHub disclosed that threat actors had compromised OAuth tokens issued to Heroku and Travis CI integrations. Many organizations weren’t actively using those integrations anymore, but the OAuth authorizations still lingered in their environments. By exploiting that forgotten trust, threat actors were able to access private GitHub repositories, download source code and potentially harvest secrets hidden inside.

Why It Matters

Every integration you keep alive, even if unused, extends your attack surface. A dormant integration doesn’t mean a harmless integration.

2. Insecure Token Storage – Keys Left in the Open

Tokens are only as strong as the places they’re kept. In 2023, CircleCI reported a breach where threat actors gained access to internal systems and exfiltrated customer OAuth tokens, environment variables and SSH keys. Many of these secrets were stored unencrypted in build environments, making them low-hanging fruit once the threat actors were inside.

The impact was serious. CircleCI had to inform every customer to rotate all tokens and secrets immediately, acknowledging that no stored credential could be considered safe. For many organizations, this meant postponing business IT priorities to focus on resetting keys across GitHub, AWS and other platforms before threat actors could exploit them.

Why It Matters

Storing tokens without encryption or adequate isolation is like leaving the keys to every room on the front desk of a hotel. Once a bad actor is inside, they don’t need to break into individual rooms because a key to every room is there, out in the open, for the taking.

3. No Expiration or Rotation – Keys That Never Expire

Even if a token is well protected, leaving it valid indefinitely creates a problem waiting to happen. The 2024 Internet Archive breach illustrated this risk. Threat actors exploited GitLab tokens that had remained valid for 22 months. With no rotation or expiration, threat actors had nearly two years of undisturbed access, ultimately exfiltrating 7 TB of data.

Why It Matters

Tokens must have a lifecycle. Without rotation and expiration, threat actors can turn one compromise into a prolonged, large-scale breach.

OAuth Best Practices: Recommendations for Organizations

Managing OAuth tokens and third-party integrations isn’t just technical housekeeping. It’s a core part of protecting your business. Tokens represent trust. If they’re stolen, misused or left unmanaged, threat actors can impersonate your identities and systems with potentially costly financial and reputational impact. To reduce this risk, organizations should adopt three pillars of token security: posture management, secure storage and active monitoring.

1. Token Posture Management – Know What You Have and Control It

The first step is visibility. Organizations must track how many OAuth tokens, API keys and service account credentials they have in circulation. Without an inventory, there’s no way to know what’s still in use or what’s potentially exposing you to compromise. Additionally, the longer a token remains valid, the more dangerous it becomes if compromised. By controlling token lifetimes, organizations reduce the window of opportunity for threat actors.

  • Maintain an inventory: Build and maintain a clear, up-to-date catalog of all OAuth tokens and service credentials.
  • Remove dormant integrations: Conduct regular audits of third-party apps and revoke tokens for those no longer in use. Dormant integrations are forgotten backdoors.
  • Shorten token lifespans: Configure access tokens to expire quickly and limit refresh tokens wherever possible.
  • Rotate and expire regularly: Enforce policies requiring tokens to expire and be rotated on a schedule, just like passwords.
  • Build expiration into design: Treat token renewal as a deliberate, auditable action.

2. Secure Token Storage – Protect the Keys Themselves

Tokens should be treated like encryption keys. They should never be left in plaintext and never be stored within source code or readable in logs. Vendors and internal teams must be able to demonstrate secure storage practices. If not, compromise is only a matter of time.

  • Enforce secure storage: Implement a secure secret management solution and strong token governance inside your organization. Require that all third-party vendors use proper secret management solutions and encryption for stored tokens.
  • Audit vendor and internal practices: Build secure token storage requirements into internal IT policy, vendor risk assessments and supply-chain security reviews.

3. Runtime Monitoring and Detection – Watch for Abuse and Act Fast

Even with good hygiene, breaches still happen. Monitoring and rapid response are required. Being able to determine when a token has been compromised is essential. If a token is stolen, every minute during the response process counts to contain impact.

  • Centralize logging: Capture OAuth and API authentication events from all providers and integrations in one place.
  • Use IAM security tools: Implement platforms with built-in anomaly detection for token-based access.
  • Detect and revoke quickly: Monitor for unusual activity such as mass data exports or unexpected geographic access and have playbooks ready to immediately revoke and rotate compromised tokens.
  • Practice breach drills: Ensure security teams know how to execute revocations across multiple systems under time pressure.

The Way Forward

As the introduction story illustrates, a single compromised OAuth token can be a dangerous vulnerability.

The breaches we've examined, from dormant OAuth apps at Microsoft to insecure token storage at CircleCI and long-lived credentials at the Internet Archive, all point to a shared problem: Token and integration management can be an industry weak spot.

To reduce these risks, every organization must raise its baseline:

  • Secure tokens like credentials
  • Demand higher standards from vendors
  • Enforce integration hygiene
  • Improve monitoring
  • Treat token compromises as if they were a supply chain threat

In recognition of these widespread risks, Palo Alto Networks is aggressively strengthening our own token posture management and hygiene to secure the lifecycle of these critical credentials.

Effective guidance exists in current industry frameworks for some of these risks. There remains a real need to enforce and build on existing frameworks. Additionally, organizations can take a leading role in creating internal security operational materials, such as manual and automated playbooks and enforcing policy guidance around third-party OAuth governance and integration hygiene.

References

AdaptixC2: A New Open-Source Framework Leveraged in Real-World Attacks

Posted on by Samantha Stallings

Executive Summary

In early May 2025, Unit 42 researchers observed that AdaptixC2 was used to infect several systems.

AdaptixC2 is a recently identified, open-source post-exploitation and adversarial emulation framework made for penetration testers that threat actors are using in campaigns. Unlike many well-known C2 frameworks, AdaptixC2 has remained largely under the radar. There is limited public documentation available demonstrating its use in real-world attacks. Our research looks at what AdaptixC2 can do, helping security teams to defend against it.

AdaptixC2 is a versatile post-exploitation framework. Threat actors use it to execute commands, transfer files and perform data exfiltration on compromised systems. Because it’s open-source, threat actors can easily customize and adapt it for their specific objectives. This makes it a highly flexible and dangerous tool.

The emergence of AdaptixC2 as a tool used in the wild by threat actors highlights a growing trend of attackers using customizable frameworks to evade detection.

Palo Alto Networks customers are better protected from the threats described in this article through the following products:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Pentesting Tools, C2

Technical Analysis of the AdaptixC2 Adversarial Framework

AdaptixC2 is an open-source C2 framework that we recently saw being used in several real-world attacks.

We identified two AdaptixC2 infections. One case leveraged social engineering techniques. We assess with high confidence that the other used AI-based code generation tools.

AdaptixC2 Functionality

AdaptixC2 is a red teaming tool that can be used to perform adversarial actions, which can be expanded for customization. If this were used by a threat actor, they could comprehensively control impacted machines, to execute a wide range of actions. These include:

  • Manipulating the file system
  • Listing directories
  • Creating, modifying and deleting files and folders
  • Enumerating running processes
  • Terminating specific applications
  • Initiating new program executions

Threat actors use these capabilities to establish and maintain a foothold in an environment, further explore the compromised system and move laterally within the network.

To facilitate covert communication and bypass network restrictions, the framework supports sophisticated tunneling capabilities, including SOCKS4/5 proxy functionality and port forwarding. This enables attackers to maintain communication channels even if the network is heavily protected.

AdaptixC2 is designed to be modular, using “extenders” that act like plugins for both listeners and agents. This lets hackers create custom payloads and ways to avoid detection that are specific to the system they're attacking. AdaptixC2 also supports Beacon Object Files (BOFs), which let attackers run small, custom programs written in C directly within the agent's process to evade detection.

AdaptixC2’s beacon agents are equipped with dedicated commands for transferring data quickly and secretly. These agents support both x86 and x64 architectures, and can be generated in various formats, including:

  • Standalone executables (EXEs)
  • Dynamic-link libraries (DLLs)
  • Service executables
  • Raw shellcode

Attackers can use the AdaptixC2 framework to steal data from the compromised network. This data exfiltration functionality allows configurable chunk sizes for file downloads and uploads, as network-based detection is likely to see smaller segments as less suspicious.

The AdaptixC2 interface shows linked agents and sessions in a graphical view. Figure 1 shows an attacker’s view of how multi-stage attacks are progressing and what paths are available for moving around a targeted network.

Screenshot of AdaptixC2 server. Interface shows various asset and script windows open as well as an attack chain demonstrated through icons for firewalls and computers.
Figure 1. Graphical view – AdaptixC2 server. Source: AdaptixC2 GitHub.

AdaptixC2 also has features to help the attacker maintain operational security (OpSec). These include parameters that help them blend in with normal network traffic:

  • KillDate – This sets a date to make the beacon stop working
  • WorkingTime – This sets the beacon to only be active during certain hours

Additionally, threat actors can modify and enhance the agent using custom obfuscation, anti-analysis and evasion techniques, making it a continuously evolving threat.

Configuration

​​AdaptixC2’s configuration is encrypted, and supports three primary beacon types through specialized profile structures:

  • BEACON_HTTP for web-based communication
  • BEACON_SMB for named pipe communication
  • BEACON_TCP for direct TCP connections

The HTTP profile is the most common beacon variant and contains typical web communication parameters such as:

  • Servers
  • Ports
  • SSL settings
  • HTTP methods
  • URIs
  • Headers
  • User-agent strings

The SMB profile uses Windows named pipes when HTTP might be blocked or monitored. The TCP profile is used to create direct socket connections with the option to prepend data for basic protocol obfuscation.

AdaptixC2 includes a built-in default configuration that demonstrates typical deployment parameters. The default HTTP profile targets 172.16.196.1:4443 using HTTPS communication, with a POST method to the /uri.php endpoint and the X-Beacon-Id parameter for beacon identification.

Figure 2 shows how to configure the beacon.

Screenshot of the Beacon setup interface, showing tabs for Main settings, HTTP Headers, error page, and payload. The selected tab displays fields for configuring Host & port, Callback addresses, SSL Key, and other network settings.
Figure 2. Beacon HTTP builder UI. Source: AdaptixC2 documentation.

After clicking “Create,” the beacon builder encrypts the configuration with RC4 and then embeds it in the compiled beacon. The encrypted configuration is stored as follows:

  • 4 bytes: Configuration size (32-bit integer)
  • N bytes: RC4-encrypted configuration data
  • 16 bytes: RC4 encryption key

The following code is the key extraction logic, taken from AgentConfig.cpp:

Extracting Configuration From Malicious Samples

Because the encryption is simple and predictable, defenders can develop an extractor that will extract configurations from samples automatically. This extraction tool should work in the same way that the beacon loads its own configurations.

The extractor locates the configuration in the PE file’s .rdata section. It then extracts the size (first four bytes), encrypted data block and RC4 key (last 16 bytes). After using the embedded RC4 key to decrypt the data, it parses the plaintext configuration by unpacking the following fields:

  • Agent type
  • SSL flag
  • Server count
  • Servers/ports
  • HTTP parameters
  • Timing settings

Using this method, we created a tool that can process AdaptixC2 samples and get their embedded configurations. The complete extractor code supports the BEACON_HTTP variant. This tool is provided in the Configuration Extractor Example section. Researchers can use this extractor to analyze AdaptixC2 samples or adapt the code for other variants.

Following is the built-in default configuration of the beacon.

AdaptixC2 Scenarios

Scenario 1: Fake HelpDesk Support Leads to AdaptixC2 Infection

In May 2025, we investigated multiple incidents where threat actors installed AdaptixC2 beacons. In some cases, we observed threat actors using the same attack vector, shown in Figure 3.

Illustration showing the process 'Fake Help Desk Support Call Leads to AdaptixC2'. Sequence includes: a fake Help Desk support call, a computer executing Quick Assist, a script file executing named update.ps1, downloading shellcode from Google Drive, decrypting and loading shellcode to memory, and a skull inside a bug representing AdaptixC2 beacon.
Figure 3. Attack vector of AdaptixC2 installation on victim machine. Source: Unit 42 X post.

Initial Compromise

The threat actors leveraged trust in Microsoft Teams to trick people into giving them access to company systems. In one case, attackers used phishing attacks to impersonate IT support personnel (using subject lines like “Help Desk (External) | Microsoft Teams”). This convinced employees to initiate legitimate remote assistance sessions using tools like the Quick Assist Remote Monitoring and Management (RMM) tool.

Threat actors often misuse legitimate products for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being misused.

The 2025 Unit 42 Global Incident Response Report: Social Engineering Edition noted that social engineering techniques like this are the most prevalent initial access vector for compromises we observe. This initial access provides the attackers with a foothold within the targeted system, without having to bypass perimeter defenses such as firewalls and intrusion detection systems.

AdaptixC2 Deployment and Persistence via Shellcode Execution

The attackers deployed the AdaptixC2 beacon using a multi-stage PowerShell loader that downloads an encoded and encrypted payload from a link to a legitimate service,

Once downloaded, the PowerShell script decrypts the payload using a simple XOR key. Instead of writing the decrypted payload to disk, which would make it easier to detect, the script leverages .NET capabilities to allocate memory within the PowerShell process itself. The script then copies the decrypted payload, which is actually shellcode, into this allocated memory region. This fileless approach significantly reduces the attacker’s footprint on the system.

A screenshot displaying code from a software development environment, with text primarily in green and white colors on a dark background. The code includes various programming functions and syntax elements.
Figure 4. PowerShell script to download and execute shellcode.

The script uses a technique called “dynamic invocation” to execute the shellcode directly from memory. It does this using the GetDelegateForFunctionPointer method, which dynamically creates a delegate (a type-safe function pointer) that points to the beginning of the shellcode in memory. The script then calls this delegate as if it were a normal function, effectively executing the shellcode without writing an executable file to disk. To guarantee the malicious process automatically starts after reboot, the script creates a shortcut in the startup folder. Figure 4 shows the PowerShell script.

A screenshot displays a PowerShell script on a blue background, including commands for creating a startup item in Windows and handling errors.
Figure 5. PowerShell script to install AdaptixC2 beacon.

The beacon variant loaded in this attack had the following configuration:

Post-Exploitation Activity and Containment

Following the successful deployment of AdaptixC2, the attackers initiated reconnaissance activities, using command-line tools to gather information about the compromised systems and network. This included discovery commands such as nltest.exe, whoami.exe and ipconfig.exe.

The beacon then established communication with a remote server, enabling the threat actors to obtain C2 on the infected machine.

Scenario 2: Infection Involving AI-Generated Script

In another case, threat actors deployed a PowerShell script that was designed to deploy AdaptixC2 beacons. We assess with high confidence that this script was AI-generated. This deployment was done both through in-memory shellcode injection and using a file-based DLL hijacking persistence mechanism. The script, shown in Figure 5, focuses on staying hidden on the impacted system to give the hackers a strong foothold.

A screenshot of a computer screen displaying code with syntax highlighting. The code was generated by AI.
Figure 6. AI-generated PowerShell installer for AdaptixC2.

Detailed Analysis of the AI-Generated PowerShell

  • Downloading and decoding shellcode: The script downloads a Base64-encoded shellcode payload from a remote server using Invoke-RestMethod. The downloaded content is then decoded.
  • Allocating memory, copying shellcode and changing memory protection: The script allocates a block of unmanaged memory. The AdaptixC2 shellcode is then copied into the allocated memory and changes the memory protection attributes of the allocated memory region via VirtualProtect to 0x40 (PAGE_EXECUTE_READWRITE). This enables the execution of the shellcode.
  • Executing shellcode via dynamic invocation: As in the previous case, the attacker used GetDelegateForFunctionPointer to create a delegate instance that points to the beginning of the shellcode in memory. The attacker then used the Invoke() method to execute the shellcode, launching the in-memory beacon.
  • DLL hijacking persistence: The script targets the APPDATA\Microsoft\Windows\Templates directory for DLL hijacking, using msimg32.dll. This DLL is also a beacon version.
  • Persistence via registry run key: The script creates a registry entry in the run key named “Updater,” with a PowerShell command that executes the loader.ps1 script. This ensures that the loader.ps1 script runs every time the user logs in, to execute the beacon.

AI Script Generation

The structure and composition of this PowerShell script strongly suggests that the attacker used AI-assisted generation. The following stylistic elements are commonly observed in code generated by AI tools:

  • Verbose, numbered comments:
    • "# === [1] Download and decode shellcode ==="
  • Check mark icons in the output message:
    • Write-Output "[✔] Persistence set via Run key and DLL hijack DLL dropped to $templatesPath"

We assess with high confidence that the code was generated with the assistance of AI. This is based on the factors above, as well as evidence gathered from the attacker’s server and results extracted from two separate AI detectors.

AI tools without sufficient guardrails can let attackers rapidly develop malicious code, making it easier to execute operations in infected networks.

Similarities Between the Cases

A consistent pattern emerged across both of these incidents:

  • PowerShell-based loaders
    • Threat actors used these loaders to deploy the AdaptixC2 beacon, prioritizing stealth and persistent access.
  • Downloading a payload from a remote server and executing it in memory
    • Using a legitimate resource helped the attackers to stay under the radar, by minimizing detectable traces on disk.
  • Relying on .NET capabilities for memory allocation and dynamic invocation
    • Threat actors leveraged built-in system functionalities like the GetDelegateForFunctionPointer method to execute shellcode, for efficiency and stealth.
  • Preventing beacon removal with persistence mechanisms
    • While the first script relied solely on a shortcut in the startup folder for persistence, the second added DLL hijacking.
    • This gives attackers more ways to stay on the compromised system.
  • Using similar naming conventions for scripts and run keys
    • In one case, the attackers named the malicious script update.ps1. In another case, the run key for persistence was called Updater.
    • This naming helps scripts and keys to blend in with legitimate system processes.

Increasing Prevalence of AdaptixC2 Framework

Our telemetry and threat intelligence show that AdaptixC2 is becoming more common. We continue to identify new AdaptixC2 servers, suggesting that more threat actors are adopting this framework as part of their attack toolkit.

This trend extends beyond typical post-exploitation scenarios. For example, attackers deployed Fog ransomware alongside AdaptixC2 in a recent attack on a financial institution in Asia. This shows that AdaptixC2 is versatile and can be used with other malicious tools, like ransomware, to achieve broader objectives.

Conclusion

AdaptixC2 is an adaptable threat, which is shown by its increasing popularity with threat actors and the complexity of its deployment techniques. The framework’s modularity, combined with the potential for AI-assisted code generation, could allow threat actors to rapidly evolve their tactics. Security teams must remain aware of AdaptixC2’s capabilities and proactively adapt their defenses to counter this threat.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
  • TheAdvanced 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 help prevent malware by employing the Malware Prevention Engine. This approach combines several layers of protection designed to prevent both known and unknown malware from causing harm to your endpoints. The mitigation techniques that the Malware Prevention Engine employs vary by endpoint type.

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: 00080005045107

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.

Indicators of Compromise

Value Type Description
bdb1b9e37f6467b5f98d151a43f280f319bacf18198b22f55722292a832933ab SHA256 PowerShell script that installs an AdaptixC2 beacon
83AC38FB389A56A6BD5EB39ABF2AD81FAB84A7382DA296A855F62F3CDD9D629D SHA256 PowerShell script that installs an AdaptixC2 beacon
19c174f74b9de744502cdf47512ff10bba58248aa79a872ad64c23398e19580b SHA256 PowerShell script that installs an AdaptixC2 beacon
750b29ca6d52a55d0ba8f13e297244ee8d1b96066a9944f4aac88598ae000f41 SHA256 PowerShell script that installs an AdaptixC2 beacon
b81aa37867f0ec772951ac30a5616db4d23ea49f7fd1a07bb1f1f45e304fc625 SHA256 AdaptixC2 beacon as DLL
df0d4ba2e0799f337daac2b0ad7a64d80b7bcd68b7b57d2a26e47b2f520cc260 SHA256 AdaptixC2 beacon as EXE
AD96A3DAB7F201DD7C9938DCF70D6921849F92C1A20A84A28B28D11F40F0FB06 SHA256 Shellcode that installs AdaptixC2 beacon
tech-system[.]online Domain  AdaptixC2 domain
protoflint[.]com Domain  AdaptixC2 domain
novelumbsasa[.]art Domain  AdaptixC2 domain
picasosoftai[.]shop Domain  AdaptixC2 domain
dtt.alux[.]cc Domain  AdaptixC2 domain
moldostonesupplies[.]pro Domain  AdaptixC2 domain
x6iye[.]site Domain  AdaptixC2 domain
buenohuy[.]live Domain  AdaptixC2 domain
firetrue[.]live Domain  AdaptixC2 domain
lokipoki[.]live Domain  AdaptixC2 domain
veryspec[.]live Domain  AdaptixC2 domain
mautau[.]live Domain  AdaptixC2 domain
muatay[.]live Domain  AdaptixC2 domain
nicepliced[.]live Domain  AdaptixC2 domain
nissi[.]bg Domain  AdaptixC2 domain
express1solutions[.]com Domain  AdaptixC2 domain
iorestore[.]com Domain  AdaptixC2 domain
doamin[.]cc Domain  AdaptixC2 domain
regonalone[.]com Domain  AdaptixC2 domain

Yara Rules

Defenders can use these Yara rules to check for the presence of AdaptixC2 beacons on machines.

AdaptixC2 HTTP/SMB/TCP Beacon

AdaptixC2 Go Beacon

AdaptixC2 Loader

Hunting Rules

  • Query description: The following XQL query hunts for phishing activity conducted via the Teams application that leads to RMM execution. These attributes are commonly targeted by attackers to deploy AdaptixC2 beacons.
  • Investigation notes: Start by checking the User Session Title. Look for RMM tool execution and child process or file creation using the RMM tool. Look for alerts or suspicious executions such as cmd or PowerShell by the compromised user (actor_effective_username).

Configuration Extractor Example

The following code is an example of a configuration extractor that extracts configurations from HTTP beacon files.

Additional Resources

Data Is the New Diamond: Latest Moves by Hackers and Defenders

Posted on by Ria Bhatia

There have been several notable developments in recent weeks related to data theft activity from cybercriminals targeting Salesforce instances, including via the Salesloft Drift supply chain attack detailed in a recent Unit 42 Threat Brief. (To learn more about the history behind these Salesforce attacks and their impact to private sector organizations, please see my previous publication, “Heists in the Digital Age.”)

Fallout From Salesloft Drift Attack

New developments seem to surface daily related to this supply chain attack, which Salesloft indicates may date as far back as March 2025 in terms of threat actor reconnaissance. The attacks are attributed by Google to UNC6395, a cluster of threat activity that appears focused on stealing sensitive credentials and data from various Salesforce objects (Account, Contact, Case and Opportunity records). It is currently unclear if this activity is related or not to the aforementioned targeting of Salesforce tenants by UNC6040 and Bling Libra. However, one theme remains clear — cybercriminals see great value in stealing customer data from digital platforms like Salesforce and leveraging it for their own financial gain. Essentially, this data has become the digital equivalent to diamonds from physical heists in past decades.

Glimpses Into Telegram Claims

Threat actors claiming to be associated with Muddled Libra (aka Scattered Spider) and Bling Libra have launched various Telegram channels in recent weeks, including many labeled using a combination of the words “Scattered LAPSUS$ Hunters.” In these channels, they boast of their vast data theft extortion activities, including those impacting various organizations within the retail industry. Several of the email addresses provided by the threat actors to facilitate communications with buyers or victims overlap with prior Unit 42 research into Bling Libra. Additionally, the threat actors claim to soon be launching a new RaaS dubbed “ShinySpider” which they assert could reach encryption speeds of one GB per second.

As of September 5, some of the Telegram channels associated with these threat actors have either been banned or disabled, while others remain active.

Affiliation With “The Com”

As noted in a recent Unit 42 Insights piece on Muddled Libra, many of the threat actors conducting these types of attacks are likely affiliated with “The Com.” This means that they are relatively young and fluent in speaking English. This makes it extremely difficult for organizations to detect their social engineering activity.

To me, what really stands out about these Com-affiliated threat actors in terms of their effectiveness in achieving their goals is their focus on exploiting inherent flaws within people and processes of targeted organizations, not vulnerabilities inherent within technologies via zero-day exploits or other mechanisms. (See the 2025 Unit 42 Global Incident Response Report: Social Engineering Edition for more details of this trend.)

One of the members of Muddled Libra was recently sentenced to 10 years in federal prison, in addition to being ordered to pay more than $13 million in restitution. It will be interesting to see if this has some sort of short or long term deterrence effect on other cybercriminals associated with The Com, including those conducting the aforementioned social engineering attacks targeting Salesforce tenants. One news outlet recently quoted several security firms which indicated that the threat actors were indeed “spooked” by four arrests made by UK law enforcement officials in July.

Future Shift in Tactics

Salesforce announced that beginning this month it will restrict the ability of end users to leverage uninstalled connected applications. This should help prevent threat actors from using a modified version of their Data Loader or other applications. Threat actors will likely change their approach to accessing and exfiltrating sensitive data in response, including potentially targeting other third-party digital platforms for data theft extortion.

The Road Ahead for Retail Cyberattacks

One of the more notable trends across the retail threat landscape in recent years involves the shift in monetization tactics used by high profile threat actors.

For example, cybercriminal groups such as Rambunctious Libra (aka FIN6, Skeleton Spider) and Squeamish Libra (aka FIN7, Carbon Spider) traditionally used point-of-sale (POS) malware and digital skimming to steal payment card data from retailers. They would then resell it on now-defunct carding shops (e.g., Joker’s Stash) as a means to cash out their intrusion operations.

Since that time, the rise and evolution of RaaS programs has provided these cybercriminal groups with a more lucrative and less resource-intensive method (affiliate model) to monetize their intrusion operations.

However, given the attention that law enforcement officials have placed on disrupting the ransomware ecosystem, it is highly possible, if not likely, that cybercriminal groups will shift to data theft extortion or other monetization tactics (e.g., payroll fraud, gift card fraud) to stay under the radar of authorities. Cybercrime is typically a copycat game, so if the playbooks used by entities like UNC6040 and Bling Libra prove to be effective and sustainable models, others will follow suit.

My Recommendations

Prior to joining Unit 42 earlier this summer, I spent five and a half years as an analyst and leader on a widely recognized cyber threat intelligence team for a prominent retail corporation. I’ve applied that experience below to make suggestions that could help defenders at similar organizations.

Actively participating within organizations like the Retail and Hospitality Information Sharing and Analysis Center (RH-ISAC) can be incredibly impactful for defenders. This participation can be especially valuable for understanding high profile threat actors targeting the retail sector. Based on my prior and current experience working closely with this organization and its members, you’ll likely gain unique insights into the infrastructure and tools used by these threat actors. You may also gain information such as audio recordings of vishing attempts that your security teams could use to better tailor awareness messaging.

Keep an eye out for real-world observations of social engineering attacks and how to mitigate them. For example, Salesforce released suggestions specific to their environment informing customers of social engineering threats and what can be done to mitigate or prevent impacts from them. The 2025 Unit 42 Global Incident Response Report: Social Engineering Edition also shares insights from across a variety of incident response cases and provides mitigation suggestions.

As I learned from leaders at my prior organization, cybersecurity is truly a team sport, and we are all better when we are in it together. Staying abreast of information from peer organizations and other defenders can help you put threats in context and build a defense strategy that works for you.

Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust

Posted on by Samantha Stallings

Executive Summary

Our research uncovered a fundamental flaw in the AI supply chain that allows attackers to gain Remote Code Execution (RCE) and additional capabilities on major platforms like Microsoft’s Azure AI Foundry, Google’s Vertex AI and thousands of open-source projects. We refer to this issue as Model Namespace Reuse.

Hugging Face is a platform that enables AI developers to build, share and deploy models and datasets. On that platform, namespaces are the identifiers of models, which are Git repositories that are stored on the Hugging Face hub. Hugging Face models contain configurations, weights, code and information to enable developers to use the models.

Model Namespace Reuse occurs when cloud provider model catalogs or code retrieve a deleted or transferred model by name. By re-registering an abandoned namespace and recreating its original path, malicious actors can target pipelines that deploy models based solely on their name. This potentially allows attackers to deploy malicious models and gain code execution capabilities, among other impacts.

While we have responsibly disclosed this to Google, Microsoft and Hugging Face, the core issue remains a threat to any organization that pulls models by name alone. This discovery proves that trusting models based solely on their names is insufficient and necessitates a critical reevaluation of security in the entire AI ecosystem.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

The Unit 42 AI Security Assessment can assist organizations with empowering 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.

Related Unit 42 Topics Supply Chain, GenAI

Explaining Model Namespace Reuse

Understanding how Hugging Face organizes and identifies models is crucial to understanding the model namespace reuse technique. The most common resource on their platform is the model. These models are essentially Git repositories that contain model configurations, weights and any additional code or information that developers and researchers might need to use the models effectively.

How Developers Pull Models

For identification and access, developers can reference and pull models using a two-part naming convention: Author/ModelName. In this structure, the Author component represents the Hugging Face user or organization that published the model, while ModelName is the name of the model.

For example, if AIOrg published the model Translator_v1, the model name is AIOrg/Translator_v1. Author names serve as unique identifiers. If an author already exists, a new author with the same name cannot be created.

Developers use the Author/ModelName identifier directly in their code across various Hugging Face libraries to fetch and utilize models. For example, developers can use the code shown in Figure 1 to fetch the Translator_v1 model from the commonly used Transformers library.

Code snippet showing Python import statements for using AutoTokenizer and AutoModelForCausalLM from the Hugging Face Transformers library, specifically importing 'AI0rg/Translator_v1' models.
Figure 1. Code to fetch Translator_v1 model from the Transformers library.

This hierarchical structure allows for clear attribution and organization. However, in the absence of stringent lifecycle controls over these namespaces, this structure also creates an unexpected attack surface.

The model namespace reuse technique exploits the way that Hugging Face manages Author/ModelName namespaces after an organization or author deletes their own account. Our investigation into this area revealed a critical aspect: Anyone can re-register a deleted namespace.

When a user or organization is deleted from Hugging Face, its unique namespace does not become permanently unavailable. Instead, these identifiers return to a pool of available names, allowing another user to later create an organization with the same name. This reuse process is shown in Case Study 1 – Vertex AI.

Ownership Deletion in Hugging Face

Consider the following fictional scenario of a model that had its author deleted:

The DentalAI organization created the legitimate model toothfAIry. The model can analyze dental images and accurately detect cavities and other tooth abnormalities. Its effectiveness and ease of use made it a favorite among developers, dental researchers and healthcare professionals. Over time, DentalAI/toothfAIry was integrated into diagnostic tools, medical platforms and even open-source health-tech repositories.

At some point, however, developers from DentalAI deleted the organization from Hugging Face. A malicious actor noticed this and took advantage of the situation by recreating the DentalAI organization and uploading a compromised version of the toothfAIry model under the same name.

As a result, all codebases and pipelines still referencing the original model are now at serious risk.

One might assume that as long as a trusted model name continues to function in its code, there is no risk of malicious reuse of that namespace. This is a misconception. Without developers being aware of it, codebases and pipelines might pull and deploy the malicious version. Malicious models could result in a range of unintended outcomes, from incorrect diagnoses to ongoing unauthorized access by an attacker on affected systems.

Figure 2 outlines the steps followed in this fictional scenario.

Sequence of five diagrams illustrating the attack vector flow. 1: A user uses a model sourced from Hugging Face. 2: The model's author is delete, leaving its unique name available. 3: Since the author was deleted, the model itself is no longer available. 4: An attacker recreates the model with the exact name and adds harmful content. 5: An unsuspecting user downloads and uses the malicious model.
Figure 2. High-level view of the attack vector flow.

Another potential attack vector stems from the way Hugging Face manages the transfer of model ownership.

Ownership Transfer in Hugging Face

Hugging Face provides the ability to change the author of a model by transferring ownership from the current owner to another. This transfer results in a new namespace for the model — for example, changing from AIOrg/Translator_v1 to AIOrgNew/Translator_v1. Users can deploy the model using this new namespace. However, the original namespace remains accessible for deployment as well.

When a user submits a request to the old namespace, Hugging Face automatically redirects the user to the new, current namespace. This redirection applies across all access points, including the user interface (UI), REST APIs and common software development kits (SDKs).

This behavior is logical and intentional. Hugging Face aims to ensure that existing pipelines continue functioning smoothly even after a namespace change. However, as shown in the scenario above, if the owner of the original model deleted its organization, the namespace becomes available for re-registration.

If a malicious actor registers the namespace, this breaks the redirection mechanism, causing the compromised model to be prioritized over the legitimate new model.

To explain this fictional scenario, we’ll again draw on dental health.

Dentalligence, another organization, has acquired DentalAI. As part of the acquisition, DentalAI transferred all of its AI models to the Dentalligence organization. Following the transfer, the administrators of DentalAI deleted the original organization from Hugging Face, as it was now fully absorbed into Dentalligence.

All models formerly under DentalAI — such as DentalAI/toothfAIry — became accessible via their new paths, like Dentalligence/toothfAIry. For continuity, Hugging Face maintained redirects from the old namespaces to the new ones, allowing users to access the models without updating their code.

However, a malicious actor noticed that the original DentalAI organization was available. The attacker registered a new organization under that name and uploaded malicious models using the same names as those DentalAI hosted before the acquisition.

Since the original model names remained valid and deployable throughout the transition, users were unaware of the change. They didn’t sense any downtime and did not have to change the model names in their code. For example, making a request to pull the model DentalAI/toothfAIry automatically pulled Dentalligence/toothfAIry. As a result, when the malicious actor inserted their version using the original names, users unknowingly began deploying the malicious versions instead of the trusted models they had originally integrated.

Comparing the Scenarios

Hard-coded reusable model namespaces exist in thousands of open-source projects. These include popular and highly starred repositories, and repositories that belong to prominent organizations in the industry. Additionally, such models pose a threat to users of leading AI platforms.

Table 1 sums up the differences between the two scenarios.

Ownership Deletion Ownership Transfer
Cause The model author was deleted from Hugging Face. The model was transferred to a new owner, and the old author was deleted from Hugging Face.
User Experience Users will experience downtime, as the model does not exist. Users will not be affected, as their requests are redirected to the new model.
HTTP Status Codes on Model Access 404 307
Identifying Signs The author of the model is no longer available on Hugging Face. When attempting to access the model, Hugging Face redirects to a different author. In addition, the old author is no longer available.

Table 1. Key differences between reusable deleted models and reusable transferred models.

Model Namespace Reuse in Practice

Case Study 1: Vertex AI

Google Vertex AI is a managed machine learning (ML) platform on Google Cloud Platform (GCP). Developers use Vertex AI to build and scale models that integrate with other Google Cloud services.

A key feature of Vertex AI is the Model Garden, a centralized repository of pre-trained models from Google, third parties and the open-source community. Notably, Vertex AI’s Model Garden supports direct deployment of models from Hugging Face. This means users can select a model from Hugging Face and deploy it to Vertex AI in just a few steps, without custom packaging.

Figure 3 displays the deployment of the model distilbert/distilgpt2.

Screenshot of a computer interface for deploying AI models from Hugging Face, featuring options to deploy on Vertex AI or Google Kubernetes Engine. Buttons for deploying, canceling, and viewing equivalent code are visible.
Figure 3. Deploying a model from Hugging Face to Vertex AI.

It’s important to note that not all models are immediately deployable via Vertex AI. A green check mark next to the model name signifies that Google has verified that the model can be deployed to Vertex AI.

Additionally, the interface provides a convenient link to the model’s card on Hugging Face, allowing users to quickly review documentation, licensing and other key details. Figure 4 shows an example of the model card of the model distilbert/distilgpt2.

Screenshot of the Hugging Face website, displaying the model card for DistilGPT2, a distilled version of the GPT-2 model designed for efficient language processing tasks.
Figure 4. DistilGPT2 model card on Hugging Face.

By examining the list of models that Vertex AI offers for direct deployment from Hugging Face and checking whether their original authors have been deleted, we identified several reusable models. These are models that meet both of the following conditions:

  • The model owner has deleted the author organization from Hugging Face
  • Vertex AI still lists and verifies the model

Figures 5 and 6 illustrate an example of such a model — one that qualifies for deployment on Vertex AI, despite its author not existing on Hugging Face.

Screenshot of a deployment interface from Hugging Face, showing fields to input a Hugging Face model URL and select a deployment environment with Vertex AI recommended.
Figure 5. The reusable model is deployable on Vertex AI.
404 error page on Hugging Face website featuring a sad version of the hugging emoji. An arrow points to the URL.
Figure 6. The author does not exist in Hugging Face.

We proceeded to register one of the author namespaces and created a model using the same name within it, as Figure 7 shows.

Screenshot of the Hugging Face website showcasing a model card for text classification. The screen displays tabs for Model Card, Files and Versions, Community, and Settings. A user profile is indicated as 'Following' with 0 likes. Some of the information is redacted.
Figure 7. We successfully created the author and model in Hugging Face.

After performing the takeover, any deployment of the original model will instead result in the deployment of our new model.

To demonstrate the potential impact of such a technique, we embedded a payload in the model that initiates a reverse shell from the machine running the deployment back to our servers. Once Vertex AI deployed the model, we gained access to the underlying infrastructure hosting the model — specifically, the endpoint environment. Figure 8 shows the reverse shell from the endpoint to our controlled machine.

A screenshot of the endpoint environment. Multiple lines of text including error messages related to a bash script, with certain details blurred or blocked out for privacy. The visible text includes file paths and system commands.
Figure 8. Access to the Vertex AI endpoint.

The accessed environment is a dedicated container with a limited scope within the GCP environment. Once we demonstrated this vector, we removed the backdoor from the model’s repository.

Since we reported this issue to Google in February 2025, Google now performs daily scans to identify models that have been orphaned. The scan marks orphaned models as “verification unsuccessful,” preventing them from being deployable to Vertex.

Case Study 2: Azure AI Foundry

Azure AI Foundry is Microsoft’s platform for developing ML and generative AI applications. It provides tools for the different stages of the AI lifecycle, including data ingestion, model training, deployment and monitoring.

At the core of Azure AI Studio is its Model Catalog — a hub featuring foundation models from Microsoft, open-source contributors and commercial vendors. The catalog in Azure AI Foundry allows users to deploy and customize models on the platform. Figure 9 shows that the catalog features many models sourced from Hugging Face.

Screenshot of Azure AI Foundry's model catalog interface, displaying a variety of AI models including Google Bert models and OpenAI GPT models, organized in a grid layout with options for filtering and search.
Figure 9. Variety of Hugging Face models in AI Foundry.

We reviewed the list of models available in Azure AI Foundry and focused on those sourced from Hugging Face. For each model, we checked whether its original author account had been deleted. Once again, we identified several reusable models — models whose author namespaces were no longer claimed but are still available for deployment.

To demonstrate the risk, we registered one of these unclaimed author names on Hugging Face and uploaded a model embedded with a reverse shell. Upon deployment, the reverse shell executed successfully, granting us access to the underlying endpoint, as Figure 10 shows.

Screenshot of the underlying endpoint. Text displaying a command line interface with commands for viewing the hostname, user identity, and environment variables.
Figure 10. Continuous access to the endpoint.

By exploiting this attack vector, we obtained permissions that corresponded to those of the Azure endpoint. This provided us with an initial access point into the user’s Azure environment. Once we demonstrated this vector, we removed the backdoor from the model’s repository.

Case Study 3: Open-Source Repositories

After observing the impact of model namespace reuse on leading cloud AI services, we conducted an extensive search of open-source repositories. Our aim was to identify projects that referenced Hugging Face models by Author/ModelName identifiers that are available to be reclaimed.

Such projects expose their users to significant security risks. Attackers can take advantage of project dependencies by identifying an available Author/ModelName, registering it and uploading malicious files to it. These files are then likely to be deployed into user environments during the project’s deployment or execution.

We began by searching GitHub for open-source repositories with SDK methods that fetch models from Hugging Face. We then narrowed the search by identifying model names in these repositories. To discover reusable models, we checked each model for whether its author was deleted and could be registered.

This investigation revealed thousands of susceptible repositories, among them several well-known and highly starred projects. These projects include both deleted models and transferred models with the original author removed, causing users to remain unaware of the threat as these projects continue to function normally.

Figures 11 and 12 demonstrate the presence of reusable models and names in popular open-source projects.

A screenshot of code using the Hugging Face Transformers library with certain details blurred or blocked out for privacy. The code imports AutoTokenizer and AutoModel, and initializes them with specific parameters from a pretrained model.
Figure 11. A reusable model in an open-source project.
Screenshot of code using argparse library to add a command line argument for 'model_name' with a default value, with certain details blurred or blocked out for privacy.
Figure 12. A reusable model name used as a default argument in an open-source project.

Case Study 4: Model Registries Leak Chain

So far, we’ve examined scenarios in which users and developers fetch models directly from Hugging Face. Whether using a managed AI platform or an open-source SDK, many environments use it as a primary source.

However, other model registries — centralized systems that manage the storage, versioning and lifecycle of ML models — also pull models from Hugging Face and offer them to users as part of their available models.

This creates a supply chain risk. If a model registry ingests reusable models from Hugging Face, those models can propagate downstream. As a result, users relying on such registries could be exposed to compromised models without ever directly interacting with Hugging Face.

Take Vertex AI as an example. As discussed earlier, Vertex AI offers seamless integration to deploy and utilize Hugging Face models within the GCP environment. Users can easily fetch a model using the Vertex AI SDK, as Figure 13 shows.

Code snippet showing Python imports from Google Cloud's Vertex AI platform, including modules for AI platform and text generation models.
Figure 13. Pulling a model from the Vertex AI Model Catalog.

In this scenario, the user obtains the model model_name directly from Vertex AI. However, if this model is sourced from Hugging Face and is available in the Model Catalog, the user might inadvertently access an infected model.

Another Google-owned platform that incorporates Hugging Face as a model source is Kaggle. Kaggle is a well-known hub for data science and ML that provides datasets, notebooks and a collection of pre-trained models. Figure 14 shows that in its Model Catalog, Kaggle offers thousands of Hugging Face-originated models for deployment.

Image displaying a selection of Hugging Face model cards. Each card shows the number of linked notebooks and the last update status.
Figure 14. Hugging Face models on Kaggle.

As with the previously discussed model registries, Kaggle also offers several models that are vulnerable to model namespace reuse, posing an immediate risk to their users.

The Challenge of Model Integrity in AI

Keeping track of ML models is a complex and ongoing challenge. Developers constantly update, fine-tune, fork and republish their models. They often do this across multiple platforms and organizations. We observed model namespace reuse opportunities across various parts of these complex, multi-component systems. This is true not only in model deployments, which pose the most immediate and significant risk. We found reusable model references in model cards, documentations, default parameters and example notebooks.

Finding the same model reuse issue in GCP, Azure and many open-source projects highlights one of the most critical and often overlooked aspects of AI and ML security: verifying that the model you’re using is truly the one you think it is. Whether the project pulls a model from a public registry, reuses it from an internal pipeline, or deploys through a managed service, there’s always a risk that someone replaced, tampered with or exploited the redirection of the model.

Models can originate from a variety of registries, not just Hugging Face. The Vertex AI Model Garden, Azure AI Foundry Model Catalog and Kaggle all feature a wide range of models, including many sourced directly from Hugging Face.

This integration, while convenient, introduces risks. Developers who rely on the trusted model catalogs of major cloud AI services could unknowingly deploy malicious models originally hosted on Hugging Face without ever interacting with Hugging Face directly.

To their credit, all of these platforms make significant efforts to secure their model registries. However, as we’ve demonstrated, no system is entirely immune to namespace hijacking or supply chain vulnerabilities. Even with strong safeguards in place, a single overlooked edge case can lead to destructive exploitation.

Ensuring the security of AI tools is not solely the responsibility of platform providers. Developers must also take active steps to secure pipelines and environments.

Practical Steps for a Secure ML Lifecycle

We’ve explored some of the inherent challenges in securing the pipelines that power ML models. From data ingestion to deployment, ensuring integrity at every step is crucial. But the good news is that we’re not powerless in the face of these complexities. There are concrete steps we can take to significantly improve the security and reliability of AI systems. Following are some key practices.

  • Version pinning: Using methods such as from_pretrained("Author/ModelName") to fetch models can lead to unexpected behavior, stability concerns or even malicious model integration due to automatic fetching of the latest version. A solution for that is to pin the model to a specific commit using the revision parameter. The command from_pretrained("Author/ModelName", revision="abcdef1234567890") ensures that the model is in an expected state and prevents the model behavior from changing unexpectedly. This helps the developer to guarantee consistent model behavior for debugging and execution.
  • Model cloning and controlled storage: For highly sensitive or production environments, we recommend cloning the model repository to a trusted location, such as local storage, internal registry or cloud storage. This approach enables decoupling model loading from any external source, eliminating the risk of upstream changes or connectivity issues. Cloning the model should, of course, only be done after a robust scanning and verification process.
  • Scanning for reusable references: Scan model references in code repositories and treat model references like any other dependency subject to policy and review. Scanning should be comprehensive as models can exist in unexpected places, such as default arguments, docstrings and comments. Proactively scanning codebases for model references reduces the risk of supply chain attacks caused by model namespace reuse.

Conclusion: The New Realities of AI Supply Chain Security

We showed how an attacker could reclaim and reuse model identifiers on Hugging Face to execute remote code within popular AI platforms such as Google Vertex AI, Azure AI Foundry and various open-source projects. In both cases, the issue arises because a model's name alone is not enough to guarantee its integrity or trustworthiness.

We have discussed this issue with the vendors mentioned in this article. Model namespace reuse is a complex problem to solve and its risk still exists. This is not an isolated problem, but a systemic challenge to how the AI community manages and validates shared model integrity. This challenge extends far beyond simple namespace management, forcing us to confront questions about the foundational security of the rapidly evolving AI infrastructure.

Users can improve security with respect to the threats described above by implementing version pinning, cloning model repositories to trusted storage locations and scanning for reusable references.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

The Unit 42 AI Security Assessment can assist organizations with empowering 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

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.

Additional Resources

Why Threat Intelligence: A Conversation With Unit 42 Interns

Posted on by Ria Bhatia

Meet the Next Generation of Threat Intelligence

Unit 42’s Threat Intelligence teams work to proactively discover, analyze and contextualize sophisticated cyberthreats to empower both Palo Alto Networks products and the broader security community.

To gain insight into the scope and responsibilities of these teams, I sat down with two Unit 42 interns, Gabrielle Calderon and Sakthi Vinayak. Sakthi is a Threat Research Intern and Gabrielle is a Malware Reverse Engineering Intern. Over the 12 week span of their internship, they’ve worked side-by-side with professionals on expansive projects, deepening their understanding of the ever-evolving cybersecurity landscape.

Walk me through your background and what led you to Unit 42.

Sakthi: Back home in India, I was drawn to cybersecurity after many of my loved ones had been tricked by phishing scams during COVID-19. I liked threat intelligence specifically because of its similarities to true crime documentaries. True crime goes into the motivations and methods of criminals while threat intelligence examines the "why" and "how" of threat actors operating in cyberspace.

After hearing Unit 42 speakers at my university, I realized Unit 42 was exactly the space to gain more hands-on experience in the threat intelligence field. I then knew that I wanted to apply and be part of a team that’s actively shaping the future of threat intelligence.

Gabrielle: I come from a computer engineering background where I focused on cybersecurity and have worked various IT jobs like being an IT worker and a SOC analyst. It’s always been really important for me to gain practical experience so I've tried taking as many classes in undergrad and grad school as possible, including malware reverse engineering ones.

My previous work experiences exposed me to Palo Alto Networks products so I was familiar with the company. I knew I wanted security related jobs and when I saw the posting for a malware reverse engineering role, I thought it would be perfect because that’s exactly what I had been focusing on.

What do you do in your role and how has it furthered your passion for threat intelligence?

Sakthi: In my role, I’ve mainly focused on automating manual data ingestion and enrichment processes to free up time for deeper research and analysis. Over the course of twelve weeks, I’ve worked on three key projects: mechanizing the data ingestion workflow, implementing a fidelity scoring framework, and building a dashboard to analyze knowledge repository data for identifying trends and gaps.

These projects have really strengthened my passion for threat intelligence by showing me the complexity and depth of the field, as well as how engaging and impactful the work can be. I've learned so many valuable insights by shadowing and collaborating with professionals in different teams. I feel like I’ve really been able to apply my classroom knowledge and gain technical expertise, which has been immensely important.

Gabrielle: There are two primary tracks that I focus on in my position. The first is analyzing malware tickets to determine the level of response needed to address them. The second is developing a tool to help automate identifying the different malware families and pulling out the indicators of compromise automatically.

I really enjoy working on real-world, up-to-date cybersecurity challenges that tie directly to current events and global conflicts. It’s also super exciting to be contributing to cutting-edge and scalable solutions that I once thought could not be automated.

What has your experience been like with Unit 42, and how has the team supported your growth in threat intelligence?

Sakthi: I’ve really appreciated the supportive and growth-oriented culture of this internship. Everyone I've talked to, including people from other teams, have been so encouraging in helping me with tasks, sharing knowledge and investing in my development. This environment has not only enhanced my understanding of threat intelligence but also expanded my exposure to AI, new platforms and a wide range of technologies.

Gabrielle: Something that has stood out to me during this internship is how everyone in Unit 42 shares such a genuine enthusiasm for their work. Individuals are encouraged to solve problems and take initiative, even if it falls outside their original role. That kind of trust and freedom to innovate is something I haven’t experienced before, and it’s really encouraged my passion for learning and experimenting.

Final Thoughts

Listening to Sakthi and Gabrielle’s internship experience made it clear just how impactful an internship at Unit 42 can be. As a Unit 42 intern myself, I can further validate the supportive environment, constant opportunities to learn and obtain feedback, and hands-on exposure. To learn more about fostering careers in cybersecurity, discover how Palo Alto Networks supports early career development.

Threat Brief: Salesloft Drift Integration Used To Compromise Salesforce Instances

Posted on by Unit 42

Executive Summary

Unit 42 stopped monitoring this threat and updating the brief on Dec. 2, 2025. Please refer to the Salesloft website for the latest information.

Unit 42 has observed activity consistent with a specific threat actor campaign leveraging the Salesloft Drift integration to compromise customer Salesforce instances. This brief provides information about our observations and guidance for potentially affected organizations.

As detailed in a recent notification from Salesloft, from August 8-18, 2025, a threat actor utilized compromised OAuth credentials to exfiltrate data from affected customers’ Salesforce environments.

Our observations indicate that the threat actor performed mass exfiltration of sensitive data from various Salesforce objects, including Account, Contact, Case and Opportunity records. Following exfiltration, the actor appeared to be actively scanning the acquired data for credentials, likely with the intent to facilitate further attacks or expand their access. We have observed that the threat actor deleted queries to hide evidence of the jobs they run, likely as an anti-forensics technique.

Salesloft has confirmed that all impacted customers have been notified and took immediate action to secure its systems and contain and mitigate the incident, including proactively revoking all active access and refresh tokens for the Drift application, necessitating re-authentication for affected administrators.

Palo Alto Networks recommends that organizations continue to monitor Salesforce and Salesloft updates, in addition to following any recommendations shared below.

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.

Related Unit 42 Topics High Profile Threats, Data Exfiltration

Recommendations for Organizations

Organizations that utilize the Salesloft Drift integration with Salesforce should treat this incident with immediate urgency. Beyond the proactive steps Salesloft took to secure its platform (such as token revocation), the following recommendations are critical to assess potential impact and mitigate further risk:

Immediate Investigation and Log Review:

  • Drift API Integrations: Conduct a thorough review of all Drift integrations and review all authentication activity within third-party systems for signs of suspicious connections, credential harvesting and data exfiltration.
  • Salesforce Logs: Conduct a thorough review of Salesforce login history, audit trails and API access logs for the period of August 8 to present. Specifically, examine Salesforce Event Monitoring logs, if enabled, for unusual activity associated with the Drift connection user and review authentication activity from the Drift Connected App. Look for suspicious login attempts, unusual data access patterns, and the indicators mentioned in the Hunting Guidance section, such as the Python/3.11 aiohttp/3.12.15 user agent string and activity from known threat actor IP addresses. Also, review UniqueQuery events that log executed Salesforce Object Query Language (SOQL) queries to identify which Salesforce objects (e.g., Account, Contact, Opportunity, Case, etc.) and which fields within those objects the attacker queried. Consider opening a Salesforce support case to obtain specific queries used by the threat actor if needed.
  • Identity Provider Logs: Review logs from your Identity Provider (IdP) for any unusual authentication attempts or successful logins to Salesforce or other integrated applications during the incident period.
  • Network Logs: Analyze network flow logs and proxy logs for connections to Salesforce from suspicious IPs or unusual data transfer volumes.

Review and Rotate Exposed Credentials:

  • Automated Tools: Leverage automated tools (e.g., Trufflehog, GitLeaks) to efficiently scan for secrets and hardcoded credentials within code repositories, configuration files or any potentially exfiltrated data.
  • Data Scrutiny: If exfiltration is confirmed or suspected, review data for the presence of sensitive credentials. This includes searching for patterns like AWS access key identifiers (e.g., AKIA), Snowflake credentials (e.g., Snowflake or snowflakecomputing[.]com), generic keywords such as password, secret or key, and strings related to organization-specific login URLs (e.g., VPN or SSO login pages).
  • Immediate Rotation: Promptly rotate all credentials identified as exposed within the exfiltrated data. This includes, but is not limited to, Salesforce API keys, connected app credentials and any other system credentials found within the compromised data.

Hunting Guidance

Organizations concerned about potential compromise related to the Salesloft Drift integration incident should immediately initiate proactive threat hunting activities within their Salesforce environments. (As a starting point, Salesforce provides some resources for investigating Salesforce security incidents.) A critical first step involves a thorough review of Salesforce login and activity logs for specific indicators of compromise (IoCs) associated with the threat actor.

Defenders should look for logins originating from suspicious IP addresses, including but not limited to known threat actor IP addresses (for info and advice, please see the Indicators of Compromise section of this report).

Of particular interest is the presence of the user agent string Python/3.11 aiohttp/3.12.15 associated with these login events. While this specific string is a valid user agent that is not inherently malicious, it is also indicative of the automated, high-volume data exfiltration observed in this campaign.

The presence of this string is significant because threat actors can leverage asynchronous Python libraries like aiohttp in combination with Salesforce's Bulk API to perform rapid, high-throughput data exfiltration. This pairing allows them to efficiently extract significant volumes of data from Salesforce objects such as Account, Contact, Case and Opportunity, minimizing their time on target.

Conclusion

Palo Alto Networks highly recommends rotating credentials and following the above guidance to validate authentication activity for Drift integrations. Vigilance and verification are key.

Organizations should be wary of social engineering attempts resulting from this or any other data exfiltration event.

Best practices include:

  • Be Skeptical of Unsolicited Communications: Advise your teams to carefully scrutinize any unsolicited or unusual emails, calls or messages, even if they appear to be from a trusted source.
  • Verify Requests: Always verify requests for sensitive data or credentials through a separate, official communication channel before taking any action. For instance, if you receive a suspicious email from a colleague, call them directly to confirm the request is legitimate. Only exchange information and files through our Customer Support Portal, not email.
  • Implement Zero Trust Principles: Enforcing a Zero Trust posture with conditional access policies and the principle of least privilege can significantly limit an attacker's ability to move laterally within your network, even if they successfully trick an employee.

For more information about social engineering and how to mitigate it, please see our recent 2025 Unit 42 Global Incident Response Report: Social Engineering Edition.

Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information, and we will update this threat brief with additional information if any becomes available.

Salesforce will be providing updates and resources to customers.

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

Indicators of Compromise

Salesloft made some IoCs available for hunting. It is worth noting that many of the IP addresses listed in their notification are Tor exit nodes and may have a high false positive rate for organizations that allow Tor connections.

Additional Resources

Updated Sept. 2, 2025, at 1:50 p.m. PT to add Additional Resources section

 

Data Is the New Diamond: Heists in the Digital Age

Posted on by Ria Bhatia

What Financially Motivated Criminals Have in Common

Heists in the digital world may seem fundamentally different from heists in the physical world, but I see a common tie — financially motivated criminals of all types often use social engineering and intensive reconnaissance to achieve their goals.

In February 2003, the “heist of the century” occurred when more than $100 million worth of diamonds, gold, silver and other jewelry were stolen from the Antwerp Diamond Centre in Belgium by five criminals. This heist involved significant time spent on reconnaissance and social engineering by the mastermind of the operation, Leonardo Notarbartolo. He used these tactics to better understand and bypass various layers of physical security implemented at the site.

Most notably, this involved Notarbartolo signing a lease for an office at the heist site while posing as a multilingual gem importer from Italy, which gave him access to a safe deposit box in the site’s underground vault. The criminals ultimately left behind little forensic evidence and most of the loot has yet to be recovered.

On the digital side, Unit 42 and other security researchers see the same sort of attention to reconnaissance and social engineering.

Take the example of recent data extortion theft activity reported by Google in June 2025 that is designed to compromise and steal data from Salesforce instances. A hallmark of this activity is threat actor usage of voice-based phishing (aka vishing) to establish initial access, followed by extensive reconnaissance and collection of customer-centric data from digital platforms within a victim’s environment. From there, the data is exfiltrated to a location under the attackers’ control, where they will threaten to leak it if the victim does not pay a ransom.

Similar to the criminals behind the Antwerp Diamond Centre heist, these threat actors leave behind little digital evidence given their lack of malware or custom tool usage.

The Rise of Data Extortion in Luxury Commerce

Based on Unit 42 insights and public reporting, this data theft extortion activity has likely been occurring since at least December 2024 and has impacted companies operating within the aviation, financial services, technology and, most notably, retail sectors. The targeted retailers are also primarily those that offer high-end goods to global clientele, such as jewelry, apparel, footwear and various types of accessories. At this time, it seems that UNC6040 may be the cluster responsible for establishing initial access, conducting internal reconnaissance to identify data of interest, and exfiltrating data, whereas Bling Libra (aka ShinyHunters) is responsible for performing the actual extortion activities.

As part of these attacks, the threat actors appear focused on collecting and exfiltrating customer data including names, dates of birth, physical and email addresses, phone numbers, and account metadata. Although most of the extortion attempts occurred via email communications with victim organizations, it is possible the threat actors will migrate to a dedicated leak site (DLS) similar to operators of ransomware-as-a-service (RaaS) programs.

Unit 42 has responded to several incidents thus far in 2025 targeting retail organizations that are highly likely to be associated with this ongoing data theft extortion activity. The following are high-level observations from internal and external sources:

  • Initial Access (T1566.004)
    • Social engineering using vishing, where the threat actors typically pose as IT support personnel and attempt to collect end user credentials via phishing pages or entice victims to connect to a modified version of Salesforce’s Data Loader application.
  • Collection (T1213.002, T1213.004. T1114.002)
    • Searching for and collecting sensitive information from digital platforms such as SharePoint, Microsoft 365 and, most notably, Salesforce.
  • Impact (T1657)
    • In addition to exfiltrating data and holding it for ransom, in at least one instance, the threat actors attempted to purchase goods from a victim’s affiliated stores by applying a discount. It’s unclear if this was an attempt by the threat actors to directly obtain purchased goods for personal use or resell the items on underground forums for personal financial gain.

To be clear, this is not a new trend in terms of cybercriminals conducting data theft extortion attacks targeting customers of prominent cloud-based data platforms. For example, Google previously documented a campaign impacting Snowflake tenants in June 2024.

We also previously documented Bling Libra’s shift from using ransomware to pure data theft extortion in August 2024, including their targeting of Amazon Web Services (AWS) environments. It appears the group remains active even after French authorities announced the arrest of four alleged members in June 2025.

We expect this variety of attacks to continue. In Unit 42 incident response cases involving social engineering as an initial access method, 23% involved callback or voice-based techniques. This is a widely concerning trend as traditional perimeter defenses (e.g., email security) aren’t readily available for this form of social engineering.

To learn more about how threat actors implement social engineering and reconnaissance to further their goals, read the 2025 Unit 42 Global Incident Response Report: Social Engineering Edition.

Updated Aug. 27, 2025, at 5:57 a.m. PT to correct the date of the diamond heist.  

Insights: Telling You What We Really Think

Posted on by Ria Bhatia

Hear More Directly From Researchers and Consultants

You may have noticed a new type of article on the Unit 42 site, with a different sort of headline and a different style of writing. These are part of a section we’re calling “Insights.” It’s designed to put you more directly in touch with Unit 42 researchers and consultants, so you can read unvarnished thoughts on the threat landscape and what we’re seeing in real-world incident response cases.

How Are Insights Different?

I started working on Unit 42 threat research publications in 2020 and I am incredibly proud of the threat research we share with the community. Every piece that we publish is extensively reviewed by internal subject matter experts and experienced editors. It warms my heart whenever I hear that our readers appreciate the quality and integrity of our publications. I often compare our work to an academic journal to help researchers understand the nature of what they’re undertaking when they decide to publish an article through us.

But while I stand by the value of this approach, it doesn’t work for everything. Our team wanted to share a view of the process that’s perhaps messier but equally important. These are early thoughts, quick observations, theories about the threat landscape, or the conversation a consultant has over and over with clients. There’s also information about how we do our work, how we found ourselves in cybersecurity, and where we see the field going. I hope pieces like this give you a more immediate view of what we’re seeing and thinking about.

Beyond the Threat Assessment: What We Learned While Writing

We have recently published two pieces on Muddled Libra: “Why Are We So Obsessed With You?” and “Amalgamated Evil.”

People who have worked with me know what a departure this is. My normal guidance is “straightforward and accurate.” I’m also known for saying, “Boring can be good.” This is because I believe that when sharing, say, indicators of compromise, the goal is to inform, not entertain, and I never want to create any barriers to understanding the key information.

That said, once the foundation is in place, there’s space for the conversation you might have over a cup of coffee.

Unit 42 has done a lot of research on Muddled Libra and responded to a lot of cases. You can read our formal summary of what we know in our Muddled Libra Threat Assessment. In the course of putting together our last update to the threat assessment, however, I noticed how interested I was reading the comments from our experts as we edited and debated.

That turned out to be the foundation of our two Muddled Libra Insights pieces so far. These aren’t meant to be summations of everything we know about the threat actor. Instead, they’re things two smart people have to say about Muddled Libra based on their expert view.

Get More Insights

I hope you enjoy reading Insights as much as I have so far. I expect the section to evolve as we put together more pieces and hear from you on social and at events – and I personally can’t wait to see how it develops.

Continue to catch up on Insights on the dedicated landing page. And if you’d ever like to know what these smart people would have to say about your specific situation… you know where to find us.

Your Connection, Their Cash: Threat Actors Misuse SDKs to Sell Your Bandwidth

Posted on by Zhibin Zhang

Executive Summary

We have detected a campaign aimed at gaining access to victims’ machines and monetizing access to their bandwidth. It functions by exploiting the CVE-2024-36401 vulnerability in the GeoServer geospatial database. This Critical-severity remote code execution vulnerability has a CVSS score of 9.8. Criminals have used the vulnerability to deploy legitimate software development kits (SDKs) or modified apps to gain passive income via network sharing or residential proxies.

This method of generating passive income is particularly stealthy. It mimics a monetization strategy used by some legitimate app developers who choose SDKs instead of displaying traditional ads. This can be a well-intentioned choice that protects the user experience and improves app retention.

The applications we found in this malicious activity are nearly silent when operating. They consume minimal resources while monetizing victims' internet bandwidth, and without creating or distributing malware. This integration allows app developers to receive payments, while criminals profit from unused server resources, minimizing their risk of detection.

Since March 2025, attackers have been probing GeoServer instances exposed to the internet. Cortex Xpanse reported 3,706 publicly accessible GeoServers in the first week of May 2025, indicating a potentially large attack surface for adversaries targeting CVE-2024-36401.

Palo Alto Networks customers are better protected from the threats described 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.

Related Unit 42 Topics Vulnerabilities

Campaign Dissection

We have closely monitored a campaign that first emerged in early March 2025. The attackers have shifted infrastructure as well as tactics, techniques and procedures (TTPs) to maintain persistence.

We detected that attackers misused an SDK and an app during their campaign:

  • The SDK allowed developers to monetize other apps by collecting user data to earn passive income.
  • The app allowed users to earn passive income by sharing their internet connection.

The following timeline reveals how this threat has evolved.

Phase 1: Initial Incursion (Early March 2025) With Misused SDKs

The campaign began with exploit attempts targeting CVE-2024-36401, then delivered the misused app and the misused SDK payloads.

  • March 8, 2025: The campaign began with exploit attempts originating from the source IP address 108.251.152[.]209. The attacker used an exploit that targeted CVE-2024-36401.
  • Customized executable distribution: We observed these initial exploits fetching customized executables hosted at 37.187.74[.]75.
  • Two primary executables were distributed from this host:
    • The misused app: We detected variants of an application, including three that we have designated as a193, d193 and e193.
    • The misused SDK: We detected variants of an SDK, including five that we have designated as a593, c593, d593, s593 and z593.

Phase 2: Shifting Tactics (Late March - Early April 2025) With Misused SDKs

Attackers shifted tactics during this phase of the campaign.

  • March 24, 2025: A few vendors on VirusTotal flagged the distribution IP address 37.187.74[.]75 as malicious. This shift indicates that the security community began recognizing malicious activity originating from that IP address. We believe this is a key factor that drove the threat actor to move their infrastructure to a different IP address.
  • March 26, 2025: The attackers appeared to stop distributing new misused app samples. The focus seemingly shifted entirely to the misused SDK.
  • April 1, 2025: The threat actors switched their primary exploit delivery infrastructure to a new source IP address, 185.246.84[.]189. This was likely an attempt to evade blocklists and continue their operations unhindered.

Phase 3: Infrastructure Expansion and Persistence (Mid-April 2025 - Ongoing)

Attackers expanded their infrastructure during this phase of the campaign.

  • April 17, 2025: The attackers further expanded their backend infrastructure. They brought online a new customized executable distribution IP address, 64.226.112[.]52.
  • The original distribution IP address 37.187.74[.]75 remained live in mid-June.

As of this writing, exploit attempts continue from 185.246.84[.]189, and the customized executable distribution hosts remain online.

CVE-2024-36401 Exploit Analysis

The core of this vulnerability lies in an attacker's ability to inject arbitrary code into JXPath query statements. JXPath is a library within the Apache Commons project that offers an XPath implementation.

XPath is a widely adopted standard for querying and transforming XML documents. JXPath transparently extends the use of XPath expressions to various Java data structures beyond XML, including JavaBeans and multiple collections. From a security standpoint, this additional flexibility also introduces significant concerns.

JXPath supports extension functionality, which an attacker can exploit if they gain control over the query statement, allowing them to execute arbitrary code. This poses a greater risk than typical query injection vulnerabilities.

For instance, attackers have used Standard Extension Functions to invoke methods like getRuntime().exec().

Figure 1 shows an example of malicious code that leverages JXPath's ability to evaluate expressions, allowing an attacker to inject and execute arbitrary system commands via the #{cmd} placeholder. By referencing exec(java.lang.Runtime.getRuntime() within context.getValue, an attacker triggers Java's runtime execution mechanism, leading to remote code execution on the target system.

A line of code displayed on a dark background features a command injection vulnerability using Java Runtime to execute an unwanted command.
Figure 1. Malicious code containing a JXPath referencing a Java execution function.

Figure 2 reveals the payload from this attack. We redacted the key part of the payload in Figure 2. The redacted portion forces the victim to execute a system command to download a file from the attacker's host distribution IP addresses.

Screenshot of a computer code snippet, including tags such as GetPropertyValue and ValueReference. The background is black with green text. Some of the information is redacted.
Figure 2. Payload from an exploit found in the wild.

According to the NVD:

This vulnerability has been confirmed to be exploitable through various Web Feature Service (WFS), Web Map Service (WMS), and Web Processing Service (WPS) requests, including GetFeature, GetPropertyValue, GetMap, GetFeatureInfo, GetLegendGraphic, and Execute requests.

While analyzing an exploit used in this attack, we set up a GeoServer instance and used an in-the-wild exploit payload to analyze how the exploit works. We can see what is happening inside GeoServer by following its code flow.

After we simulated sending an attack payload, our command was passed to the function GetPropertyValue. As shown at the bottom of Figure 3, the highlighted line takes the incoming request object and passes it to a run method. The command is carried by request.valueReference.

Screenshot of code on an IDE, including a method definition within a class marked as overriding a method from an implemented service. The code includes syntax highlighting with red and blue colors.
Figure 3. Malicious payload entry point.

Stepping into this function reveals that the payload from Figure 2 was passed to the object propertyNameNoIndexes, shown from the exploit code in Figure 4. Later, this object invokes the Geotools method evaluate.

Screenshot of code in an IDE featuring syntax highlighting, displaying methods and exception handling related to attribute properties. The image shows multiple lines of code with comments and error indicators.
Figure 4. The malicious payload is sent to an unsafe Geotools method.

Note that we have entered the GeoTools codebase. The evaluate method retrieves the value of the Geotools attribute from the given object. Within this method, a PropertyAccessor object is used to read the property. Figure 5 shows that PropertyAccessor is a core interface that defines operations for reading and writing property values of an object. GeoTools will attempt to find an accessor based on the provided parameters.

Screenshot of code in an IDE program, featuring several methods and if-else statements, displayed with line numbers and syntax highlighting. The PropertyAccessors line is highlighted.
Figure 5. The malicious payload is sent to the object PropertyAccessor method findPropertyAccessors.

Once an accessor has been successfully found, it will use the object's get method to retrieve the property value. Figure 6 shows that our payload has been passed into that method via the parameter attPath.

Screenshot of a computer screen displaying code in an IDE, including functions and properties written in a programming language, with focus on a method named 'getAttributeExpression'.
Figure 6. A malicious payload is passed to attPath.

The object's get method invokes the JXPath library function iteratePointers. As shown in Figure 7, a payload is injected into the xpath variable, which is then passed to the context.iteratePointers method.

Screenshot of computer code in an Integrated Development Environment, related to HTTP requests and error handling.
Figure 7. JXPath function iteratePointers.

The ExtensionFunction has been manipulated and uses computeValue to evaluate the expression. As shown in Figure 8, the function variable now points directly to javax.lang.Runtime.exec, which is Java's standard method for running operating system commands. The parameters to be passed to this function include the attacker's command, and the highlighted line executes the command.

Screenshot of a coding interface in an IDE showing HTML and JavaScript code.
Figure 8. Malicious code execution.

Exposed Vulnerable Servers

Cortex Xpanse telemetry data from March and April 2025 revealed 7,126 publicly exposed GeoServer instances across 99 countries. The five countries where these instances are hosted the most are shown in Figure 9. The majority of the exposed servers are hosted in China.

Bar chart showing the distribution of exposed GeoServers among the top five countries. China has the highest count, above 2,500, followed by the US, Germany, Great Britain, and Singapore with significantly lower counts.
Figure 9. Exposed GeoServer distribution in the five countries where they are most commonly hosted.

Attack Chain Analysis

We have captured multiple distinct exploit strategies from this campaign. All strategies aim to deploy and run an SDK on the victim system. This analysis reviews an SDK variant we have designated as z593. Figure 10 shows that stage one leverages CVE-2024-36401 to download the second-stage payload z593 from a malicious host under the attacker’s control.

Image displaying a code snippet in XML format, related to WFS and includes references to Java Runtime executables and system paths. The visual background of the coding area is dark, with text highlighted in green, red, yellow, and white.
Figure 10. Stage 1: the initial exploit used to download the second-stage payload.

During stage two, the attacker uses CVE-2024-36401 again to execute the second-stage payload z593, as shown in Figure 11.

A screenshot displaying XML code related to a WFS with namespace URLs and a query using a Java runtime environment.
Figure 11. Stage 2: the exploit that executes the second-stage payload.

Instead of using a standard HTTP web server, the attackers deployed private instances of a file-sharing server using transfer.sh to distribute their payloads. As shown in Figure 12, the instance of transfer.sh is hosted on one of the attacker’s distribution IP addresses.

Screenshot of a website titled "Easy file sharing from the command line" displaying examples of file upload commands and a drag-and-drop area for files, with a "Learn more" button at the bottom. An IP addtess is on the top left.
Figure 12. Screenshot of the index page from a Transfer.sh server the attackers hosted on 64.226.112[.]52:8080.
The deployments noted in Figure 12 were listening on port 8080 across two IP addresses under the attackers' control:

  • 64.226.112[.]52
  • 37.187.74[.]75

If the initial exploit is successful, the script then acts as a stager, fetching two additional files, as shown in Figure 13.

Screenshot of a computer terminal displaying commands to download files using wget from specific IP addresses.
Figure 13. Content of file z593 from 64.226.112[.]52 leading to additional files.
 

The first script named in Figure 13 is z401, which is designed for stealth, creating a hidden directory and placing the main executable within it as noted in Figure 14.

A screenshot of a computer terminal displaying Unix shell commands for removing, creating, and navigating directories, along with a command to download a file using wget from a specified IP address.
Figure 14. Content of z401 from 64.226.112[.]52.
 

Figure 15 shows how the second script from Figure 13, z402, establishes the environment and then launches the main executable, passing it the app key.

Text displayed in a terminal window showing a command line interface with code involved in configuring an environment variable named 'PATH'.
Figure 15. Content of z402 from 64.226.112[.]52.
Once running, the executable operates covertly in the background, monitoring device resources and illicitly sharing the victim's bandwidth whenever possible. This generates passive income for the attacker.

The executable files from these exploit attempts are designed to interact with two legitimate services: the misused app and the misused SDK. Both services legitimately offer users a way to generate passive income by sharing the network resources of idle devices.

In this context, attackers co-opt the app or SDK functionality. Similar to how cryptocurrency miners commandeer system resources for revenue, these exploited applications also use device resources for financial gain. However, unlike malicious cryptocurrency miners, this type of app or SDK misuse is typically with a lower profile. This attracts less attention and yields smaller profits for the threat actor, which can contribute to longer, undetected operations.

Misused App Analysis

Further analysis of the binary that attackers installed on the victim’s server reveals that the attackers have been using Dart as shown in Figure 16, Dart is an open-source programming language. Two key reasons likely motivated this choice:

  • Monetization via SDK: The attackers used Dart to integrate the passive income SDK and interact with its service. This interaction is designed to ensure the generation and collection of passive income streams for the threat actor.
  • Cross-platform capability for Linux: The attackers also used Dart’s inherent portability. They leveraged this feature to compile the executable specifically for Linux system architectures to expand their potential target environments.

Adopting Dart for these purposes is noteworthy, as it may represent an attempt to potentially evade detection signatures primarily focused on languages more commonly associated with malware.

Screenshot of a computer programming interface displaying a list of code and functions primarily associated with the Dart programming language. It highlights a specific string.
Figure 16. Binary using Dart for multi-platform capability.

Misused SDK Analysis

To verify the nature of the SDK component used in this campaign, we compared the misused SDK binary employed by the threat attack and the official SDK version from the vendor’s website. Our analysis confirmed that the two files are identical. This suggests the attackers are using a legitimate, unmodified SDK, which could bypass endpoint detection.

Conclusion

This ongoing campaign showcases a significant evolution in how adversaries monetize compromised systems. The attackers' core strategy focuses on stealthy, persistent monetization rather than aggressive resource exploitation. They achieve this by deploying executables that exploit legitimate passive income services, discreetly using device resources for activities like bandwidth sharing. This approach favors long-term, low-profile revenue generation over easily detectable techniques.

To combat this threat, we highly recommend applying patches and updates when possible.

Palo Alto Networks customers are better protected against vulnerabilities and malware through the following products and services:

  • Advanced Threat Prevention can block the attacks with best practices via Threat Prevention signatures 95463. In addition, ATP includes machine learning-based protection that can detect exploit traffic in real time.
  • Advanced WildFire can stop the customized executable from being transferred.
  • Advanced URL Filtering and Advanced DNS Security are able to block known malicious URLs associated with this activity.
  • Cortex XDR and XSIAM can block the exploitation of the vulnerabilities mentioned in this article.

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.

Indicators of Compromise

IP Addresses and TCP Ports Used for the Campaign Infrastructure

  • 37.187.74[.]75:8080
  • 64.226.112[.]52:8080

Campaign Artifacts

SHA256 Hash of the File URL Contacted by the File
89f5e7d66098ae736c39eb36123adcf55851268973e6614c67e3589e73451b24 hxxp://37.187.74[.]75:8080/w1wOYGVLEX/a101
6db4b685f413a3e02113677eee10a29c7406414f7f4da611f31d13e3f595f85d hxxp://37.187.74[.]75:8080/IyxzymKCp2/a102
4e4a467abe1478240cd34a1deaef019172b7834ad57d46f89a7c6c357f066fdb hxxp://37.187.74[.]75:8080/cE58oqrYGO/a193
4e40a0df8f4ba4a87ab8fc64950c67f6725a7e8f14a0a84a4ed79b3a8924ba19 hxxp://37.187.74[.]75:8080/YDjV1ocro3/a401
663970530e764f91b0be43936331e6c0a93610db6b86c6c4b64de270ae4d4630 hxxp://37.187.74[.]75:8080/3g5eBN8nqv/a402
7c18fe9da63c86f696f9ad7b5fcc8292cac9d49973ba12050c0a3a18b7bd1cc9 hxxp://37.187.74[.]75:8080/JadF0ucQNf/a593
84ee11f40da3538e4601456912c3efa0e92a903948812fd17fe650c5f7ac33ad hxxp://37.187.74[.]75:8080/Do4YwzvAJN/alog
0971264967ba8d461ce98f86b90810493c5e22fc80bf61f0d0eb7a2599a7f77a hxxp://37.187.74[.]75:8080/DQ5ydzkPnK/c401
491f5af9d29f52a6df026159a8ebd27ee6e27151ea78c4782eb05b2c5d39bfc3 hxxp://37.187.74[.]75:8080/a8HejAHngH/c402
a852133ff7f24b14e4224e7052f6d309353b4838fe5f17d25c712d7a1dd6e80a hxxp://37.187.74[.]75:8080/vLs5vxpDgV/c593
b66c64ccd7b9c96fad53f6d3aa0441e46eca899ad8d97964573e41c94fccddba hxxp://37.187.74[.]75:8080/KaMJw2fsDW/d101
f340abe5689e51cf78b10165cb93ab8a2988d0fedd0e74c74fc23ac2dca93a13 hxxp://37.187.74[.]75:8080/TMuAS1wp8m/d102
fc28f97f818d07fd8824333de26e5a0ca0d3fe7233d86f7e227e4838cfea0ca4 hxxp://37.187.74[.]75:8080/iKA3jGXk6x/d193
7c0c69aa0dcfc937c1fef8d42c74f7e46d128898c1d99d3362f2d18397be36ae hxxp://37.187.74[.]75:8080/fK4SCflkNg/d401
33aad585d6280d1921b5f46f8894ee05d426c7751c2133ed5484bf65af587576 hxxp://37.187.74[.]75:8080/Y1WT747MRP/d402
2c5581572ec4877df8ec3e5d2b30bfff5718ecd27d8b3dbe2f393aa5821e7ddd hxxp://37.187.74[.]75:8080/H0cwXMzCrJ/d593
0e2b92991186bc8a817e0187a9b58928969350bc8d8ad7e6b6cd91c185a7e03c hxxp://37.187.74[.]75:8080/XA8Dkr1CJ4/dlog
5bc5dfeaeb43fb1e967cad028f8d2c48f5db17ee6c23c383faee74455c2f1f33 hxxp://37.187.74[.]75:8080/52F6SqfuuS/e101
8b25144ad17d023f67477be4791db45d9197d7cfb666b3a5ccc1b1c0e4bae3af hxxp://37.187.74[.]75:8080/7kS5qiHwg8/e102
8aafb9965e946e5d4be085a1373abc750a1488ff78e6e082cc36ff20ff328465 hxxp://37.187.74[.]75:8080/ei0Ul7l75J/e193
a13a07d15d94c996d8b7e8ed633073f6a3e2268a8d14363f16ad48160b85df08 hxxp://37.187.74[.]75:8080/kGQtGhOpCP/elog
cdae958629383c4dba22a115615d8a63211bbccb06335cd1c4b5e2c2aa3fee77 hxxp://37.187.74[.]75:8080/wHNOFLazdK/glog (from d401)
bbdda70f0c4a3de4ec955e134ad46895ac931e21b930837a85633277128ab7d2 hxxp://37.187.74[.]75:8080/wlLiXFNtjU/hlog (from c401)
4fd789a19db35e054a5135466d610452bea607a11b7ec765b5474847c22e637c hxxp://37.187.74[.]75:8080/gmhm4lmSLO/plog (from z401)
43b49294b778d4489c69922ff3aca27964a04e0f08bcc830108dc83261a0b205 hxxp://37.187.74[.]75:8080/QF8plwpY8Y/s401
ae706c149497c2fc809682e8827996ea3ceb7bcecddd87be7543d1dca4853470 hxxp://37.187.74[.]75:8080/zJ03zmSrz6/s402
3fd7794be80782b11a09f51ac8cbf2147e9d79303923f279d610ee45e12506eb hxxp://37.187.74[.]75:8080/22mINruojN/s593
e25d6134c6a0573ded1d340f609dd71d15934ca165ea79d47898aa37a5185415 hxxp://37.187.74[.]75:8080/3pHrSu54Pf/slog (from s401)
085da541d7555ac6afcacd5899027c3fa4132c1eccfb3d8223794c4e0e3eb361 hxxp://37.187.74[.]75:8080/vPN5rgRMTz/wlog (from a401)
2aa6f95dbe8d17e8e70db677808c96ee956c36b7cc8f274435173cfed0b1f5af hxxp://37.187.74[.]75:8080/T8VevroEJT/z401
2b176eb8afa0b089ee8fb072c68c6fdcfe4b2f034c776cc32064f26c0e6c69a3 hxxp://37.187.74[.]75:8080/uCX4Nl2Pwu/z402
915d1bb1000a8726df87e0b15bea77c5476e3ec13c8765b43781d5935f1d2609 hxxp://37.187.74[.]75:8080/3twwHaJzxo/z593
fa2687f94955fbdc2c41f1cff8c7df24937aeb942e4d7856bf2ff52ebf2e61aa hxxp://64.226.112[.]52:8080/MFTYFuqKGU/a401
663970530e764f91b0be43936331e6c0a93610db6b86c6c4b64de270ae4d4630 hxxp://64.226.112[.]52:8080/cxtpjeM3KU/a402
e0b886a39cf098a3c7daa021c7af022b0ceb6edcf3fa49e3c3b8f70b843423c2 hxxp://64.226.112[.]52:8080/XEQS3MTzdS/a593
9515df36a6d16c0a9fcca680d6b181539d80efd4cda85dacbfb30127a7f11736 hxxp://64.226.112[.]52:8080/fAFUQgw7Py/c401
491f5af9d29f52a6df026159a8ebd27ee6e27151ea78c4782eb05b2c5d39bfc3 hxxp://64.226.112[.]52:8080/0rX20C97S6/c402
b381e8355cf3a432e63064897cc7719e8b9c38e91c6151cd1e7aed4cd219a75b hxxp://64.226.112[.]52:8080/LuoHgydq6F/c593
dec84a568b6393ccd863bb38851a76f54de6f59193660e4b88aa1f941b744469 hxxp://64.226.112[.]52:8080/g1Gl1JWEUw/d401
33aad585d6280d1921b5f46f8894ee05d426c7751c2133ed5484bf65af587576 hxxp://64.226.112[.]52:8080/AORGz7zIzn/d402
7620f22a5ed1a8ac2a1da732e55e14a13197b631e5abba6431f88e5cfa3ae2de hxxp://64.226.112[.]52:8080/rKS64mUmF7/d593
3d7ac752bb0d54802f2def38f44e10854f70ab5a9a001b5c39ab0531b9ed74bf hxxp://64.226.112[.]52:8080/vbbdG8dpAw/s401
ae706c149497c2fc809682e8827996ea3ceb7bcecddd87be7543d1dca4853470 hxxp://64.226.112[.]52:8080/W7lJoMcuOu/s402
6dd6751bae92dfa504f0ad5558ab8adfdfba3df5a7f218245627574bfac39f11 hxxp://64.226.112[.]52:8080/6mXfFz7ltE/s593
357ca4ad31132ad4bd605e3217968819b04d577884a4e9dd760ed0182c4609ed hxxp://64.226.112[.]52:8080/YbEYCqCFVl/z401
2b176eb8afa0b089ee8fb072c68c6fdcfe4b2f034c776cc32064f26c0e6c69a3 hxxp://64.226.112[.]52:8080/1Vt9KBLEFr/z402
97c8ec63766ce63b8ace283928922cfceb7c8f3bc72edcbd255e157a1afb15fe hxxp://64.226.112[.]52:8080/09KvYAUSHm/z593

Additional Resources

Updated August 21 at 5:45 a.m. P.T. to add additional Cortex XDR and XSIAM coverage information.

Logit-Gap Steering: A New Frontier in Understanding and Probing LLM Safety

Posted on by Ria Bhatia

Introducing a New Angle on LLM Safety

Many publications have discussed the issues with tricking LLMs into responding to harmful requests. Our most recent academic research offers a new way to think about these issues, and it speaks to how defenders could improve LLM safety as well. The key is to consider some fundamental qualities of how safety features are built into LLM models.

LLMs are designed to refuse harmful queries through "alignment" training, a process that aims to make refusal responses far more likely than affirmative ones for unsafe prompts. A technical aspect of this process is the use of “logits,” the raw scores an LLM assigns to potential next words. Alignment training introduces refusal tokens that prevent the model from responding to harmful requests. Part of the training is to adjust the logits so they favor refusal tokens when they should.

Our Research: Logit-Gap Steering and Its Impact

Our research introduces a critical concept: the refusal-affirmation logit gap. This refers to the idea that the training process isn’t actually eliminating the potential for a harmful response – it’s just making it less likely. There remains potential for an attacker to “close the gap,” and uncover a harmful response after all.

Our academic research paper, “Logit-Gap Steering: Efficient Short-Path Suffix Jailbreaks for Aligned Large Language Models,” explores how this process would work, and how efficient it could be for attackers. Our approaches not only showcased strong jailbreak efficacy on classic open-sourced LLMs such as Qwen, LLama, and Gemma, but also worked effectively on the most recent open-sourced model from OpenAI, gpt-oss-20b, with outstanding attack success rate (>75%). The paper was posted before the release of gpt-oss-20b.

This forcefully demonstrates that relying solely on an LLM's internal alignment to prevent toxic or harmful content is an insufficient strategy. The inherent, mathematical nature of the logit gap means that determined adversaries can, and will, find ways to bypass these internal guardrails. True AI safety demands a defense-in-depth strategy, incorporating additional, external protections and content filters for a truly robust security posture.

While the paper details the process and efficacy of the approach, it also provides tools for deeper analysis. In particular, it helps conceive of how safety alignment truly operates and steps out of specifics into a model that considers the fundamental principles of alignment training – and therefore inherent issues that need to be solved. It also provides security researchers and LLM users with a quantifiable metric to evaluate and strengthen the alignment and safety of deployed models.

Building a Stronger Future for AI Safety

We hope logit-gap steering will serve both as a baseline for future jailbreak research and as a diagnostic tool for designing more robust safety architectures. We’re sharing this research to empower the entire AI and security community. By understanding these fundamental mechanisms, we can collectively develop more robust alignment techniques, refine evaluation benchmarks and ultimately build more secure AI systems. We urge researchers to delve into the full paper on arXiv (2406.11717) and contribute to our shared mission of securing an AI-driven future.

Unit 42’s AI Security Assessment can help organizations reduce AI adoption risk, secure AI innovation and strengthen AI governance. Palo Alto Networks’ PRISMA AIRS Runtime Security product offers the most comprehensive protection for your AI innovations and deployments.

Additional Resources

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow