Novel Technique to Detect Cloud Threat Actor Operations

Posted on by Nathaniel Quist

Executive Summary

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.

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

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

Related Unit 42 Topics Muddled Libra (related to Scattered Spider), API, IAM

Another Lens on Cloud Alert Trends

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 Token and 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.

MITRE Tactics MITRE Techniques MITRE Technique Name
Collection T1530 Data from Cloud Storage
Defense Evasion T1578.002 Modify Cloud Compute Infrastructure: Create Cloud Instance
Defense Evasion, Persistence, Privilege Escalation, Initial Access T1078.004 Valid Accounts: Cloud Accounts
Discovery T1069.003 Permission Groups Discovery: Cloud Groups
Discovery T1087.004 Account Discovery: Cloud Account
Discovery T1526 Cloud Service Discovery
Discovery T1538 Cloud Service Dashboard
Discovery T1580 Cloud Infrastructure Discovery
Lateral Movement T1021.007 Remote Services: Cloud Services
Persistence, Privilege Escalation T1098.001 Account Manipulation: Additional Cloud Credentials
Persistence, Privilege Escalation T1098.003 Account Manipulation: Additional Cloud Roles

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.

Bar chart titled "Muddled Libra Unique Alerts" displaying various sectors on the vertical axis and alert counts on the horizontal. "HighTechnology" leads with the highest alerts, followed by "Wholesale & Retail Trade" and "Financial Services." The chart continues with sectors like "Real Estate" and "Federal Government" showing fewer alerts. Bars are colored red and blue where red indicates Muddled Libra.
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.

Bar chart displaying average alerts per day across various industries. X-axis lists industries such as Transportaion and Logistics, Pharmaceuticals and Life Sciences, Retail, and Telecommunications. Y-axis ranges from 0 to 8 alerts. Bars in blue and red vary in height, with the highest being Transportaion and Logistics at 7 alerts and the lowest being Media and Entertainment at 2 alerts.
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.

Bar chart that shows alerts from June 2024 to June 2025. Each month from June to May has 10-12 alerts in blue bars, and June has 15 alerts in a red bar, indicating Muddled Libra.
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 T1526 Discovery
Microsoft 365 storage services exfiltration activity T1530 Collection, Exfiltration
Multi region enumeration activity T1580

T1535

T1526

 Discovery
Storage enumeration activity T1619

T1530

T1526

 Discovery, Collection
Cloud Identity Queried Cost or Usage Information T1087.004

T1580

 Discovery
A cloud identity invoked IAM related persistence operations T1098

T1136

T1078.004

 Defense Evasion, Persistence, Privilege Escalation, Initial Access
Cloud infrastructure enumeration activity T1580

T1526

 Discovery
Suspicious identity downloaded multiple objects from a bucket T1530

T1020

 Collection, Exfiltration
Suspicious cloud infrastructure enumeration activity T1580

T1526

 Discovery
ML model discovery T1526 Discovery

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.

MITRE Tactics MITRE Techniques MITRE Technique Name
Collection T1119 Automated Collection
Collection T1530 Data from Cloud Storage
Credential Access T1555.006 Credentials from Password Stores: Cloud Secrets Management Stores
Defense Evasion,

Lateral Movement

 T1550.001 Use Alternate Auth Material: Application Access Token
Defense Evasion,

Persistence,

Privilege Escalation,

Initial Access

 T1078.004 Valid Accounts: Cloud Accounts
Discovery T1619 Cloud Storage Object Discovery
Exfiltration T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage
Impact T1485 Data Destruction
Initial Access T1190 Exploit Public-Facing Application
Initial Access T1199 Trusted Relationship
Persistence T1136.003 Create Account: Cloud Account
Persistence,

Privilege Escalation

 T1098.001 Account Manipulation: Additional Cloud Credentials

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.

Bar chart showing various industries by unique alerts by industry. High Technology, Financial Services, and Wholesale and Retail have the highest alert counts. Other sectors like Federal Government and Real Estate show fewer alerts. Red bars indicate the industries publicly reported as targeted by Silk Typhoon.
Figure 4. Count of unique alerts and average daily alerts by industry. Red bars indicate the industries public reported as targeted by Silk Typhoon.
Bar chart displaying alert averages across various industries. The chart shows the Federal Government with the most alerts, followed by sectors like Agriculture, Pharma and Life Sciences, and High Technology. Healthcare, Media and Entertainment, and Real Estate have the fewest alerts. Bars are colored in red and blue where red indicates 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 T1530 Collection, Exfiltration
Process execution with a suspicious command line indicative of the Spring4Shell exploit T1190 Initial Access
Storage enumeration activity T1619 Discovery
A cloud identity invoked IAM related persistence operations T1098 Persistence, Privilege Escalation
Suspicious identity downloaded multiple objects from a bucket T1530

T1020

 Collection, Exfiltration
Suspicious identity downloaded multiple objects from a backup storage bucket T1530

T1020

 Collection, Exfiltration
An identity performed a suspicious download of multiple cloud storage objects T1530

T1020

 Collection, Exfiltration
An identity performed a suspicious download of multiple cloud storage objects from multiple buckets T1530

T1020

 Collection, Exfiltration
Massive code file downloads from SaaS service T1530 Collection
Deletion of multiple cloud resources T1485 Impact

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.

Comparison of industry ranking shifts in unique cloud alerts for general trends versus 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.

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

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

The Shadow Campaigns: Uncovering Global Espionage

Posted on by Unit 42

Executive Summary

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:

Related Unit 42 Topics Asia, Phishing

Actor Introduction

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.

Phishing email screenshot, translated. Email announcing organizational changes at a government ministry, emphasizing improvements in global interaction and structure efficiency. Includes a link to detailed changes and an invitation for feedback.
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:

  • hxxps[:]//raw.githubusercontent[.]com/padeqav/WordPress/refs/heads/master/wp-includes/images/admin-bar-sprite[.]png
  • hxxps[:]//raw.githubusercontent[.]com/padeqav/WordPress/refs/heads/master/wp-includes/images/Linux[.]jpg
  • hxxps[:]//raw.githubusercontent[.]com/padeqav/WordPress/refs/heads/master/wp-includes/images/Windows[.]jpg

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
  • D-Link remote code execution vulnerability
  • HTTP directory traversal request attempt
  • HTTP SQL injection attempt
  • Struts2 OGNL remote code execution vulnerability
  • Ruijieyi Networks remote command execution vulnerability
  • Eyou Email System remote command execution vulnerability
  • Beijing Grandview Century eHR Software SQL injection vulnerability
  • Weaver Ecology-OA remote code execution vulnerability
  • Microsoft Windows win.ini access attempt detected
  • Commvault CommCell CVSearchService download file authentication bypass vulnerability
  • Zhiyuan OA 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:

  1. 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.
  2. 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:

  1. Infrastructure may appear more legitimate to network defenders
  2. This could enable low-latency connections across the Americas, Europe and Southeast Asia
  3. 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.

World map showing various countries colored in orange.
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.

World map showing various countries highlighted in orange. The countries include those in the Americas, Africa, Europe, and Asia.
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.

Map highlighting Mexico, Colombia, and Venezuela in orange, with other areas in gray.
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.

Satellite image showing a marked location using Google Street Maps.
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

In early November, a Tibetan news source announced that the Czech president would also co-patronize the Dalai Lama’s 90th birthday gala. Shortly after, we witnessed a second round of scanning focused narrowly on the Czech president’s website.

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.

Map of Europe highlighting several countries colored in orange, including Italy, Germany, and Greece.
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.

Map highlighting several countries in Asia and Oceania in orange, including China, India, Indonesia, and Australia.
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.

Map view focusing on Soekarno–Hatta International Airport with terminals labeled and a red marker indicating a specific location within the area.
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:

Map of Africa with various countries shaded in orange to represent data counts.
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:

  • Advanced URL Filtering and Advanced DNS Security identify known URLs and domains associated with this activity as malicious.
  • 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.

Indicators of Compromise

IP Addresses

  • 138.197.44[.]208
  • 142.91.105[.]172
  • 146.190.152[.]219
  • 157.230.34[.]45
  • 157.245.194[.]54
  • 159.65.156[.]200
  • 159.203.164[.]101
  • 178.128.60[.]22
  • 178.128.109[.]37
  • 188.127.251[.]171
  • 188.166.210[.]146
  • 208.85.21[.]30

