28.10.2025
15 min
563
Cybercriminals are increasingly bypassing security systems by using DLL search order substitution, a technique that allows malicious code to run under the guise of legitimate programs. This article explains how this method works, why it is particularly dangerous for the telecom and industrial sectors, and how modern variants of the PlugX, RainyDay, and Turian backdoors differ. You will see a detailed analysis of the attack chain, methods for bypassing security controls and stealth loading of payloads, as well as typical signs of compromise that can help detect an intrusion at an early stage.
An ongoing campaign targeting the telecommunications and manufacturing sectors in Central and South Asia has been identified. Based on the analysis of the evidence collected, there is a medium level of confidence that the campaign can be attributed to Naikon, an active Chinese-speaking cybercriminal who has been active since 2010. This assessment is based on the PlugX configuration format used during the campaign, as well as the malware infection chain, which is very similar to previous RainyDay samples.
The investigation revealed two important facts. First, several instances of the Turian backdoor and the newly identified PlugX variants abused the same legitimate mobile pop-up application as RainyDay to load themselves into memory. Second, the three malware families were observed using bootloaders with similar XOR decryption functionality and using the same RC4 key to decrypt the encrypted payload. While no RainyDay or Turian-related activity was observed in this campaign, the observations above allow for reasonable inferences about attribution.
Naikon is a well-known Chinese-speaking cyber espionage group that has been active since at least 2010. This threat group primarily targets government, military, and civilian organizations across Southeast Asia.
Naikon uses a variety of backdoors, including Aira-body, Nebulae, and RainyDay, as well as numerous specialized hacking tools to support data retention and extraction from victims’ network environments. Specifically, Symantec reported that the group used the RainyDay backdoor to attack telecommunications operators in several Asian countries as part of a long-running espionage campaign that they traced back to 2020.
BackdoorDiplomacy is a group of hackers that has been active since at least 2017. Its primary targets are foreign ministries and telecommunications companies across Africa, Europe, the Middle East, and Asia.
Their primary tool is Turian, which is believed to be an updated version of Quarian. ESET has observed similarities in the network encryption methods of Turian and a backdoor known as Backdoor.Whitebird.1. Bitdefender has suggested that Quarian, Turian, and Whitebird may be different versions of the same backdoor. Bitdefender has also published a blog post about attacks on telecommunications companies in the Middle East that began in February 2022.
Comparison of Naikon and BackdoorDiplomacy using the diamond model depicted in Figure 1.
Analysis of the DLL search order abuse mechanism used in this campaign revealed that RainyDay, Turian, and the PlugX variant used the same legitimate software to launch their malicious downloaders. Despite the fact that these families are associated with different groups (Naikon and BackdoorDiplomacy), there are signs of a possible relationship between them.
First, there is a striking similarity in target selection: both groups consistently attack the telecommunications sector in Central and South Asian countries. In one incident, Naikon targeted a telecom operator in Kazakhstan, a country bordering Uzbekistan, which had previously been targeted by BackdoorDiplomacy. Historical data also confirms the activity of both groups in South Asian countries.
In addition, the downloaders and shellcode structure used by these actors show significant similarities. The use of identical RC4 keys and the XOR → RC4 → RtlDecompressBuffer scheme for decrypting the payload in RainyDay (Naikon), PlugX (Naikon), and Turian (BackdoorDiplomacy) is observed. These technical similarities are discussed in more detail in the next section. A timeline of intrusion activity associated with these three malware families was created (Figure 2) by analyzing data from:
Campaigns we observed
Third-party reports
Malware compilation timestamps
Timestamps present in keystroke logs generated during infections
While we cannot conclude that there is a clear connection between Naikon and BackdoorDiplomacy, there are significant overlaps, such as target selection, payload encryption/decryption methods, reuse of encryption keys, and use of tools supported by the same vendor. These similarities suggest a medium-certainty connection to a Chinese-speaking actor in this campaign.
RainyDay, Turian, and the new PlugX variant discovered in this campaign execute through DLL search order hijacking.
While there are differences between these three malware types, the behavior of the loaders themselves is similar. The loaders for RainyDay, PlugX, and Turian, which are loaded by exploiting legitimate executables, read encrypted shellcode files located in the same directory as the executables and decrypt the data to launch the corresponding malware. The decrypted RainyDay and PlugX payloads are unpacked into memory and inject code into the calling process to execute the malware. Turian injects code into a new legitimate process (wabmig.exe or explorer.exe) to execute the malware. Once executed, it loads configuration data that specifies the destination of the command and control (C2) and an INI file containing an “AntiVir” section.
These three loaders are designed to read, decrypt, and execute the encrypted shellcode of their respective malware from the source directory.
Let’s take a look at the decryption routines for the RainyDay, PlugX, and Turian loaders. These three loaders share a significant amount of code. First, they use the GetModuleFileNameA API to obtain the full path to the executable. They then read the data from the source directory using the hard-coded filenames in the malware.
The original RainyDay loader, observed in 2016, did not encrypt data. However, in the following malware samples, each loader contains a decryption routine. As shown in Figures 6–8, the RainyDay loader decrypts data from “rdmin.src,” the PlugX loader decrypts data from “Mcsitesdvisor.afx,” and the Turian loader decrypts data from “winslivation.dat,” all of which use XOR encryption. The decrypted shellcode is then unpacked into memory and executed using CALL or JMP instructions.
The shellcode format that each of the three malware loaders decrypts is the same. It contains data encrypted and compressed using RC4 and LZNT1, respectively. This data is then decompressed and decrypted, ultimately providing code to execute in memory.
After a jump using a CALL or JMP instruction, code similar to the one shown in the figure below is executed again. In some cases, control flow flattening (CFF) may be implemented.
As shown in the image, the Windows API uses an additive hash function based on ROL25 to solve the API. The code is then decrypted using RC4, as shown in the illustration below.
After decryption, the code is compressed using LZNT1 and the RtlDecompressBuffer API is called to decompress and deploy RainyDay, PlugX, or Turian.
The DLL file unpacked by LZNT1, as shown in Figure 12 below, has the file header bytes removed. In this example, the value of e_lfanew (which points to the location of the PE header) is set to an abnormally large value of 0x01240120, clearly indicating that an invalid value has been inserted.
Figure 13 below shows the RC4 keys used by each of the three different malware families and their corresponding samples. RainyDay uses “8f-2;g=3/c?1wf+c92rv.a” as its RC4 key. This same key is also used by PlugX and Turian. In early versions of RainyDay, this string was used to encrypt the communication, not the malware itself. Another RC4 key listed in RainyDay, “jfntv`1-m0vt801tyvqaf_)U89chasv”, is also used by PlugX. We can conclude that the same RC4 keys are shared by RainyDay, PlugX, and Turian. We can also conclude that attackers are working with multiple malware families simultaneously, and that the use of shared RC4 keys by multiple malware families indicates that these actions are being carried out by the same or related groups of attackers.
Several PDB paths were found in the loader samples that explain the role of the loader DLLs.
Turian loader:
C:\vc_code\No.3\3-2hao\3-2hao-211221\dlltoshellcode_and_shellcodeloader_211221\Resources\pc2msupp.pdb
C:\vc_code\code_test\26.icmpsh-master(tigong wangzhiban)\shellcodeloader_vs2008\Release\shellcodeloader_vs2008.pdb
Possible PlugX loader:
C:\Users\admin\Desktop\Desktop_bak\success_bai\MicrosoftEdgeUpdate.exe\shellcode_xor\dll-MicrosoftEdgeUpdate\Release\2-dll-MicrosoftEdgeUpdate.pdb
A closer look at the PDB lines reveals a few key points. First, all bootloaders contain shellcode structures that are consistent across both the backdoors that are extracted and injected into memory. Second, the PDB path of the Turian bootloader (also mentioned by Bitdefender), “No.3\3-2hao\3-2hao-211221”, appears to reference project names, versions, and a timestamp, where “211221” likely represents the date of December 21, 2021.
In addition, another PDB path of the Turian bootloader contains “icmpsh-master”, which likely refers to ICMP Shell (icmpsh), a known malware tool or method used for stealth C2 communication. In the PDB line, the phrase “(tigong wangzhiban)” in brackets translates from Chinese as “provide web version” (最好的网站版), suggesting that this version of icmpsh may have been modified for web use, perhaps to interact with a remote server or web C2 infrastructure.
Finally, the RainyDay loader PDB path points to a project that includes a DLL associated with “MicrosoftEdgeUpdate”. This DLL may be malicious and intended to be injected into the legitimate MicrosoftEdgeUpdate.exe process.
This section examines the history and technical details of the RainyDay backdoor. This malware was first discovered in 2021 by Bitdefender, and Kaspersky can trace it as FoundCore based on the behavior they describe in their analysis. Combining data from both research reports, we can outline the key characteristics and behavior of the RainyDay backdoor:
It uses a legitimate DLL download to launch the malware.
The payload contains shellcode that is responsible for extracting the final payload.
The payload is encrypted using XOR-RC4-RtlDecompressBuffer, and its configuration is encrypted using a simple one-byte XOR key.
Most importantly, the configuration contains critical details such as the C2 server address, folder name, service description, mutex, registry key path, and other information.
From the above information, we were able to find several RainyDay backdoor loaders and payloads in various malware repositories. While all samples matched the RainyDay backdoor signatures, it was found that the final backdoors actually belong to two different malware families: the previously reported RainyDay backdoor and a new variant of the notorious Chinese remote access trojan (RAT) PlugX. Figures 15–17 show different malware families that contain the same code responsible for decrypting the configuration.
After detailed analysis, an older variant of the RainyDay backdoor was discovered. The code structure is closely related to newer variants described in publications by other cybersecurity vendors. This older variant uses the same code logic to determine the Windows version and processor architecture of the target machine. It is noteworthy that the debug logs show significant similarities between the variants. As shown in Figure 18, it is clear that the attacker has not only improved the functionality of the RainyDay backdoor, but also improved the debug log output. This improvement likely contributes to more efficient debugging of individual functions by malware developers. However, this older variant closely reflects what has been detailed in previous Bitdefender reports, the main differences being the lack of C2 HTTP communication capabilities and file manipulation features.
Two additional pieces of evidence have been found that support the conclusion that this is an early version of the RainyDay backdoor. First, the loader for this variant was compiled on February 27, 2018 at 12:32:40 UTC, making it the oldest identified sample to date. Second, the configuration file contains a timestamp dated December 28, 2016. Based on this information, it is highly likely that the RainyDay backdoor has been operating since at least 2016.
A path to a PDB string embedded in the malware was also found, which reveals the original name of the backdoor file.
C:\Users\Qs\Desktop\Workspace\1qaz\bin\core.pdb
The file names are the same; therefore, this discovery further confirms the connection between this older variant of the RainyDay backdoor and the 2021 version of FoundCore.
Another recent payload is a customized variant of the PlugX backdoor, which we believe has become the primary backdoor used by the attacker in recent campaigns. While this PlugX variant is not particularly new, and its plugin functionality has been documented in previous reports, it stands out for one key reason: its configuration is significantly different from the previously identified PlugX configuration. Instead, it uses the same configuration structure as the RainyDay backdoor. This anomaly strongly suggests that the attackers likely have access to the original PlugX source code, allowing them to modify it in this way. However, it is still important to remember that the attacker could further modify part of the PlugX backdoor configuration to match their desired configuration structure.
There is a high level of confidence that the PlugX variant observed in this campaign is a customized version of BackDoor.PlugX.38. Like the original variant, it uses the “SetUnhandledExceptionFilter” exception handler to identify the thread ID responsible for triggering the exception in the “threads_container” and then generates the associated strings. However, this variant introduces a modification to use an additional XOR operation to encrypt these strings. When the malware executes the appropriate function, it dynamically decrypts the strings at runtime.
After completing the preparation routines, the Trojan elevates its privileges by obtaining SeDebugPrivilege and SeTcbPrivilege. It then initializes its main routine and determines the folder path specified in its configuration where it will place the infection chain files. The malware creates a DoImpUserProc thread to manage plug-in operations or execute a function called OnlineMainDump. To avoid detection, the attacker hides the SeDebugPrivilege and SeTcbPrivilege strings by encrypting them with a modified Tiny Encryption Algorithm (TEA).
When the PlugX backdoor executes the OnlineMainDump function, it first attempts to elevate its privileges to grant high-level access to its own process. It then obtains three specific plugins: KeylogDump, Nethood, and PortMap. It then uses the same techniques as BackDoor.PlugX.38 to hide its malicious service in the services.exe process. Once this is complete, the OnlineNotifyDump thread is initiated and the configuration is reinitialized. The malware then uses the OlProcManager thread to manage the execution of the three plugins within the current process.
After completing all initialization procedures, the malware begins a repetitive cycle of connections to its C2 server. While the connection methodology remains identical to that of BackDoor.PlugX.38, this variant specifically uses the HTTPS protocol for communication. In addition, the “VTCP 10.12.08” library version was identified as embedded in this PlugX backdoor. The VTCP library has already been confirmed in previous analyses as a component commonly associated with PlugX, further confirming that this variant belongs to the same malware family.
It was also noted that the attacker embedded a keylogger plugin into all analyzed PlugX backdoor payloads. The functionality of the keylogger and the data recording format remain similar to those described in previous reports. However, there are notable differences: the filename has been changed and the path to the dump file has been adjusted to match the current location of the PlugX backdoor. These changes indicate that the attacker sought to better integrate the keylogger with this specific variant.
Additionally, analyzing several keylogger log files discovered on VirusTotal revealed timestamps indicating that these files were actively generated throughout 2022. Notably, one of the log files demonstrated successful persistence in the victim’s environment, recording activity from late 2022 to December 2024 — nearly two years of continuous compromise.
This campaign is a prime example of how mature cyber groups evolve and don’t just repeat techniques, but subtly combine them, hiding their tracks for years. The use of the same legitimate software, similar bootloaders, identical RC4 keys, and identical decryption logic all paint a picture of a well-coordinated ecosystem of tools, rather than a random coincidence. Despite the distinct malware brands and different groups behind them, the connections between RainyDay, PlugX, and Turian suggest shared resources or a technical “consortium” that continues to refine attacks and expand their reach.
