In April 2025, Microsoft patched 121 vulnerabilities in its products. According to the company, only one of them was being used in real-world attacks at the time the patch was released: CVE-2025-29824. The exploit for this vulnerability was executed by the PipeMagic malware, which we first discovered in December 2022 in a RansomExx ransomware campaign. In September 2024, we encountered it again in attacks on organizations in Saudi Arabia. Notably, it was the same version of PipeMagic as in 2022. We continue to track the malware’s activity. Most recently, in 2025 our solutions prevented PipeMagic infections at organizations in Brazil and Saudi Arabia.
This report is the result of a joint investigation with the head of vulnerability research group at BI.ZONE, in which we traced the evolution of PipeMagic – from its first detection in 2022 to new incidents in 2025 – and identified key changes in its operators’ tactics. Our colleagues at BI.ZONE, in turn, conducted a technical analysis of the CVE-2025-29824 vulnerability itself.
Background
PipeMagic is a backdoor we first detected in December 2022 while investigating a malicious campaign involving RansomExx. The victims were industrial companies in Southeast Asia. To penetrate the infrastructure, the attackers exploited the CVE-2017-0144 vulnerability. The backdoor’s loader was a trojanized version of Rufus, a utility for formatting USB drives. PipeMagic supported two modes of operation – as a full-fledged backdoor providing remote access, and as a network gateway – and enabled the execution of a wide range of commands.
In October 2024, organizations in Saudi Arabia were hit by a new wave of PipeMagic attacks. This time, rather than exploiting vulnerabilities for the initial penetration, the attackers used a fake ChatGPT client application as bait. The fake app was written in Rust, using two frameworks: Tauri for rendering graphical applications and Tokio for asynchronous task execution. However, it had no user functionality – when launched, it simply displayed a blank screen.
| MD5 | 60988c99fb58d346c9a6492b9f3a67f7 |
| File name | chatgpt.exe |
Blank screen of the fake application
At the same time, the application extracted a 105,615-byte AES-encrypted array from its code, decrypted it, and executed it. The result was a shellcode loading an executable file. To hinder analysis, the attackers hashed API functions using the FNV-1a algorithm, with the shellcode dynamically resolving their addresses via GetProcAddress. Next, memory was allocated, necessary offsets in the import table were relocated, and finally, the backdoor’s entry point was called.
One unique feature of PipeMagic is that it generates a random 16-byte array used to create a named pipe formatted as:
.pipe1.<hex string>. After that, a thread is launched that continuously creates this pipe, attempts to read data from it, and then destroys it. This communication method is necessary for the backdoor to transmit encrypted payloads and notifications. Meanwhile, the standard network interface with the IP address
127.0.0.1:8082 is used to interact with the named pipe.
To download modules (PipeMagic typically uses several plugins downloaded from the C2 server), attackers used a domain hosted on the Microsoft Azure cloud provider, with the following name:
hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com.
PipeMagic in 2025
In January 2025, we detected new infections in Saudi Arabia and Brazil. Further investigation revealed connections to the domain
hxxp://aaaaabbbbbbb.eastus.cloudapp.azure[.]com, which suggested a link between this attack and PipeMagic. Later, we also found the backdoor itself.
Initial loader
| MD5 | 5df8ee118c7253c3e27b1e427b56212c |
| File name | metafile.mshi |
In this attack, the loader was a Microsoft Help Index File. Usually, such files contain code that reads data from .mshc container files, which include Microsoft help materials. Upon initial inspection, the loader contains obfuscated C# code and a very long hexadecimal string. An example of executing this payload:
c:windowssystem32cmd.exe "/k c:windowsmicrosoft.netframeworkv4.0.30319msbuild.exe c:windowshelpmetafile.mshi"
Contents of metafile.mshi
The C# code serves two purposes – decrypting and executing the shellcode, which is encrypted with the RC4 stream cipher using the key
4829468622e6b82ff056e3c945dd99c94a1f0264d980774828aadda326b775e5 (hex string). After decryption, the resulting shellcode is executed via the WinAPI function
EnumDeviceMonitor. The first two parameters are zeros, and the third is a pointer to a function where the pointer to the decrypted shellcode is inserted.
The injected shellcode is executable code for 32-bit Windows systems. It loads an unencrypted executable embedded inside the shellcode itself. For dynamically obtaining system API addresses, as in the 2024 version, export table parsing and FNV-1a hashing are used.
Loader (ChatGPT)
| MD5 | 7e6bf818519be0a20dbc9bcb9e5728c6 |
| File name | chatgpt.exe |
In 2025, we also found PipeMagic loader samples mimicking a ChatGPT client. This application resembles one used in campaigns against organizations in Saudi Arabia in 2024. It also uses the Tokio and Tauri frameworks, and judging by copyright strings and PE header metadata, the executable was built in 2024, though it was first discovered in the 2025 campaign. Additionally, this sample uses the same version of the libaes library as the previous year’s attacks. Behaviorally and structurally, the sample is also similar to the application seen in October 2024.
Decrypting the payload using AES
Loader using DLL hijacking
| MD5 | e3c8480749404a45a61c39d9c3152251 |
| File name | googleupdate.dll |
In addition to the initial execution method using a .mshi file launched through msbuild, the attackers also used a more popular method involving decrypting the payload and injecting it with the help of an executable file that does not require additional utilities to run. The executable file itself was legitimate (in this campaign we saw a variant using the Google Chrome update file), and the malicious logic was implemented through a library that it loads, using the DLL hijacking method. For this, a malicious DLL was placed on the disk alongside the legitimate application, containing a function that the application exports.
It is worth noting that in this particular library sample, the exported functions were not malicious – the malicious code was contained in the initialization function (DllMain), which is always called when the DLL is loaded because it initializes internal structures, file descriptors, and so on.
First, the loader reads data from an encrypted file – the attackers pass its path via command-line arguments.
Reading the payload file
Next, the file contents are decrypted using the symmetric AES cipher in CBC mode, with the key
9C 3B A5 B2 D3 22 2F E5 86 3C 14 D5 13 40 D7 F9, and the initialization vector
(IV) 22 1B A5 09 15 04 20 98 AF 5F 8E E4 0E 55 59 C8.
The library deploys the decrypted code into memory and transfers control to it, and the original file is subsequently deleted. In the variants found during analysis, the payload was a shellcode similar to that discovered in the 2024 attacks involving a ChatGPT client.
Deployed PE
| MD5 | 1a119c23e8a71bf70c1e8edf948d5181 |
| File name | – |
In all the loading methods described above, the payload was an executable file for 32-bit Windows systems. Interestingly, in all cases, this file supported graphical mode, although it did not have a graphical user interface. This executable file is the PipeMagic backdoor.
At the start of its execution, the sample generates 16 random bytes to create the name of the pipe it will use. This name is generated using the same method as in the original PipeMagic samples observed in 2022 and 2024.
Creating a pipe with a pre-generated name
The sample itself doesn’t differ from those we saw previously, although it now includes a string with a predefined pipe path:
.pipemagic3301. However, the backdoor itself doesn’t explicitly use this name (that is, it doesn’t interact with a pipe by that name).
Additionally, similar to samples found in 2022 and 2024, this version creates a communication pipe at the address
127.0.0.1:8082.
Discovered modules
During our investigation of the 2025 attacks, we discovered additional plugins used in this malicious campaign. In total, we obtained three modules, each implementing different functionality not present in the main backdoor. All the modules are executable files for 32-bit Windows systems.
Asynchronous communication module
This module implements an asynchronous I/O model. For this, it uses an I/O queue mechanism and I/O completion ports.
Processing core commands
Immediately upon entering the plugin, command processing takes place. At this stage, five commands are supported:
| Command ID | Description |
| 0x1 | Initialize and create a thread that continuously receives changes from the I/O queue |
| 0x2 | Terminate the plugin |
| 0x3 | Process file I/O |
| 0x4 | Terminate a file operation by the file identifier |
| 0x5 | Terminate all file operations |
Although I/O changes via completion ports are processed in a separate thread, the main thread waits for current file operation to complete – so this model is not truly asynchronous.
Getting the I/O queue status
If the command with ID 0x3 (file I/O processing) is selected, control is transferred to an internal handler. This command has a set of subcommands described below. Together with the subcommand, this command has a length of at least 4 bytes.
| Command ID | Description |
| 0x1 | Open a file in a specified mode (read, write, append, etc.) |
| 0x3 | Write to a file |
| 0x4, 0x6 | Read from a file |
| 0x5 | Change the flag status |
| 0x7 | Write data received from another plugin to a file |
| 0x9 | Close a file |
| 0xB | Dump all open files |
The command with ID 0x5 is presumably implemented to set a read error flag. If this flag is set, reading operations become impossible. At the same time, the module does not support commands to clear the flag, so effectively this command just blocks reading from the file.
Setting the read error flag
To manage open files, the file descriptors used are stored in a doubly linked list in global memory.
Loader
This module, found in one of the infections, is responsible for injecting additional payloads into memory and executing them.
At startup, it first creates a pipe named
.pipetest_pipe20.%d, where the format string includes a unique identifier of the process into which the code is injected. Then data from this pipe is read and sent to the command handler in an infinite loop.
The unique command ID is contained in the first four bytes of the data and can have the following possible values:
| Command ID | Description |
| 0x1 | Read data from the pipe or send data to the pipe |
| 0x4 | Initiate the payload |
The payload is an executable file for 64-bit Windows systems. The command handler parses this file and extracts another executable file from its resource section. This extracted file then undergoes all loading procedures – obtaining the addresses of imported functions, relocation, and so on. In this case, to obtain the system method addresses, simple name comparison is used instead of hashing.
The executable is required to export a function called
DllRegisterService. After loading, its entry point is called (to initialize internal structures), followed by this function. It provides an interface with the following possible commands:
| Command ID | Description |
| 0x1 | Initialize |
| 0x2 | Receive data from the module |
| 0x3 | Callback to get data from the payload |
Injector
This module is also an executable file for 32-bit Windows systems. It is responsible for launching the payload – an executable originally written in C# (.NET).
First, it creates a pipe named
.pipe0104201.%d, where the format string includes a unique identifier of the process in which the module runs.
The sample reads data from the pipe, searching for a .NET application inside it. Interestingly, unlike other modules, reading here occurs once rather than in a separate thread.
Before loading the received application, the module performs another important step. To prevent the payload from being detected by the AMSI interface, the attackers first load a local copy of the
amsi library. Then they enable writing into memory region containing the functions
AmsiScanString and
AmsiScanBuffer and patch them. For example, instead of the original code of the
AmsiScanString function, a stub function is placed in memory that always returns 0 (thus marking the file as safe).
After this, the sample loads the
mscoree.dll library. Since the attackers do not know the target version of this library, during execution they check the version of the .NET runtime installed on the victim’s machine. The plugin supports versions
4.0.30319 and
2.0.50727. If one of these versions is installed on the device, the payload is launched via the
_Assembly interface implemented in mscoree.dll.
Post-exploitation
Once a target machine is compromised, the attackers gain a wide range of opportunities for lateral movement and obtaining account credentials. For example, we found in the telemetry a command executed during one of the infections:
dllhost.exe $system32dllhost.exe -accepteula -r -ma lsass.exe $appdataFoMJoEqdWg
The executable dllhost.exe is a part of Windows and does not support command-line flags. Although telemetry data does not allow us to determine exactly how the substitution was carried out, in this case the set of flags is characteristic of the procdump.exe file (ProcDump utility, part of the Sysinternals suite). The attackers use this utility to dump the LSASS process memory into the file specified as the last argument (in this case, $appdataFoMJoEqdWg).
Later, having the LSASS process memory dump, attackers can extract credentials from the compromised device and, consequently, attempt various lateral movement vectors within the network.
It is worth noting that a Microsoft article about attacks using CVE-2025-29824 mentions exactly the same method of obtaining LSASS memory using the procdump.exe file.
Takeaways
The repeated detection of PipeMagic in attacks on organizations in Saudi Arabia and its appearance in Brazil indicate that the malware remains active and that the attackers continue to develop its functionality. The versions detected in 2025 show improvements over the 2024 version, aimed at persisting in victim systems and moving laterally within internal networks.
In the 2025 attacks, the attackers used the ProcDump tool renamed to dllhost.exe to extract memory from the LSASS process – similar to the method described by Microsoft in the context of exploiting vulnerability CVE-2025-29824. The specifics of this vulnerability were analyzed in detail by BI.ZONE in the second part of our joint research (in Russian).
IoCs
Domains
aaaaabbbbbbb.eastus.cloudapp.azure[.]com
Hashes
5df8ee118c7253c3e27b1e427b56212c metafile.mshi
60988c99fb58d346c9a6492b9f3a67f7 chatgpt.exe
7e6bf818519be0a20dbc9bcb9e5728c6 chatgpt.exe
e3c8480749404a45a61c39d9c3152251 googleupdate.dll
1a119c23e8a71bf70c1e8edf948d5181
bddaf7fae2a7dac37f5120257c7c11ba
Pipe names
.pipe104201.%d
\.pipe1.<16-byte hexadecimal string>