Domains

  • abwxjp5[.]me
  • brackusi0n[.]live
  • dog3rj[.]tech
  • emezonhe[.]me
  • gouvn[.]me
  • msonline[.]help
  • pickupweb[.]me
  • pr0fu5a[.]me
  • q74vn[.]live
  • servgate[.]me
  • zamstats[.]me
  • zrheblirsy[.]me

Phishing/Downloader SHA256

  • 66ec547b97072828534d43022d766e06c17fc1cafe47fbd9d1ffc22e2d52a9c0
  • 23ee251df3f9c46661b33061035e9f6291894ebe070497ff9365d6ef2966f7fe

Cobalt Strike SHA256

  • 5175b1720fe3bc568f7857b72b960260ad3982f41366ce3372c04424396df6fe
  • 358ca77ccc4a979ed3337aad3a8ff7228da8246eebc69e64189f930b325daf6a
  • 293821e049387d48397454d39233a5a67d0ae06d59b7e5474e8ae557b0fc5b06
  • c876e6c074333d700adf6b4397d9303860de17b01baa27c0fa5135e2692d3d6f
  • b2a6c8382ec37ef15637578c6695cb35138ceab42ce4629b025fa4f04015eaf2
  • 5ddeff4028ec407ffdaa6c503dd4f82fa294799d284b986e1f4181f49d18c9f3
  • 182a427cc9ec22ed22438126a48f1a6cd84bf90fddb6517973bcb0bac58c4231

ShadowGuard SHA256

  • 7808b1e01ea790548b472026ac783c73a033bb90bbe548bf3006abfbcb48c52d

CVE-2019-11580 Exploit SHA256

  • 9ed487498235f289a960a5cc794fa0ad0f9ef5c074860fea650e88c525da0ab4

Updated Feb. 5, 2026, at 7:40 a.m. PT to add Cortex product protections language.

Why Smart People Fall For Phishing Attacks

Posted on by Ria Bhatia

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.

Additional Resources

Privileged File System Vulnerability Present in a SCADA System

Posted on by Asher Davila

Executive Summary

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.

CVE Identifier Vulnerability Description Score
CVE-2025-0921 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:

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

Related Unit 42 Topics Vulnerabilities, Privilege Escalation, CVE-2025-0921

Background

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.

The image shows a settings window for MMXPAGER TAP/SMS configuration. It includes checkboxes and fields for enabling TAP log file, TAP and SMS dialogs, acknowledgments, ANSI Modem, and SMS Unicode. There are input fields for SNPP server host name, port (set to 444), SNPP protocol level, pin, and password. There's also a dropdown menu option to allow shutdown.
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.

Screenshot of an SMS Unicode Configuration window. It includes fields for Device, Baudrate, Pin, Recipients, Body with a limit of 70 characters, and LogFile. There are buttons labeled "View," "Send SMS," and "Ok." A note at the bottom mentions that a modem may require a specific baud rate to run. The version is marked as "Registered version."
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.

This image shows a Windows file explorer window open to the "ICONICS" directory on a computer's C: drive. The "ICONICS Properties" dialog box is displayed on the left, showing permission settings. On the right, an "About" window for "GraphWorX64 by ICONICS, Inc." is open, displaying version 10.97. The "ICONICS, Inc." address and contact information are visible, along with icons indicating Microsoft Partner status.
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.

A screenshot of a Notepad window displaying a script or code. The text includes file paths, settings, and configurations. The file path "C:\Users\CLOSES~1\Workspace\task\Temp\deploylog.txt" is highlighted.
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.

Screenshot of an SMS Unicode Configuration window. Includes fields for Device (COM5), Baudrate (38400), Pin (1231a), Recipients, Body with a maximum of 70 characters, and LogFile path ("C:\Users\ICONICS_USER\AppData\Local\Temp\log"). Buttons for sending SMS, viewing log, and confirming settings are present. A note states that the modem may require a specific baud rate to run.
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.

Screenshot of the CFF Explorer VIII software showing the Hex Editor tab for the file "cng.sys." The window displays hexadecimal values on the left and corresponding ASCII characters on the right.
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.

A black screen with the blue Windows logo in the center. Below the logo, the text reads "Preparing Automatic Repair."
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.

Additional Resources

Updated Feb. 5, 2026, at 8:43 a.m. PT to correct OT Device Security product name. 

Understanding the Russian Cyberthreat to the 2026 Winter Olympics

Posted on by Ria Bhatia

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.

This distinction is critical for understanding how Russia perceives the IOC not as a regulatory body, but a political adversary acting in the political interest of Western nations. From the Kremlin’s perspective, the 2026 Winter Olympics ban isn't about charters or truces. It is a political attack on their state legitimacy. This is their primary venue for projecting “great power” status. When the IOC bans the flag, silences the anthem and forces competitors to compete as “Individual Neutral Athletes,” Moscow interprets it as an attempt to erase Russian identity from the global stage.

Russia’s Faltering Identity on the Global Stage

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)

During the 2018 Winter Olympics in Pyeongchang, Razing Ursa (aka APT44, Sandworm, Iridium) targeted IT infrastructure with Olympic Destroyer malware [PDF]. Targeting broadcasters, officials and sponsors, the attackers employed sophisticated false-flag tactics to frame North Korean and Chinese actors. The operation also utilized VPNFilter to compromise devices across South Korea, causing widespread disruption.

Advanced Reconnaissance (2020 Tokyo 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.

Happy 9th Anniversary, CTA: A Celebration of Collaboration in Cyber Defense

Posted on by Kathi Whitbey

The Genesis of Collective Defense

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.

Happy 9th Anniversary, CTA!

Dark blue and orange graphic celebrating the 9th anniversary of the Cyber Threat Alliance with a large orange circular "9" and a red "ANNIVERSARY YEARS" ribbon.
Figure1. Celebrating 9 Years of the CTA

Additional Resources

Sharing Threat Intelligence Makes Everyone Safer – Michael Sikorski, Palo Alto Networks

More About The Author

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.

The Next Frontier of Runtime Assembly Attacks: Leveraging LLMs to Generate Phishing JavaScript in Real Time

Posted on by Samantha Stallings

Executive Summary

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:

The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization.

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

Related Unit 42 Topics JavaScript, LLMs, Phishing

LLM-Augmented Runtime Assembly Attack Model

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.

Flowchart demonstrating a cybersecurity threat involving phishing. The process includes selecting a phishing page, translating malicious code into LLM prompts to circumvent security, and executing scripts in the browser to display a benign-looking page while malicious content is processed in the background. Icons represent coding, engineering, and trusted API endpoints, focusing on a 'SecureBank Login' example.
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 scripts with 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 code to 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.

Screenshot displaying a document containing text instructions on coding. The text includes a red underlined URL and several coding commands and explanations related to AJAX requests. The document has a plain white background with red and black text. At the top of the image is the Base64 encoded URL. The second paragraph is the ask to make the AJAX request instead of credential exfiltration.
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.

Screenshot of two side-by-side code comparisons in an IDE, focusing on different methods of extracting and handling URLs and domain data in JavaScript. The left code extract uses requests while the right code analyzes email-based URLs for domain extraction, highlighted with annotations and marked steps.
Figure 3. Polymorphism creating multiple variants of dynamically generated JavaScript code.

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.

Screenshot collage showing a phishing attack process. Top image: a fake login page. Middle image: a fake login page for Palo Alto Networks for detecting the phishing page. Bottom image: a phishing code generator interface.
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.

Attacks Leveraging In-Browser Runtime Assembly Behaviors

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.

The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization.

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.

Additional Resources

DNS OverDoS: Are Private Endpoints Too Private?

Posted on by Unit 42

Executive Summary

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.

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

Related Unit 42 Topics Microsoft Azure, Cloud Research

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.

Diagram showing network architecture with four main components: VNET1 containing VM1, connected to a DNS Resolver and a Storage Account with a Network ACL listing two rules: 1. Allow VNET1, 2. Deny *. The connections are numbered to indicate the flow of interaction.
Figure 1. Connection flow without the Private Link solution.

The flow in this case is as follows:

  1. 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.
  2. If the resolver has a record for the storage account, it returns the corresponding IP address.
  3. Once the address is obtained, the VM tries to connect to the storage account.
  4. 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.

Diagram showing network communication within Azure. VNET1 connects to a VM1 and a Private DNS Zone labeled as "privatelink.blob.core.windows.net." A Private Endpoint interacts between VM1 and a Storage Account, illustrating the flow of data marked with numbers 1 to 6, indicating the sequence of communication.
Figure 2. Connection flow with the Private Link solution.
  1. 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).
  2. When the DNS resolver identifies a matching A record, it provides the VM with the corresponding IP address.
  3. The VM then connects to the IP address, which belongs to the Private Endpoint.
  4. The Private Endpoint acts as a network interface for the storage account, evaluating the traffic and then forwarding it to the storage account.
  5. The storage account evaluates the request and supplies a response through the Private Link solution.
  6. 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.

