Hi again, this is Shusei Tomonaga from the Analysis Center.
PlugX is a type of malware used for targeted attacks. We have introduced its new features in the blog article “Analysis of a Recent PlugX Variant - ‘P2P PlugX‘”. This article will discuss the following two structural changes observed in PlugX since April 2016:
- the way API is called
- the format of main module changed from PE to raw binary code
In this article, we will refer to PlugX observed after April 2016 as “New PlugX”, and older versions as “Old PlugX”.
Change in API call
When calling Windows API, Old PlugX used the API names as the key to load the corresponding library functions based on their addresses, which is a similar behaviour of calling APIs from the usual PE files. Therefore, Old PlugX code contains strings of the Windows API names.
In contrast, New PlugX does not contain any API name strings in its code, but instead possesses hash values of those API names. When calling an API, it obtains a list of APIs by using Windows functions and performs hash calculation one by one. The API name whose hash value matches the specified value is set as a key to call an API. This method is used when code without IAT (Import Address Table), meaning code other than PE format, call Windows APIs and is applied within shellcodes. This method is also used by some types of malware in order to conceal API names.
Code in Figure 1 shows how New PlugX is calling the Windows API ‘GetSystemInfo’. “86AA8709h” is the hash value for ‘GetSystemInfo’. Address resolution is performed using the hash value, and it jumps to GetSystemInfo’s address by “jmp eax”.
In principle, as long as a collision doesn’t occur, any hash algorithm can be used for hashing Windows API names. However, New PlugX uses the same hash algorithm as Poison Ivy. Figure 2 compares the hash function of New PlugX and Poison Ivy.
Change from PE format to raw code format
While Old PlugX stored the malware in PE format (DLL), New PlugX stores only its code and does not contain a header. A single PlugX sample (‘PlugX Data’ in Fig.3) contained both the encoded version of PlugX and code to decode it (‘Decoding code’ in Figure 3). When the sample is executed, the main module of PlugX (‘PlugX main module’ in Figure 3) is decoded, and it injects itself into another process to be executed in that process. The execution flow in Old PlugX is described in Figure 3.
Figure 4 describes the execution flow in New PlugX. Like Old PlugX, the main module, which is encoded, injects itself to a process and then it is executed in the process. The big difference is that the main module has been changed from PE format (DLL) in Old PlugX to raw code format in New PlugX.
Figure 5 shows the beginning of the decoded main module of PlugX. While Old PlugX had a header that is equivalent to one in a PE format, New PlugX begins with executable code and there is no PE header.
Upon upgrading Old PlugX to New PlugX, the developer presumably referred to Poison Ivy which is also used for targeted attacks. As previously explained, New PlugX uses the same hash value for API call as Poison Ivy, but on top of that, the raw code format that New PlugX applies is also one of the features of Poison Ivy. The purpose of the upgrade is thought to complicate malware analysis so that malware can be used for a longer period of time.
We should keep an eye on PlugX because it has been evolving and still constantly used to conduct targeted attacks. At this stage, both New and Old PlugX are still being actively used.
We would like to recommend that you revisit our article since the demonstrated features there (configuration information, communication method, encode format etc.) remain the same in New PlugX.
Thanks for reading.
- Shusei Tomonaga
(Translated by Yukako Uchida)