Mustang Panda’s Hodur: Old tricks, new Korplug variant
ESET researchers have discovered Hodur, a previously undocumented Korplug variant spread by Mustang Panda, that uses phishing lures referencing current events in Europe, including the invasion of Ukraine
ESET researchers discovered a still-ongoing campaign using a previously undocumented Korplug variant, which they named Hodur due to its resemblance to the THOR variant previously documented by Unit 42 in 2020. In Norse mythology, Hodur is Thor’s blind half-brother, who is tricked by Loki into killing their half-brother Baldr.
Key findings in this blogpost:
As of March 2022, this campaign is still ongoing and goes back to at least August 2021.
Known victims include research entities, internet service providers, and European diplomatic missions.
The compromise chain includes decoy documents that are frequently updated and relate to events in Europe.
The campaign uses a custom loader to execute a new Korplug variant.
Every stage of the deployment process utilizes anti-analysis techniques and control-flow obfuscation, which sets it apart from other campaigns.
ESET researchers provide an in-depth analysis of the capabilities and commands of this new variant.
Victims of this campaign are likely lured with phishing documents abusing the latest events in Europe such as Russia’s invasion of Ukraine. This resulted in more than three million residents fleeing the war to neighboring countries, leading to an unprecedented crisis on Ukraine’s borders. One of the filenames related to this campaign is Situation at the EU borders with Ukraine.exe.
Other phishing lures mention updated COVID-19 travel restrictions, an approved regional aid map for Greece, and a Regulation of the European Parliament and of the Council. The last one is a real document available on the European Council’s website. This shows that the APT group behind this campaign is following current affairs and is able to successfully and swiftly react to them.
Figure 1. Countries affected by Mustang Panda in this campaign
Internet service providers (ISP)
Based on code similarities and the many commonalities in Tactics, Techniques, and Procedures (TTPs), ESET researchers attribute this campaign with high confidence to Mustang Panda (also known as TA416, RedDelta, or PKPLUG). It is a cyberespionage group mainly targeting governmental entities and NGOs. Its victims are mostly, but not exclusively, located in East and Southeast Asia with a focus on Mongolia. The group is also known for its campaign targeting the Vatican in 2020.
While we haven’t been able to identify the verticals of all victims, this campaign seems to have the same targeting objectives as other Mustang Panda campaigns. Following the APT’s typical victimology, most victims are located in East and Southeast Asia, along with some in European and African countries. According to ESET telemetry, the vast majority of targets are located in Mongolia and Vietnam, followed by Myanmar, with only a few in the other affected countries.
Mustang Panda’s campaigns frequently use custom loaders for shared malware including Cobalt Strike, Poison Ivy, and Korplug (also known as PlugX). The group has also been known to create its own Korplug variants. Compared to other campaigns using Korplug, every stage of the deployment process utilizes anti-analysis techniques and control-flow obfuscation.
This blogpost contains a detailed analysis of this previously unseen Korplug variant used in this campaign. This activity is part of the same campaign recently covered by Proofpoint, but we provide additional historical and targeting information.
Mustang Panda is known for its elaborate custom loaders and Korplug variants, and the samples used in this campaign showcase this perfectly.
Compromise chains seen in this campaign follow the typical Korplug pattern: a legitimate, validly signed, executable vulnerable to DLL search-order hijacking, a malicious DLL, and an encrypted Korplug file are deployed on the target machine. The executable is abused to load the module, which then decrypts and executes the Korplug RAT. In some cases, a downloader is used first to deploy these files along with a decoy document. This process is illustrated in Figure 2.
Figure 2. Overview of the deployment process for the Hodur Korplug variant.
What sets this campaign apart is the heavy use of control-flow obfuscation and anti-analysis techniques at every stage of the deployment process. The following sections describe the behavior of each stage and take a deeper look at the defense evasion techniques used in each of them.
We haven’t been able to observe the initial deployment vector, but our analysis points to phishing and watering hole attacks as likely vectors. In instances where we saw a downloader, the filenames used suggest a document with an interesting subject for the target. Such examples include:
COVID-19 travel restrictions EU reviews list of third countries.exe
REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL.exe
Situation at the EU borders with Ukraine.exe
To further the illusion, these binaries download and open a document that has the same name but with a .doc or .pdf extension. The contents of these decoys accurately reflect the filename. As shown in Figure 3, at least one of them is a publicly accessible legitimate document from the European Parliament.
Figure 3. First page of the decoy document for the REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL.exe downloader. It’s a real document available on the European Council’s website.
Although its complexity has increased over the course of the campaign, the downloader is fairly straightforward. This increase in complexity comes from additional anti-analysis techniques, which we cover later in this section.
It first downloads four files over HTTPS: a decoy document, a legitimate executable, a malicious module and an encrypted Korplug file. The combination of those last three components to execute a payload via DLL side-loading is sometimes referred to as a trident and is a technique commonly used by Mustang Panda, and with Korplug loaders in general. Both the server addresses and file paths are hardcoded in the downloader executable. Once everything is downloaded, and the decoy document opened to distract the victim, the downloader uses the following command line to launch the legitimate executable:
cmd /c ping 22.214.171.124 -n 70&&”%temp%\<legitimate executable>”
This ping command both checks internet connectivity and introduces a delay (through the -n 70 option) before executing the downloaded, legitimate executable.
The downloader uses multiple anti-analysis techniques, many of which are also used in the loader and final payload. Additional obfuscation has been added to new versions over the course of the campaign without otherwise changing their goal.
In early versions of the downloader, junk code and opaque predicates were used to hinder analysis, as shown in Figure 4, but the server and filenames are plainly visible in cleartext.
Figure 4. Control flow obfuscation in early versions of the downloader
In later versions, the files on the server are RC4 encrypted, using the base 10 string representation of the file size as the key, and then hex-encoded. This process is illustrated in the Python snippet below. The opposite operations are performed client-side by the downloader to recover the plaintext files. This is likely done to bypass network-level protections.
from Crypto.cipher import ARC4 key = “%d” % len(plaintext) rc4 = ARC4.new(key) cipher_content = rc4.encrypt(plaintext).hex().upper()
These versions replace the use of cleartext strings with encrypted stack strings. They are still hardcoded in the file, but the obfuscation surrounding them, and the use of different keys, makes it hard to decrypt them statically in an automated manner. This same technique is used heavily in the subsequent stages. Encrypted stack strings are also used to obfuscate calls to Windows API functions.
First, the name of the target function is decrypted and passed to a function. This function obtains a pointer to the InMemoryOrderModuleList field of the PEB (Process Environment Block). It then iterates over the loaded modules, passing each handle to GetProcAddress along with the function name until the target function is successfully resolved. Part of this process can be seen in Figure 5.
Figure 5. Obfuscation of Windows API calls in the downloader. The screenshot shows a call to WriteFile, but the same pattern is used for all API functions.
As is common with Korplug, the loader is a DLL that exploits a side-loading vulnerability in a legitimate, signed executable. We have observed many different applications being abused in this campaign, for instance a vulnerable SmadAV executable previously seen by Qurium in a campaign attributed to Mustang Panda that targeted Myanmar.
The loader exports multiple functions. The exact list varies depending on the abused application, but in all cases, only one of them does anything of consequence. In all of the loaders we observed, this is the exported function with the highest load address. All the other exports, and the library’s entry point, either return immediately or execute some do-nothing junk code. Many of these exports have names that consist of random lowercase letters and point to the same address as shown in Table 1.
Table 1. Functions exported by a Hodur loader. The createSystemFontsUsingEDL export is the one that loads the final malware stage in this version.
The loader function obtains the directory from which the DLL is running using GetModuleFileNameA and tries to open the encrypted Korplug file it contains. That filename is hardcoded in the loader. It reads the file’s contents into a locally allocated buffer and decrypts it. The loader makes this buffer executable using VirtualProtect before calling into it at offset 0x00.
Windows API function calls are obfuscated with a different technique than that used in the downloader. Unlike the loader, which contains the names of its functions (as shown in Table 1 above), only the 64-bit hashes of the Windows API function calls are present in the binary. To resolve those functions, the loader traverses the export lists of all loaded libraries via the InMemoryOrderModuleList of the PEB. Each export’s name is hashed, then compared to the expected value. The FNV-1a hash algorithm, recently brought back into the mainstream by the Sunburst backdoor, has previously been used by Mustang Panda, in Korplug loaders documented by XORHEX, to resolve GetProcAddress and LoadLibraryA, although it was not identified by name in that analysis. In this version, however, it is used for all API functions.
Korplug (also known as PlugX) is a RAT used by multiple APT groups. In spite of it being so widely used, or perhaps because of it, few reports extensively describe its commands and the data it exfiltrates. Its functionality is not constant between variants, but there does seem to exist a significant overlap in the list of commands between the version we analyzed and other sources such as the Avira report from January 2020 and the plugxdecoder project on GitHub.
As previously mentioned, the variant used in this campaign bears many similarities to the THOR variant, which is why we have named it Hodur. The similarities include the use of the Software\CLASSES\ms-pu registry key, the same format for C&C servers in the configuration, and use of the Static window class.
As expected for Korplug payloads, this stage is only ever decrypted in memory by the loader. Only the encrypted version is written to disk in a file with a .dat extension.
Unless stated otherwise, all hardcoded strings discussed in this section are stored as encrypted stack strings.
In this module, Windows API functions are obfuscated through a combination of the methods used in previous stages. LoadLibraryA and GetProcAddress are resolved via the FNV-1a hashing technique and stack strings are decrypted and passed to them to obtain the target function.
Once decrypted, the payload is a valid DLL that exports a single function. In almost all observed samples from this campaign, this function is named StartProtect. However, launching it directly via this export or its entry point will not execute the main payload and the loading process is quite intricate.
As explained in the previous section, the file is decrypted in memory as a continuous blob by the loader and the execution starts at offset 0x00. The PE header contains shellcode, shown in Figure 6, that calls a specific offset that corresponds to the module’s single export.
Figure 6. Shellcode in the PE header that calls the exported function
This function parses the PE blob in memory and manually maps it as a library into a newly allocated buffer. This includes mapping the various sections, resolving imports and, finally, using DLL_PROCESS_ATTACH to call the DLL entry point. Once again, opaque predicates and junk code are used to obfuscate the purpose of this function.
The entry point of the properly loaded library is then called with the non-standard value of 0x04 for the fdwReason parameter (only values from 0x00 to 0x03 are currently defined). This special value is required to get it to execute its main payload. This simple check prevents the RAT from being trivially executed directly with a generic tool like rundll32.exe.
The backdoor first decrypts its configuration using the string 123456789 as a repeating XOR key. Once decrypted, the configuration block starts with ########. The layout of the configuration varies slightly between samples, but they all contain at least the following fields:
Installation directory name. Also used as the name of the registry key created for persistence. This value roughly corresponds to the name of the abused application with three random letters appended (e.g., FontEDLZeP or AdobePhotosGQp)
A value that is either a version or ID string
List of C&C servers. Each entry includes IP address, port number, and a number indicating the protocol to use with that C&C
The backdoor then checks the path from which it is running using GetModuleFileNameW. If this matches %userprofile%\<installation directory> or %allusersprofile%\<installation directory>, the RAT functionality will be executed. Otherwise, it will go through the installation process.
To install itself, the malware creates the aforementioned directory under %allusersprofile%. Using SetFileAttributesW, it is then marked as hidden and system. The vulnerable executable, loader module, and encrypted Korplug files are copied to the new directory.
Next, persistence is established. Earlier samples achieved this by creating a scheduled task to be run at boot via schtasks.exe. Newer samples add a registry entry to Software\Microsoft\Windows\CurrentVersion\Run, trying the HKLM hive first, then HKCU. This entry has the same name as the installation directory with its value set to the newly copied executable’s path.
Once persistence has been set up, the malware launches the executable from its new location and exits.
The RAT functionality of the Hodur variant used in this campaign mostly lines up with other Korplug variants, with some additional commands and characteristics. As we have previously stated, though, detailed analyses of Korplug commands are few and far between, so we aim to provide such an analysis in the hopes of aiding future analysts.
When in this mode, the backdoor iterates through the list of C&C servers in its configuration until it reaches the end or receives an Uninstall command. For each of those servers, it processes commands until it receives a Stop command or encounters an error.
Hodur’s initial handshake can be done over HTTPS or TCP. This is determined by a value in the configuration for that particular C&C server. Subsequent communication is always done over TCP using a custom protocol that we describe in this section, along with the commands that can be issued. Hodur uses sockets from the Windows Sockets API (Winsock) that support overlapped I/O.
Following the initial handshake, Hodur’s communications involve TCP messages that consist of a header, with the structure described in Table 2, followed by a message body that is usually compressed using LZNT1 and always encrypted with RC4. Messages whose Command number header field have the 0x10000000 bit set (those that contain file contents for the ReadFile and WriteFile commands, described in Table 3) have encrypted but not compressed message bodies. All encrypted message bodies use the hardcoded key sV!e@T#L$PH% with a four-byte random nonce (the value at offset 0x00 in the header) appended to it.
Table 2. Header format used for communication between the C&C and the backdoor
Hodur’s C&C message headers are transmitted in the clear, followed by variably sized (the value at offset 0x08 of the header) message bodies. The format of the message body varies per command, but once decrypted and decompressed, values of variable length (like strings) are always at a message body’s end and their offset in the body is stored as an integer in the corresponding message field.
Like the version described by Avira, Hodur has two groups of commands – 0x1001 and 0x1002 – each with its own handler. The C&C server can set which group to listen for by sending the corresponding ID as the command number when a client is not already in one of the two modes. It will continue to listen for the same group until it receives the Stop command, or an error occurs (including receiving a message with an invalid Command number in its header).
The first group, 0x1001, contains commands for managing the execution of the backdoor and doing initial reconnaissance on a newly compromised host. As these commands take no arguments, messages sent by the C&C server consist only of the headers. Table 3 contains a list of these commands. The GetSystemInfo command is described in more detail below. Note that no command names are present in the RAT; they were either taken from previous analyses or provided by us.
Table 3. Commands in group 0x1001
The GetSystemInfo command collects extensive information about the system, as detailed in Table 4. If it doesn’t already exist, the Software\CLASSES\ms-pu\CLSID registry key is set to the current timestamp, trying HKLM first then HKCU. The value of this key is then sent in the response.
Table 4. Response body format for the GetSystemInfo response
The 0x1002 group contains commands that provide RAT functionality, as detailed in Table 5. Some of these take parameters provided in the command’s message body. The FindFiles command is described in more detail below. Again, note that no command names are present in the RAT; they were either taken from previous analyses or provided by us
Table 5. Commands in group 0x1002
Starting from the provided directory, this command searches for files whose names match the given pattern. This pattern supports the same wildcard characters as the Windows FindFirstFile API. For each matching file, the client sends a response message with its body in the format described in Table 6.
Table 6. Format of the response body for the FindFiles command
Offset Value Offset Value
0x00 File attributes 0x24 Folder path(offset)
0x04 File size in bytes 0x26 Filename(offset)
0x0C Creation time 0x28 8.3filename(offset)
0x1C Last write time
One response message with an empty body is sent once the search is completed.
The decoys used in this campaign show once more how quickly Mustang Panda is able to react to world events. For example, an EU regulation on COVID-19 was used as a decoy only two weeks after it came out, and documents about the war in Ukraine started being used in the days following the beginning of the launch of the invasion. This group also demonstrates an ability to iteratively improve its tools, including its signature use of trident downloaders to deploy Korplug.
For any inquiries about our research published , please contact us at firstname.lastname@example.org. ESET Research now also offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the ESET Threat Intelligence page.