Diagram showing two virtual networks, VNET1 and VNET2, connected by a storage account. VNET1 includes a VM1 and a private DNS zone. The storage account is positioned between both networks. This setup may result in failed connections, as indicated by red crosses on paths from VM1 to the storage account. VNET2 contains a private DNS zone and a linked private endpoint.
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:

  1. 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.
  2. 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.
  3. 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:

  1. Scanning for resources with each service individually
  2. Using Azure Resource Graph Explorer

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.

Additional Resources

Anatomy of an Attack: The Payroll Pirates and the Power of Social Engineering

Posted on by Ria Bhatia

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.

Additional Resources

About Unit 42

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.

Threat Brief: MongoDB Vulnerability (CVE-2025-14847)

Posted on by Unit 42

Executive Summary

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 Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Vulnerabilities Discussed CVE-2025-14847

Details of CVE-2025-14847

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.

Please refer to the issues tracker maintained by MongoDB for additional suggestions and updates.

Unit 42 Managed Threat Hunting Queries

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.

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)
  • 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 Threat Prevention

Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices via the following Threat Prevention signature 96856 and 96857.

Cortex XDR and XSIAM

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.

Cortex Cloud

Cortex Cloud can help detect cloud-hosted resources vulnerable to CVE-2025-14847 through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment.

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.

Remote Code Execution With Modern AI/ML Formats and Libraries

Posted on by Samantha Stallings

Executive Summary

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:

Related Unit 42 Topics Python, LLMs, Machine Learning

AI/ML Model Formats

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.

A screenshot of computer code containing configuration parameters for a machine learning model.
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().

A screenshot of computer code from the Hydra API, showing conditional statements written in Python for handling configuration-based instantiation.
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.

A screenshot of code in a text editor, featuring lines written in Python. The code includes a print statement with "Hello world".
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.

Screenshot of Python code including a function to decode distribution output and a class definition using PyTorch.
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.

Screenshot of a JSON script containing a Python print function code that displays "Hello world".
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.

A line of code displayed on a dark background that includes the text "payload", "target", and "builtins."
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.

Additional Resources

Securing Vibe Coding Tools: Scaling Productivity Without Scaling Risk

Posted on by Ria Bhatia

Vibe Coding and Vulnerability: Why Security Can’t Keep Up

The promise of AI-assisted development, or “vibe coding,” is undeniable: unprecedented speed and productivity for development teams. In a landscape defined by complex cloud-native architectures and intense demand for new software, this force multiplier is rapidly becoming standard practice. However, this speed comes at a severe, often unaddressed cost. As AI agents generate functional code in seconds, they are frequently failing to enforce critical security controls, introducing mass vulnerabilities, technical debt and real-world breach scenarios.

This challenge is magnified by the rise of citizen developers (personnel without development backgrounds) who lack the literacy to review or secure the code being generated. Due to this lack of development background, citizen developers may not have a full understanding of the security requirements required in the application life cycle, which may require application security training and/or experience. For every leader from the CEO to the CISO, as well as technical practitioners, understanding this gap is critical. This blog introduces the SHIELD framework (see below in the What Unit 42 is Seeing section) to put necessary governance back into the coding process, ensuring we scale productivity without scaling risk.

Identifying and Addressing Vibe Coding Risks

A user types a simple prompt: // Write a function to fetch user data from the customer API. In seconds, a dozen lines of functional code appear.

This is the new reality of vibe coding. The productivity gains are undeniable. Development teams, already stretched thin by complex software development life cycles (SDLCs) and cloud-native pressures, now have a powerful force multiplier.

But let’s examine the unexpected outcomes vibe coding creates.

What happens when that AI-generated function correctly fetches the data, but neglects to include vital authentication and rate-limiting controls? What happens when the AI agent is tricked by a malicious prompt into exfiltrating sensitive data?

As organizations rapidly adopt these tools, a gap is widening between productivity and security. The "nightmare scenarios" are no longer hypothetical; they are documented, real-world incidents.

The accelerated demand for software, increasing reliance on cloud-native technologies and widespread adoption of DevOps have intensified the complexity and resource requirements of the SDLC. Vibe coding offers a silver lining, enabling teams to do more with less. However, in the wake of wider adoption, Unit 42 has observed that real-life catastrophic failures have occurred:

  • Insecure application development leading to breach: A sales lead application was successfully breached because the vibe coding agent neglected to incorporate key security controls, such as those for authentication and rate limiting, into the build
  • Insecure platform logic leading to code execution: Researchers discovered a critical flaw via indirect prompt injection that allowed malicious command injection via untrusted content, executing arbitrary code and enabling exfiltration of sensitive data
  • Insecure platform logic leading to authentication bypass: A critical flaw in the authentication logic for a popular program allowed a bypass of controls by simply displaying an application’s publicly visible ID in an API request
  • Rogue database deletion leading to data loss: An AI agent, despite explicit instructions to freeze production changes, deleted the entire production database for a community application

Understanding the Root Causes of Vibe Coding Risk

These incidents are symptoms of predictable, fundamental gaps in how AI models operate. From our analysis, these risks cluster into a few key categories:

  • Models prioritize function over security: AI agents are optimized to provide a working answer, fast. They are not inherently optimized to ask critical security questions, resulting in a nature that is insecure by default. Use of security scanning or “judge agents” in many of these tools is elective, leaving potential security gaps.
  • Critical context blindness: An AI agent lacks the situational awareness a human developer possesses (e.g., distinguishing between production and development environments).
  • The "phantom" supply chain risk: AI models often hallucinate helpful-sounding libraries or code packages that do not exist, leading to unresolvable dependencies.
  • Citizen developers and developer over-trust: Personnel without a development background lack training in how to write secure code. The democratization of code development is thus accelerating the introduction of security vulnerabilities and long-term technical debt. Additionally, the code looks correct and it works. This creates a false sense of security, accelerating vulnerabilities due to a lack of traditional change control and secure code review.

What Unit 42 Is Seeing

Through its AI visibility and security assessment engagements, Unit 42 has found that most evaluated organizations allow employees to use vibe coding tools due to the absence of hard blocks (e.g., blocking tools at the firewall). However, very few of these organizations have performed a formal risk assessment on the use of these tools, and very few are monitoring inputs, outputs, and security outcomes.

Addressing Risk Through the SHIELD Framework

The proliferating threat landscape may seem unmanageable, but returning to the first principles of security controls is the answer. Unit 42 works with clients to implement the SHIELD framework for vibe coding, placing properly designed security controls back into the coding process.

  • S - Separation of Duties: Vibe coding platforms may over-aggregate privileges. Ensure that incompatible duties (e.g., access to development and production) are not granted to AI agents. Restrict agents to development and test environments only.
  • H - Human in the Loop: Vibe coding platforms may fail to enforce human review. For any code impacting critical functions, ensure a mandatory secure code review performed by a human and require a pull request (PR) approval prior to code merge. This is vital when non-developers are involved.
  • I - Input/Output Validation:
    • Input: Sanitize prompts by separating trusted instructions from untrusted data via guardrails (prompt partitioning, encoding, role-based separation).
    • Output: Require the AI to perform validation of logic checks and code through Static Application Security Testing (SAST) after development and before merging.
  • E - Enforce Security-Focused Helper Models: Develop external/independent helper models (specialized agents designed to provide automated security validation for vibe-coded applications) to perform SAST testing, secrets scanning, security control verification, and other critical validation functions to identify vulnerabilities and hard-coded secrets prior to deployment.
  • L - Least Agency: Implement the principle of least agency for all vibe coding platforms and AI agents. Only grant the minimum permissions and capabilities required to perform their role. Restrict access to sensitive files and guardrail any destructive commands.
  • D - Defensive Technical Controls: Employ defensive controls around supply chain and execution management, such as performing Software Composition Analysis (SCA) on components before consumption, and disabling auto-execution to allow for human-in-the-loop and helper agent involvement in deployment.

