Unit 42 stopped monitoring this threat and updating the brief on March 24, 2026. Please refer to Ivanti’s website for the latest information.
Two critical zero-day vulnerabilities (CVE-2026-1281 and CVE-2026-1340) affecting Ivanti Endpoint Manager Mobile (EPMM) are being actively exploited in the wild, affecting enterprise mobile fleets and corporate networks. These vulnerabilities allow unauthenticated attackers to remotely execute arbitrary code on target servers, granting them full control over mobile device management (MDM) infrastructure without requiring user interaction or credentials.
Unit 42 has observed widespread exploitation of these vulnerabilities, including:
Establishing a reverse shell
Installing web shells
Conducting reconnaissance
Downloading malware
This campaign also affected the following sectors in the United States, Germany, Australia and Canada:
State and local government
Healthcare
Manufacturing
Professional and legal services
High technology
Due to the severity of the threat, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-1281 to its Known Exploited Vulnerabilities (KEV) Catalog.
Threat actors are accelerating operations, moving from initial reconnaissance to deploying dormant backdoors designed to maintain long-term access even after organizations apply patches.
Palo Alto Networks Cortex Xpanse has identified the presence of over 4,400 EPMM instances in our telemetry.
Palo Alto Networks customers are better protected from CVE-2026-1281 and CVE-2026-1340 through the following products:
Palo Alto Networks also recommends referring to Ivanti’s security advisory, released in January 2026. Ivanti recommends in their security advisory to apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. The RPMs are version-specific, not vulnerability-specific. No downtime is required to apply the patch, and Ivanti is not aware of any feature functionality impact with this patch. More details can be found in the Interim Guidance section.
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.
CVE-2026-1281 (CVSS 9.8) is a critical remote code execution (RCE) vulnerability in Ivanti EPMM. The vulnerability lies in legacy bash scripts used by the Apache web server to handle URL rewriting.
The vulnerable component in Ivanti EPMM uses Apache RewriteMap configurations that point to bash scripts located at /mi/bin/map-appstore-url. These scripts are designed to process URLs for the In-House Application Distribution feature.
The flaw is a specific type of code injection that uses bash arithmetic expansion. The exploitation process works by tricking the bash script into evaluating a variable that contains a malicious command. This process consists of the following phases:
Input manipulation: The attacker sends an HTTP GET request to an endpoint like /mifs/c/appstore/fob/....
Variable pointing: The attacker sets the st parameter to the string theValue (padded with spaces to meet length requirements). The script assigns this input to a variable named gStartTime.
Payload injection: The attacker sets the h parameter to include the malicious command wrapped in an array index, such as gPath['sleep 5']. The script assigns this to the variable theValue.
Execution: The script attempts to compare gStartTime (which is now the string theValue) against the current time using an arithmetic evaluation (if [[ ${theCurrentTimeSeconds} -gt ${gStartTime} ]]).
Expansion: Because gStartTime points to theValue, bash resolves theValue. Inside theValue, the attacker has embedded a command substitution (the array index). Bash executes the command (e.g., sleep 5 or a reverse shell) while resolving the array index.
Details of CVE-2026-1340
CVE-2026-1340 (CVSS 9.8) impacts the Ivanti Android File Transfer mechanism. Although the root cause (unsafe bash script usage) is the same as CVE-2026-12821, they reside in two distinct scripts (map-appstore-url vs. map-aft-store-url) handling different features. This vulnerability is triggered via HTTP GET requests to endpoints beginning with /mifs/c/aftstore/fob/.
Current Scope of the Exploitation
Unit 42 has observed widespread and mostly automated exploitation attempts of CVE-2026-1281 and CVE-2026-1340.
We have seen the following command to target vulnerable Ivanti EPMM servers via the following URL pattern shown below in Figure 1.
Figure 1. Format of command targeting vulnerable Ivanti EPMM servers.
Malware Download
In some instances, attackers attempted to bypass authentication on Ivanti's MobileIron platform and immediately download and run a second-stage payload (the /slt script). This second stage typically installs a web shell, a cryptominer or a persistent backdoor to grant the attacker control of the appliance.
Figure 2 below shows an example of the URL and subsequent commands seen during an attempt.
Figure 2. URL and commands from an exploitation attempt.
Botnet Activity
We observed attackers downloading a Nezha monitoring agent, an open-source server monitoring utility. They downloaded this tool with specific parameters to fetch from Gitee if the victim’s location is China, ensuring the largest possible victim base irrespective of location. Figure 3 below shows the command to download the Nezha agent.
Figure 3. Attempt to download a Nezha monitoring agent.
Reverse Shell Attempts
In many cases, we observed attempts to execute reverse shells by injecting commands establishing outbound connections to a listening post. Figure 4 below shows examples of these attempts.
Figure 4. Attempts to execute reverse shells.
Reconnaissance
We also observed attackers issue sleep commands in attempts to determine whether the server targeted was vulnerable to exploitation. This is a simple method of testing if the server will pause for five seconds. If the connection hangs for exactly five seconds before returning an error (e.g., a 404 error), the attacker knows they have achieved RCE and will follow up immediately with malicious payloads. Figure 5 shows examples of commands for the reconnaissance attempts.
Figure 5. Attempts at reconnaissance.
Web Shell Activity
We observed threat actors attempt to install a lightweight JSP web shell with names like 401.jsp, 403.jsp and 1.jsp at filepath /mi/tomcat/webapps/mifs/ across various intended targets. In these cases, if the web server is running as root or Administrator, the attacker would gain administrative control of the server. Figure 6 below shows an example of these JSP web shells.
Figure 6. Example of a decoded JSP web shell.
Interim Guidance for CVE-2026-1281 and CVE-2026-1340
A January 2026 Ivanti security advisory recommends their customers apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. Customers do not need to apply both RPMs as they are version-specific, not vulnerability-specific.
No downtime is required to apply this patch, and the company is not aware of any feature functionality impact with this patch.
Ivanti’s recommendation remains the same: Customers who have not yet patched should do so immediately, and then review their appliance for any signs of exploitation that may have occurred prior to patching. Applying the patch is the most effective way to prevent exploitation, regardless of how IOCs change over time, especially once a POC is available. The patch requires no downtime and takes only seconds to apply.
Ivanti has provided customers with high‑fidelity indicators of compromise, technical analysis at disclosure, and an Exploitation Detection script developed with NCSC‑NL, and continues to support customers as they respond to this threat.
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
If Ivanti EPMM logs are being ingested into Cortex XDR or XSIAM, the following query can be used to identify signs of exploitation. To do so, the dataset name will need to be specified within the dataset stage.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
//Description: This query identifies HTTP(S) requests logged within Ivanti EPMM (Formerly MobileIron) logs that match exploitation URI parameters. The EPMM Version number is also extracted (as EPMM_Version) to provide additional context for security teams to identify if their software version is vulnerable.
config case_sensitive=false
//Note: Replace <ENTER_DATASET_NAME_FOR_IVANTI_EPMM> with the actual name of your Ivanti EPMM syslog dataset.
The rapid weaponization of these vulnerabilities demonstrates that the window between disclosure and mass exploitation has effectively collapsed, with opportunistic attackers integrating new CVEs into automated scanning frameworks within hours. While these types of attacks lack precision, successfully compromising unpatched edge devices at scale makes them high-risk assets unsecured by patching cycles alone. Organizations with internet-facing management interfaces should adopt an assumed breach mentality and treat detection of any indicators as potential compromise with possible deeper persistence and lateral movement.
Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections for CVE-2026-1281 and CVE-2026-1340
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
Next-Generation Firewalls With Advanced Threat Prevention
Cortex Xpanse has the ability to identify exposed Ivanti EPMM devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that they’ve enabled the Ivanti Endpoint Manager Mobile (MobileIron Core) Attack Surface Rule. Identified findings can be viewed in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module.
Cortex Cloud
While there are no known indications of the exploitation of this vulnerability within cloud infrastructure, Cortex Cloud customers are better protected from, and can detect and remediate, vulnerable cloud infrastructure by using Cortex Cloud’s vulnerability monitoring. Additionally, the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment helps detect and prevent the malicious operations, configuration alterations or exploitations at runtime providing sustained defenses of the cloud environment.
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)
This article explores the misuse of QR codes in today's threat landscape, covering three areas of concern:
QR codes using URL shorteners to disguise malicious destinations
QR codes using in-app deep links to steal account credentials and take control of a victim's apps
QR codes attempting to bypass app store security by linking to direct downloads of malicious apps
With QR codes a notable presence in our everyday lives, some people instinctively scan them without hesitation. But QR codes are also a vector for attack. QR codes enable attackers to bypass organizational security by exploiting the weaker controls of personal mobile devices. By doing this, they can trick users into scanning codes and interacting with malicious destinations outside the corporate security perimeter.
Over the past several months, we have tracked campaigns that used QR codes for phishing (known as quishing) and scams. Our telemetry reveals an average of over 11,000 detections of malicious QR codes each day. Investigating these detections, we found that attackers are leveraging QR code shorteners, in-app deep links and direct downloads to bypass people’s awareness and security controls.
In addition to mass campaigns, we see attackers using QR codes for highly targeted messenger app phishing, such as targeting Ukrainian Signal users in the context of the Russia-Ukraine war. These findings necessitate further analysis of deep links and QR code data.
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
QR codes are not a new technology, but their prevalence has increased with the push for contactless interactions, especially during the initial emergency phase of the coronavirus pandemic. QR codes allow companies to interact seamlessly with their customer base for payments, enabling customers to join rewards programs and sign up for apps or mailing services. People have grown used to QR codes in daily life, and often scan them without sufficient caution, increasing their susceptibility to attacks.
The popularity of QR codes has led to their use by attackers. In our offline web crawlers, we currently find an average of 75,000 detections of QR codes each day, with 15% of these pages containing QR codes leading to malicious links. This represents an average of over 11,000 detections of malicious QR code use each day.
Problem of Evasive QR Code Redirects
We looked beyond the recognized risks of QR codes. While straightforward QR code web-based attacks remain a threat, our focus shifted to understanding how attackers are leveraging the following trends to remain evasive to both victims and security controls:
These tactics represent an evolution in QR code-based attacks that security teams need to address.
Previous Unit 42 research has covered several key attack vectors for phishing QR codes hosted on documents, which are also relevant when hosted on websites. Attacks through these vectors can be effective for several reasons including:
Lower user vigilance
Security solutions having difficulty extracting URLs embedded in QR codes
Complex redirection chains that obscure final destinations
Weaker security controls on personal mobile devices
Hosting on otherwise legitimate-looking pages
Building upon this threat model, in-app deep links allow the attacker to target specific apps and trigger specific behavior (Figure 1).
Figure 1. QR code threat model.
QR codes on websites need to be analyzed by security crawlers and other security solutions. To close this security gap, specific QR code detection techniques must be deployed to analyze the various data types stored in QR codes:
Standard HTTPS URLs
Deep links
Non-URL content (e.g., JSON, plaintext)
Key Definitions
QR code shorteners are services that combine a URL shortener with a QR code generator to create a shorter, more scannable QR code that links to a long URL. These shorteners offer benefits such as reducing the size of the QR code, allowing attackers to change the destination URL later, and tracking scan data in a single dashboard.
Figure 2 shows an example that displays a phishing site impersonating a job match and training program website that hosts a payment in-app deep link. Deep links are often used to improve user experience by reducing the number of steps to access specific content from external sources like emails, social media, authentication tokens or ads.
Figure 2. QR code in-app deep link example.
The Stealth Factor: QR Code Shorteners
Attackers use QR code shorteners to mask malicious destinations. QR code shorteners convert a static image into a dynamic endpoint. Consequently, the attacker can change the redirect destination at will.
The attacker is also able to leverage the good reputation of QR code shortener services to evade detection of malicious activity. Even security-conscious people who check the URL preview before scanning cannot determine the final destination when presented with shortened links. This technique effectively prevents targets from being aware of potential threats until after the malicious payload has been delivered.
Our previous article has already talked about the risk of URL shorteners more broadly. However, the combination of a QR code and URL shortener is even more likely to bypass scrutiny.
Steady Increase in QR Code Shortener Traffic
We have seen QR code shortener traffic grow steadily over the past three years (Figure 3).
Figure 3. QR code shortener traffic trends, 2023-2025.
We see a steady increase of QR code shortener traffic in our telemetry. This includes a 55% increase from the first half of 2023 to the first half of 2024 and a 44% increase from the first half of 2024 to the first half of 2025. This data is based on the following popular QR code shortener services:
qrcc[.]io
qrco[.]de
me-qr[.]com
qr[.]io
qrfy[.]com
qrfy[.]io
get-qr[.]com
qr[.]ne, qrs[.]ly
Most Misused QR Code Shortener Services
Our telemetry reveals that qrco[.]de, me-qr[.]com and qrs[.]ly are the most used QR code shorteners. Compared to the top QR code shorteners mentioned in the Anti-Phishing Working Group (APWG) phishing trends report [PDF], qrs[.]ly is a notable new addition as the QR code shortener used in 7.3% of the malicious URLs observed.
Targeted Industries
Financial services was the most impacted industry when considering compromised QR code shorteners, accounting for 29% of this type of attack. This is followed by high tech (19%) and wholesale and retail (14%). Significantly, QR code shorteners for financial services make up only 4.8% of this type of traffic as a whole. This makes the high percentage of compromised QR code shorteners for financial services even more striking as shown in Figure 4
Figure 4. This chart illustrates the contrast between the total QR code shorteners we observed in traffic, by industry, and the number of compromised QR code shorteners, by industry.
Example of a Phishing Attack Misusing a QR Code Shortener
The webpage shown in Figure 5 is a popular file-sharing platform containing a QR code that appears to imitate a school by including its logo. Upon analysis, we found that it is a QR code shortener that first redirects to a CAPTCHA page and then lands on a phishing page that impersonates Outlook hosted on cdnimg.jeayacrai[.]in[.]net. After a few days, the URL from this QR code no longer worked, illustrating how QR code shorteners are often ephemeral and can quickly cease redirecting to the original malicious endpoint.
Figure 5. Malicious QR code shortener example.
In-App Deep Links Vulnerabilities: More Than Just Web Browsing
Modern mobile devices support a wide range of QR code actions beyond simple web browsing. The distribution of in-app deep links in QR codes is an understudied area despite its exploitability. In-app deep links account for about three percent of the QR codes in our telemetry. Attackers can either misuse app functionality (e.g., adding a trusted device, or sending a payment), or push malicious content to those apps (such as, adding malicious links to calendar invites).
Defenders face a challenge in detecting malicious in-app deep links embedded in QR codes because the activity generated by these links is often invisible to standard web crawlers. Effective detection necessitates a mobile sandbox environment with the specific app installed to properly observe and analyze this activity. Custom in-app deep links lack standardization across applications. This makes identifying malicious signals difficult to generalize, often requiring individualized investigation for each case.
Both iOS and Android devices can process QR codes with in-app deep links that have direct app integration. We categorize in-app deep links as those that apply to the following types of apps:
Social media and communications
App stores
Payment
System utilities (e.g., Wi-Fi, contacts, calendar, telephone, email, SMS, navigation)
The three most popular custom app URLs that we found were for Telegram, XHS Discover (RedNote) and Line, which respectively account for 44.7%, 1.8% and 0.8% of in-app deep links. As we discuss later, attackers commonly misuse Telegram and Line.
Attack Scenarios
In-app deep links enable additional cross-device interactions, creating new attack scenarios via QR codes.
Table 1 lists some examples of the attack chain scenarios possible through in-app deep links.
Attack Name
Deep Link Category
Description
Example (QR Code Content)
Financial fraud
Payment
Direct access to payment applications with pre-filled recipient information
bitcoin:attackers_address
Account Takeover
Social Media and Communications
Directs the victim to authenticate the attacker into the victim’s account
Attacker’s website hosts: tg[:]//login?token=xxxx
Embedding Malicious URLs
Communications, Other Apps
Attackers can embed malicious URLs in emails or text messages to be sent from the victim’s device, saved into a file, etc.
Table 1. Attack scenarios involving in-app deep links.
Many of these attack scenarios involve embedding malicious URLs into specific data entries stored in mobile apps. Figure 6 illustrates this for contact poisoning, where a malicious URL is embedded in a saved contact card.
Figure 6. Contact poisoning attack scenario.
Some of the scenarios described in Table 1 were not observed in our data collection, while others were. The ones not observed are plausible, but hypothetical scenarios. We will further discuss the scenarios observed in our data collection below.
Current Attack Trends and Examples
Financial Fraud In-App Deep Links
Financial in-app deep links represent a significant financial risk to potential victims. QR codes are commonly used in legitimate business transactions to facilitate payments, making it straightforward for attackers to misuse this trusted interaction through phishing schemes. We observed legitimate in-app deep links from popular payment apps such as:
WeChat Pay
Alipay
Bitcoin
Ethereum
LitCoin
Metamask
Trust (wallet)
The familiarity and trust people have with payment-related QR codes create an ideal environment for social engineering attacks, where malicious QR codes can closely mimic legitimate payment requests. Phishing campaigns using pressure tactics can manipulate people into making quick payments.
Below, we share a few examples where an attacker attempts to trigger a financial transaction using a QR code. Figure 7 includes two examples. The first example is a phishing campaign claiming easy returns on investment, asking for an initial payment through a Bitcoin in-app deep link. The second example is a hacking for hire service advertising and providing easy payment with a WeChat payment in-app deep link.
Figure 7. Examples of malicious financial in-app deep links.
Figure 8 illustrates another get-rich-quick phishing scheme that requests an initial payment through a popular cryptocurrency wallet via a QR code with an in-app deep link.
Figure 8. QR code phishing scheme that uses a popular cryptocurrency wallet.
Messenger Account Takeover Through In-App Deep Links
Account takeovers through in-app deep links appear to be a significant phishing vector for messaging and social media sites. Telegram, in particular, was the most prominent application identified in our analysis that uses custom in-app deep links. We found over 35,000 QR codes that contain Telegram in-app deep links such as tg[:]//login or tg[:]//resolve and we observed multiple instances where attackers exploited these links to compromise accounts.
We saw three kinds of Telegram in-app deep links:
Login
Resolve
Proxy
Login accounted for 97% of the Telegram in-app deep links observed. Login grants the QR code creator authorization to access your account.
Previous reporting of Telegram in-app deep link scams warns about these account takeover attacks. Roughly one out of every five host pages with a login Telegram in-app deep link is malicious, based on our conservative estimate.
Figure 9 includes two examples of such Telegram login scams. However, while Telegram is the most popular, attackers are also targeting other popular communication apps.
Figure 9. Example of a QR code designed to give an attacker full access to the device and account owner’s Telegram.
Figure 10 shows an example of a QR code containing an in-app deep link that requests authorization to a target's Line account. This would allow attackers to send Line messages under the device and account owner’s name. Of note, Line has since deprecated this in-app deep link, and the link will now result in an error.
Figure 10. Example of a QR code for a Line account takeover.
Figure 11 shows an example of a QR code containing an in-app deep link that requests authorization to access a target's Signal account.
Figure 11. Example of a QR code for a Signal account takeover.
Figure 12 shows an example of a QR code containing an in-app deep link that requests authorization to access a target's WhatsApp account.
Figure 12. Example of a QR code for a WhatsApp account takeover.
In addition to mass phishing campaigns, there's a clear trend toward more focused attacks aimed at stealing Signal credentials. For instance, the Google Threat Intelligence Group (GTIG) has documented increased efforts by Russia state-aligned actors to compromise Signal Messenger accounts. These attacks frequently misuse Signal's feature to link devices with malicious QR codes.
Many of these campaigns have targeted Ukraine in the context of the Russia-Ukraine war. In July 2024, the CERT-UA reported on several threat groups, such as UAC-0185 (aka UNC4221), that have specifically targeted messenger accounts.
Our researchers continue to observe new malicious domains targeting Ukrainian Signal users, including snitch.open-group[.]site and similar variations. After linking a new session to Signal accounts, the attackers can exfiltrate message history and other account information. We have reported discovered information to our Ukrainian cybersecurity partners.
Figure 13 shows a QR code from a campaign targeting Ukraine-based Signal accounts.
Figure 13. QR code from a campaign targeting Ukraine-based Signal accounts.
Bypassing App Store Security: Direct App Downloads
QR codes are widely used for easy downloading of files and applications. Attackers can exploit this convenience to trick victims into downloading malicious content or installing harmful mobile applications.
Major app stores impose strict security and compliance guidelines to limit the distribution of harmful apps. However, attackers may circumvent these security measures by distributing links to unreviewed Android Package Kit (APK) files hosted on their own servers via QR codes.
Our investigation identified 59,000 detections of host pages distributing a total of 1,457 distinct APK files directly through QR codes, without going through any app store. Notable examples of these distributed APKs are listed below.
Gambling/Casino App Downloads
Gambling and casino games websites are distributing their apps through APK files in QR codes.
Figures 14-16 illustrate some examples of such host pages. They are all hosted by many different domains and request certain Android permissions that could be concerning to people.
Figure 14 shows an ad for a popular game that includes a QR code, which redirects the victim to another QR code to download a game app named yicai.apk from f9999[.]app. This QR code is hosted on 10,022 unique URLs.
The app requests read and write permissions to the device's external storage and camera. It also requests install packages permissions.
Figure 14. First example of a gambling game distribution campaign through a QR code.
Figure 14 shows an ad for another game hosted on 9,161 unique URLs. The URL used in Figure 15 is hxxps[:]//pyreneesakbash[.]com/m-nagapoker/android.html. The file for the game is named NagaPocker.apk, and it requests write to external storage and internet permissions.
Figure 15. Second example of a gambling game distribution campaign through a QR code.
Figure 16 shows an app distributed through two different pages. Named app-u7cp-release.apk, the app requests:
Access to coarse location
Access to fine location
Background location
Read and write access to external storage
Read phone state
Camera permissions
Figure 16. Two different pages with QR codes leading to the same app.
Warnings from Trustwave about malicious APK files highlight that these types of gambling and betting apps expose victims to harmful activity, such as:
Excessive advertising
Theft of personal data
Theft of funds
Hidden fees
Subscriptions
These apps provide financial incentives for engagement, prolonging the life of such scams. Allowing victims to download apps directly and bypassing official app stores enables attackers to circumvent app verification procedures.
Many campaigns hosting QR codes that pointed to a given APK file did so across numerous domains. The apps request suspicious Android permissions, most notably write external storage, camera and access fine location. These permissions could allow intentional data exfiltration, accidental data leakage and surveillance. The aggressive distribution across many different host pages, stealthy methods and excessive permissions suggest malicious intent.
Other Malicious App Downloads
Though gambling apps account for a large portion of the QR codes distributing APK files, QR codes also distribute other kinds of suspicious apps. Figure 17 illustrates two examples.
Figure 17. Examples of QR code with malicious app downloads.
The first example is a phone optimization app named ludashi_home.apk. It requests the following permissions:
Recording audio
Reading battery status
Reading phone state
Accessing the camera
Reading and writing to external storage
Authenticating accounts
Clearing the app cache
Installing packages permissions
The second example is a social network app for educators named k12sns.apk. This app also requests several different types of permissions:
Accessing the internet
Reading logs
Waking the lock
Reading the phone state
Writing to external storage
Several vendors detect these apps as suspicious or malicious, and they extract sensitive information from the device they are installed on. For example, the phone optimization app can take on certain behaviors like authenticating accounts and installing further packages, which attackers can misuse for malicious gains.
Conclusion
The attack scenarios and variety of examples we've discovered illustrate the extensive potential and existing prevalence of QR code misuse. The fundamental challenges of this type of misuse are user awareness and lack of visibility from current detection systems.
Most people scanning QR codes don't anticipate the broad range of device functions that can be triggered from in-app deep links or unexpected endpoints from QR code shorteners. This expectation mismatch creates a significant security weak spot that attackers can actively exploit.
User education remains critical — people need to understand that QR codes can do much more than simply open webpages.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Customers using Advanced URL Filtering and Prisma Browser (with Advanced Web Protection) are better protected against various QR code attacks. Our detectors analyze QR code landing pages and deep links.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Acknowledgements
The authors would like to thank Bradley Duncan and Billy Melicher for the thorough technical review of the article. We would also like to thank the editorial team including Samantha Stallings and Lysa Myers for the assistance with improving and publishing this article.
Between June and December 2025, the official hosting infrastructure for the text editor Notepad++ was compromised by a state-sponsored threat group known as Lotus Blossom. The attackers breached the shared hosting provider’s environment.
This allowed the attackers to intercept and redirect traffic destined for the Notepad++ update server. This infrastructure-level hijack enabled the attackers to selectively target specific users. The targets were primarily located in Southeast Asia across government, telecommunications and critical infrastructure sectors. Attackers served these targets malicious update manifests instead of legitimate software updates.
We’ve identified additional unreported infrastructure, which is linked to this campaign. We’ve observed two chains of infection including a Lua script injection variant that resulted in the delivery of Cobalt Strike beacon malware as well as DLL side-loading to deliver a Chrysalis backdoor. Unit 42 also found that this threat activity is targeting more sectors and more regions than previously reported.
This campaign also affected the following sectors in South America, the U.S., Europe and Southeast Asia:
Cloud hosting
Energy
Financial
Government
Manufacturing
Software development
Notepad++ is a lightweight, open-source code editor and text replacement utility. This tool is widely favored for its speed, extensive plugin ecosystem and unique ability to handle massive data files while persisting sessions that users have not yet saved.
In enterprise environments, Notepad++ often serves as a foundational instrument for system administrators, network engineers and DevOps personnel. These personnel commonly use this tool to modify server configurations, parse heavy system logs and audit code on secure jump boxes where heavier applications are impractical.
This specific user demographic makes Notepad++ a strategically critical target for threat actors. Compromising this single tool allows attackers to effectively bypass perimeter defenses and piggyback into the sessions of the most privileged users in the organization, gaining implicit administrative access to the network's core infrastructure.
Palo Alto Networks customers receive protections from and mitigations for the activity discussed in this article in the following ways:
This supply chain attack relied on exploiting insufficient verification controls in older versions of the Notepad++ updater, WinGUp. This exploitation allowed the threat group to redirect traffic to attacker-controlled servers.
When targeted victims attempted to update their software, they downloaded a malicious NSIS installer. This installer — often named update.exe — initiated a complex infection chain. This chain used DLL sideloading techniques and misused a legitimate Bitdefender component (BluetoothService.exe) to load a malicious library (log.dll) that decrypted and executed a custom backdoor. In another infection chain, attackers utilized an NSIS installer to execute a command to run a malicious Lua script to load Cobalt Strike Beacon.
This malware, called Chrysalis, employed advanced evasion techniques. These included:
Establishing persistent remote control over infected systems
Additional Exploitation Activity in This Campaign
Unit 42 observed evidence of two separate attack sequences:
One in which a malicious NSIS installer drops a compiled Lua script containing an installer to download and execute a Cobalt Strike Beacon payload
One in which attackers used DLL side-loading to inject the Chrysalis backdoor into memory
We observed additional activity dating between mid-August and November 2025 that was consistent with this exploitation activity. In an August incident, we observed communication with a command-and-control (C2) IP address 45.76.155[.]202. After days of C2 beacon traffic to this IP address, attackers shifted to a second C2 server at 45.77.31[.]210, with communication lasting until September.
In cases between September and November 2025, we observed activity consistent with outbound connections to a C2 server. These were followed by subsequent download requests for update.exe that are consistent with the reported Chrysalis backdoor. In some cases, download attempts were made to an IP address, whereas others were made to domains. Successful beacons to malicious servers occurred within seconds of successful download of the malicious payload and continued for an unspecified amount of time.
In September and October 2025, we observed a Lua script injection variant deploying malicious Lua scripts to inject shellcode. This attack used the EnumWindowStationsW API and resulted in the delivery of Cobalt Strike beacon malware. In this case, the download originated from:
45.76.155[.]202/update/update.exe
Separately, we also observed a Bluetooth DLL sideloading variant in the same case. This Lua variant uses Bluetooth service DLL sideloading techniques to deploy the Chrysalis backdoor. Download attempts for this variant were made from a different malicious server:
Downloading version 8.9.1, which includes the relevant security enhancement
Running the installer to update your Notepad++ manually
According to Notepad++, they have migrated their website to a new hosting provider with significantly stronger security practices.
Within Notepad++ itself, they enhanced the WinGup updater in v8.8.9 to verify both the certificate and the signature of the downloaded installer.
Additionally, they also note:
The XML returned by the update server is now signed (XMLDSig)
Certificate and signature verification will be enforced starting with the upcoming version 8.9.2, which they expect to release in about a month
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any signs of misuse or anomalous activity, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to assist with their investigations or hunting.
As the majority of activity likely occurred prior to December 2, we recommend reviewing data retention limits to determine if these queries will be effective in your environment. If available in your environment, you may consider using "cold storage" queries (cold_dataset = xdr_data) to query data beyond hot retention limits. Please note that running queries against cold storage will consume compute units.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Name: DLL sideloading via BYO application
// Description: Identifies renamed Bitdefender utility loading a log.dll file
This campaign marks a notable evolution in the operational tradecraft of threat actors of this type, representing a pivot from broad infrastructure pre-positioning to highly targeted “soft” supply chain interdiction. Recent campaigns from groups like Volt Typhoon and Salt Typhoon have focused primarily on compromising critical infrastructure backbones and edge devices, relying on living-off-the-land techniques and minimal malware. This operation instead illuminates a distinct strategic priority of focusing on administrative keyholders.
Hijacking the traffic flow of a trusted utility rather than injecting code into the software build pipeline allowed the threat actors to weaponize their delivery mechanism without alerting the vendor. This adversary-in-the-middle (AitM) capability allowed for dynamic fingerprinting of incoming update requests, enabling for highly selective filtering of priority targets.
This campaign is not focused on disruption, but on long-term valuable intelligence. This is illustrated by the combination of the threat actor’s selective victimology — focused on system administrators and developers in many geopolitically strategic regions — and their choice to use a lightweight backdoor with a low-profile.
Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Advanced WildFire
Advanced WildFiremachine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Next-Generation Firewalls With Advanced Threat Prevention
Cortex XDR and XSIAM help to prevent the threats described in this article by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints.
Cortex Cloud
Organizations using Cortex Cloud, such as those within the cloud hosting industry which were actively targeted during this campaign, are better protected from the downloading and execution of the malware mentioned within this article 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.
During a September 2025 incident response investigation, Unit 42 discovered a rogue virtual machine (VM) which we believe with high confidence to be used by the cybercrime group Muddled Libra (aka Scattered Spider, UNC3944). The contents of this rogue VM and activity from the attack provide valuable insight into the operational playbook of this threat actor.
Muddled Libra created the VM after the group successfully gained unauthorized access to the target's VMware vSphere environment. Activities during the attack include:
Performing reconnaissance
Downloading tools
Establishing persistence via a command and control (C2) channel
Using stolen certificates
Copying files from the rogue VM to the target's domain controller (DC)
Interacting with the target’s Snowflake infrastructure
Based on the characteristics of the attack, we assess with high confidence that Muddled Libra conducted it. This article provides a detailed analysis of our observations to shed further light on the threat actor’s tactics, techniques and procedures (TTPs).
Palo Alto Networks are better protected from the threats discussed in this article through the following products and services:
As previously documented, threat actors affiliated with Muddled Libra use various social engineering tactics (e.g., smishing, vishing) to gain initial access to targeted organizations. Activities can include targeting call centers operated by potential victims, as well as those outsourced to third-party firms. These third-party firms include business process outsourcing (BPOs) and managed service providers (MSPs). This expands the group’s range of potential targets.
Threat actors affiliated with Muddled Libra are highly proficient at exploiting human psychology by impersonating employees to attempt password and multi-factor authentication (MFA) resets. Figure 1 illustrates the composition of Muddled Libra in terms of their demographics, tradecraft, victim targeting and actions on objectives.
Figure 1. Muddled Libra threat profile.
While their tradecraft has evolved, threat actors affiliated with Muddled Libra continue to minimize their use of malware throughout the attack chain. Whenever possible, they prefer to use their targets' own assets against them.
Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply that the legitimate product is flawed or malicious.
Background on the Attack Chain
We assisted a client with an incident response engagement in September 2025. Throughout our investigation, we identified and recovered a VM created and leveraged by the threat actor to conduct the early stages of its attack. Attackers were unable to delete this VM before their access was cut off. We often observe threat actors creating VMs within targeted environments to avoid detection from endpoint tools like endpoint detection and response (EDR) or extended detection and response (XDR).
By examining this VM, we discovered the tools the attackers leveraged and the basic troubleshooting they conducted during their unauthorized access. This provided insights into their operational methods.
Using forensic artifacts and logs, we uncovered a large amount of activity conducted from this VM, including lateral movement and tools used. Figure 2 further illustrates our observations during the investigation. Note that the analysis below is of a single system and does not cover the entire incident observed by Unit 42.
Figure 2. High-level chain of events in the attack investigated by Unit 42.
A Peek Into Muddled Libra Tactics
Approximately two hours after gaining initial access to the target’s environment, we observed the attackers accessing the target’s vSphere portal and creating a new VM named “New Virtual Machine.” The attackers then leveraged this VM for the early stages of the incident as a beachhead host using the local Administrator account.
Shortly after logging into the newly created VM, attackers downloaded stolen certificates from the targeted environment. They leveraged these certificates to forge tickets throughout their attack chain.
Within three minutes, attackers established additional persistence in the target’s environment using an SSH tunnel through the Chisel tool. This tool was contained in a ZIP archive named goon.zip that was hosted on an AWS S3 bucket under the attackers' control.
Nearly one minute after they downloaded the ZIP archive containing Chisel, we observed malicious network connections to an attacker-controlled IP address over TCP port 443 (HTTPS). We observed this connection for a total of 15 hours. Figures 3-5 illustrate these observations.
Figure 3. URL hosting archive containing the Chisel tool.Figure 4. The downloaded tool, goon.zip.Figure 5. The SSH tunneling tool, chisel.exe, extracted from goon.zip.
A minute later, we observed them logging in interactively with a new local user account named gooner.
Approximately 15 minutes after creating the VM, the attackers began using vSphere to power down two of the target's virtualized DCs. They then mounted the virtual machine disks (VMDKs) of the powered-down DCs. This allowed them to copy the NTDS.dit and SYSTEM registry hive files from these two DCs and place them on the desktop of the Administrator account on their newly created VM.
Approximately two minutes later, they wrote two files, result and result.kerb, to the local Administrator account’s desktop. We retrieved these files and determined that these were decrypted versions of the target’s NTDS.dit Active Directory database, which contained hashes of all users. Figures 6 and 7 illustrate these observations.
Figure 6. VMware logs of the shutdown activities of the DC.Figure 7. List of files discovered for credential dump, NTML hash and Kerberos hash.
At nearly 30 minutes of access to this newly created VM, the attackers began executing the Active Directory enumeration tool ADRecon. We observed and retrieved dozens of files associated with ADRecon, including a PowerShell script and output files.
These files contained information such as:
Domain details
Forest
Trusts
Sites
Subnets
Schema
Password policy
DCs
Service Principal Names (SPNs)
Users
Group Policy Objects (GPOs)
The output of the ADRecon tool would then be placed in a ZIP archive named <VICTIM ORGANIZATION>.zip (where <victim organization> represents the name of the victim, redacted for this report). We also observed the attackers downloading the tool ADExplorer64.exe directly from the Microsoft SysInternals domain. Figure 8 illustrates these observations.
Figure 8. List of ADRecon output files discovered during our investigation.
Within the ADRecon output, the threat actors only opened the CSV file ComputerSPNs.csv. This file contained all available service principal names (SPNs) associated with hosts in the environment. Attackers gather this information to help identify critical services running that they are interested in targeting. These critical services include:
Veeam
Terminal services
Hyper-V
MSSQL
Exchange
Other similar systems as shown in Figure 9
Figure 9. List of targeted services discovered during our investigation.
One hour later, attackers began searching the web for various acronyms associated with the targeted organization, likely to determine what data could be sensitive and interesting for exfiltration. This included searches such as “what is NAIC code” and “NAICS code lookup,” as shown in Figure 10.
A North American Industry Classification System (NAICS) code is a six-digit number that classifies businesses by their primary economic activity. By looking up this code, attackers might have been trying to understand the business category of the target organization.
Figure 10. Example of web searches.
Thirty minutes after their web searches, attackers began interacting with significant data from the target’s Snowflake database, which they also downloaded to their VM. For the next few hours, attackers began interacting with the data and attempting to identify ways to send the data from their VM to a file-sharing site. However, we observed them having difficulties finding a file-sharing site that the targeted organization had not already blocked.
After trying several common file-sharing sites, they began using Bing to search on the phrases “upload files” and “upload files no registration” to identify a file-sharing site that was not blocked. We observed attempts at accessing sites such as:
LimeWire
upload[.]ee
uploadnow[.]io
filetransfer[.]io
filebin[.]io
Dropbox
Figures 11-13 illustrate these observations.
Figure 11. List of Snowflake web browsing activities documented from our investigation.Figure 12. Web searches for cloud storage services discovered during our investigation.Figure 13. Web browsing activities to cloud storage services discovered during our investigation.
Shortly after interacting with the data, the attackers began lateral movement using multiple then-compromised accounts with their SSH tunnel, RDP and PsExec. They downloaded the PsExec tool directly from the Microsoft SysInternals domain.
Approximately four hours after the creation of their VM, the attackers began looking for additional sensitive data. At that time, we observed them having compromised a handful of accounts, one of which they used to access the mailboxes of other accounts to download a Personal Storage Table (PST) file. However, based on Bing search history, they had difficulty accessing the mailbox via Office.
The attackers then searched the web for “office[.]com old setup download” and “is there a place to download an older version of Outlook?” Attackers also reviewed various Reddit posts related to this query. Shortly after, they downloaded and ran OfficeSetup.exe from Microsoft.
They then began troubleshooting items such as “Outlook slow downloading emails” and performed several internet speed checks using the site fast[.]com. Figures 14-17 illustrate these observations.
Figure 14. Online Outlook login activities discovered during our investigation.Figure 15. Web searches for Outlook agents discovered during our investigation.Figure 16. Web searches for older Outlook versions discovered during our investigation.Figure 17. Web searches to troubleshoot slow email download issues and perform a speed test.
In addition to troubleshooting their download speeds, attackers used Bing to identify the location of the Outlook ODT file. Figure 18 illustrates this observation.
Figure 18. Web search for the Outlook ODT file location discovered during our investigation.
Additionally, we observed Microsoft Defender, presumably installed on the VM by default, taking action on multiple malicious files on this VM. This included ADRecon, Chisel and GoSecretsDump. Figure 19 lists these detections.
Figure 19. Microsoft Defender detections on tools discovered during our investigation.
After some time, the attackers then began attempting to exfiltrate the Outlook PST file. They first searched for the S3 Browser tool. Once they downloaded the tool from the S3 Browser website, attackers then attempted to exfiltrate the PST file by uploading it to their S3 bucket. Figures 20 and 21 illustrate these observations.
Figure 20. Downloaded S3 browser executable discovered during our investigation.Figure 21. S3 Browser logs of PST file upload.
After approximately 15 hours of access to their VM, attackers began browsing various VMware ESXi hosts. They continued to pivot through the network, leveraging access to multiple compromised accounts before their access was terminated by the targeted organization’s security team. Figure 22 illustrates this observation.
Figure 22. Browsing activities to the target’s VMware ESXi hosts discovered during our investigation.
Conclusion
Intrusion operations Muddled Libra conducts have affected the business operations of many organizations across the globe. This is not because they use advanced malware or novel exploits, but because they exploit the weakest link: humans.
While focusing on identity compromise and social engineering, this threat actor leverages legitimate tools and existing infrastructure to blend in. They operate quietly and maintain persistence.
This incident offers a rare window into an operational playbook used by Muddled Libra, revealing how a single rogue VM can serve as a powerful foothold for lateral movement and data theft. The threat actor's methods underscore the importance of:
Strengthening identity security
Enforcing strict access controls
Continuously monitoring for anomalous use of administrative tools and cloud environments
Organizations should adopt a defense-in-depth strategy centered on:
Protecting identity
Maintaining least-privileged access
Detecting living-off-the-land behaviors
While Muddled Libra’s tactics may appear simple, their effectiveness reminds us that cybersecurity resilience begins not with complexity, but with vigilance, visibility and disciplined access management.
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.
Cortex Cloud customers can better protect their cloud infrastructure from the topics discussed within this article through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within their 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.
Cortex XDR and XSIAM help to prevent the threats described in this blog, by employing the Malware Prevention Engine. This approach combines several layers of protection, including WildFire, Behavioral Threat Protection and the Local Analysis module, designed to prevent both known and unknown malware from causing harm to endpoints.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Host Based
Important note: The following files are not malicious, but they are indicators because they were used during the attack.
Cloud-based alerting systems often struggle to distinguish between normal cloud activity and targeted malicious operations by known threat actors. The difficulty doesn’t lie in an inability to identify complex alerting operations across thousands of cloud resources or in a failure to follow identity resources, the problem lies in the accurate detection of known persistent threat actor group techniques specifically within cloud environments.
In this research, we hypothesize how a new method of alert analysis could be used to improve detection. Specifically, we look at cloud-based alerting events and their mapping to the MITRE ATT&CK® tactics and techniques they represent. We believe that we can show a correlation between threat actors and the types of techniques they use, which will trigger specific types of alerting events within victim environments. This distinct, detectable pattern could be used to identify when a known threat actor group compromises an organization.
To prove this method of alert analysis, Unit 42 researchers focused on two known threat actor groups that use two fundamentally different types of operational techniques to compromise their victims’ cloud environments. These groups are the cybercrime group Muddled Libra and the nation-state group Silk Typhoon. Both threat actor groups are known to target cloud operations.
We analyzed cloud alerting events across 22 industries between June 2024 and June 2025.
The research was conducted by pairing the cloud-related MITRE ATT&CK techniques known to be used by Muddled Libra and Silk Typhoon with the specific security alerts they are known to trigger in cloud environments.
The test confirmed, as you will see within the remainder of this article, that security teams can successfully distinguish unique alerting patterns between Muddled Libra and Silk Typhoon based solely on the types of alerts observed.
Additionally, the results show a clear link between threat actors’ cloud-focused operations and the industries those groups target. Therefore, at times when one of the groups was known to be attacking certain industries, we can see those patterns appear in our data.
The confirmation that our detection method works as expected opens the door to the possibility of automated prevention capabilities for complex cloud architectures.
Cortex Cloud is designed to detect and prevent the malicious operations, configuration alterations and exploitations discussed in this article, by associating events with MITRE tactics and techniques. These capabilities help organizations to maintain runtime detection of events.
Following our previous article on cloud alert trends, we conducted another analysis of cloud alert statistics.
As part of the effort to determine whether we could identify threat groups, this time we analyzed the data in terms of the industries in which cloud alerts were triggered. Adding industry telemetry to the analysis allowed us to focus our efforts on identifying the techniques, and thus the resulting alerts, used by these threat actors as a control parameter. Using alert data pulled between June 2024 and June 2025, we identified the industries that saw the highest number of unique alert types as well as the highest average number of daily alerts. We then correlated these trends with the activities and targets of two threat groups: Muddled Libra and Silk Typhoon.
This article presents our analysis of Muddled Libra and Silk Typhoon operational techniques and the associated alert analysis.
Glossary: Mapping Techniques to Alerts
The research was conducted by analyzing cloud-related MITRE ATT&CK techniques known to be used by Muddled Libra and Silk Typhoon and pairing them with the specific security alerts they are known to trigger in cloud environments. The following glossary will assist readers in understanding the results we present.
Mapping MITRE Techniques to Alerts: A single MITRE technique can potentially trigger multiple unique security alerts, and conversely, a single alert can map to one or more MITRE techniques and tactics. For example, the alert Remote command line usage of serverless function’s token in the Cortex Cloud platform correlates to the MITRE tactic Credential Access, and the MITRE techniques Steal Application Access Tokenand Unsecured Credentials.
Unique Alert Count: We counted each alert rule only once for the basis of this research. For example, we identified nearly 70 different unique alerting rules that could be attributed to at least one of the 11 different cloud-related MITRE techniques known to be used by Muddled Libra. For Silk Typhoon, we found just over 50 unique alerting rules that could be attributed to at least one of their 12 known cloud-related MITRE techniques. Additionally, we found that only three unique alert rules were present in both Muddled Libra and Silk Typhoon alert rule sets. In some cases, these alerting rules triggered multiple times within our data across multiple organizations, but when we refer to unique alerts within an industry, we are only considering whether an alert triggered at all during the specified period.
Average Daily Occurrences: If a threat actor used the MITRE technique Data from Cloud Storage (T1530), one of the resulting unique Cortex alert rules might be Suspicious identity downloaded multiple objects from a bucket. If this alert is triggered 1,000 times in a single day, it counts as a single unique alert, but the 1,000 occurrences of that alert in that day will be calculated in the average daily occurrences. When we report average alerts per day by industry in the article below, we take the average for each organization within that industry vertical.
To use a metaphor to help explain how we considered alerts, if each alert rule was a type of fruit, we would see that Muddled Libra holds a very different basket of fruit than Silk Typhoon does. In fact, the baskets are so diverse, that out of the nearly 70 different types of fruit Muddled Libra has, and the more than 50 different types of fruit Silk Typhoon has, they only have 3 types of fruit in common.
When we look at alerts triggered within an industry, we might see a variety of fruit scattered about — maybe 10 oranges, 14 lemons and so on. When we analyze the fruit trail in terms of the types of fruit found within a particular industry, compared with the types of fruit found in the baskets we know Muddled Libra or Silk Typhoon to be holding, we can make a reasonable determination of which threat actor was involved.
Methodology
We collected alerts between June 2024 and June 2025 that were triggered on a combination of platforms, including:
Cloud service providers
Container environments
Cloud-hosted applications
SaaS platforms
We then analyzed the alerts based on their unique naming, originating platform, alert date and metadata such as:
Industry
Region
Frequency of occurrence
Average number of occurrences in each organization
As described above, we integrated the correlation of the MITRE ATT&CK framework, by pairing each alert with its corresponding MITRE technique.
We also analyzed the correlation between the targeted organization’s industry and region and the severity level of the alerts they experienced. This helped to identify the types of alerts that are more likely to occur, based on these factors.
Threat Actor Profiles
Muddled Libra
Background
Muddled Libra (also known as Scattered Spider, or UNC3944) is a cybercrime group that has been active since 2021.
Known for its use of social engineering, including making calls to organizations’ help desks, Muddled Libra has also been known to partner with ransomware-as-a-service (RaaS) programs. By continually updating its approach, the group has successfully used social engineering techniques, including smishing (SMS phishing), vishing (voice phishing) and spear phishing (directly targeting an employee).
Upon successfully compromising an organization, the group uses several tools, including ransomware variants such as DragonForce – a subscription-based RaaS framework created by a group of the same name, tracked by Unit 42 as Slippery Scorpius. The group also uses cloud enumeration tools such as ADRecon, an open source Active Directory reconnaissance tool.
Targeted Industries and Techniques
While Muddled Libra’s targeted industries have evolved since 2022, the following sectors have been consistently reported:
Aerospace and defense
Financial services
High technology
Hospitality
Media and entertainment
Professional and legal services
Telecommunications
Transportation and logistics
Wholesale and retail
Muddled Libra employs multiple offensive techniques to compromise and maintain access within a victim’s environment. We analyzed the group’s known techniques, and extracted those techniques that specifically focus on cloud infrastructure, as Table 1 shows. Together, these form a sort of “fingerprint” that we can use to identify the group within cloud alert data.
Table 1. Known Muddled Libra cloud tactics and techniques.
Methodology Walkthrough
Even though each MITRE Technique is relatively granular in terms of scope of operation, there can be multiple types of computational events from a cloud platform or software-as-a-service (SaaS) application which can fall under the purview or scope of a single MITRE technique.
For example, the MITRE technique T1078.004 - Valid Accounts: Cloud Accounts is focused on the operational event of a valid cloud account. This can have a wide scope in the types of event which can be counted, such as:
Unusual resource modification from a newly seen IAM user
Deletion of multiple cloud resources by a newly created IAM role
A suspicious identity created or updated password for an IAM user
Each of these can be linked to a valid cloud account but each one could have vastly different root causes.
Additionally, when looking specifically at an individual alert type, such as Unusual resource modification from a newly created IAM role, this event could be considered to align not only with the MITRE tactic Initial Access, but it could also align with the MITRE tactics Defense Evasion or even Persistence.
When we expanded our scope to include potential alerting events that could be triggered by any of the MITRE techniques known to be used by Muddled Libra, we found nearly 70 alerting events that could be attributed to at least one of these MITRE techniques.
We collected all of these alerts, which were associated with each of the MITRE techniques known to be used by Muddled Libra. We then distilled those alerts to identify the number of unique alerts that were present within each industry. We also tracked the number of average daily occurrences for each organization within those industries. To use our fruit analogy, we identified the number of unique fruit that the threat actors left at each respective industry (unique alerts), then we also counted how many of each fruit type were present at each organization within that industry (average alert count).
As explained in the Glossary section, we were able to use these numbers to build patterns.
Industry and Technique Analysis
Comparing the triggered alerts and their associated MITRE techniques with the targeted industries shows a correlation between the industries targeted according to public reports and the alerts triggered by Muddled Libra operations. Figure 1 shows this correlation by ranking industries from the highest to the lowest based on the number of unique alerts related to the MITRE techniques listed within Table 1, between June 2024 and July 2025. Industries that were publicly reported as targeted are shown in red.
Figure 1. Count of unique alerts by industry from June 2024-June 2025. Red bars indicate the industries publicly reported as targeted by Muddled Libra.
Figure 2 shows the average daily number of alerts that occurred during the same timeframe.
Figure 2. Count of the average daily alerts by industry from June 2024-June 2025. Red bars indicate the industries publicly reported as targeted by Muddled Libra.
Figure 2. Count of the average daily alerts by industry from June 2024-June 2025. Red bars indicate the industries publicly reported as targeted by Muddled Libra.
While the highest volume of unique alerts (shown in Figure 1) aligns perfectly with Muddled Libra’s most-reported targets — specifically high technology, wholesale and retail, financial, and professional and legal services—the presence of a number of signature alerts in other sectors shouldn't be ignored. When an industry like manufacturing or pharma and life sciences or state and local government shows a significant subset of Muddled Libra’s "fingerprint" (for instance, 16 or more unique alert types), it suggests the group could have an active interest in these environments even if we haven’t seen headlines about it. Security teams in these "middle-tier" industries should treat these clusters of unique alerts as early warning signs that these industries are witnessing a significant number of the group's known operational techniques.
The unique alert data (Figure 1) should be considered alongside average daily alert data (Figure 2) to distinguish between a threat actor’s strategic breadth and their operational persistence. For instance, transportation and logistics serves as a primary example of high-intensity targeting; it ranks sixth in unique alert variety but first in average daily volume, showing a 25% spike in unique alerts in June 2025 alone. This combination indicates that Muddled Libra is not only using a wide array of its signature techniques in this sector but is doing so with higher frequency. We will take a deeper dive into transportation and logistics in the next section.
In contrast, telecommunications and media and entertainment were some of the first and most frequent targets of Muddled Libra in 2022 and 2023, but their standings as the last two positions for average daily alerts in 2024-2025 suggest that these two industries in particular have experienced a saturation effect. Namely, the targeting of these groups may be aging off. They no longer appear to be the key focus of the Muddled Libra actors. The other industries that could also fall into this category are hospitality and aerospace and defense.
For a defender, this data provides a threshold for proactive investigation. A high count of unique alerts (the "variety" of the fruit basket) typically signals a sophisticated, multi-stage intrusion attempt, whereas a high daily average (the "quantity" of fruit) may point to automated scanning or persistent credential stuffing. If your organization sees more than 10 unique Muddled Libra-associated alerts within a 30-day window, it is time to look deeper, regardless of whether your specific industry is currently "trending" in threat intelligence circles. The goal is to move from reactive patching to proactive defense by identifying these actor-specific patterns before they escalate to data exfiltration.
Focused Analysis: Aviation
Reports that Muddled Libra was targeting the aviation industry initially surfaced in June 2025. Unit 42 does not track aviation as a singular category. Instead, aviation organizations appear under our transportation and logistics category.
When looking at the transportation and logistics industry alerts, we found an increase in the number of unique alerts based on the MITRE techniques used by Muddled Libra during this same timeframe.
It is important to note that here we are looking at the number of unique alert rules for this analysis and breaking this out by month, as opposed to the whole year view shown in Figure 1. We arrive at “unique alerts” for the industry by taking the average number of unique alerts seen for each organization tracked in that category over a monthly timeframe.
Figure 3 shows that the average number of unique alerts per organization in the transportation industry increased by 25% from May-June 2025. What makes this finding important is that Muddled Libra made several headlines during June 2025 for its operations targeting airline organizations.
Figure 3. Unique alerts by month for the transportation industry. The bar for June is red because it is the period publicly reported to have the highest targeting of the aviation industry.
As illustrated in Figure 3, June 2025 saw the highest number of unique alerts for the transportation industry, with 15 unique alerts.
The Verdict on the Fingerprinting Effort
Looking at the correlation, there does appear to be a fingerprint capability that could be used as a detection pattern. This pattern could help organizations identify if they are potentially targeted and take mitigative steps. Additionally, this could also assist organizations in developing an early warning detection trigger. For example, if defenders witness an increase in the number of daily average occurrences alerts from known Muddled Libra techniques, this could indicate reconnaissance or discovery activity occurring against their infrastructure. This then provides an opportunity to proactively prepare for future operations.
Top 10 Alerts from Muddled Libra Techniques
Table 2 lists the top 10 alerts that we observed in association with Muddled Libra’s MITRE techniques.
Alert Names
MITRE Techniques
Tactics
Azure sensitive resources enumeration activity using Microsoft Graph API
Table 2. The top 10 alerts associated with Muddled Libra’s MITRE techniques.
As outlined in Table 2, Muddled Libra has an extensive history of targeting Microsoft Azure environments using Graph API, a RESTful API that enables access to Azure cloud resources. This type of activity correlates with the MITRE techniques used by Muddled Libra and the alerts triggered by their operations. The most frequent alert between June 2024 and June 2025, in relation to the MITRE techniques used by Muddled Libra, was resource enumeration using Microsoft Graph API. The next most common alert was for exfiltration activity from Microsoft 365 storage services. While discovery operations represented the bulk of the remaining alert types, collection and exfiltration operations were the second most frequent alert type.
Silk Typhoon
Background
Silk Typhoon (also known as HAFNIUM) is a China-nexus threat actor group that has been in operation since at least 2021. This group has historically exploited multiple vulnerabilities on Microsoft Exchange Servers. In recent years, the group appears to be shifting targets towards cloud environments, using compromised credentials obtained via vulnerable public-facing VPN endpoints to move laterally through cloud environments. The group relies on remote monitoring and management (RMM) tools to maintain persistent access and leverages Microsoft’s Graph API to enumerate cloud resources.
Targeted Industries and Techniques
Cybersecurity researchers have identified that the industries most commonly targeted, primarily located within the U.S., include:
Education
High technology
Federal governments
Financial services
Nongovernmental organizations (NGOs)
Professional and legal services
State and local governments
Utilities and energy
Silk Typhoon has employed several offensive techniques to compromise and maintain access within a victim’s environment. Using the same methodology that was employed during the Muddled Libra analysis above, we analyzed the techniques and identified those that focus on cloud infrastructure, as Table 3 shows. We found that between Silk Typhoon and Muddled Libra’s known employed technique usage, only three techniques were employed by both threat actor groups, T1530, T1078.004 and T1098.001. This provides a basis on which to compare and contrast the results between both groups’ operations and, more importantly, on the types of alerts witnessed by organizations in the industries they target.
Table 3. Known Silk Typhoon cloud tactics and techniques.
Methodology Walkthrough
As a brief recap to the methodology of our research, we analyzed the types of alerting events that could be associated with each of the MITRE Techniques known to be used by Silk Typhoon. When we included potential alerting events that could be triggered by any of the MITRE Techniques known to be used by Silk Typhoon, we found just over 50 alerting events that could be attributed to at least one of these MITRE Techniques.
We collected all of these alerts and distilled those alerts to identify the number of unique alerts that were present within each industry and the number of average daily occurrences of those alerts for each organization within those industries.
To use the same analogy as above, we wanted to identify what types of fruit Silk Typhoon brought to the party, and how many pieces of fruit they typically deploy when attacking.
Industry and Technique Analysis
We compared the total number of unique alerts for each month from June 2024 to June 2025 with the industries from which those alerts were triggered. This comparison confirmed that we were able to see the “fingerprints” of Silk Typhoon in the alerts triggered in industries that the group was known to be targeting.
As mentioned, Silk Typhoon had just over 50 unique alerts associated with their known technique usage, where Muddled Libra had nearly 70.
In contrast, we saw higher numbers of unique alerts within each industry when examining our Silk Typhoon data than we did in our Muddled Libra data.
In other words, Silk Typhoon may be holding a basket with fewer types of fruit (50) than in Muddled Libra’s (70), but the threat actor seems to use more types from the basket in its operations (i.e. as many as 27 unique alerts as opposed to 22).
The graph in Figure 4 shows our observations of alerts by industry over the period studied.
Figure 4. Count of unique alerts and average daily alerts by industry. Red bars indicate the industries public reported as targeted by Silk Typhoon.Figure 5. Count of the average daily alerts by industry. Red bars indicate the industries publicly reported as targeted by Silk Typhoon.
While the highest volume of unique alerts aligns with Silk Typhoon’s most-reported targets—specifically high technology, financial services, and professional and legal services—the presence of signature alerts in other sectors is equally telling. When an industry like wholesale and retail or manufacturing shows a significant subset of Silk Typhoon’s "fingerprint" (for instance, 18 or more unique alert types), it indicates that the group could be actively deploying their offensive techniques against these industry environments. This could be occurring even if public reporting is minimal or nonexistent at this date. Security teams in these "middle-tier" industries should treat these clusters of unique alerts as evidence that they are witnessing a broad spectrum of the group's known operational techniques, rather than isolated incidents.
The unique alert data for Silk Typhoon (Figure 4) should be considered alongside average daily alert data (Figure 5) to distinguish between a threat actor’s strategic breadth and their operational persistence. To return to our metaphor, Silk Typhoon holds a "basket" with fewer types of fruit (50) than Muddled Libra (70), but they tend to use more of what is in their basket at any given time. For example, we witnessed as many as 27 unique alerts in a single sector compared to Muddled Libra’s 22.
The federal government serves as a primary example for high-intensity targeting. This industry ranks last in the number of unique alerts, or rather in variety, ie. the "types of fruit" in its basket, but first in average daily volume, peaking at 7.28 alerts per day (the "quantity of fruits witnessed"). This suggests that while Silk Typhoon may use a narrower set of techniques against government targets, it deploys those specific tactics with relentless frequency. Conversely, high technology shows a "worst-of-both-worlds" scenario, ranking first in unique tactical variety and near the top for daily volume. This indicates campaigns that are both sophisticated and persistent.
Similar to our comments on unique alerts, when we see a high level of activity possibly related to the threat group, it may be worth defenders' threat hunting for other known alerts related to Silk Typhoon, out of an abundance of caution. High levels of average alert activity could signify threat groups trying to gain initial access, but not yet succeeding in deploying their full toolset.
For a defender, this data provides a threshold for proactive investigation: a high count of unique alerts (the "variety" of the fruit basket) typically signals a sophisticated, multi-stage intrusion attempt, whereas a high daily average (the "quantity" of fruit) may point to automated scanning or persistent exploitation of specific vulnerabilities. If an organization observes more than 10 unique Silk Typhoon-associated alerts within a month, it is time to look deeper, regardless of whether a specific sector is making headlines as a common target.
Top 10 Alerts from Silk Typhoon Techniques
Table 4 lists the alerts most commonly seen in relation to the MITRE techniques used by Silk Typhoon.
Alert Names
MITRE Techniques
Tactics
Microsoft O365 storage services exfiltration activity
Table 4. The top 10 alerts associated with Silk Typhoon’s MITRE techniques.
As outlined in Table 4, collection and exfiltration techniques were the most common alerts associated with Silk Typhoon’s MITRE techniques. Microsoft 365 storage services exfiltration was the most frequently observed alert. Other alerts identified include cloud storage enumerations and suspicious downloads of cloud storage objects.
Industry Cloud Alert Trends
Perhaps the most striking result of our research came to light when we compared general cloud alerting trends with the trends we discovered while performing the fingerprinting analysis of Muddled Libra and Silk Typhoon.
The industry of high technology was consistently the top ranked industry when considering general cloud alerting trends, as well as the two threat actor groups’ alerting trends. However, the remaining industries we studied did not follow a uniform pattern. As shown in Figure 6, we found that the order of the most targeted industries shifted when we only counted alerts from Muddled Libra and Silk Typhoon operations.
Figure 6. Ranking of the top industries by unique alert counts for all alerts, Muddled Libra and Silk Typhoon.
As stated above, the high technology industry is in first place across both threat actor group findings, as well as the top ranking industry when looking at all cloud alerts by industry.
However, the remaining industry ranks do not mirror the same results. Looking at the wholesale retail industry illustrates a key finding. This industry is the second highest for Muddled Libra alerting events and third highest for Silk Typhoon, but is 14th on the industry list for all alerts.
This indicates that the fingerprinting analysis on these alerting operations does not reflect the same pattern as the general noise of all alerting trends. It appears that the distinct operations performed by the threat actors against the industries they target carry their own unique trends.
Conclusion
Our analysis confirms the capacity to leverage the alerts triggered as a fingerprint detection pattern for the malicious techniques used by Muddled Libra and Silk Typhoon. This distinct detection capacity offers a new pathway for organizations to implement predictive and proactive cloud defense strategies.
Our research successfully differentiated the MITRE tactic and technique operations used by Muddled Libra, notably the aviation industry’s 25% increase in the number of unique alerts compared to the previous month, and Silk Typhoon’s increased higher than average number of daily alerts within the Federal and State Government industry.
By identifying the alert patterns that each threat actor’s techniques have on the alerting events within cloud environments, threat researchers can identify the threat actors most likely to target certain industries using specific techniques. This can then help defenders to proactively prepare defenses against those types of threats. Through the analysis of threats based on the types of attack techniques they leverage, organizations can create a defense methodology built specifically for their industry vertical.
Proper implementation of these defense controls can be effective in defending against targeted threat actor scenarios through the creation of tailored defensive alerting. Additionally, these controls can provide the capability to detect early warning scenarios and techniques, such as initial access operations, enabling prevention operations to block malicious cloud operations before they escalate to execution, impact or exfiltration.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud customers can help secure and protect their cloud environments through compliance guardrails, application security monitoring and prevention techniques and through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment. Cortex Cloud is designed to identify cloud events witnessed on cloud platforms, to protect cloud posture and runtime operations. By associating events with MITRE tactics and techniques, Cortex Cloud helps detect and prevent the malicious operations, configuration alterations and 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: 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.
This investigation unveils a new cyberespionage group that Unit 42 tracks as TGR-STA-1030. We refer to the group’s activity as the Shadow Campaigns. We assess with high confidence that TGR-STA-1030 is a state-aligned group that operates out of Asia. Over the past year, this group has compromised government and critical infrastructure organizations across 37 countries. This means that approximately one out of every five countries has experienced a critical breach from this group in the past year. Further, between November and December 2025, we observed the group conducting active reconnaissance against government infrastructure associated with 155 countries.
This group primarily targets government ministries and departments. For example, the group has successfully compromised:
Five national-level law enforcement/border control entities
Three ministries of finance and various other government ministries
Departments globally that align with economic, trade, natural resources and diplomatic functions
Given the scale of compromise and the significance of these organizations, we have notified impacted entities and offered them assistance through responsible disclosure protocols.
Here we describe the technical sophistication of the actors, including the phishing and exploitation techniques, tooling and infrastructure used by the group. We provide defensive indicators to include infrastructure that is active at the time of this publication. Further, we explore an in-depth look at victimology by region with the intent of demonstrating the suspected motivations of the group. The results indicate that this group prioritizes efforts against countries that have established or are exploring certain economic partnerships.
Additionally, we have also pre-shared these indicators with industry peers to ensure robust cross-industry defenses against this threat actor.
Palo Alto Networks customers are better protected from the threats described in this article through products and services, including:
Unit 42 first identified TGR-STA-1030 (aka UNC6619) upon investigating a cluster of malicious phishing campaigns (referred to here as the Shadow Campaigns) targeting European governments in early 2025. We use the prefix TGR-STA as a placeholder to denote a temporary group of state-aligned activity while we continue to refine attribution to a specific organization.
Since our initial investigation, we have identified actor infrastructure dating as far back as January 2024, suggesting that the group has been active for at least two years. Over the past year, we have monitored the evolution and expansion of the group as it has compromised:
Five national-level law enforcement/border control entities
Three ministries of finance and various other government ministries
Departments globally that align with economic, trade, natural resources and diplomatic functions
We assess with high confidence that TGR-STA-1030 is a state-aligned group that operates out of Asia. We base this assessment on the following findings:
Frequent use of regional tooling and services
Language setting preferences
Targeting and timing that routinely align with events and intelligence of interest to the region
Upstream connections to operational infrastructure originating from the region
Actor activity routinely aligning with GMT+8
Additionally, we found that one of the attackers uses the handle “JackMa,” which could refer to the billionaire businessman and philanthropist who co-founded Alibaba Group and Yunfeng Capital.
Phishing
In February 2025, Unit 42 investigated a cluster of malicious phishing campaigns targeting European governments. These campaigns followed a pattern of being sent to government email recipients with a lure of a ministry or department reorganization and links to malicious files hosted on mega[.]nz. Figure 1 below shows an example.
Figure 1. Example phishing email (translated).
Clicking on the link downloads an archive file with language and naming that is consistent with the targeted country and ministry.
We assess that an Estonian government entity identified the campaign and uploaded one such ZIP archive to a public malware repository. In this case, the Estonian filename was:
Politsei- ja Piirivalveameti organisatsiooni struktuuri muudatused.zip
This translates to Changes to the organizational structure of the Police and Border Guard Board.zip
Diaoyu Loader
Analyzing the archive, we found that the contents were last modified on Feb. 14, 2025. Further, the archive itself contains an executable file containing an identical name as the ZIP and a zero-byte file named pic1.png.
Reviewing the executable metadata, we found that the file version is presented as 2025,2,13,0, suggesting that the file was likely created one day prior, on Feb. 13. This date also corresponds to the PE compile timestamp.
Additionally, the metadata shows that the file’s original name was DiaoYu.exe. The term Diaoyu translates to fishing, or phishing in a cybersecurity context.
The malware employs a dual-stage execution guardrail to thwart automated sandbox analysis. Beyond the hardware requirement of a horizontal screen resolution greater than or equal to 1440, the sample performs an environmental dependency check for a specific file (pic1.png) in its execution directory.
In this context, pic1.png acts as a file-based integrity check. If the malware sample is submitted to a sandbox in isolation, the absence of this auxiliary file causes the process to terminate gracefully before detonation, effectively masking its malicious behavior. Only upon satisfying these prerequisites does the malware proceed to audit the host for the following cybersecurity products:
Avp.exe (Kaspersky)
SentryEye.exe (Avira)
EPSecurityService.exe (Bitdefender)
SentinelUI.exe (Sentinel One)
NortonSecurity.exe (Symantec)
This narrow selection of products is interesting, and it is unclear why the actor chose to only look for these specific products. While various malware families commonly check for the presence of antivirus products, malware authors typically include a more comprehensive list that encompasses a variety of global providers.
After checking for these products, the malware downloads the following files from GitHub:
It should be noted that the padeqav GitHub project is no longer available.
Finally, the malware performs a series of actions on these files that ultimately result in the installation of a Cobalt Strike payload.
Exploitation
In addition to phishing campaigns, the group often couples exploitation attempts with their reconnaissance activities to gain initial access to target networks. To date, we have not observed the group developing, testing or deploying any zero-day exploits. However, we assess that the group is comfortable testing and deploying a wide range of common tools, exploitation kits and proof-of-concept code for N-day exploits.
For example, over the past year, our Advanced Threat Prevention service has detected and blocked attempts by the group to exploit the following types of vulnerabilities:
SAP Solution Manager privilege escalation vulnerability
Pivotal Spring Data Commons remote file read XXE vulnerability
Microsoft Open Management Infrastructure remote code execution vulnerability
Microsoft Exchange Server remote code execution vulnerability
On one occasion, we observed the actor connecting to e-passport and e-visa services associated with a ministry of foreign affairs. Because the server for these services was configured with Atlassian Crowd software, the actor attempted to exploit CVE-2019-11580, uploading a payload named rce.jar. The code included in the payload was similar to the description of code from another analysis of CVE-2019-11580 provided by Anquanke.
Tooling
We assess that the group relies heavily on a mix of command-and–control (C2) frameworks and tools common to the actors’ region to move laterally and maintain persistent access within compromised environments.
C2 Frameworks
From 2024 through early 2025, we observed the group commonly deploying Cobalt Strike payloads. However, over time the group slowly transitioned to VShell as its tool of choice.
VShell is a Go-based C2 framework. The group often configures its web access on 5-digit ephemeral TCP ports using ordered numbers. In November 2025, NVISO published comprehensive research [PDF] on the origins of this tool, its features and its wide-scale use by multiple threat groups and actors.
Within the past year, we assess that the group has also leveraged frameworks like Havoc, SparkRat and Sliver with varying degrees of success.
Web Shells
TGR-STA-1030 has frequently deployed web shells on external-facing web servers as well as on internal web servers to maintain access and enable lateral movement. The three most common web shells used by the group are Behinder, Neo-reGeorg and Godzilla.
Further, we noted during one investigation that the group attempted to obfuscate its Godzilla web shells using code from the Tas9er GitHub project. This project obfuscates code by creating functions and strings with names like Baidu. It also adds explicit messages to governments.
Tunnels
We have observed the group leveraging GO Simple Tunnel (GOST), Fast Reverse Proxy Server (FRPS), and IOX across both their C2 infrastructure and compromised networks to tunnel desired network traffic.
Introducing ShadowGuard
During an investigation, we identified the group using a new Linux kernel rootkit, ShadowGuard. The sample we discovered (SHA-256 hash 7808B1E01EA790548B472026AC783C73A033BB90BBE548BF3006ABFBCB48C52D) is an Extended Berkeley Packet Filter (eBPF) rootkit designed for Linux systems. At this time, we assess that the use of this rootkit is unique to this group.
eBPF backdoors are notoriously difficult to detect because they operate entirely within the highly trusted kernel space. eBPF programs do not appear as separate modules. Instead, they execute inside the kernel's BPF virtual machine, making them inherently stealthy. This allows them to manipulate core system functions and audit logs before security tools or system monitoring applications can see the true data.
This backdoor leverages eBPF technology to provide the following kernel-level stealth capabilities:
Kernel-level concealment: It can conceal process information details directly at the kernel level.
Process hiding (syscall interception): The tool intercepts critical system calls, specifically using custom kill signals (entry and exit points) to identify which processes the attacker wants to hide.
It conceals specified process IDs (PIDs), making them invisible to standard user-space analysis tools like the standard Linux ps aux command
It can hide up to 32 processes simultaneously
File and directory hiding: It features a hard-coded check to specifically conceal directories and files named swsecret.
Allow-listing: The backdoor includes an allow list mechanism where processes placed on the list are deliberately excluded and remain unaffected by the hiding functionality.
When started, the program will automatically check for the following:
Root privileges
eBPF support
Tracepoint support
Example commands once ShadowGuard is started are shown below in Table 1.
Command
Overview
kill -900 1234
-900 = Add target PID (1234) to the allow list
kill -901 1234
-901 = Remove target PID (1234) from the allow list
touch swsecret_config.txt
mkdir swsecret_data
* Note: By default ShadowGuard hides/conceals any directories or files named swsecret. This could be a shortened, internal code name used by the rootkit's developers to tag their own files. Example: “Put all configuration and logs inside a directory named swsecret.”
ls -la files/directories beginning with swsecret should display as a dot . (i.e., it should be hidden)
Table 1. Examples of commands for ShadowGuard.
Infrastructure
Consistent with any advanced actor conducting cyberespionage, this group goes to great lengths to mask and obfuscate the origin of its operations. However, despite all of its best efforts, it is exceptionally hard to overcome the following two challenges:
Network Traffic Inspection: It is widely known that several nations employ methods to censor and filter traffic entering/exiting their respective countries. As such, it is extremely unlikely that foreign cyberespionage groups would willingly route their network traffic through any nation that employs these inspection capabilities.
Network evolution: Maintaining infrastructure for cyberespionage operations is hard. It requires the routine creation of new domains, virtual private servers (VPS) and network tunnels. Studying a group’s infrastructure over time almost always reveals mistakes and errors where tunnels collapse or perhaps identity protection services expire.
Network Structure
We assess that the group applies a multi-tiered infrastructure approach to obfuscate its activities.
Victim-Facing
The group routinely leases and configures its C2 servers on infrastructure owned by a variety of legitimate and commonly known VPS providers. However, unlike most groups that configure their malicious infrastructure on bulletproof providers or in obscure locations, this group prefers to establish its infrastructure in countries that have a strong rule of law.
For example, the group frequently chooses virtual servers in the U.S., UK and Singapore. We assess this preference in locations likely aids the group in three ways:
Infrastructure may appear more legitimate to network defenders
This could enable low-latency connections across the Americas, Europe and Southeast Asia
These locations have separate laws, policies and priorities that govern the operations of their domestic law enforcement and foreign intelligence organizations. Thus, having infrastructure in these locations likely necessitates cross-agency cooperation efforts for their governments to effectively investigate and track the group.
Relays
To connect to the C2 infrastructure, the group leases additional VPS infrastructure that it uses to relay traffic through. These hosts are often configured with SSH on port 22 or a high-numbered ephemeral port. In some cases, we have also observed hosts configured with RDP on port 3389.
Proxies
Over time, the group has leveraged a variety of capabilities to anonymize its connections to the relay infrastructure. In early 2025, we observed the group using infrastructure we associated with DataImpulse, a company that provides residential proxy services. Since then, we have observed the group using the Tor network and other proxy services.
Upstream
In tracking upstream infrastructure, it is important to recognize that the primary goal of an espionage group is to steal data. To accomplish that task, a group has to build a path from the compromised network back to a network it can access. As such, the flow of data upstream typically correlates geographically to the group’s physical location.
As noted above, the act of maintaining all of this infrastructure and its associated connections is quite challenging. On occasion, the group makes mistakes either because it forgets to establish a tunnel or because a tunnel collapses. When this happens, the group connects directly from its upstream infrastructure.
On several occasions, we have observed the group connecting directly to relay and victim-facing infrastructure from IP addresses belonging to Autonomous System (AS) 9808. These IP addresses are owned by an internet service provider in the group’s region.
Domains
We have identified several domains used by the group to facilitate malware C2 communications. Most were registered with the following top-level domains:
me
live
help
tech
Noteworthy domains include:
gouvn[.]me
The group used this domain to target Francophone countries that use gouv to denote government domains. While the actor consistently pointed this domain name to leased victim-facing VPS infrastructure, we noted an anomaly in late 2024. While the domain never pointed to it, the actor appears to have copied an X.509 certificate with the common name gouvn[.]me from a victim-facing VPS to a Tencent server located in the actors’ region. Here it was visible for four days in November 2024.
dog3rj[.]tech
The group used this domain to target European nations. It’s possible that the domain name could be a reference to “DOGE Jr,” which has several meanings in a Western context, such as the U.S. Department of Government Efficiency or the name of a cryptocurrency. This domain was registered using an email address associated with the domain 888910[.]xyz.
zamstats[.]me
The group used this domain to target the Zambian government.
Global Targeting Overview
Over the course of the past year the group has substantially increased its scanning and reconnaissance efforts. This shift follows the group's evolution from phishing emails to exploits for initial access. Most emblematic of this activity, we observed the group scanning infrastructure across 155 countries between November and December 2025, as noted in Figure 2.
Figure 2. Countries targeted by TGR-STA-1030 reconnaissance between November and December 2025.
Given the expansive nature of the activity, some analysts might wrongly assume that the group simply launches broad scans across the entire IPv4 space from 1.1.1[.]1 to 255.255.255[.]255, but that is not the case. Based on our observation, the group focuses its scanning narrowly on government infrastructure and specific targets of interest across each country.
The group’s reconnaissance efforts shed light on its global interests. We have also observed the group's success at compromising several government and critical infrastructure organizations globally. We assess that over the past year, the group compromised at least 70 organizations across 37 countries, as shown in Figure 3. The attackers were able to maintain access to several of the impacted entities for months.
Figure 3. Locations of organizations impacted in 2025.
Impacted organizations include ministries and departments of interior, foreign affairs, finance, trade, economy, immigration, mining, justice and energy.
This group compromised one nation’s parliament and a senior elected official of another. It also compromised national-level telecommunications companies and several national police and counter-terrorism organizations.
While this group might be pursuing espionage objectives, its methods, targets and scale of operations are alarming, with potential long-term consequences for national security and key services.
By closely monitoring the timing of the group’s operations, we have drawn correlations between several of its campaigns and real-world events. These correlations inform assessments as to the group’s potential motivations. The following sections provide additional insights from notable situations by geographic region.
Americas
During the U.S. government shutdown that began in October 2025, the group began to display greater interest in organizations and events occurring across North, Central and South American countries. Over that month, we observed scanning of government infrastructure across Brazil, Canada, Dominican Republic, Guatemala, Honduras, Jamaica, Mexico, Panama and Trinidad and Tobago.
Perhaps the most pronounced reconnaissance occurred on Oct. 31, 2025, when we observed connections to at least 200 IP addresses hosting Government of Honduras infrastructure. The timing of this activity falls just 30 days prior to the national election, in which both candidates signaled openness to restoring diplomatic relations with Taiwan.
In addition to reconnaissance activities, we assess that the group likely compromised government entities across Bolivia, Brazil, Mexico, Panama, and Venezuela, as noted in Figure 4.
Figure 4. Location of impacted entities in the Americas.
Bolivia
We assess that the group likely compromised the network of a Bolivian entity associated with mining. The motivation behind this activity could be associated with interest in rare earth minerals.
We find it noteworthy that the topic of mining rights became a central focus in Bolivia’s recent presidential election. In late July 2025, candidate Jorge Quiroga pledged to scrap multi-billion-dollar mining deals that the Bolivian government had previously signed with two nations.
Brazil
We assess that the group compromised Brazil’s Ministry of Mines and Energy. Brazil is considered to have the second largest supply of rare earth mineral reserves in the world.
According to public reporting, exports of these minerals tripled in the first half of 2025. As Asian companies tighten their global control on these resources, the U.S. has begun looking to Brazil for alternative sourcing.
In October, the U.S. Charge d'Affaires in Brazil held meetings with mining executives in the country. In early November, the U.S. International Development Finance Corporation invested $465 million in Serra Verde (a Brazilian rare earth producer). This has been seen as an effort to reduce reliance on Asia for these key minerals.
Mexico
We assess that the group compromised two of Mexico’s ministries. This activity is very likely associated with international trade agreements.
On Sept. 25, 2025, Mexico News Daily reported on an investigation into Mexico’s latest plans to impose tariffs on certain goods. Coincidentally, malicious network traffic was first seen originating from networks belonging to Mexico’s ministries within 24 hours of the trade probe announcement.
Panama
In December 2025, a report stated that local authorities destroyed a monument, prompting immediate condemnation from some leaders and calls for investigation.
Coincidentally, around the same time, we assess that TGR-STA-1030 likely compromised government infrastructure that may be associated with the investigation.
Venezuela
On Jan. 3, 2026, the U.S. launched Operation Absolute Resolve. This operation resulted in the capture of the Venezuelan president and his wife. In the days that followed, TGR-STA-1030 conducted extensive reconnaissance activities targeting at least 140 government-owned IP addresses.
We further assess that as early as Jan. 4, 2026, the group likely compromised an IP address that geolocates to a Venezolana de Industria Tecnológica facility, as seen in Figure 5. This organization was originally founded as a joint venture between the Venezuelan government and an Asian technology company. The venture enabled the production of computers as an early step toward deepening technology and economic ties between the two regions.
Figure 5. Geolocation data for the compromised IP address.
Europe
Throughout 2025, TGR-STA-1030 increased its focus on European nations. In July 2025, it applied a concerted focus toward Germany, where it initiated connections to over 490 IP addresses hosting government infrastructure.
In August 2025, Czech President Petr Pavel privately met with the Dalai Lama during a trip to India. In the weeks that followed, we observed scanning of Czech government infrastructure, including:
The Army
Police
Parliament
Ministries of Interior, Finance and Foreign Affairs
Separately, in late August, the group applied a concerted focus on European Union infrastructure. We observed the group attempting to connect to over 600 IP addresses hosting *.europa[.]eu domains.
In addition to reconnaissance activities, we assess that the group likely compromised government entities in countries across Cyprus, Czechia, Germany, Greece, Italy, Poland, Portugal and Serbia, as shown in Figure 6. In doing so, the group compromised at least one ministry of finance where it sought to collect intelligence on international development from both the impacted country as well as the European Union.
Figure 6. Location of impacted entities in Europe.
Cyprus
We assess that the group compromised government infrastructure in early 2025. The timing of this activity coincided with efforts by an Asian nation to expand certain economic partnerships across Europe. At the time, Cyprus was also taking preparatory steps toward assuming the presidency of the Council of the European Union at the end of the year, a position that it currently holds.
Greece
We assess that the group likely compromised infrastructure associated with the Syzefxis Project. This project was intended to modernize Greek public sector organizations using high-speed internet services.
Asia and Oceania
While the group performs scanning widely across both continents, TGR-STA-1030 appears to prioritize its reconnaissance efforts against countries in the South China Sea and Gulf of Thailand regions. We routinely observe scanning of government infrastructure across Indonesia, Thailand and Vietnam. For example, in early November 2025, we observed connections to 31 IP addresses hosting Thai government infrastructure.
Additionally, it’s worth noting that the group's reconnaissance efforts often extend beyond connections to web-facing content on ports 80 and 443. In November 2025, we also observed the group attempting to initiate connections to port 22 (SSH) on infrastructure belonging to:
Australia’s Treasury Department
Afghanistan’s Ministry of Finance
Nepal’s Office of the Prime Minister and Council of Ministers
In addition to reconnaissance activities, we assess that the group likely compromised government and critical infrastructure entities in countries including Afghanistan, Bangladesh, India, Indonesia, Japan, Malaysia, Mongolia, Papua New Guinea, Saudi Arabia, Sri Lanka, South Korea, Taiwan, Thailand, Uzbekistan and Vietnam, as shown in Figure 7.
Figure 7. Location of impacted entities in Asia and Oceania.
Indonesia
In March 2024, Indonesia pledged to increase certain counterterrorism coordination efforts. In mid-2025, the group compromised an Indonesian law enforcement entity.
We assess that the group also compromised infrastructure associated with an Indonesian government official. This activity might have been associated with the extraction of natural resources from Papua province. We found that the official was tasked with overseeing development in the province and foreign investment in the mining sector.
The group also compromised an Indonesian airline. The compromised infrastructure geolocates to facilities at Soekarno-Hatta International Airport as shown in Figure 8. The airline had been in talks with a U.S. aerospace manufacturer to purchase new aircraft as part of its strategic growth plans. At the same time, a competing interest was actively promoting aircraft from a manufacturer based in Southeast Asia.
Figure 8. Geolocation data for the compromised IP address.
Malaysia
We assess that the group compromised multiple Malaysian government departments and ministries. Using this access, the group sought to extract immigration and economic intelligence data.
Additionally, we assess that the group compromised a large private financial entity in Malaysia that provides microloans in support of low-income households and small businesses.
Mongolia
The group compromised a Mongolian law enforcement entity on Sept. 15, 2025. Shortly after, Mongolia’s Minister of Justice and Internal Affairs met with a counterpart from an Asian nation. Following the meeting, both countries signaled an intent to expand cooperation to combat transnational crime.
Given the timing, we assess that this activity was likely associated with intelligence gathering in support of the initial meeting and ongoing cooperation discussions.
Taiwan
In early 2025, the group compromised a major supplier in Taiwan's power equipment industry. With this access, we believe the group was able to access business files and directories pertaining to power generation projects across Taiwan. We further assess that in mid-December 2025, the group regained access to this network.
Thailand
We assess that on Nov. 5, 2025, the group compromised a Thai government department where it likely sought economic and international trade intelligence. The timing of this activity overlaps with the government’s effort to expand diplomatic relations with neighboring nations. As such, we assess the activity was likely intelligence gathering in support of the visit and future cooperation discussions.
Africa
It is our observation that when it comes to African nations, the group's focus remains split between military interests and the advancement of economic interests, specifically mining efforts.
We assess that the group likely compromised government and critical infrastructure entities in countries across the Democratic Republic of the Congo, Djibouti, Ethiopia, Namibia, Niger, Nigeria and Zambia, as shown in Figure 9:
Figure 9. Location of impacted entities in Africa.
Democratic Republic of the Congo (DRC)
We assess that in December 2025, the group compromised a government ministry in this country. We found that earlier in the year, an Asian mining firm was responsible for an acid spill that caused significant impacts to a river in neighboring Zambia. In November 2025, a second spill by another Asian company impacted the waterways around Lubumbashi, the second-largest city in the DRC. This event prompted authorities to suspend mining operations for a subsidiary of the Zhejiang Huayou Cobalt Co. Given the timing and the group's unique focus on mining operations, we assess that activity could be related to this mining situation.
Djibouti
Several nations maintain military bases in Djibouti. These bases enable combating piracy on the high seas as well as other regional logistics and defense functions across the Arabian Sea, Persian Gulf and Indian Ocean.
In mid-November, a new Naval Escort Group from one of the nations assumed responsibilities in the region. During its operational debut, the group escorted a Panamanian-registered bulk carrier called the Nasco Gem that carries cargo such as coal and ore. In the context of cyber activity, this could be related to the targeting of mining sectors we observed from TGR-STA-1030.
We assess that in late October 2025, the group gained access to a Djibouti government network. Given the timing of the activity, we believe it might be associated with intelligence collection in support of the naval handover operations.
Zambia
We assess that the group compromised a Zambian government network in 2025. This activity is likely associated with the Sino-Metals Leach Zambia situation.
In February, a dam that held waste from an Asian mining operation collapsed and polluted a major river with cyanide and arsenic. The situation and associated clean-up efforts remain a political point of contention.
Conclusion
TGR-STA-1030 remains an active threat to government and critical infrastructure worldwide. The group primarily targets government ministries and departments for espionage purposes. We assess that it prioritizes efforts against countries that have established or are exploring certain economic partnerships.
Over the past year, this group has compromised government and critical infrastructure organizations across 37 countries. Given the scale of compromise and the significance of the impacted government entities, we are working with industry peers and government partners to raise awareness of the threat and disrupt this activity.
We encourage network defenders and security researchers to leverage the indicators of compromise (IoCs) provided below to investigate and deploy defenses against this group.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Advanced Threat Prevention is designed to defend networks against both commodity threats and targeted threats.
Cortex XDR and XSIAM help to protect against the threats described in this blog, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, designed to prevent both known and unknown malware from causing harm to endpoints.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
The cybersecurity landscape of 2026 is stronger than ever with countless security resources and protective tools. Despite robust defenses at anyone’s fingertips, common phishing scams and spoofing attacks remain an ongoing issue. Unfortunately, the reality is that these attacks aren’t disappearing; they’re simply evolving.
While we cannot surely predict the future statistics of these types of attacks, data from the past five years showcases similar trends, despite advances in security technologies. In 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) reported that phishing emails are associated with more than 90% of successful cyberattacks. Even though overall numbers of phishing attacks have slightly decreased, their effectiveness in terms of monetary assets stolen has increased [PDF]. But why is this the case? Why are these tactics still effective even with elevated defenses?
The Psychology of Phishing
Phishing is a multifaceted cybercrime that has evolved extensively. Attackers are constantly advancing their techniques with any means available, resulting in more targeted and stealthier intrusions. There is no solid indicator on what ensures that a phishing attack will be successful. However, a variety of tactics all revolve around the same common avenue: the human element.
In her Threat Vector feature, Palo Alto Networks Consultant Sama Manchanda details how attackers use psychological theories to ensure maximum effectiveness when targeting their potential victims. There are three main stages:
The Bait: Attackers first research victims to discover exactly what will attract them
The Hook: They deliver attractive information designed to grab the victim’s attention
The Catch: Once the victim engages by performing an action (e.g., clicking a link or entering credentials), the compromise is initiated
These stages provide the blueprint of how attackers exploit human emotions in order to bypass defenses. The most effective attacks also employ social engineering tactics. Unit 42 has observed three prevalent techniques:
Urgency and Fear: Attackers combine scare tactics such as identity theft, legal action or account suspension with extreme urgency to panic victims into clicking malicious links or revealing sensitive data without fully considering the consequences.
Authority and Trust: Attackers impersonate legitimate figures, such as company executives, IT staff or university administrators to trick the victim into trusting them. These tactics are often assisted by the use of AI deepfakes.
Distraction: Attackers take advantage of individuals’ desensitized attitudes towards routine actions such as clicking a link or scanning a QR code. When individuals are in a rush or in between tasks, attackers use these fleeting moments to strike.
These tactics demonstrate how attackers have mastered the psychological triggers required to manipulate users into surrendering assets. They also serve as a stark reminder that technology alone cannot prevent these attacks. True security requires a shift in personal mindset and proactive commitment to digital vigilance.
How Cognitive Bias Opens the Door
Outside of an attacker’s toolkit, certain inherent human traits can actually increase a person’s vulnerability. In her Threat Vector feature, Lisa Plaggemier, Executive Director of the National Cyber Security Alliance, discusses how overconfidence and the “illusion of control” create dangerous blind spots.
After surveying individuals across the globe, Plaggemier discovered an alarming trend: a vast majority of individuals rated their phishing detection skills as nearly perfect. This universal tendency to overestimate one's expertise is exactly what attackers take advantage of. When confidence exceeds actual competence, the risk of a breach increases exponentially.
Plaggemier’s studies highlight how individuals prioritize their own intuition instead of trusting in proven security protocols. By overvaluing personal habits, users internally diminish the worth of reliable technical controls. This confidence poses a significant risk because it can override a person’s intellectual knowledge by prompting them to ignore logic in favor of self-validation. It furthers the "contrarian mindset” where humans tend to reject educational messages that contradict their belief in their own abilities. Instead of learning or adapting to real-time situations, they adopt a defensive stance. This reaction creates a dangerous cycle that reinforces bad habits and leaves room for compromises.
The Future of Phishing
The advancement of AI has permanently altered the phishing landscape by erasing the misspelled words and awkward phrasing that once gave attackers away. This combined with the addition of deepfakes and voice mimicry has made it nearly impossible to distinguish a friend from a fraud through traditional means. As a result, these advancements raise the critical question on how individuals can truly stay protected.
The hard truth is that no one is ever 100% secure. The most persistent attackers will constantly find ways to innovate and adjust. Factors such as cognitive bias and the “illusion of control” tell us that we can accurately identify phishing attempts, but it’s clear that going strictly off intuition is a flawed approach. To survive the AI shift, we must stop relying on instinct and start relying on consistent efforts such as:
Maintain a zero-trust mindset: Assume every unsolicited request requires verification
Stay educated: Keep up with the latest phishing trends and AI-driven tactics
Recognize psychological triggers: Be wary of messages designed to create fear or extreme urgency
Practice cyber hygiene: Refrain from clicking unknown links and keep credentials secure
Unit 42’s Biggest Piece of Advice: Pause and Identify the Facts
No matter how convincing a message appears or how urgent a request feels, stop and truly assess the situation. Taking a moment to verify the source before taking any sort of action can stop an attack in its tracks.
Security is a continuous journey rather than a final destination. By choosing to analyze the information given rather than succumbing to an attacker’s strategies, you transform yourself from a potential victim into an active defender of your digital life.
This report details a vulnerability we found in the Iconics Suite, tracked as CVE-2025-0921 with a Medium CVSS score of 6.5. Iconics Suite is the name of a supervisory control and data acquisition (SCADA) system. This system is used for controlling and monitoring industrial processes in different industries including automotive, energy and manufacturing.
In early 2024 we conducted an assessment of Iconics Suite and identified five vulnerabilities. These were for Microsoft Windows versions 10.97.2 and earlier. We published on related vulnerabilities in a previous post. This article concentrates on the analysis of CVE-2025-0921.
Successful exploitation of this vulnerability could create a denial-of-service (DoS) condition on the affected system. Additional details are outlined in Table 1.
Execution with unnecessary privileges vulnerability in multiple services of Mitsubishi Electric Iconics Digital Solutions GENESIS64.
6.5 - Medium
Table 1. Details on CVE-2025-0921.
Attackers could misuse privileged file system operations in a machine running a vulnerable version of Iconics Suite to elevate privileges to corrupt critical binaries, compromising the integrity and availability of the system. We coordinated with the Iconics security team, which released an advisory detailing measures to address the issue. If applied, the workaround removes all our reported vulnerabilities.
Palo Alto Networks customers are better protected from the threats discussed in this post with the following products and services:
In a prior article, we reported on five vulnerabilities that we had discovered within Iconics Suite in versions 10.97.3 and earlier. These vulnerabilities could allow attackers to escalate privileges and ultimately render vulnerable systems inoperable. Related to this investigation, we found one further issue, which we've now documented in this article.
Understanding the Vulnerability Context
Processes running with elevated privileges represent a significant security risk, particularly when they interact with sensitive files and directories without proper access controls. This is known as a privileged file system operations vulnerability.
This type of vulnerability can create opportunities for attackers to exploit file system operations such as creating, overwriting, copying, moving or deleting files. These actions can have various security consequences, ranging from DoS and information leakage to complete system compromise.
The CVE-2025-0921 vulnerability allows privileged file system operations in Iconics Suite that attackers can misuse to corrupt critical system binaries and disrupt the availability and integrity of the SCADA system. This vulnerability can be exploited in various scenarios. Our demonstration leverages a previously identified vulnerability CVE-2024-7587 that creates an optimal attack environment by granting excessive file permissions.
To demonstrate the full impact of CVE-2025-0921, we use a vulnerability chain that includes CVE-2024-7587 (detailed in previous research). CVE-2024-7587 affects the GenBroker32 installer, which grants excessive permissions to the C:\ProgramData\ICONICS directory, allowing any user on the system to modify critical configuration files.
In Iconics Suite, we found this privileged file system operation vulnerability in the Pager Agent, a component of the AlarmWorX64 MMX feature set. AlarmWorX64 MMX is the alarm management system that monitors industrial processes and automatically triggers alerts when problems occur.
The Pager Agent enables administrators to establish customized triggers and activity alerts in AlarmWorX64 MMX. These alerts are managed through PagerCfg.exe, the configuration utility for the Pager Agent. This utility allows administrators to configure the alerts for delivery via a wide variety of pager services and protocols such as SMS, GSM and TAP.
Figure 1 shows the Pager Agent configuration window displayed when running PagerCfg.exe on a Windows host.
Figure 1. Pager Agent configuration window when running PagerCfg.exe.
To configure SMS alerts, administrators can use the SMS Unicode button shown in Figure 1 to open the SMS configuration window. Figure 2 shows the parameters in the SMS Unicode Configuration window.
Figure 2. SMS Unicode Configuration window.
This SMS Unicode Configuration window enables system administrators to select a device, baud rate and recipients, and to compose the alert message body. This configuration window also provides the option to send a test SMS.
In addition to SMS configuration, the PagerCfg.exe enables administrators to define a path for an SMSLogFile, as shown in Figure 2, where logging information will be written. Once an administrator defines the SMSLogFile path, the application will write every log for each SMS operation into this file.
The Critical Configuration File Vulnerability
After an administrator configures the Pager Agent using PagerCfg.exe, the path for the SMSLogFile is saved in the C:\ProgramData\ICONICS\IcoSetup64.ini configuration file. In a normal security environment, this configuration file would be protected from modification by unprivileged users. However, when GenBroker32 is installed on the system, CVE-2024-7587 comes into play.
GenBroker32 is a legacy communications utility included in the Iconics software suite that helps older industrial systems connect to newer Iconics software by translating between different communication protocols. The vulnerability in GenBroker32's installer (CVE-2024-7587) grants full read and write access to the C:\ProgramData\ICONICS directory for every user on the system, making the IcoSetup64.ini configuration file writable by any local user.
Figure 3 shows the permissions of GraphWorX64, a central HMI/SCADA visualization component of the Iconics Suite, for C:\ProgramData\ICONICS that the GenBroker32 installer had modified.
Figure 3. Permissions of GraphWorX64.
Exploiting the Vulnerability
In a scenario where an attacker gains non-administrative access to a system with GenBroker32 installed, the attacker could manipulate any information contained within the configuration file. This is especially true of the SMSLogFile path that controls where the application logs SMS activity.
On a system with GenBroker32 installed, an attacker could perform the following steps to exploit CVE-2025-0921 (leveraging the excessive permissions from CVE-2024-7587) to perform a DoS attack.
Step 1
Logged in as a non-administrative user, an attacker can discover the SMSLogFile path by inspecting the IcoSetup64.ini file located in C:\ProgramData\ICONICS. The path for the SMSLogFile is C:\users\iconics_user\AppData\Local\Temp\logs\log.txt as shown in Figure 4.
Figure 4. SMSLogFile path highlighted in the IcoSetup64.ini configuration file.
Step 2
The attacker creates a specially crafted symbolic link (called symlinks) from the SMSLogFile location to the target binary. The attacker does not require administrator privileges to create this symbolic link. In our security assessment, we selected cng.sys as the target binary. Subsequently, PagerCfg.exe writes or overwrites the contents of this binary, and as a consequence corrupts the target binary.
The cng.sys driver is used for Microsoft Cryptography API: Next Generation (CNG). CNG provides cryptographic services in Windows system components. The cng.sys driver usually resides in the C:\Windows\System32\drivers directory. However, if cng.sys is present in its parent directory C:\Windows\System32, Windows might attempt to load the driver file from C:\Windows\System32 instead of C:\Windows\System32\drivers.
If an attacker successfully creates an invalid driver or corrupts a valid driver at C:\Windows\System32\cng.sys, the operating system would fail to boot. This can be achieved by combining Object Manager symbolic links with NTFS mount points to create file symbolic links without administrator privileges.
Step 3
The attacker would then wait for an administrator to send a test message through the SMS Unicode Configuration window or for AlarmWorx MMX to automatically trigger an alert.
Figure 5 shows an example of the SMS Unicode Configuration parameters we used during our security assessment, including the SMSLogFile path.
Figure 5. SMS Unicode Configuration window.
When an SMS is sent, this configuration directs its logging information to follow the symbolic link from C:\ProgramData\ICONICS\LogFiles\log.txt to C:\Windows\System32\cng.sys, effectively redirecting the logging data into C:\Windows\System32\cng.sys.
The altered content of cng.sys would now contain the SMS information log data instead of the expected binary. We verified this by inspecting C:\Windows\System32\cng.sys using CFF Explorer as shown in Figure 6.
Figure 6. Hex dump of the newly altered cng.sys file created by the exploit.
Step 4
Upon rebooting the machine, the operating system would then attempt to load C:\Windows\System32\cng.sys. However, since the newly altered file is not a valid driver but a log file, the loading process would fail. This failure would cause the operating system to become stuck in failed repair mode, as shown in Figure 7.
Figure 7. Endless Windows boot loop caused by the corrupted driver.
To summarize this DoS attack method:
While logged in as a local user without administrator privileges, the attacker would first identify the SMSLogFile path previously set by the administrator in the IcoSetup64.ini file.
Then, by creating a symbolic link, the attacker would corrupt a critical binary such as the cng.sys driver.
The attacker would then wait for the administrator to trigger an SMS, redirecting logging information to the cng.sys file, which would result in a corrupted version of the cng.sys driver.
Upon reboot, the operating system would unsuccessfully attempt to load the corrupted driver. This would result in a failed boot, leaving the machine in repair mode, causing a DoS in a critical OT engineering workstation.
Even if the vulnerability CVE-2024-7587 described in our previous threat research article were not present, attackers could still exploit CVE-2025-0921 if the log file became writable by unprivileged users through other means. For example, this could include misconfigurations, alternative vulnerabilities or social engineering attacks that modify file permissions.
Conclusion
People often overlook the possibility of attackers misusing privileged file system operations, regardless of the danger they can pose to systems running these processes. This is especially pertinent when these vulnerabilities are found in OT environments.
The discovery of vulnerabilities within the Iconics Suite for Microsoft Windows versions 10.97.2 and earlier highlights the importance of robust security measures. Proactive measures can help mitigate these vulnerabilities and safeguard against potential exploitation.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Palo Alto Networks OT Device Security helps organizations gain visibility across industrial environments to assess potential exposure, including systems running SCADA applications such as Iconics Suite. When combined with Next-Generation Firewalls (NGFW), customers can apply segmentation and access controls that reduce the risk associated with local exploitation of vulnerabilities such as CVE-2025-0921.
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: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
The 2026 Winter Games in Milano Cortina extend beyond sport. Tensions between the Russian Federation and the International Olympic Committee (IOC), stemming from disputes over compliance and governance, lie within a broader geopolitical context. In this environment, the Games may face increased cyber risk, as major international events increasingly intersect with geopolitical competition. The exclusion of Russia from a global stage of historic national importance removes a critical geopolitical guardrail protecting the 2026 Winter Olympic Games.
From Olympic Sanctions to Political Exclusion
Russia’s current isolation from the Olympic movement is driven less by earlier doping-related disputes than by the geopolitical consequences of its 2022 invasion of Ukraine. While past sanctions reflected regulatory enforcement, measures imposed since 2023 sit within a broader political and security context.
Russia’s indefinite suspension followed the invasion of Ukraine just days after the Beijing 2022 Winter Games, which the International Olympic Committee (IOC) condemned as a violation of the Olympic Truce. This was reinforced by Russia’s incorporation of regional sports councils in occupied Ukrainian territories — an action the IOC stated violated the territorial integrity of Ukraine’s National Olympic Committee.
This shift from regulatory sanctions to political exclusion helps explain the current dynamic. In this context, Russia increasingly appears to view the IOC not solely as a sports regulator, but as a political actor within a wider geopolitical framework — an interpretation that carries implications for the security environment surrounding major international events such as the 2026 Winter Games.
In 2007, Vladimir Putin personally led Russia's successful final presentation in English and French before the International Olympic Committee in Guatemala City. That resulted in Russia winning the right to host the 2014 Winter Olympic Games. That victory and the subsequent 2014 Sochi Winter Olympics were watershed moments for Russia, intended to highlight its resurgence on the global stage. It was meant to project an image of a capable, re-emerging global power with the logistical and political authority to deliver world-class events.
Dating back as far as the 1952 Helsinki Olympic Games, the Russian state (then the Soviet Union) viewed the Games as a diplomatic tool to illustrate the merits of Soviet institutions and communist ideology. Medal counts have long been a way of quantifying that dominance and legitimization, and the Soviet Union still holds the second highest overall medal count of all time. This philosophical strategy remains unchanged today.
Moving Up The Escalation Ladder
Already in 2014, Russia was having challenges with the IOC related to a sports doping scandal that culminated in a ban from the 2018 Winter Olympics in South Korea. Tracing the history of their retaliation against this ban and the additional perceived humiliation and exclusion related to the invasion of Ukraine, we see a clear escalating pattern.
Exposing Data “Everyone Is Doping” (2016 Rio Olympics)
The World Anti-Doping Agency (WADA) was breached in 2016 by the threat actor group Fighting Ursa (aka APT28, Fancy Bear, Strontium, Forest Blizzard). Fighting Ursa is attributed to Russia’s Main Intelligence Directorate (GRU). The group leaked athlete data to discredit the regulators who investigated Russia.
False Flag Tactics Targeting Key Entities (2018 Pyeongchang Olympics)
Although the games were subsequently postponed due to the coronavirus pandemic, the UK Foreign, Commonwealth & Development Office claimed GRU was conducting cyber operations and reconnaissance in preparation for the games.
AI-Enabled Deception and Defaming (2024 Paris Olympics)
Ahead of the 2024 Paris Games, Russian-linked threat actors (Storm-1679 and Storm-1099) used AI-generated disinformation [PDF] for information operations, creating a fake Netflix documentary, narrated by a Tom Cruise voicealike, to manufacture safety threats and suppress attendance. Separately, the actor Storm-1679 produced deceptive videos over the past year, trying to deter spectators from attending the Games and to defame the IOC. The group did this by falsely suggesting that trusted sources confirm expected violence.
The Outlook: A Changed Strategic Calculus
Russia’s exclusion from medal competition at the 2026 Winter Games changes the strategic context surrounding Milan Cortina. With no national team participating, traditional deterrents tied to reputational or competitive consequences are reduced.
Russian officials' repeated public comments illustrate they no longer view the IOC as a neutral sporting body, but as operating within a broader political environment. Given the history of Russian-linked cyber activity targeting past Olympic Games, the risk of state-aligned cyber operations cannot be discounted, potentially drawing on previously observed disruptive or influence-based tactics.
The exclusion of Russia from the Milan Cortina 2026 Winter Olympics carries significant symbolic weight, distinct from their absence at the Paris 2024 Summer Olympics. Because marquee events like ice hockey and figure skating are so deeply embedded in Russian national pride, their absence is felt more profoundly than exclusion from Summer sports. Given the particular prominence of winter sports in Russia's national sporting identity, this banishment from a flagship event may intensify perceptions and influence responses concerning the upcoming Winter Games.
Considering the aforementioned, we’re looking at the potential threat picture as a combination of separate or complementary attacks:
Kinetic Cyber Effects on Critical Infrastructure: The possible deployment of destructive malware targeting operational technology essential to venue operations to affect configurations and paralyze infrastructure. Specific targets could include the power grid in the Dolomites, snow-making equipment, and scoring networks; systems where a compromise would cause immediate physical disruption and event interruption or cancellation.
Exploiting the V2X “Smart Road” Attack Surface: The digitization of Smart Road SS51 Alemagna toward Cortina, creates a large, novel vulnerability through its vehicle-to-infrastructure (V2I). The road relies on smart poles with cameras, fiber optics and internet-of-things (IoT) sensors, creating a potential attack surface where threat actors could inject false telemetry or hijack Variable message Signs (VMS) weaponizing traffic patterns to cause gridlock or endanger drivers in transit.
AI Amplified Hybrid Threats and Deepfakes: Generative AI will likely serve as a force multiplier for physical or cyber attacks, which could amplify confusion into panic. In a hybrid scenario, threat actors could combine a cyber-based disruption with the release of high-fidelity deepfake audio or video depicting a catastrophic event. This technique would flood social media and alert channels with disinformation transforming a minor technical outage into a public safety crisis.
Geopolitical Information Warfare (IO): Threat actors are likely to exploit public interest in the Olympics to disseminate narratives and disinformation. This could include creating websites that imitate legitimate media sources, with the goal of targeting audiences and disparaging the IOC and Western nations.
Strategic Hack-and-Leak Operations: High-profile attendees, IOC officials and anti-doping agencies face a high risk of “weaponized transparency”, stealing data for political leverage. Through targeting phishing and social engineering, threat actors will focus on private emails and therapeutic use exemptions intended to manufacture scandal, embarrass host organizers and undermine the credibility of the Games.
It’s time to accept that for the Kremlin, disrupting these games is an acceptable measurable way to reclaim “Great Power” status they feel was unfairly taken. For cybersecurity professionals, the threat model has shifted significantly from espionage to disruption, necessitating a need to focus on resilience over protection of physical infrastructure.
For those defenders operating within the Games’ digital perimeter, the priority should be zero-trust visibility. Security teams must enforce anomaly detection to flag irregular behavior in IoT devices and apply strict telemetry verification to prevent spoofing. Critically, infrastructure must be micro-segmented ensuring a compromised edge device cannot move laterally to critical control systems.
Finally, organizations should implement content provenance measures to verify legitimate communications against AI-generated content, while maintaining heightened vigilance surrounding the probable surge in social engineering and event-related phishing campaigns.
At certain moments in a career, you get the rare opportunity to look back and say, this work mattered. Not because of an individual accomplishment, but because it contributed to something larger — something that changed how an industry thinks and operates. The Cyber Threat Alliance (CTA) is one of those efforts.
When the CTA was first conceived in 2014, the cybersecurity industry looked very different than how it does today. Threat intelligence was widely viewed as a competitive advantage, tightly guarded and rarely shared beyond company walls. Collaboration between major security vendors — especially direct competitors — was almost unheard of. The prevailing mindset was simple: information was power, and power was proprietary.
Against that backdrop, a bold idea emerged: What if competitors worked together for the collective defense of customers and the broader digital ecosystem? What if sharing high-fidelity threat intelligence could raise the cost for adversaries and make everyone safer? As Mark McLaughlin, then CEO of Palo Alto Networks, famously put it at the time, the importance of the future CTA was clear: “Don’t let this fail.”
With that charge, four industry leaders — Palo Alto Networks, Fortinet, McAfee (Intel Security) and Symantec — came together on a handshake agreement to prove that collaboration at scale was not only possible, but necessary. It was, by any measure, a radical idea. Yet those early conversations laid the foundation for what would become the Cyber Threat Alliance.
The Architecture of Trust: Turning Vision into Reality
Turning that vision into reality required more than shared intent. A small working group representing each founding company was tasked with answering hard questions: what the CTA should be, what it should not be and how it could operate independently while earning trust across the industry. With guidance from experts familiar with the ISAC and ISAO landscape, the group worked through governance models, legal frameworks and operational structures. This involved reading more bylaws and legal documents than anyone ever hoped to encounter, but it was essential work. The CTA needed to be built deliberately, with integrity and clarity of purpose.
As the organization took shape, strong leadership became critical. That need was met when Michael Daniel, fresh from serving as Cybersecurity Coordinator for President Obama, stepped in to lead the CTA. His experience, credibility and ability to navigate both policy and industry realities helped propel the organization forward during its formative years.
Fast forward to 2026. As the CTA marks its ninth anniversary, the mission that sparked its creation remains relevant and urgent. The CTA has grown its influence beyond data sharing.
The CTA stands in a unique position to provide oversight and technical influence as a global leader in cybersecurity policy by representing the member companies in one place. With the expanding membership that spans across the globe, the CTA is now an essential piece of global cybersecurity infrastructure. Adversaries continue to evolve, borders remain irrelevant to cyber threats and no single organization can defend alone. What has changed is our proof point: collaboration works.
Reflecting on Nine Years and the Road Ahead
For those of us who have had the privilege of being involved since the earliest days, it has been remarkable to watch a bold idea turn into a trusted global institution. What began as a handful of competitors agreeing to try something different has grown into an organization that meaningfully influences how the industry shares intelligence, engages on policy and works together to protect customers worldwide.
Being part of that journey — helping shape the foundation, watching it mature and continuing to support its growth — has been one of the most professionally rewarding experiences of my career.
The CTA’s success is not defined solely by years or membership numbers, but by the collective commitment of its members to act in the interest of the broader ecosystem. Every shared indicator, every technical contribution and every policy engagement strengthens not just individual companies, but the security of communities across the globe.
As we look ahead, the call to action is simple: stay engaged, stay committed and continue to collaborate. Whether through sharing intelligence, contributing technical expertise or helping shape global cybersecurity policy, each member plays a role in ensuring the CTA remains a trusted and effective force against today’s most pressing cyber threats.
The work is far from done. Together, we are better positioned than ever to meet what comes next.
Kathi Whitbey is the Lead Principal Program Manager for Unit 42 at Palo Alto Networks, where she has spent more than a decade driving strategic programs and initiatives. She played a pivotal role in the formation and incorporation of the Cyber Threat Alliance (CTA), including leading early efforts to design and operationalize the CTA Platform for secure intelligence sharing among member companies.Deeply committed to the mission of Unit 42,
Kathi is a strong advocate for the team’s work and a dedicated mentor to emerging professionals in cybersecurity and risk management. Her career includes leadership roles in software development management and technical training across multiple U.S. government organizations, including the Department of State, where she traveled globally to deliver training on custom software applications. In addition to her professional work, Kathi has served as a volunteer Emergency Medical Technician, including a 12-month deployment supporting the U.S. Navy at Camp Lemonnier in Djibouti, Africa. She holds a Master’s degree in Information Systems and brings together technical expertise, operational leadership and a deep commitment to service and collaboration.
Imagine visiting a webpage that looks perfectly safe. It has no malicious code, no suspicious links. Yet, within seconds, it transforms into a personalized phishing page.
This isn't merely an illusion. It's the next frontier of web attacks where attackers use generative AI (GenAI) to build a threat that’s loaded after the victim has already visited a seemingly innocuous webpage.
In other words, this article demonstrates a novel attack technique where a seemingly benign webpage uses client-side API calls to trusted large language model (LLM) services for generating malicious JavaScript dynamically in real time. Attackers could use carefully engineered prompts to bypass AI safety guardrails, tricking the LLM into returning malicious code snippets. These snippets are returned via the LLM service API, then assembled and executed in the victim's browser at runtime, resulting in a fully functional phishing page.
This AI-augmented runtime assembly technique is designed to be evasive:
The code for the phishing page is polymorphic, so there’s a unique, syntactically different variant for each visit
The malicious content is delivered from a trusted LLM domain, bypassing network analysis
It is assembled and executed at runtime
The most effective defense against this new class of threat is runtime behavioral analysis that can detect and block malicious activity at the point of execution, directly within the browser.
Palo Alto Networks customers are better protected through the following products and services:
Our previous research shows how attackers can effectively use LLMs to obfuscate their malicious JavaScript samples offline. Reports from other sources have documented campaigns that leverage LLMs during runtime execution on compromised machines to tailor attacks (e.g., LLM-powered malware and ransomware).
Anthropic researchers have also published reports indicating that LLMs have aided cybercriminals and played a role in AI-orchestrated cyberespionage campaigns. Motivated by these recent discoveries, we researched how threat actors could leverage LLMs to generate, assemble and execute phishing attack payloads within a webpage at runtime, making it challenging to detect with network analysis. Below we outline our proof of concept (POC) for this attack scenario and offer steps to help mitigate the impact of this potential attack.
Attack Model For Our PoC
The attack scenario begins with a seemingly benign page. Once loaded in the victim's browser, the initial webpage makes requests for client-side JavaScript to popular and trusted LLM clients (e.g., DeepSeek and Google Gemini, though the PoC could be effective across a number of models.).
Attackers can then trick the LLM into returning malicious JavaScript snippets using carefully engineered prompts that circumvent safety guardrails. These snippets are then assembled and executed in the browser's runtime to render a fully functional phishing page. This leaves behind no static, detectable payload.
Figure 1 shows how we developed our PoC to leverage LLMs to enhance existing attacks and bypass defenses. The first two steps involve initial preparation, while the final step details the generation and execution of phishing code within the browser at runtime.
Figure 1. Workflow of the PoC. The first two steps are initial preparation, and the third is an example of generating malicious content to be rendered in the browser.
Step 1: Select a Malicious or Phishing Webpage
The attacker’s first step would be to select a webpage from an active phishing or malicious campaign to use as a model for the type of malicious code that would perform the desired function. From there, they can create JavaScript code snippets that will be generated in real-time to dynamically render the final page displayed to the user.
Step 2: Translate Malicious JavaScript Code Into LLM Prompts
The attacker’s next step would be to craft prompts describing the JavaScript code's functionality to the LLM in plain text. They could iteratively refine prompts, generating malicious code that bypasses existing LLM guardrails. These generated snippets could differ structurally and syntactically, allowing attackers to create polymorphic code with the same functionality.
Step 3: Generate and Execute Malicious Scripts at Runtime
From there, attackers could embed these engineered prompts inside a webpage, which would load on the victim's browser. The webpage would then use the prompt to request a popular, legitimate LLM API endpoint to generate malicious code snippets. These snippets could then be transmitted over popular, trusted domains to bypass network analysis. Subsequently, these generated scripts could be assembled and executed to render malicious code or phishing content.
How This Attack Technique Helps with Evasion
This technique builds upon existing evasive runtime assembly behaviors that we often observe on phishing and malware delivery URLs. For example, 36% of malicious webpages we detect daily exhibit runtime assembly behavior, such as executing constructed child scripts with an eval function (e.g., retrieved, decoded or assembled payloads). Leveraging LLMs during runtime on a webpage gives attackers the following benefits:
Evading network analysis: The malicious code generated by an LLM could be transferred over the network from a trusted domain, as access to domains of popular LLM API endpoints is often allowed from the client side.
Increasing the diversity of malicious scriptswith each visit: An LLM can generate new variants of phishing code, leading to higher polymorphism. This can make detection more challenging.
Using runtime assembly and executing JavaScript codeto complicate detection: Assembling and executing these code snippets during runtime enables more tailored phishing campaigns, such as selecting a target brand based on the victim's location or email address.
Obfuscating code in plain text: Translating code into text for subsequent concealment within a webpage can be viewed as a form of obfuscation. Attackers commonly employ various conventional techniques (e.g., encoding, encryption and code fragmenting) to visually conceal malicious code and evade detection. While advanced analyses often identify conventional obfuscation methods by evaluating expressions, it will be more challenging for defenders to evaluate text as executable code without subjecting each snippet to an LLM.
PoC Example
In researching the PoC we were able to demonstrate how this augmentation could be applied to a real-world phishing campaign, illustrating its ability to enhance evasion techniques through the steps we outline above. A brief overview of this PoC is provided below.
Step 1: Selecting a Malicious/phishing Webpage
For our PoC, we replicated a webpage from an advanced real-world phishing campaign known as LogoKit. The original phishing attack uses a static JavaScript payload to transform a benign-looking web form into a convincing phishing lure. This script performs two key functions: personalizing the page based on the victim’s email in the address bar and exfiltrating captured credentials to an attacker's web server.
Step 2: Translating Malicious JavaScript Code Into LLM prompts
Our PoC uses a popular LLM service, accessible via a chat API query from within the browser's JavaScript. To mitigate potential misuse by attackers, we are not disclosing the name of this specific API. We used this LLM API to dynamically generate the code necessary for credential harvesting and impersonate target webpages. Because the malicious payload is generated dynamically in the browser, the initial page transmitted over the network is benign, allowing it to inherently bypass network-based security detectors.
The attack's success hinged on careful prompt engineering to bypass the LLM's built-in safeguards. We found simple rephrasing was remarkably effective.
For instance, a request for a generic $AJAX POST function was permitted (shown in Figure 2), while a direct request for "code to exfiltrate credentials" was blocked. Furthermore, indicators of compromise (IoCs) (e.g., Base64-encoded exfiltration URLs) could also be hidden within the prompt itself to keep the initial page clean.
Figure 2. Example of prompt engineering to bypass LLM guardrails and generate JavaScript code for phishing content.
The non-deterministic output of the model provided a high degree of polymorphism, with each query returning a syntactically unique yet functionally identical variant of the malicious code. For example, Figure 3 shows differences in code snippets highlighted in red. This constant mutation makes detection more difficult.
Of note, LLM-generated code can include hallucinations but we mitigated this through prompt refinement and increased specificity, effectively reducing syntax errors. As a result, the final, highly specific prompt successfully generated functional code in most instances.
Step 3: Executing Malicious Scripts at Runtime
The generated script was assembled and executed at runtime on the webpage to render the phishing content. This process successfully constructed a functional, brand-impersonating phishing page, validating the attack's viability (shown in Figure 4). The successful execution of the generated code, which rendered the phishing page without error, confirmed the efficacy of our PoC.
Figure 4. Example of a phishing page rendered by assembling dynamically generated JavaScript on runtime in-browser.
Generalizing the Threat and Expanding the Attack Surface
Alternate Methods to Request LLM API
Our attack model, demonstrated through a PoC, could be implemented in various ways. However, each methodology described in the PoC speaks to how an attacker connects to LLM APIs for transferring malicious code as snippets that are executed in the browser at runtime.
As shown in our PoC, attackers could bypass security measures by directly connecting to a well-known LLM service API endpoint from a browser to execute code-generation prompts. Alternatively, they might use a backend proxy server on trusted domains or content delivery networks (CDNs) to connect to the LLM service for prompt execution. A further tactic could involve connecting to this backend proxy server via non-HTTP connections such as WebSockets, a method we have previously reported in phishing campaigns.
Other Abuses of Trusted Domains
Attackers have abused the trust of legitimate domains to circumvent detections in the past, as seen in instances like EtherHiding. In EtherHiding, attackers concealed malicious payloads on public blockchains associated with reputable and trusted smart contract platforms.
The attack detailed in this article uses a combination of diverse, LLM-generated malicious code snippets and the transmission of this malicious code through a trusted domain, to evade detection.
Translation of Malicious Code Into Text Prompts for More Attacks
This article focuses on the conversion of malicious JavaScript code into a text prompt to facilitate the rendering of a phishing webpage. This methodology presents a potential vector for malicious actors to generate diverse forms of hostile code. For example, they could develop malware or establish a command-and-control (C2) channel on a compromised machine that generates and transmits malicious code from trusted domains associated with popular LLMs.
The attack model presented here exemplifies runtime assembly behaviors, where malicious webpages are dynamically constructed within a browser. Prior research has also documented different variants of runtime assembly for crafting phishing pages or malware delivery. For example, this article mentions a technique where an attacker breaks down malicious code into smaller components, subsequently reassembling them for execution at runtime within the browser (termed by SquareX as last mile reassembling attack). Various reports describe attackers using HTML smuggling techniques to deliver malware.
The attack model outlined in this post goes further, as it involves the runtime generation of novel script variants that are later assembled and executed, posing a significantly elevated challenge to detection.
Recommendations for Defenders
The dynamic nature of this attack in combination with runtime assembly in the browser makes it a formidable defense challenge. This attack model creates a unique variant for every victim. Each malicious payload is dynamically generated and unique, transmitted over a trusted domain.
This scenario signals a critical shift in the security landscape. Detection of these attacks (while possible through enhanced browser-based crawlers) requires runtime behavioral analysis within the browser.
Defenders should also restrict the use of unsanctioned LLM services at workplaces. While this is not a complete solution, it can serve as an important preventative measure.
Finally, our work highlights the need for more robust safety guardrails in LLM platforms, as we demonstrated how careful prompt engineering can circumvent existing protections and enable malicious use.
Conclusion
This article demonstrates a novel AI-augmented approach where a malicious webpage uses LLM services to dynamically generate numerous variants of malicious code in real-time within the browser. To combat this, the most effective strategy is runtime behavioral analysis at the point of execution through in-browser protection and by running offline analysis with browser-based sandboxes that render the final webpage.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Prisma AIRS customers can secure their in-house built GenAI applications against inputs that attempt to circumvent guardrails.
Customers using Advanced URL Filtering and Prisma Browser (with Advanced Web Protection) are better protected against various runtime assembly attacks.
Prisma Browser customers with Advanced Web Protection are protected against Runtime Re-assembly attacks from the first attempt, or "patient zero" hit, because the defense uses runtime behavioral analysis directly within the browser to detect and block malicious activity at the point of execution.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
We discovered an aspect of Azure’s Private Endpoint architecture that could expose Azure resources to denial of service (DoS) attacks. In this article, we explore how both intentional and inadvertent acts could result in limited access to Azure resources through the Azure Private Link mechanism. We uncovered this issue while investigating irregular behavior in Azure test environments.
The risk is present in three scenarios:
Accidental - internal: A network administrator deploys Private Endpoints to improve network security within an Azure environment.
Accidental - vendor: A third-party vendor deploys Private Endpoints as part of its solution, for example to enable resource scanning by a security product.
Malicious - attacker: A threat actor who gained access to an Azure environment intentionally deploys Private Endpoints as part of a DoS attack.
Our research indicates that over 5% of Azure storage accounts currently operate with configurations that are subject to this DoS issue. In most environments, at least one resource in each of the following services is susceptible:
Key Vault
CosmosDB
Azure Container Registry (ACR)
Function Apps
OpenAI accounts
This issue has the potential to affect organizations in multiple ways. For example, denying service to storage accounts could cause Azure Functions within FunctionApps and subsequent updates to these apps to fail. In another scenario, the risk could lead to DoS to Key Vaults, resulting in a ripple effect on processes that depend on secrets within the vault.
Microsoft provides fallback to internet advice that partially addresses this and other known issues associated with Private Endpoints.
We discuss these issues, provide potential solutions and suggest ways that defenders can scan environments for resources that are susceptible to DoS attacks.
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products:
Unit 42 Cloud Security Assessment is a strategic evaluation service that reviews your organization's cloud infrastructure to identify misconfigurations and security gaps, enabling teams to strengthen their posture against cloud-based threats.
Azure Private Link Key Components, Concepts and Flows
As part of Azure’s networking offering, Microsoft created Azure Private Link. This mechanism offers a private, secure way to connect to supported Azure resources and Azure-hosted custom services using Azure’s backbone network.
Definitions
To understand the solution and the secure connection process of resources using it, let’s first define the key components and concepts.
Service: Destination to which a connection is made
Private Link: Azure implementation that allows and handles the connections
Private Endpoint: A network interface within a customer’s virtual network that allows connectivity to the service
Private DNS zone: The default Domain Name System (DNS) service that is used with Private Endpoints
Virtual network link: The link created by default between a Private DNS zone and a virtual network
DNS A record: A DNS record that maps a domain or hostname to an IP address
Network ACL: Network access control lists (ACLs) define rules that allow or restrict traffic to a service, separate from the Private Link solution
Azure resources expose public endpoints by default. These endpoints resolve through standard DNS infrastructure — either public Azure DNS, or customer-managed DNS resolvers. When a client queries a service name such as mystorageaccount.blob.core.windows[.]net, the DNS resolver returns a public IP address owned by Microsoft. The IP address allows connectivity over the public internet or Azure service endpoints, depending on the network access controls that are applied.
When Azure Private Link is introduced, DNS resolution behavior changes. A Private DNS zone — for example, privatelink.blob.core.windows[.]net — can be linked to one or more virtual networks. If a virtual network has a link to a Private DNS zone for a given service type, Azure’s DNS resolution logic prioritizes that zone when resolving matching service names. If a matching record exists, the name resolves to the private IP address of the Private Endpoint, instead of the public endpoint.
Organizations commonly deploy one of the following architectures:
Public-only architecture: Resources are accessed using their public endpoints and standard DNS resolution. Network ACLs, firewalls or service endpoints restrict access.
Private-only architecture: All access to the resource occurs through Private Endpoints. Public network access is disabled, and DNS resolution is fully controlled through Private DNS zones.
Hybrid architecture (public and private): Some virtual networks or workloads access the resource through Private Endpoints, while others continue using the public endpoint. This model is frequently used during migrations, phased rollouts, third-party integrations, or shared service environments.
We use the example of storage accounts to demonstrate how Private Endpoints are used in Azure networking. However, the same concepts apply to any Private Link-supported service. By default, when a network administrator or a user with appropriate Azure Role-Based Access Control (RBAC) permissions creates a Private Endpoint linked to a resource, a Private DNS zone is created with a virtual network link to the same virtual network as the Private Endpoint.
The DNS zone’s name has a predetermined structure that is based on the Private Endpoint’s destination service (e.g., privatelink.blob.core.windows[.]net for blob storage). Additionally, an A record is created in the DNS zone, linking the name of the destination resource and the IP address of the Private Endpoint.
There are two ways to connect between a virtual machine VM and a storage account with a Network ACL:
Without a Private Endpoint (using public or service endpoints)
With a Private Endpoint
Connection Flows
Figure 1 shows how a connection is made to a resource that does not use the Private Link solution.
Figure 1. Connection flow without the Private Link solution.
The flow in this case is as follows:
When trying to access the storage account, the VM attempts to resolve the account’s name to an IP address. This usually occurs through an external DNS resolver, and the traffic traverses the public internet.
If the resolver has a record for the storage account, it returns the corresponding IP address.
Once the address is obtained, the VM tries to connect to the storage account.
The storage account then evaluates the virtual machine’s IP address against its Network ACL. If the connection is allowed, the storage account responds with the requested information.
Figure 2 shows how the same connection is made when a Private Endpoint is used.
Figure 2. Connection flow with the Private Link solution.
Initially, the VM attempts to resolve the account’s name to an IP address. If a virtual network link exists in the virtual network (VNET) to a Private DNS zone that points to a Private Link service, Azure’s Private Link mechanism forces resolution using the Private DNS zone. This occurs when the connection is to a Private Link service of the same type (e.g., blob storage).
When the DNS resolver identifies a matching A record, it provides the VM with the corresponding IP address.
The VM then connects to the IP address, which belongs to the Private Endpoint.
The Private Endpoint acts as a network interface for the storage account, evaluating the traffic and then forwarding it to the storage account.
The storage account evaluates the request and supplies a response through the Private Link solution.
The response is presented to the VM, which essentially accesses the storage account using Azure’s backbone network.
Potential Private Link DNS Dangers
As outlined above, interactions with a Private Link service from a virtual network configured with a Private DNS zone for that service type are forced to resolve through the Private DNS zone.
Consider an environment where VM1 in VNET1 successfully accesses a storage account using its public endpoint. DNS resolution occurs through the default public DNS infrastructure, and access is permitted by the storage account’s Network ACLs. At this stage, the workload is operating normally.
Later, a Private Endpoint is created for the storage account in VNET2 — either intentionally, accidentally, or by a third-party deployment. As part of this process, a Private DNS zone for blob storage (privatelink.blob.core.windows[.]net) is linked to VNET1 or shared across virtual networks.
Once this DNS zone is linked, Azure’s DNS resolution logic forces all blob storage name resolution in VNET1 through the Private DNS zone. However, because no “A” record exists in the zone for the storage account within the context of VNET1, DNS resolution fails. VM1 can no longer resolve the storage account hostname and is unable to connect — even though the public endpoint remains accessible and unchanged.
This configuration change effectively creates a denial-of-service condition for workloads in VNET1 that previously functioned correctly. The outage is triggered solely by a DNS resolution side effect introduced by the Private Link configuration, without any change to the target resource itself.
Figure 3 demonstrates this example.
Figure 3. Potential issue caused by using the Private Link solution.
The figure above shows that VM1 attempts to connect to the storage account. This storage account has a Private Endpoint in VNET2 and does not have a Private Endpoint in VNET1. Hypothetically, VM1 could try to connect using the storage account’s public endpoint. This would work if the VM’s virtual network did not have a Private DNS zone resolving to the same resource type. In this case, however, the Private DNS zone and the service are Private Link registered, so Private Link forces resolution through the Private DNS zone.
The process shown in Figure 3 occurs as follows:
Private Link recognizes the blob storage Private DNS zone in VNET1 and identifies that the storage account is Private Link registered. Private Link forces DNS resolution through the Private DNS zone.
The configuration in Figure 3 shows that no record was created for the storage account in the Private DNS zone linked to VNET1. As such, the virtual machine cannot resolve the service.
Due to the DNS resolution issue in step 2, the subsequent steps – in which VM1 sends a request to the storage account and receives a response from it – do not occur.
This scenario causes a partial denial of service: any resource in VNET1 that tries to access the storage account will not be able to.
This risk can also be present when using local DNS resolvers, depending on the configurations and the records added. Additionally, although our example relates specifically to blob storage, any service that supports Azure Private Link is potentially at risk.
Mitigations and Recommendations
Azure Private Link was originally intended as a binary solution, to be either fully enabled, or disabled. When the service is implemented as intended, users can only access resources that use Private Link through those resources' Private Endpoints. This approach eliminates the need to use a combination of private, public and service endpoints. However, as over 5% of Azure storage accounts are configured in a way that is subject to this issue, we recognize the need to provide solutions that address the risks introduced by these implementations.
Mitigations
Microsoft acknowledges that the binary nature of the solution is a known issue and mentions it in their documentation. Microsoft also provides a partial solution: enabling a fallback to internet option when creating a virtual network link. Using this fallback solution, when the DNS Resolver cannot find a record that matches the requested service, it falls back to the public internet. While this solution solves the issue, it does not necessarily match the main concept of Azure Private Link, which is to traverse Azure’s backbone network rather than the public internet.
A second, partial solution is to manually add a record for the affected resource in the necessary Private DNS zone. This option is less appropriate for large production environments, as it creates additional operational overhead.
Although neither fallback nor manually adding a record is a definitive solution, combining the above approaches with comprehensive discovery will help with mapping, finding and remediating affected configurations.
Comprehensive Discovery and Scanning
There are two ways to scan and identify resources that are potentially at risk:
Scanning for resources with each service individually
The second scanning method is more efficient and can easily be modified to match most resource types. We created a graph query that retrieves a list of all the virtual networks in the environment that are linked to a blob storage Private DNS zone (privatelink.blob.core.windows[.]net). These virtual networks are forced to resolve blob storage resources through their Private Endpoints when communicating with Private Link registered resources.
In addition, it is important to identify which virtual networks interact with blob storage resources that do not have Private Endpoint connections. We created the following query for this purpose. This query retrieves storage accounts that allow access to their public endpoint and do not have a Private Endpoint connection.
This query identifies allowed virtual networks and also retrieves resources that allow specific IP addresses. This is useful when there is limited visibility into the DNS configurations for virtual networks, making it difficult to determine whether or not the configurations are affected.
Defenders should be aware that even resources that do not have Network ACLs could still be at risk. However, there is no way to use the configurations to determine which virtual networks, if any, attempt to communicate with such resources. To address this risk, use network logs to identify connections made from Azure network ranges to susceptible resources.
Defenders can change and match the resource and the Private DNS zone details in the above Resources query to detect Private Link-supported resources that are at risk.
Conclusion
Fully understanding the limitations of Azure Private Link is vital to securing networks that rely on it. With certain configurations of components and architecture, the binary nature of Azure Private Link can lead to connectivity loss and in some cases, could enable DoS attacks.
Two of the possible solutions to secure Private Endpoints against this risk include:
Enabling fallback to public DNS resolution
Manually adding DNS records for affected resources
Defenders can increase the effectiveness of these solutions by querying resources, conducting comprehensive network scanning to identify resources at risk, and implementing the necessary protections.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products:
Cortex Cloud customers are better protected from the misuse of the Azure Private Endpoints discussed within this article through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment. Cortex Cloud is designed to protect a cloud’s posture and runtime operations against these types of threats. It helps detect and prevent the malicious operations or configuration alterations or exploitation discussed within this article.
Unit 42 Cloud Security Assessment is a strategic evaluation service that reviews your organization's cloud infrastructure to identify misconfigurations and security gaps, enabling teams to strengthen their posture against cloud-based threats.
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
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.
No employee wants their paycheck to go missing. One organization learned about an incident when they started hearing exactly this complaint. It turned out that an attacker had modified direct-deposit details in order to redirect an organization’s paychecks into attacker-controlled accounts.
What happened to this organization started with nothing more than a phone call.
In fact, findings in our 2025 Unit 42 Global Incident Response Report: Social Engineering Edition suggest that 36% of all incidents Unit 42 engaged with began with a social engineering tactic. This includes phishing, vishing, search engine optimization (SEO) poisoning, fake system prompts and help desk manipulation.
In spite of technical protection tools available, attackers find that old-fashioned exploitation attempts still work. Instead of breaching networks, dropping malware or exploiting cloud misconfigurations, some threat actors are bypassing technical controls altogether and going straight for the humans who run them.
The Attack: Social Engineering in Action
The threat actor's initial access was not gained through a technical breach but rather through a social engineering campaign. The attacker impersonated employees to manipulate multiple help desks, including those for payroll, IT and HR shared services. They then tricked the help desk personnel by successfully circumventing the challenge/response authentication into performing password resets and re-enrolling multi-factor authentication (MFA) devices.
Social platforms provide easy access to publicly available information needed for threat actors to bypass help desk authentication. In many cases, attackers even call back multiple times to probe for the types of verification questions being asked, thereby allowing them to gather the necessary data for a successful subsequent attempt. As social platforms continue to expand the amount of personal and professional data available, this reconnaissance has become easier than ever.
In addition, the threat actor tried to establish persistence by registering an external email address as an authentication method for a service account within the client's Azure AD environment. This demonstrates a clear intent for long-term access beyond the immediate payroll diversion.
Once authenticated into the payroll system, the attacker moved quickly. In total, they compromised multiple employee accounts, each one granting access to sensitive payroll information. The attacker then proceeded to modify direct-deposit details for multiple individuals, redirecting their paychecks into bank accounts under the attacker’s control. Because the credentials were valid and MFA appeared legitimate, the activity blended in with normal operations. The incident was discovered only when employees reported missing paychecks. That triggered an internal investigation, which traced suspicious account changes dating back weeks. The organization engaged legal counsel, who referred them to Unit 42 to conduct a full-scope investigation.
How Unit 42 Helped
Once Unit 42 was engaged, we conducted a thorough investigation. Our team performed extensive threat hunting by deploying Cortex XSIAM and correlating telemetry from various sources, including the payroll system, HR system and the client's Next-Generation Firewall (NGFW) logs. This in-depth analysis allowed Unit 42 to confirm the incident and limit its impact. Our investigation confirmed that the incident was limited to the payroll diversion and account compromises, with no evidence of broader lateral movement or data exfiltration from the internal network.
But, unrelated to the payroll incident, our threat hunting effort identified evidence of an ongoing compromise related to the WannaCry ransomware in the client’s legacy OT environment. (Yes, you read that right! Given when it came out, WannaCry has been lurking in their environment for years!)
The Outcome: How We Closed Critical Security Gaps
Unit 42 worked with the customer to quickly contain the account compromises, reverse fraudulent payroll changes and regain control over impacted cloud identities.
At the same time, the team began advising on hardening measures across both IT and OT environments, including:
Enhancing help desk verification procedures
Strengthening MFA enforcement and recovery workflows
Improving logging, including forwarding application logs into Cortex XSIAM
Addressing the WannaCry foothold within OT systems
Despite the initial compromise, the impact was contained to just three employee accounts. This is largely because the organization acted quickly. Additionally, the attacker’s objective was financial gain rather than deeper network access. We were able to accelerate incident resolution and strengthen their security posture with stronger help desk protocols and identity governance.
What This Investigation Revealed
This incident highlights how modern attackers are increasingly bypassing traditional technical controls and focusing on operational processes, especially help desks. Human-driven workflows like password resets and MFA enrollment can become high-impact vulnerabilities if not tightly governed. It also illustrates how narrowly scoped fraud investigations can reveal deeper systemic issues, such as the discovery of a long-standing WannaCry presence in OT systems.
As attackers continue to refine their social engineering tactics, organizations must treat help desk and similar interactions with the same rigor as technical authentication flows. The case underscores the importance of:
Unified visibility across the environment
Security team skillset
Strong verification procedures for all identity-related requests
Interested in learning more about the latest attack trends? If so, take a look at our 2025 Unit 42 Global Incident Response Report: Social Engineering edition, which distills the most critical findings based on our direct experience responding to real-world cyberattacks at over 500 organizations across 38 countries.
Unit 42 strengthens your team with the tools and expertise needed to stay ahead of threats and protect your business. With our proven strategies and insights from thousands of engagements, we’ll help your team handle the toughest situations with confidence.
On Dec. 19, 2025, MongoDB publicly disclosed MongoBleed, a security vulnerability (CVE-2025-14847) that allows unauthenticated attackers to leak sensitive heap memory by exploiting a trust issue in how MongoDB Server handles zlib-compressed network messages. This flaw occurs prior to authentication, meaning an attacker only needs network access to the database's default port to trigger it.
Key details of the threat are summarized below:
Vulnerability: CVE-2025-14847 is a critical, unauthenticated memory disclosure vulnerability in MongoDB Server's handling of zlib-compressed messages (CVSS 8.7).
Impact: This memory can contain sensitive data such as cleartext credentials, API keys, session tokens and personally identifiable information (PII).
Status: Confirmed active exploitation in the wild. A public proof-of-concept (PoC) exploit is available. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added this vulnerability to the Known Exploited Vulnerabilities (KEV) Catalog on Dec. 29, 2025, based on evidence of active exploitation.
Cortex Xpanse identified approximately 146,000 instances of MongoDB exposed to the internet.
Palo Alto Networks customers are better protected from activity related to CVE-2025-14847 through the following products and services:
The MongoBleed vulnerability originates in the way MongoDB processes zlib-compressed wire-protocol messages, a feature that is enabled by default. Communication is handled via an OP_COMPRESSED header, which wraps the original message payload and includes a field specifying the expected size of the uncompressed data.
The execution of the attack mechanism occurs in the following manner:
An unauthenticated attacker sends a specially crafted, compressed message to a vulnerable MongoDB server.
The attacker manipulates the uncompressedSize field within the OP_COMPRESSED header, setting it to a value significantly larger than the actual compressed payload.
The server fails to validate this value and allocates an oversized memory buffer based on the attacker-specified size. This buffer is populated with uninitialized heap memory, remnants of previously processed data.
The leak is further amplified by MongoDB’s error-handling logic. When the attacker's malformed BSON object is sent without a null terminator, the server attempts to parse memory until it encounters a null terminator. When parsing ultimately fails, the server returns an error response that includes both the original malicious message and the contents of the leaked heap memory.
It’s important to note that MongoDB automatically applied the patch to managed MongoDB Atlas customers, meaning self-hosted MondoDB servers require manual patching.
This process allows an attacker to progressively leak large portions of the server's memory by sending repeated malformed requests.
Attack Vector and Impact
The attack vector is fully remote, unauthenticated, and requires no user interaction. An adversary only needs network access to the default MongoDB port (TCP/27017) to exploit the flaw.
The primary impact is a high-confidentiality data loss. Although MongoBleed is limited to being a read-only memory disclosure vulnerability and does not allow for remote code execution, the strategic significance of the information that can be leaked is vast. Attackers could leverage the leaked secrets to enable further system compromise, data exfiltration and lateral movement.
This vulnerability affects the following MongoDB versions:
Version 8.2: 8.2.0 – 8.2.2
Version 8.0: 8.0.0 – 8.0.16
Version 7.0: 7.0.0 – 7.0.27
Version 6.0: 6.0.0 – 6.0.26
Version 5.0: 5.0.0 – 5.0.31
Version 4.4: 4.4.0 – 4.4.29
End-of-life (no fix available):
All v4.2 versions
All v4.0 versions
All v3.6 versions
Current Scope of the Attack Using CVE-2025-14847
The threat posed by MongoBleed is not theoretical. A working public PoC exploit was published on GitHub on Dec. 26, 2025. Security researchers observed active exploitation in the wild shortly after the vulnerability's disclosure.
Official confirmation of active exploitation came on Dec. 29, 2025, when the U.S. CISA added CVE-2025-14847 to its KEV Catalog, mandating that federal agencies patch the flaw.
Cortex Xpanse identified approximately 146,000 vulnerable instances of MongoDB exposed to the internet, providing a tangible metric for the global attack surface.
Interim Guidance
If immediate patching is not feasible, the following temporary measures should be considered to help reduce risk:
1. Network Segmentation: Reduce exposure by blocking all inbound internet access to MongoDB instances on port TCP/27017. Connections should be restricted at the network level to explicitly trusted sources only.
2. Disable zlib Compression: As a temporary workaround, disable zlib compression support within the MongoDB configuration. This action prevents the vulnerable code path from being triggered. Safe alternatives include snappy, zstd or fully disabling compression.
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our Managed Services customers, using telemetry available within Cortex XDR. Cortex XDR customers who don’t leverage Unit 42 Managed Services can also use the following XQL query to search for signs of exploitation.
The following query attempts to identify a high number of network connections to MongoDB servers. Results of this query may not explicitly indicate exploitation but could be used to signal systems for further review.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Description: High Velocity network connection to MongoDB server may indicate exploitation of MongoBleed (CVE-2025-14847)
// Notes: Review the source IP of the requests and the host IP addresses. Validate they are not the same. If the IPs are on the same subnet it may be due to routing or load-balancing configuration.
// Filter for non-RFC1918 IP addresses. To include all IPs (depending on routing configuration it is possible traffic may have the internal IP of a load balancer, proxy, router, or firewall) comment the following line.
|comp count(_time)asCounter,values(agent_ip_addresses)asagent_ip_addresses,values(agent_external_ip)asagent_external_ip,values(action_local_port)asLocal_ports,count_distinct(action_local_port)asLocal_port_Count by agent_hostname,action_remote_ip,_time
// Identify source IPs with a high volume of connections per Minute. This number can be increased or decreased as needed. The higher the number the greater the chance of malicious activity, while the lower the number the broader the scope/ ability to identify activity.
|filter Counter>=500
Conclusion
While MongoBleed carries a Critical severity rating, successfully weaponizing it against a monitored enterprise is operationally difficult. Due to the return of unstructured, random fragments of data from an exploited server, capturing valuable data requires an attacker to barrage the server with thousands of requests.
This makes any worthwhile exploitation of MongoBleed a loud intrusion, creating a fingerprint that standard heuristics and rate-limiting controls should be well designed to detect and block long before significant data exfiltration typically occurs.
Palo Alto Networks customers are better protected by our products, as listed below.
Palo Alto Networks Product Protections for CVE-2025-14847
Palo Alto Networks customers can leverage a variety of product protections and services to help identify and defend against this threat.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
Cortex XDR and XSIAM help protect against post-exploitation activities using the multi-layer protection approach.
Cortex Xpanse
Cortex Xpanse is designed to identify exposed MongoDB devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the MongoDB Server and Insecure MongoDB Server Attack Surface Rules are enabled.
Cortex Attack Surface Testing (AST) can also validate whether exposed MongoDB instances are vulnerable to exploitation by executing benign PoC checks.
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 attack surface management (ASM) module.
While MongoDB’s managed service offering was automatically patched by the MongoDB Security Engineering team, self-hosted cloud instances can still be vulnerable. Cortex Cloud is designed to provide discovery of self-hosted MongoDB instances across Amazon Web Services (AWS), Azure and Google Cloud (GCP). This allows organizations to gain visibility into cloud-hosted assets, a critical first step in mitigating threats like MongoBleed.
Furthermore, Cortex Cloud has detection rules specifically designed to identify and alert on any self-hosted MongoDB instances that are publicly accessible.
Lastly, if cloud identities were leaked from a compromised MongoDB instance, Cortex Cloud Identity Security can help detect common post-exploitation identity-based techniques used to gain and maintain persistence resulting in further exploitation of cloud platforms.
Updated Jan. 14, 2026, at 1:05 p.m. PT to remove the word "vulnerable" from the sentence about exposed servers.
Updated Feb. 6, 2026, at 4:47 p.m. PT to add protection information about Advanced Threat Prevention.
We identified vulnerabilities in three open-source artificial intelligence/machine learning (AI/ML) Python libraries published by Apple, Salesforce and NVIDIA on their GitHub repositories. Vulnerable versions of these libraries allow for remote code execution (RCE) when a model file with malicious metadata is loaded.
Specifically, these libraries are:
NeMo: A PyTorch-based framework created for research purposes that is designed for the development of diverse AI/ML models and complex systems created by NVIDIA
Uni2TS: A PyTorch library created for research purposes that is used by Salesforce's Morai, a foundation model for time series analysis that forecasts trends from vast datasets
FlexTok: A Python-based framework created for research purposes that enables AI/ML models to process images by handling the encoding and decoding functions, created by researchers at Apple and the Swiss Federal Institute of Technology’s Visual Intelligence and Learning Lab
These libraries are used in popular models on HuggingFace with tens of millions of downloads in total.
The vulnerabilities stem from libraries using metadata to configure complex models and pipelines, where a shared third-party library instantiates classes using this metadata. Vulnerable versions of these libraries simply execute the provided data as code. This allows an attacker to embed arbitrary code in model metadata, which would automatically execute when vulnerable libraries load these modified models.
As of December 2025, we have found no malicious examples using these vulnerabilities in the wild. Palo Alto Networks notified all affected vendors in April 2025 to ensure they had a chance to implement mitigations or resolve the issues before publication.
NVIDIA issued CVE-2025-23304, rated High severity, and released a fix in NeMo version 2.3.2
The researchers who created FlexTok updated their code in June 2025 to resolve the issues
Salesforce issued CVE-2026-22584, rated High severity, and deployed a fix on July 31, 2025
These vulnerabilities were discovered by Prisma AIRS, which is able to identify models leveraging these vulnerabilities and extract their payloads.
Additionally, Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
AI/ML training and inference pipelines depend on saving complex internal states, such as learned weights and architecture definitions. These internal states are saved as model artifacts, and the artifacts must be shared between producers and consumers. Libraries provide built-in mechanisms to serialize these artifacts.
Python libraries for AI/ML have long depended on functionality from the pickle module in the Python standard library to store and load Python objects to and from files. This module serializes Python objects by creating a simple program to reconstruct the objects, and the pickle module is executed when the Python objects are loaded. Because the pickle module executes code when loading files, using it brings significant security risks.
The PyTorch library’s file format simply embeds .pickle files in a container format. Other libraries like scikit-learn use .pickle or other extensions used for pickle (like .joblib) on their own. Most popular AI/ML libraries clearly document these risks and provide mature mitigations to prevent the execution of unexpected code by default.
Security Issues in New Model Formats
Newer formats have been developed to address the security issues of these pickle-based formats. These “safe” formats largely achieve this by only supporting the serialization of model weights or by representing pipelines as data instead of code, using formats like JSON. For example, HuggingFace’s safetensors format only allows for the storage of model weights and a single JSON object to store model metadata.
Older formats have also moved away from relying on the pickle module. For example, PyTorch will only load model weights by default. If pickle loading is enabled, PyTorch will only execute functions from a predefined allow list that should prevent the execution of arbitrary code.
While these newer formats and updates remove the ability to serialize pipelines as code, they do not make applications and libraries using these models impervious to traditional exploits. Security researchers at JFrog have identified vulnerabilities in applications that use these formats using well-known techniques such as XSS and path traversal.
Technical Analysis
While newer formats have removed the ability to store model state and configurations as code, researchers still have use cases for serializing that information. Because these libraries are large and the configurations of their classes can be complex, many libraries use third-party tools to accomplish this.
Hydra is a Python library maintained by Meta that is a tool commonly used to serialize model state and configuration information.
We identified three open-source AI/ML Python libraries used by models on HuggingFace that leverage Hydra to load these configurations from model metadata in a way that allows for arbitrary code execution:
NeMo: A PyTorch-based framework created for research purposes designed for the development of diverse AI/ML models and complex systems created by NVIDIA
Uni2TS: A PyTorch library created for research purposes used by Salesforce's Morai, a foundation model for time series analysis that forecasts trends from vast datasets
FlexTok: A Python-based framework created for research purposes that enables AI/ML models to process images by handling the encoding and decoding functions, created by researchers at Apple and the Swiss Federal Institute of Technology’s Visual Intelligence and Learning Lab
Hydra
All the vulnerabilities we identified use the hydra.utils.instantiate() function, which is intended to “instantiate different implementations of an interface.”
The Hydra API takes as arguments a configuration object (like a Python dictionary or an OmegaConf object) that describes the target interface to instantiate and optional *args and **kwargs parameters to be passed to that interface. This configuration expects a _target_ value specifying the class or callable to instantiate, and an optional _args_ value defining arguments for _target_.
In each of the cases we identified, hydra.utils.instantiate() is only used to instantiate instances of library classes with simple arguments stored in metadata. Figure 1 shows an example of the metadata NeMo passes to the instantiate() function.
Figure 1. Metadata from a NeMo file.
What these libraries appear to have overlooked is that instantiate() doesn’t just accept the name of classes to instantiate. It also takes the name of any callable and passes it the provided arguments.
By leveraging this, an attacker can more easily achieve RCE using Python's built-in functions like eval() and os.system(). In all the proofs of concept we used to test these vulnerabilities, we employed a payload using builtins.exec() as the callable and a string containing Python as an argument.
Since these issues were first identified, Hydra has been updated to add a warning to its documentation stating that RCE is possible when using instantiate() and to add a simple block-list mechanism. This mechanism works by comparing the _target_ value against a list of dangerous functions like builtins.exec() before it is called.
Because this mechanism uses exact matches against import targets before they are imported, it is trivially evaded by using implicit imports from the Python standard library (e.g., enum.bltns.eval) or from the target application (e.g., nemo.core.classes.common.os.system). However, the Hydra documentation clearly states that this mechanism is not exhaustive and shouldn’t be relied on solely to prevent the execution of malicious code. As of January 2026, this block-list mechanism is not yet available in a Hydra release.
NeMo
NVIDIA has been developing the NeMo library since 2019, as a “scalable and cloud-native generative AI framework.” NeMo uses its own file formats with the .nemo and .qnemo file extensions, which are simply TAR files containing a model_config.yaml file that stores model metadata along with a .pt file or a .safetensors file, respectively.
The main entry points for loading these .nemo model files are restore_from() and from_pretrained(). There are several layers of abstraction, but ultimately, the serialization mix-in is used to handle loading the model configuration once it has been loaded from the embedded model_config.yaml file. Figure 2 shows the vulnerable call to hydra.utils.instantiate().
Figure 2. Call to hydra.utils.instantiate() in NeMo.
At no point is any sanitization done on the metadata before it is passed to instantiate(). Because the call is made before the target model class begins its initialization, it is easy to create a model_config.yaml file with a working payload, as shown in Figure 3.
Figure 3. Example metadata triggering the NeMo vulnerability.
NeMo also integrates with HuggingFace and supports passing the name of a model hosted on HuggingFace to from_pretrained(), which is the way most NeMo models on HuggingFace appear to be used. This call is also vulnerable because once the model is downloaded from HuggingFace, the same code paths are followed.
As of January 2026, over 700 models on HuggingFace from a variety of developers are provided in NeMo format NeMo. Many of these models are among the most popular on HuggingFace, such as NVIDIA’s parakeet. This vulnerability appears to have existed since at least 2020.
The PyTorch format that NeMo extends supports code execution with embedded .pickle files, but it clearly documents this. This PyTorch format also disables arbitrary execution by default and offers several safeguards, such as allowlisting usable modules during the loading of .pickle files. NeMo does allow for the loading of embedded .pickle files inside of the PyTorch files embedded in .nemo files, but the built-in allow list mechanism in PyTorch should prevent arbitrary code execution.
NVIDIA acknowledged this issue, released a CVE record CVE-2025-23304 rated High severity and issued a fix in NeMo version 2.3.2.
To address this issue, NeMo added a safe_instantiate function to validate the _target_ values from Hydra configurations before they are executed. This function recursively looks for _target_ values in the configuration and validates each one, which prevents using nested objects for RCE. A new _is_target_allowed function first checks each _target_ value against an allow list of prefixes containing package names from NeMo, PyTorch and related libraries.
This prefix check alone would not be sufficient to prevent implicit imports of dangerous modules, as is the case for Hydra’s new block-list mechanism. However, NeMo additionally imports each target using Hydra and checks to see whether:
It is a subclass of an expected class
The import has a module name from an allow list of expected modules
By checking the actual imported value against these allow lists, NeMo ensures only expected targets are executed. For example, the target nemo.core.classes.common.os.system resolves to the posix module, which is clearly not part of the NeMo library.
Uni2TS
In 2024, Salesforce’s AI research team published an article titled Unified Training of Universal Time Series Transformers, which introduced a set of models that were published on HuggingFace. This research and the use of these models depend on uni2TS, an open-source Python library that accompanied the Salesforce article.
The uni2TS library exclusively works with .safetensors files, which were explicitly designed to provide a safe alternative to model formats that allow for code execution. The safetensors format also does not explicitly support storing model or pipeline configurations.
To facilitate storing these configurations, libraries such as HuggingFace’s huggingface_hub use a config.json file stored in a model’s repository. For models using classes in one of HuggingFace’s core ML libraries, this is done securely because only parameters that can be stored directly in JSON primitive types are used. These values are then passed to a predefined, hard-coded set of classes.
However, huggingface_hub provides a PyTorchModelHubMixin interface for creating custom model classes that can be integrated with the rest of their framework. As part of this interface, values are read from the packaged config.json file and passed to the model class.
This interface provides a little-used mechanism for registering functions called coders, which process specific arguments before they are passed to the class. The uni2TS library leverages this mechanism to decode the configuration of a specific argument using a call to hydra.utils.instantiate() before it is passed to the target class, shown in Figure 4.
Figure 4. Call to hydra.utils.instantiate() in uni2TS.
This code is executed when one of the published models is loaded using either MoraiModule.from_pretrained() or MoraiMoEModule.from_pretrained(). By adding our payload to the config.json file packaged with models using uni2TS as shown in Figure 5, RCE can be achieved when the model is loaded.
Figure 5. Example config.json metadata triggering uni2TS vulnerability.
The Salesforce models using these libraries have hundreds of thousands of downloads so far on Hugging Face. Several adaptations of these models have also been published on HuggingFace by other users. No evidence of malicious activity involving these models has been discovered.
Salesforce has acknowledged this issue, released a CVE record CVE-2026-22584, rated High severity, and issued a fix on July 31. This fix implements an allow list and a strict validation check to ensure only explicitly permitted modules can be executed.
ml-flextok
Early in 2025, Apple and the Swiss Federal Institute of Technology’s Visual Intelligence and Learning Lab (EPFL VILAB) published research that introduced a supporting Python library called ml-flextok. Like uni2TS, ml-flextok works exclusively with the safetensors format and extends PyTorchModelHubMixin. It can also load metadata from a config.json file included in the model repository. This library also supports loading configuration data from the .safetensors file directly, storing this information in the metadata section of the file under the __metadata__ key.
Because the safetensors format represents metadata as a dictionary with string keys and string values, and because the model configuration depends on lists of parameters, a secondary encoding must be used. Ml-flextok leverages Python as this secondary encoding and uses ast.literal_eval() in the Python standard library to decode the metadata.
As documented, this function does not allow for arbitrary code execution but is susceptible to attacks causing memory exhaustion, excessive CPU consumption and process crashes. After the metadata has been decoded, ml-flextok directly passes it to hydra.utils.instantiate().
If the model is loaded from HuggingFace, this metadata is read from config.json and is not double-encoded since complex structures are supported. This JSON data is loaded as a dictionary, and specific sections are passed directly to instantiate().
In both cases, payloads are created with names matching instantiate() arguments. Depending on whether the payload is added to the .safetensors file directly or in the packaged config.json file, the encoding and placement of the payload differ slightly, but the payload is still straightforward. Figure 6 shows a payload placed in a .safetensors file's metadata.
Figure 6. Example of .safetensors metadata triggering uni2TS vulnerability.
As of January 2026, no models on HuggingFace appear to be using the ml-flextok library other than those models published by EPFL VILAB, which have tens of thousands of downloads in total.
Apple and EPFL VILAB have updated their code to resolve these issues by using YAML to parse their configurations and adding an allow list of classes they will pass to Hydra’s instantiate() function. They have also updated their documentation to indicate that strings stored in model files are executed as code and only models from trusted sources should be loaded.
Conclusion
Palo Alto Networks has not identified any model files leveraging these vulnerabilities for attacks in the wild. However, there is ample opportunity for attackers to leverage them.
It is common for developers to create their own variations of state-of-the-art models with different fine-tunings and quantizations, often from researchers unaffiliated with any reputable institution. Attackers would just need to create a modification of an existing popular model, with either a real or claimed benefit, and then add malicious metadata.
Prior to this finding, there was no indication that these libraries could be insecure or that only files from trusted sources should be loaded. HuggingFace does not currently make the contents of the metadata for these files easily accessible to users as it does in other cases (e.g., APIs referenced in .pickle files). Neither does it flag files using the safetensors or NeMo formats as being potentially unsafe.
Because the latest advances in this space often require code and not just model weights, there is a proliferation of supporting libraries. In October 2025, we identified over a hundred different Python libraries used by models on HuggingFace, almost 50 of which use Hydra in some manner. While these formats on their own may be secure, there is a very large attack surface in the code that consumes them.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Prisma AIRS is able to identify models leveraging these vulnerabilities and extract their payloads.
Cortex Cloud’s Vulnerability Management identifies and manages base images for cloud virtual machine and containerized environments. This allows for identification and alerting of vulnerabilities and misconfigurations, then provides remediation tasks for identified base level container images. The Cortex Cloud Agent can also detect the runtime operations discussed within this article.
The Unit 42 AI Security Assessment can help organizations reduce AI adoption risk, secure AI innovation and strengthen AI governance.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Get updates from Unit 42 