Securing Vibe Coding: A Non-Negotiable for the AI Era

Ultimately, the age of vibe coding has arrived, but the vibes will benefit from careful tuning. Speed without security rigor can quickly lead to irreversible outcomes. Identifying tactical security controls that adequately address the risk ensures we can take the safe path to vibe coding bliss and avoid the difficult path to catastrophic scenarios we cannot take back.

The Unit 42 AI Security Assessment can help empower safe AI use and development across your organization.

Additional Resources

VVS Discord Stealer Using Pyarmor for Obfuscation and Detection Evasion

Posted on by Sheida Azimi

Executive Summary

This article details our technical analysis of VVS stealer, also styled VVS $tealer, including its distributors’ use of obfuscation and detection evasion.

The stealer is written in Python and targets Discord users, exfiltrating sensitive information like credentials and tokens stored in Discord accounts. This stealer was once in active development and marketed for sale on Telegram as early as April 2025.

VVS stealer's code is obfuscated by Pyarmor. This tool is used to obfuscate Python scripts to hinder static analysis and signature-based detection. Pyarmor can be used for legitimate purposes and also leveraged to build stealthy malware.

Malware authors are increasingly leveraging advanced obfuscation techniques to evade detection by cybersecurity tools, making their malicious software harder to analyze and reverse-engineer. This article shows how we deobfuscated VVS stealer samples to better understand its operations.

Because Python is easy for malware authors to use and the complex obfuscation used by this threat, the result is a highly effective and stealthy malware family.

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

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

Related Unit 42 Topics Infostealer, Anti-analysis

Introduction

Discord is a social messaging and communications platform that has become a popular target for malware, like VVS stealer. VVS stealer is designed to steal a victim's Discord information and browser data.

Figure 1 shows VVS stealer's advertised capabilities, including:

  • Stealing Discord data (tokens and account information)
  • Intercepting active Discord sessions via injection
  • Extracting web browser data (cookies, passwords, browsing history and autofill details)
Screenshot collage of a computer screen displaying information about "VS Stealer on Telegram," talking about its use as a hacking tool, with features listed and pricing details. Also visible is a Telegram contact link for further communication.
Figure 1. VVS stealer advertisement, focused on Telegram.

The stealer also achieves persistence by automatically installing itself on startup. It operates stealthily by displaying fake error messages and capturing screenshots. For a deeper investigation into the operation, please refer to the article by DeepCode, Investigating VVS $tealer: A Python-Based Discord Malware.

Technical Analysis

This section analyzes a Pyarmor-protected VVS stealer malware sample with the following SHA-256 hash:

  • c7e6591e5e021daa30f949a6f6e0699ef2935d2d7c06ea006e3b201c52666e07

Figure 2 shows a summary diagram illustrating the entire sample analysis workflow.

Flowchart showing the process of extracting Python bytecode from a PyInstaller executable, decompiling it to Python source code, and decrypting Pyarmor bytecode to ELF.
Figure 2. Overview of the workflow for analyzing the VVS stealer malware sample.

Step One: Extracting From the PyInstaller Binary

The sample we analyzed is distributed as a PyInstaller package. PyInstaller is a tool that bundles a Python application and its dependencies into a package to allow execution of a packaged app without installing additional modules.

Any standard PyInstaller installation ships with the built-in utility pyi-archive_viewer. We used this utility to extract and inspect the following files from our sample:

  • The Python bytecode file named vvs
  • The Pyarmor runtime dynamic-link library (DLL) file named pyarmor_runtime.pyd, located under subfolder pyarmor_runtime_007444
    • The accompanying __init__.py file within this same subfolder, which includes the following information:
      • Pyarmor version: 9.1.4 (Pro)
      • Unique license number: 007444
      • Timestamp: 2025-04-27T11:04:52.523525
      • Product name: vvs
  • Python 3.11 DLL file named python311.dll
    • The file version information indicates the Python version is 3.11.5

PyInstaller stores Python bytecode (listed as 1.) in its raw form. This raw form refers to the bytecode sequence beginning with the value e3. The value e3 is a combination of both flag and type, combined via the constant FLAG_REF.

The type represented by the value e3 is computed as: type = e3 & ~FLAG_REF. This means the value e3 is actually the type 0x63 (the letter c), also known as the enumeration constant TYPE_CODE. The full implementation of this derivation can be found in the CPython 3.11 codebase.

Figure 3 below shows this code object serialized by the marshal module is bare, missing an accompanying 16-byte header (marked in blue). To provide enough Python for the decompiler not to reject the file, we need to restore at least one of the header values (Python 3.11.5 magic number in 4-byte, little-endian format) prior to decompilation, because the Python decompiler expects a valid Python bytecode (.pyc) file as its input.

Hexadecimal data visualization showing rows of hex codes with some values highlighted.
Figure 3. Python bytecode (.pyc) file named vvs, with its header restored.

We begin our analysis by decompiling the Python bytecode .pyc) file named vvs to recover its equivalent Python source code (.py).

Step Two: Decompiling to Python Source Code

Pycdc is a Python bytecode decompiler written in C++. It is part of the Decompyle++ project. It supports decompiling Python 3.11 bytecode “back into valid and human-readable Python source code.” (Source: GitHub.) PyLingual is another Python bytecode decompiler.

After cloning the code repository and compiling the codebase, the generated executable can be invoked as follows to decompile Python bytecode to Python source code via Pycdc:

  • pycdc.exe -c -v "3.11.5" "vvs.pyc" > "vvs.py"

This will produce the decompiled Python source code shown in Figure 4.

Screenshot of a line of Python code involving an import statement from a library named "pyarmor," with obscured additional text.
Figure 4. Decompiled vvs Python source code.

We then analyze the last function argument, which can be extracted via Python 3's ast.NodeVisitor.

Step Three: Unraveling Pyarmor Obfuscation

The payload begins with the Pyarmor header shown in Figure 5.

A screenshot displaying a section of a hexadecimal code with ASCII characters on the right side, including a visible string "PY00744...
Figure 5. Pyarmor header, with particular fields of interest highlighted.

Cryptography is performed throughout using the Advanced Encryption Standard (AES) algorithm with a 128-bit key, operating in Counter (CTR) mode with an initial value of two (i.e., AES-128-CTR). Table 1 shows the breakdown of the fields.

Offsets Values Description
0x00 … 0x07 PY007444 File signature containing the unique license number
0x09 03 Python major version
0x0a 0b Python minor version
0x14 09 Protection type:

  • 09 if Pyarmor BCC mode (briefly explained in the next section) is enabled
  • 08 otherwise
0x1c … 0x1f 40 00 00 00 Start of the ELF payload, in little-endian format
0x24 … 0x27 12 c9 06 00 First four bytes of the AES-128-CTR nonce
0x2c … 0x33 dc d2 98 a1 ea 11 fd f4 Remaining eight bytes of the AES-128-CTR nonce
0x38 … 0x3b a0 7f 02 00 End of the ELF payload, in little-endian format

Table 1. Breakdown of fields present in the Pyarmor header.

This same pattern (highlighted in yellow) repeats itself once again after the end of the ELF payload, for extracting and decrypting the Pyarmor bytecode payload.

BCC Mode

BCC (likely an abbreviation of ByteCode-to-Compilation) mode converts most “functions and methods in the scripts to equivalent C functions. Those C functions will be compiled to machine instructions directly, then called by obfuscated scripts.” (Source: Pyarmor documentation.)

BCC mode is invoked as follows: pyarmor gen --enable-bcc script.py.

These converted C functions are stored in a separate ELF file, produced alongside the Pyarmor-marshaled bytecode.

The mapping of Python constants to BCC functions can be obtained using this implementation. For instance, in the Python method get_encryption_key(browser_path), the constant __pyarmor_bcc_58580__ maps to the BCC function bcc_180, whose function body is located at offset 0x4e70 of the ELF file.

Referencing this analysis of the ELF file contents, especially the bcc_ftable structure, Figure 6 shows part of the BCC function bcc_180 decompiled:

Screenshot depicting two side-by-side images of complex Python code examples on a computer screen.
Figure 6. Decompilation of the BCC function bcc_180.

We can roughly recover an equivalent of the original code of the Python method get_encryption_key, as shown in Figure 7.

Screenshot of Python code in a text editor, showing a function to retrieve the decryption key for Chromium browsers with highlighted syntax.
Figure 7. Equivalent Python code of the get_encryption_key method.

Marshaled Bytecode Format

Pyarmor 9 marshaled bytecode differs from standard Python 3.11 bytecode in several ways. Firstly, the 0x20000000 bit is set in the co_flags field to indicate that it is Pyarmor obfuscated. Secondly, there is an extra data field, whose length is denoted by the value of its first byte.

Moreover, deopt_code() needs to be disabled for the bytecode sequence to be successfully decrypted. We will discuss the cryptographic parameters in a later section of this article.

Code Object Structure

Pyarmor code objects are specially crafted, in that they should contain certain artifacts. It is common to expect to find the LOAD_CONST __pyarmor_enter_*__ instruction in the preamble and the LOAD_CONST __pyarmor_exit_*__ instruction in the trailer of the disassembly. These two instructions would wrap the encrypted bytecode, as shown in Table 2.

Operation Argument
…
LOAD_CONST __pyarmor_enter_58592__
LOAD_CONST \x00\x00\x00\x00\x00\x00\x00\x00\x05\x00\x00\x20\x16\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
… encrypted bytecode sequence (to be examined in the next section) …
LOAD_CONST __pyarmor_exit_58593__
LOAD_CONST \x00\x00\x00\x00\x00\x00\x00\x00\x05\x00\x00\x20\x16\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
…

Table 2. Pyarmor-related instructions in the disassembly listing of <module>.

Once the encrypted bytecode sequence is decrypted, it could reveal encrypted strings or BCC function invocations. Encrypted strings (reviewed in a later section of this article) are preceded by a LOAD_CONST __pyarmor_assert_*__ instruction. There is also the LOAD_CONST __pyarmor_bcc_*__ instruction to invoke a BCC function (reviewed earlier in this article).

Code Object Encryption

Bytecode sequences between the start marker (__pyarmor_enter_*__) and the end marker (__pyarmor_exit_*__) are AES-128-CTR encrypted. The associated AES key (273b1b1373cf25e054a61e2cb8a947b8) is extracted from the Pyarmor runtime DLL linked to the unique license number.

On the other hand, the corresponding AES nonce exclusive OR (XOR) key (2db99d18a0763ed70bbd6b3c) is only specific to the Pyarmor bytecode payload, for which there is an implementation of the logic for extracting this value. This key is XORed with the 12 bytes at the end marker (__pyarmor_exit_*__) to produce the correct AES nonce used in the decryption.

String Encryption

Similarly, string constants longer than eight characters are AES-128-CTR encrypted (known as "mixed" in Pyarmor terminology”). The associated AES key is also 273b1b1373cf25e054a61e2cb8a947b8, but this time, the corresponding AES nonce (692e767673e95c45a1e6876d) is computed from the Pyarmor runtime DLL linked to the unique license number.

Additionally, a 0x81 prefix value denotes that the string constant is encrypted. Otherwise, a 0x01 prefix value is used instead.

Now that the Pyarmor protection is disarmed, we shall proceed to cover some of the key capabilities of the VVS stealer in the next section.

Malware Capabilities

With the layers of Pyarmor obfuscation — including the BCC mode and AES-128-CTR string encryption — successfully stripped away, we were able to expose the underlying Python logic. This deobfuscated code revealed a stealer designed not just for data exfiltration, but for active session hijacking and persistence. The following section details the specific operational capabilities of the VVS stealer that were uncovered during this analysis.

The malware sample expires after 2026-10-31 23:59:59. It will stop working by terminating itself prematurely.

The malware sample performs all HTTP requests by sending the fixed User-Agent string Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36.

We shall now provide an overview of the main malware capabilities, as advertised on Telegram.

Discord Data

The malware sample first searches for potential encrypted Discord tokens. Encrypted Discord tokens are strings beginning with the prefix dQw4w9WgXcQ:. The malware sample uses regular expressions to form a pattern from this string prefix. It then uses this pattern to search inside the contents of files with the .ldb or .log file extensions, stored within the LevelDB directory.

Next, the malware sample decrypts the encrypted_key value in the Local State file, via the Data Protection Application Programming Interface (DPAPI). With this decrypted encrypted_key value as the AES key parameter, the malware sample applies the AES algorithm, operating in Galois/Counter Mode (GCM) mode, on the encrypted Discord tokens, to decrypt them.

The malware sample then uses the decrypted Discord tokens to query various Discord application programming interface (API) endpoints for user information, including:

  • Nitro subscription (Discord Premium features)
  • Payment methods
  • User ID
  • Username
  • Email
  • Phone number
  • Friends
  • Guilds
  • Multifactor authentication (MFA) status
  • Locale
  • Verification status
  • Avatar image
  • IP address (via the ipify service)
  • Computer name

After gathering all this information, the malware sample proceeds to exfiltrate it in JavaScript Object Notation (JSON) format. The exfiltration takes place via HTTP POST requests to the predefined webhook endpoints (%WEBHOOK% environment variable and hard-coded fall back URLs).

Webhooks are “a low-effort way to post messages to channels in Discord. They do not require a bot user or authentication to use.” (Source: Discord Developer Portal.)

Discord Injection

The code responsible for this functionality is in class Inj, likely an abbreviation of Injection.

In this class, the malware sample first kills running Discord application processes, if any are running. It then downloads the JavaScript (JS) payload from a remote file named injection-obf.js (the -obf suffix likely stands for an obfuscated version of the script), replacing the webhook endpoint URL and discord_desktop_core, into the Discord application directory. This JS file is obfuscated by the JavaScript Obfuscator Tool and can be deobfuscated via the Obfuscator.io Deobfuscator.

Some of the main functionality of the injected JS code is highlighted in the following screenshots, starting with its configuration and exfiltration code snippets, shown in Figure 8.

Screenshot of a JavaScript configuration file involving URLs and paths related to a Discord API and a remote authorization gateway. The code is displayed in a text editor with syntax highlighting.
Figure 8. Injected JS configuration and exfiltration.

Figure 8 shows the injected JS code responsible for establishing persistence in the Discord application, based on the Electron framework. This framework uses Atom Shell Archive Format (ASAR) archives to bundle the entire application's codebase into a single file, shown in Figure 9.

Screenshot of a code snippet related to a software initialization function, mentioning paths and configuration for "app.js", "index.js", and "discord.js". The code is written in JavaScript.
Figure 9. Injected JS code to perform persistence.

Figure 10 shows the injected JS code responsible for monitoring network traffic via the Chrome DevTools Protocol (CDP).

Screenshot of software code in an editor, displaying a network-related JavaScript function.
Figure 10. Injected JS code to monitor network traffic.

Figure 11 shows supporting utility functions and event hooks in the injected JS code. Event hooks are callback functions that execute upon the Discord application user performing a specific action. The actions of interest are when the user views their backup codes, changes their password or adds a payment method. The callback functions linked to these actions are capable of collecting Discord user account and billing information.

Screenshot of a computer code editor displaying multiple lines of JavaScript code, involving functions related to user data handling and API requests.
Figure 11. Injected JS code of utility functions and event hooks.

Thereafter, the malware sample restarts a compromised Discord application process via Update.exe, which it does with the command-line switch --processStart.

Web Browser Data

The malware sample targets a list of web browser applications, including:

  • Chrome
  • Edge
  • 7Star
  • Amigo
  • Brave
  • CentBrowser
  • Discord
  • Epic Privacy Browser
  • Iridium
  • Kometa
  • Lightcord
  • Mozilla Firefox
  • Opera
  • Orbitum
  • Sputnik
  • Torch
  • Uran
  • Vivaldi
  • Yandex

To these targets, the malware sample extracts the following data, where present:

  • Autofill
  • Cookies
  • History
  • Passwords

Once these data are extracted, the malware sample prepares it for exfiltration by compressing it into a single ZIP archive file named <USERNAME>_vault.zip. It then exfiltrates this file via HTTP POST requests to the predefined webhook endpoints, similar to the Discord data exfiltration process.

Startup Persistence

The malware sample copies itself to the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup folder to achieve startup persistence. The malware remains on the user’s device, enabling it to continue exfiltrating data if, for example, the user attempts to install a fresh copy of the Discord application.

Fake Error

The malware sample uses the Win32 API, specifically the MessageBoxW function in the User32.dll library, to display a modal message box about a fake fatal error that requires restarting the computer. A modal message box is a small dialog window requiring user interaction before the application can continue, as shown in Figure 12.

Error message dialog box displaying "Fatal Error" with error code 0x80070002 and a suggestion to restart the computer. An "OK" button is present for acknowledgement.
Figure 12. A fake message box instructing the victim to restart the computer.

Conclusion

VVS stealer demonstrates how tools like Pyarmor, which can be used for legitimate purposes, can also be leveraged to build stealthy malware aimed at hijacking credentials for popular platforms such as Discord. Its emergence signals a need for defenders to strengthen monitoring around credential theft and account abuse.

Palo Alto Networks Protection and Mitigation

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

The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.

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

Cortex XDR and XSIAM prevents the threats described in this article by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

SHA-256 hashes of malware samples:

  • 307d9cefa7a3147eb78c69eded273e47c08df44c2004f839548963268d19dd87
  • 7a1554383345f31f3482ba3729c1126af7c1d9376abb07ad3ee189660c166a2b
  • c7e6591e5e021daa30f949a6f6e0699ef2935d2d7c06ea006e3b201c52666e07

Discord webhook URLs

  • hxxps[://]ptb.discord[.]com/api/webhooks/1360401843963826236/TkFvXfHFXrBIKT3EaqekJefvdvt39XTAxeOIWECeSrBbNLKDR5yPcn75uIqKEzdfs9o2
  • hxxps[://]ptb.discord[.]com/api/webhooks/1360259628440621087/YCo9eVnIBOYSMn8Xr6zX5C7AJF22z26WljaJk4zr6IiThnUrVyfWCZYs6JjSC12IC8c0

Additional Resources

Who Does Cybersecurity Need? You!

Posted on by Samantha Stallings

Dispelling Stereotypes in the Field

All industries have their stereotypes. For instance, the adversaries of cyber intelligence analysts carry the stereotype of a hacker in a hoody, hunched over their laptop in the dark. Are there other stereotypes or assumptions about those who work in the field cyber intelligence?

To those outside of the industry, hearing “I work in cybersecurity” may sound cool – or intimidating. Outsiders may envision people in the field as:

  • Solely consisting of STEM majors: perhaps the super smart who double-majored in computer science and network engineering
  • People who learn programming languages easily and would be polyglots in another life
  • Single-minded nerds interested in computers from an early age, who were building their first computer before they hit high school
  • Those who effortlessly bootstrapped their way in, starting in a help desk role and quickly gaining momentum

Regardless of an individual’s path, there is an aura around cybersecurity that glows with the rigor of hard sciences. It isn’t helped by the fact that hacker stuff is downright neat.

From Art School to Threat Intelligence Research

When I was in art school in the late aughts, I never considered that I would end up in cybersecurity as I walked around listening to Animal Collective or buying secondhand clothes in the more punk neighborhoods of Chicago. A course in advanced typography wasn't going to fling me into the realm of malware. Taking attentive notes at a lecture by Chip Kidd wasn’t going to be a stepping stone to pentesting.

However, the cybersecurity field is big. Just as NASA isn’t populated with only astronauts, cybersecurity isn’t populated with only threat intelligence analysts. While astronauts do have one of the most imagination-stirring roles in existence, they need support from engineers, news chiefs and more, all the way down to the graphic designers who design the collectable mission patches. Take the case of Dr. Sian Proctor: She is a geologist who taught in higher education for years, and through a passion for planetary science and space became an analog astronaut, meaning she conducted simulated space missions on earth. Her research lays groundwork for future visits to Mars. (She did, eventually, become an astronaut on a SpaceX mission, but not before publishing a cookbook of the food she ate on these earthside Mars missions.)

Like Dr. Proctor, in my role as a Technical Writing Manager, my skills are needed to make the threat research we publish shine. To continue my analogy, I may not be an astronaut myself, but I still support the “astronauts” of threat intelligence and make sure their work launches high above the stratosphere…maybe even into cyberspace (wink, wink).

Cybersecurity's Strength Is People Like You

The bottom line is that if you’re a marketer, cybersecurity needs you. If you’re a copywriter, a product manager or a social media wiz, cybersecurity needs you. If you’re told you’re “terminally online” in your professional capacity, then cybersecurity needs you.

This field is for people who are excited by what’s just over the horizon as technology continues to change. You’re more than welcome to join us.

From Linear to Complex: An Upgrade in RansomHouse Encryption

Posted on by Samantha Stallings

Executive Summary

RansomHouse is a ransomware-as-a-service (RaaS) operation run by a group that we track as Jolly Scorpius. Recent samples of the associated binaries used in RansomHouse operations reveal a significant upgrade in encryption. This article explores the upgrade of RansomHouse encryption and the potential impact for defenders.

Jolly Scorpius uses a double extortion strategy. This strategy combines stealing and encrypting a victim's data with threats to leak the stolen data.

The scale of the group's operations is significant. At the time of this article, at least 123 victims were listed on the RansomHouse data leak site as having their data disclosed or sold since December 2021.

This group has disrupted critical sectors including healthcare, finance, transportation and government. The consequences of these intrusions include significant financial losses, major data breaches and erosion of public trust in the affected organizations.

To better understand RansomHouse operations, we review its attack chain. We also examine the upgrade to this ransomware's encryption from a simple, single-phase linear technique to a more complex, multi-layered method.

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

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

Related Unit 42 Topics Ransomware, ESXi

Actor Roles and the Attack Chain

Despite Jolly Scorpius positioning itself as a group that exposes corporate vulnerabilities, its actions reveal a straightforward extortion business. To better understand its RansomHouse operations, we can identify the specific actor roles, discern separate phases of the attack chain and determine how the roles and phases relate to each other.

Figure 1 illustrates these roles and their positions in the attack chain.

Diagram of the RansomHouse attack chain with two sections titled "Roles and Attack Chain". Under "Roles," there are icons representing an Operator, an Attacker, and a Victim. Below, the "Attack Chain" is divided into four steps: 1. Develop, showing icons for Tools and Leak website. 2. Infiltrate, indicating Initial access and Lateral movement. 3. Exfiltrate & Deploy, with icons for MrAgent and Mario alongside VMWare. 4. Extort is symbolized by a server and communication between two persons.
Figure 1. Actor roles and how they relate to phases of the RansomHouse attack chain.

The RansomHouse attack chain involves three distinct roles:

  • Operator: Operates the RaaS
  • Attacker: Deploys the ransomware
  • Victim: Targeted by the attacker

Operators are responsible for establishing and maintaining the RaaS, including the development of tools for data encryption and other functions. Individuals in this role manage the data leak site and architecture for victims to negotiate ransom payments. This includes managing the cryptocurrency wallets for ransom collection and laundering.

Attackers are typically known as affiliates because they are separate threat actors from the operators. As ransomware services rise and fall, attackers can switch their affiliation to different RaaS groups. Attackers are responsible for gaining initial access, moving laterally, exfiltrating data and deploying the ransomware.

Attackers for RansomHouse are known for targeting VMware ESXi infrastructure, a common enterprise-grade hypervisor platform. RansomHouse attackers specifically target ESXi because compromising this platform allows them to encrypt dozens or hundreds of virtual machines at once, causing maximum operational disruption.

The attack chain reflects a multi-faceted strategy to pressure RansomHouse victims. This strategy involves harvesting sensitive information, encrypting select data, publishing victim identities and threatening to release their sensitive data. The RansomHouse attack chain can be broken into four phases:

  1. Develop
  2. Infiltrate
  3. Exfiltrate and deploy
  4. Extort

Each phase involves at least one of the three roles.

Phase 1: Develop

In this phase, RansomHouse operators function as the backend providers, responsible for developing all aspects of the RaaS. Crucially, the operators typically do not conduct the initial intrusions. Instead, they rely on their affiliates (i.e., the attackers) to leverage the RaaS services developed in this phase.

Phase 2: Infiltrate

In this phase, attackers compromise victims through spear phishing emails or other social engineering techniques. In addition to email, initial access vectors include vulnerable systems in a victim's environment that attackers can compromise through zero-day or other exploits.

After achieving initial access, attackers typically use third-party tools and frameworks to explore the victim's network. The remainder of the infiltration phase includes reconnaissance to map the environment, privilege escalation, lateral movement and identifying valuable or sensitive information.

Phase 3: Exfiltrate and Deploy

Once attackers affiliated with RansomHouse have infiltrated a victim's environment, they exfiltrate sensitive data and deploy the ransomware. Typical data exfiltration techniques involve file compression and file transfer utilities, and attackers usually send data to servers under their control.

The RansomHouse RaaS uses a modular architecture that consists of two components:

  • Management tool
  • Encryptor

RansomHouse uses a management tool called MrAgent, designed to automate and track ransomware deployments across different hypervisor systems in an ESXi environment.

RansomHouse uses an encryptor known as Mario. After encrypting files, Mario drops a ransom note that contains instructions on how victims can recover their data.

Phase 4: Extort

Once a victim's data has been stolen and encrypted, the attack chain transitions to the extortion phase. RaaS operators are generally responsible for this phase, which often involves negotiations via dedicated chat rooms. Operators validate their threats through strategic information disclosure on platforms like Telegram and the RansomHouse data leak site.

Now that we better understand the RansomHouse attack chain, let's review how the components of this ransomware are used in attacks.

RansomHouse Components Used in Attacks

The two components of this ransomware (i.e., MrAgent and Mario) are specifically engineered to compromise virtualized environments. Figure 2 illustrates how these tools are used in a RansomHouse attack in an ESXi network.

Flowchart showing a cybersecurity attack process. Includes an "Attacker (RansomHouse) C2 Server" connecting and sending commands, which deploy deployment tools and ransomware via "VMware ESXi Hypervisor" to target "Virtualized Datastores" including "VM Files" like .vmdk and .vmx, affecting VMs designated as Web Server, Database, and Domain Controller.
Figure 2. Flow chart of how RansomHouse components are used in an ESXi environment.

After infiltrating the environment, an attacker deploys MrAgent onto the victim's ESXi hypervisor. MrAgent establishes a persistent connection to the attacker's command-and-control (C2) server.

Attackers then issue commands from the C2 server to MrAgent for further operations like data exfiltration. After the data is exfiltrated, attackers instruct MrAgent to download and execute the Mario encryptor, which runs directly on the hypervisor to encrypt virtual machine (VM) files.

Since MrAgent is the first component in the attack, let's review how it works.

MrAgent: The RansomHouse Deployment Tool

As the primary tool for RansomHouse operations, MrAgent provides attackers with persistent access to a victim's environment and simplifies managing compromised hosts at scale. This management is accomplished through various functions of the tool.

Functions

The main functions of MrAgent are:

  • Acquiring host identifiers
  • Acquiring the host's IP address
  • Disabling the firewall
  • Communicating with the attacker's C2 server

While an analysis by Trellix has documented the commands MrAgent uses for these functions, we can review them to better understand its operations.

Commands for acquiring host identifiers are as follows:

  • For the hostname: uname -a
  • For the MAC address: esxcli --formatter=csv network nic list

The command to acquire the host's IP address is:

  • esxcli --formatter=csv network ip interface ipv4 get

The command to disable the firewall is:

  • esxcli network firewall set --enabled false

MrAgent's function to check for connectivity to the C2 server runs in an infinite loop. During these connectivity checks, MrAgent can receive various instructions from the C2 server. Table 1 lists examples of these instructions and their function.

Instruction Function
Abort Aborts the start of encryption if the hypervisor is in its delay phase after a reboot
Abort_f Kills threads spawned by MrAgent
Config Overwrites the local configuration used for ransomware deployment
Exec Starts the ransomware deployment, changing the root password, disabling vCenter remote management via /etc/init.d/vpxa stop and starting the encryption of VMs
Info Retrieves ESXi host information
Run Executes arbitrary commands on the ESXi host by writing to the file ./shmv
Remove Removes content from the ESXi host by executing the command rm -rf [filename or path]
Quit Kills and removes the MrAgent binary using rm -f
Welcome Sets the ESXi welcome message on the host via esxcli system welcomemesg set -m="[text of message]"

Table 1. Examples of MrAgent instructions from an attacker's C2 server.

These functions enable MrAgent to deploy the Mario encryptor.

Characteristics

To impede reverse engineering, the MrAgent binary is sometimes modified with junk code, but this basic obfuscation does not alter its fundamental operations. For state management of the compromised environment, MrAgent uses two internal JSON structures to store its runtime configuration and status, with access synchronized by a mutex.

Mario: The RansomHouse Encryptor

MrAgent deploys Mario to accomplish the operation's core function of encrypting critical VM files in the ESXi hypervisor. Our research uncovered two distinct versions of Mario that reveal an evolution in its encryption methods.

Both versions follow the same overall execution flow:

  1. Create the ransom note
  2. Target file extensions
  3. Encrypt files
  4. Report statistics

Creating the Ransom Note

The first step in Mario's execution flow is creating a ransom note. The ransom note is named How To Restore Your Files.txt and is located in the directory of any files that Mario encrypts.

Mario opens the ransom note in write mode and saves text to the file that provides instructions for victims to recover their files. Figure 3 below shows an example of this note.

RansomHouse ransom note. Image of a text file titled "How To Restore Your Files.txt" open in Notepad with ASCII art depicting Super Mario alongside instructions for contacting a provided email and Telegram channel, indicating a ransomware notice from the group named "RansomHouse."
Figure 3. Example of a ransom note generated by a Mario sample.

Targeting File Extensions

The next step is directory traversal and extension targeting. Mario requires attackers to specify the directory path of the files to encrypt. Within the specified directory, Mario targets virtualization files based on the filename extensions listed in Table 2.

Extension File Description
ova Open Virtual Appliance (OVA): a single-file distribution of the OVF file package
ovf Open Virtualization Format (OVF): an open standard for packaging and distributing virtual software
vbk Veeam Backup (VBK) file: stores backup copies of a VM's data at a specific point in time
vbm Veeam Backup Metadata (VBM) file: stores metadata about a VBK file
vib VMware Installation Bundle (VIB): a package file for installing or upgrading ESXi hosts
vmdk Virtual Machine Disk (VMDK) file: used in virtual machines like VMware and VirtualBox
vmem VMware Memory (VMEM) file: a backup of a VM's RAM content from the host system
vmsd VMware Snapshot Metadata (VMSD) file: stores metadata about each VM snapshot
vmsn VMware Snapshot State (VMSN) file: stores the running state of a VM at the time of snapshot
vswp VMware Swap (VSWP) file: swaps memory pages to the hard drive when a host is low on physical memory

Table 2. File extensions targeted by Mario.

Mario iterates through each of the files in the specified directory path, checking for the targeted extensions. During this iteration process, Mario ignores various entries in the directory, like . (current directory) and .. (parent directory).

The encryptor also ignores files with the following strings anywhere in the filename, even if the filename has a targeted extension:

  • .marion
  • .emario
  • .lmario
  • .nmario
  • .mmario
  • .wmario

This exclusion is likely to avoid double-encrypting files, to avoid the possibility of the files becoming corrupted and unrecoverable.

Figure 4 shows the extensions from Table 2 when we tested a Mario sample discovered earlier this year.

Terminal screen showing a program named 'e_mario.out' running an encryption process on various files with extensions such as vmsn, vbm, vmdk, vmxf, vsv, vmsd, and vswp.
Figure 4. Mario sample targeting file extensions associated with virtualization.

Targeting an organization's virtual infrastructure and backups is a known RansomHouse tactic. Both approaches are intended to inhibit data recovery if a victim does not pay the ransom.

Encrypting Files

While encrypting targeted files, Mario displays its progress, as Figure 4 above shows. Encrypted files are renamed, appending the existing filename with an extension that includes the string mario. Figure 5 shows an example of .emario as the extension for encrypted files after running a Mario sample.

A screenshot of a terminal window displaying the output of the "ls -a" command, listing various files including ones with the suffix ".emario". Highlighted in blue is the directory named "test_subdirectory".
Figure 5. Listing the directory content reveals encrypted files with the .emario extension.

Reporting Statistics

After Mario finishes encrypting targeted files, it displays statistics of the encryption results. These statistics, in order, are:

  • The number of files that could not be encrypted
  • The number of files that were encrypted
  • The number of skipped files
  • The total file count
  • The amount of data that was encrypted

Figure 6 shows an example of a statistics report after running a Mario sample.

Screen capture of a terminal displaying the output of a file decryption process, listing statistics including encrypted files processed, skipped files, and total data tested.
Figure 6. Example of a Mario sample reporting its encryption statistics.

While all known samples of Mario follow the same execution flow, the process is more complex in recent Mario samples. The next section reviews the differences between the earlier and later Mario samples, revealing an upgrade in Mario's encryption methods.

Mario's Upgraded Encryption

We identified two versions of Mario based on the differences in encryption routines among currently known samples. Comparing these two versions reveals that developers have updated Mario to use a substantially more complex encryption method. We refer to these two versions as:

  • Original version
  • Upgraded version

Comparing blocks of disassembled code for the encryption routine, there is a noticeably more complex block of functions in the upgraded version. Figure 7 compares the encryption code blocks for these two versions, showing noticeably more sections in the upgraded version on the right than in the original version on the left.

Comparison of encryption code blocks from a sample of original Mario (left) and upgraded Mario (right), with lines and blocks highlighted in green.
Figure 7. Comparison of encryption code blocks between the original and upgraded versions of Mario.

To demonstrate the upgrade in Mario's encryption, we compare code from samples of the two versions across the following functions:

  • Encryption
  • Memory layout and buffer management
  • File processing
  • Output format

Improvements in these functions make the upgraded version of Mario significantly more efficient and resilient to analysis than the original version.

Encryption

The original version of Mario has a straightforward and basic encryption routine. Figure 8 shows disassembled code from the original version. This code performs a single pass to transform a file's data from unencrypted to encrypted.

Screenshot of programming code in an IDE, featuring multiple lines of assembly language with annotations explaining each part of the code. The code includes operations like memory setting and transformation setup.
Figure 8. Disassembled code for the original version's single-pass file transformation.

In contrast, the upgraded version of Mario features a two-stage file transformation that includes a secondary encryption key. Figure 9 shows disassembled code from a sample of the upgraded version of Mario, revealing this more complex encryption process.

Screenshot of a computer screen displaying code in an IDE with annotations explaining key encryption steps, and a flowchart diagram illustrating data processing steps on the lower right corner.
Figure 9. Disassembled code revealing the upgraded version's more complex file transformation.

The upgraded version's code reveals a two-factor encryption scheme where the file is encrypted with both a primary key and a secondary key. Data encryption is processed separately for each key. This significantly increases the difficulty of decrypting the data without both keys.

Figure 10 shows that the upgraded version of Mario uses random values to generate a 32-byte primary encryption key and an 8-byte secondary encryption key.

A screenshot of a computer code snippet displaying various assembly language instructions related to cryptographic operations such as entropy generation and key management. The code includes comments for clarification on the functionality of each line.
Figure 10. Disassembled code showing key generation used by Mario's upgraded version.

These changes represent a significant upgrade in Mario's encryption.

Memory Layout and Buffer Management

When discussing memory layout and buffer management, we must understand stack frames and buffers. In this case, buffers are portions of the stack frame specified by an offset value.

The original version of Mario uses the following stack frames and buffer values during its encryption process:

  • Upgraded version stack frame size: 0x1408 bytes
  • Key buffer offsets: var_1400 (primary), var_130 (transformation)
  • Chunk size: Fixed at 0xA00000 with no dynamic adjustments

This indicates a relatively straightforward, simple process for transforming files to an encrypted state. In contrast, stack frame and buffer values for the upgraded version of Mario show a more complex structure that is smaller and more efficient:

  • Upgraded version stack frame size: 0x1268 bytes
  • Multiple buffer offsets:
    • var_1150: Primary encryption context
    • var_A0: Intermediate transformation buffer
    • var_20: Secondary key storage (8 bytes)
    • var_40: Header storage for encrypted files

These stack frame and buffer values are used in a process where:

  • Initial data is read into the primary buffer (ptr)
  • The data is transformed using the primary key at var_1150
  • It is further processed with the secondary key at var_20
  • Final encrypted data includes a header from var_40

The careful organization of these buffers confirms the layered approach of Mario's upgraded version.

File Processing

Mario's original version uses a straightforward approach to file processing. It's a linear process that encrypts the files as sequential fixed-size segments in a loop. After encrypting each segment, the code checks if the combined size of the processed segments exceeds a specified threshold. Once it passes that threshold, the code jumps from the loop to a different function.

Figure 11 illustrates this linear process in the disassembled code.

Screenshot of a computer code in an IDE, displaying lines for file size comparison and conditional jumps with comments.
Figure 11. Disassembled code showing a linear process for encryption in Mario's original version.

Code in Mario's upgraded version reveals an encryption method that uses chunk processing with dynamic sizing. Figure 12 shows an example.

A screenshot of assembly language code displayed in a text editor with highlighted syntax. The code includes various operations such as move, shift, and multiply with registers and constants.
Figure 12. Disassembled code showing chunked processing with dynamic for encryption in Mario's upgraded version.

Comparing the processing logic between these two versions, we find significant differences.

Mario's original version uses a simpler programming loop that processes files in fixed segment lengths up to a threshold of 536,870,911 bytes, as noted in Figure 11. This version simply reports when the encryption is complete without showing any progress.

In comparison, Mario's upgraded version implements a more robust file processing scheme for encryption that uses:

  • Variable segment lengths, with a size threshold of 8 GB
  • Calculations to determine chunk size and offsets
  • A sparse encryption technique where it encrypts only certain blocks of a file at specific offsets

In addition, the upgraded version of Mario displays the progress of encrypting chunks of each file, as noted below in Figure 13.

A screenshot of computer code on a dark background with syntax highlighting, indicating variables and a string that includes 'Processed chunk."
Figure 13. Disassembled code in the upgraded version of Mario to display the progress of chunk processing.

The chunked processing of Mario's upgraded version makes static analysis more difficult because:

  • It processes files non-linearly
  • It uses complex mathematical formulas to determine processing order
  • It employs different strategies based on file size

Output Format

In addition to displaying the processed chunks of files when encrypting them, Mario's upgraded version also provides a more detailed summary when the encryption of each file is finished.

As previously stated, the original version simply reports that the encryption of a file is finished. Figure 14 shows this in the disassembled code.

A screenshot of computer code with syntax highlighting, displaying various commands and a variable named 'aDoneS'. The text has a dark background and includes colors such as purple and orange for highlighting.
Figure 14. Code from the original version of Mario to report when a file is finished processing.

Mario's upgraded version includes more information when each file is finished processing, as Figure 15 below shows in the disassembled code.

Screenshot of computer code in an IDE, highlighting the command 'aDoneSLdLdLdLd' in a purple box.
Figure 15. Code from the upgraded version of Mario to report when a file is finished processing.

Ultimately, the core functionality of these two Mario samples (the original version and the upgraded version) remains the same. Both samples encrypt files and rename them by adding .emario extension. But the upgraded version implements a more complex and potentially more secure encryption methodology with selective file processing.

Conclusion

The upgrade in encryption used by RansomHouse RaaS, going from a simple linear model to a more complex multi-layered approach, signals a concerning trajectory in ransomware development. This demonstrates how threat actors are updating their techniques to enhance effectiveness.

This upgrade is built on several key technical improvements:

  • A two-factor encryption scheme that significantly increases the difficulty of decryption without both keys
  • Chunked file processing with dynamic sizing instead of a simpler method
  • The new file processing makes static analysis and reverse engineering more challenging

Threat actors could view this as a useful path for future ransomware variants. As other ransomware groups adopt these more sophisticated methods, the ransomware threat landscape will become more resilient to security controls. This upgrade underscores the need to adopt more dynamic, adaptive strategies capable of countering the next generation of complex and evasive threats.

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 Xpanse and the ASM add-on for XSIAM provide detection of VMware ESXi infrastructure exposed to the public internet via “VMware ESXi” and “Insecure VMware ESXi” attack surface rules. In addition to these, there is also a post-compromise detection attack surface rule for “ESXiArgs Ransomware Infection.” This can detect ransom notes injected by malicious actors, as well as other indicators of ransomware infection impacting internet-exposed ESXi servers.

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

  • SHA256 hash: 0fe7fcc66726f8f2daed29b807d1da3c531ec004925625855f8889950d0d24d8
  • File description: Sample of the upgraded version of Mario
  • SHA256 hash: ​​d36afcfe1ae2c3e6669878e6f9310a04fb6c8af525d17c4ffa8b510459d7dd4d
  • File description: Sample of the original version of Mario
  • SHA256 hash: 26b3c1269064ba1bf2bfdcf2d3d069e939f0e54fc4189e5a5263a49e17872f2a
  • File description: MrAgent sample
  • SHA256 hash: 8189c708706eb7302d7598aeee8cd6bdb048bf1a6dbe29c59e50f0a39fd53973
  • File description: MrAgent sample

Additional Resources

 

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

Default Heading

Read the article Right Arrow