PlugX: A Talisman to Behold
For over a decade, the PlugX malware has been observed internationally with different variants found around the world. This blog covers a PlugX variant that we have named Talisman, a name we based on comparisons with other PlugX variants, and its rather long life since it first emerged in 2008. First, the malware’s technical details will be discussed, after which the infrastructure, attribution, and victimology will be covered.
Talisman is a newly discovered PlugX variant which follows the usual execution process by abusing a signed and benign binary which loads a modified DLL to execute shellcode. The shellcode is used to decrypt the PlugX malware which then serves as a backdoor with plug-in capabilities. Unlike other versions, the malware’s internal configuration’s signature is different, as well as other minor changes within the code.
We want to mention that a change within the PlugX malware alone does not mean a new threat actor has emerged. The PlugX source code has allegedly circulated online already. This also means that not all PlugX samples are necessarily tied to Chinese actors, although it a prevalent tool in their kit. In the case of Talisman, there is more evidence which points towards a Chinese state-backed actor than a simple change in the malware’s codebase, such as the overlaps in the used infrastructure, which is also present in Recorded Future’s research. Based on this, Trellix attributes this campaign with medium confidence to the Chinese state-backed RedFoxtrot group.
The victims were in South Asia in the Telecommunication and Defense sectors, and align with China’s geopolitical interests. One such initiative is the Belt and Road Initiative, via which China aims to establish strong social economical relationships across Europe, Asia, and Africa via trade.
Within the analysis of the PlugX Talisman variant, we will reference the THOR variant of PlugX, which was discovered by Unit42, as well as an earlier version of PlugX documented by DrWeb. These articles describe other versions of PlugX and were of help to us during the analysis of this variant to both understand and compare the different iterations of the malware. Talisman has some differences with other PlugX versions. In the coming sections, we will highlight interesting segments of the malware. Below, a visual overview of the malware’s stages is given.
Stage 1 – The signed and benign executable
The first stage of the malware is a benign executable which is used to evade the prying eyes of security products as valid signatures often help to indicate the trustworthiness of a binary. The signed executables in this campaign have been created by security companies. The sole purpose of the first stage is to load a DLL which has been modified by the attacker. Sideloading a DLL is a commonly seen technique in various PlugX variants, as is also described on the respective MITRE ATT&CK page. Lastly, a third binary file, containing the encrypted Talisman payload, is decrypted by the DLL to complete the full chain of execution.
In the sample we are analyzing, the legitimate executable has the name SNAC.exe, the Talisman DLL Loader is named WGXMAN.DLL, and the encrypted and compressed Talisman payload is named SNAC.LOG.
Most Talisman PlugX samples we analyzed consist of three-file long execution chains abusing the DLL sideloading technique, which is consistent with the tactics, techniques, and procedures of Chinese state-sponsored threat actors that use this type of execution to launch their malware to evade detection by security solutions.
The table below lists the different observed filenames for the legitimate executables, the Talisman DLL loader and the encrypted Talisman in the analyzed samples.
|Legitimate executable||Talisman DLL Loader||Encrypted Talisman|
In addition to the filenames, we detected another type of execution chain consisting of a self-extracting SFX RAR file with the name “sys.exe” that drops the three related RasTls files to disk and executes them.
Stage 2 – The modified DLL
The DLL is loaded by the benign executable, as it normally would. In this case, the DLL has only a single purpose: execute shellcode to decrypt a fake log file. The shellcode is called in the “DllMain” function the moment the DLL is attached to the executable. Once decrypted, a new PE file is uncovered, which is PlugX’ main component, to which the execution is then transferred.
The configuration decryption routine that is used within PlugX’ modified DLL to decrypt Talisman differs from both aforementioned samples. The decryption routine is a piece of shellcode which can be launched as-is, as it resolves all the required functions before using them. The decryption logic differs as the used decryption constants have been altered, which can be seen in the screenshot below.
Contrary to the other samples, the shellcode’s decryption loop contains 5 sleep calls, which slows the decryption down, albeit barely noticeably. The decrypted buffer is then decompressed using “RtlDecompressBuffer”, after which the PE module is accessible in-memory.
|Filename||- (decrypted and decompressed SNAC.LOG)|
This section will deep dive into the used obfuscation techniques, briefly cover the execution flow, and provide insight into the used decryption routines, as well as the internally used structures within the malware.
The used obfuscation techniques attempt to make the analysis harder, but one can quite easily deobfuscate the sample. The used Windows API functions are loaded dynamically, based on the CRC32 hash of the function name. Note that the name’s terminating null byte must be included when hashing the function name.
The image below shows a wrapper function for WSAIoctl, which is resolved based on the given hash, as can be seen in the third function argument. Additionally, the second argument is a handle to the module which contains the given function. It returns a pointer to the requested function, which can then be invoked as a function.
Secondly, some of the internally used strings are encrypted, but not all. The string encryption is based on simple XOR cipher, where the encrypted string is first created on the stack. The characters of the encrypted string are then decrypted and stored at the location of the encrypted character. Once the decryption loop has finished, the decrypted string will be stored on the stack. The image below shows the decryption of a string. Note that both ascii and wide strings are used within the program, which can cause some confusion when decrypting the strings with the wrong encoding.
The qmemcpy function is an assumption that is made by IDA, since the assembly view contains mov instructions for the complete encrypted string. The loop that follows uses addition, bitwise exclusive or, and subtraction operators to decrypt the string, one byte at a time. The string decryption keys are the same for all encrypted strings within the binary. Note that not all strings within the sample are encrypted.
PlugX execution flow
Upon executing, the main function will resolve some functions, as these are used later. Additionally, the malware adjusts the SeDebugPrivilege and SeTcbPrivilege tokens of its own process. These two tokens ensure that the malware can, respectively, debug processes which aren’t owned by the current process’ owner, and the malware can create access tokens as if they are made by any user. Both instances allow the malware to act as the SYSTEM user, allowing free roam around the machine. The malware then creates its main thread, which is named “bootProc”.
The screenshot below shows the pseudo code of the token adjustment, and the creation of the main thread. Note the plaintext “bootProc” string, as well as the token names, are prime examples to show that not all strings within the sample are encrypted.
The first noteworthy action the main thread performs, is the unloading of the modified DLL from memory, minimising the amount of malicious artefacts in-memory. The rest of the malware’s execution is in-line with other PlugX variants’ behaviour, one example being the number of command-line arguments which decide the persistence method, as well as the persistence methods themselves: varying from the creation of a key in the register’s start-up folder, the creation of a scheduled task, or the creation of a service.
Additionally, the malware connects with the command-and-control server, as is stored in the internal configuration structure. The usage of plug-ins is possible, much like other PlugX variants, if the correct signature is present in the plug-in. The following sections will highlight interesting segments of the sample.
A piece of shellcode is used to decrypt Talisman, a pointer to which is stored within a custom structure within the binary. The shellcode resolves all functions it requires and handles the decryption and the decompression of the given data blob. Additionally, the MZ-header and PE-header are verified using the offsets of 0 and 0x4550 respectively, which correspond to fields named e_magic and e_lfanew. The entry point of the newly decrypted PE file is stored in the custom structure as well. The image below shows the checks and structure field assignments in the pseudocode overview.
Our findings regarding the custom structure differ when comparing them to the analysis of DrWeb. Since the sample where DrWeb refers to is unavailable, we could not compare the two samples. In 2014, Takahiro Haruyama and Hiroshi Suzuki presented “I Know You Want Me - Unplugging PlugX” at Black Hat Asia. On slide 10, one can see the shellarg structure matches our findings. The image below shows DrWeb’s version of the structure, as well as the version that is found within Talisman.
Within the custom structure, the signature field often corresponds to PLUG. In other variants, a different value is used, such as the THOR version that Unit42 wrote about. The Talisman variant uses the constant value 0xCF455089 as a signature, which decodes to the Chinese characters “䗏襐” using the UTF16-LE encoding and translates to “crotch” in English. Other versions are named based on their signature but given Talisman’s rude signature word we opted for a different name.
Before decrypting the configuration, the malware will check for the presence of the Talisman signature and ensure that the configuration length matches. In the observed Talisman variants, the configuration size equals 0x1924 bytes, as passed by the “shellarg_talisman” structure, which is located at the start of the binary.
If those checks are met, Talisman will call the decryption routine to decrypt the configuration with the well-known PlugX algorithm, as is shown in the image below.
The encrypted configuration is fetched from “SNAC.LOG”, which is decrypted by the second stage DLL, rather than the Talisman PlugX binary. This is to ensure that the full execution chain (the benign executable, the modified DLL, and the encrypted SNAC.LOG file) are executed. If this is not the case, the malware will crash.
The Talisman PlugX configuration has a size of 0x1924 bytes and contains all the necessary values and information to properly run the executable. The following fields are contained in the Talisman configuration: a list of control panels (i.e., freewula.strangled.net), the target process that will inject (i.e., %SystemRoot%\system32\nslookup.exe), the malware home directory (i.e., %ALLUSERSPROFILE%\SymantecSNAC), the persist name (i.e., SymantecSNAC), the service display name (i.e., SymantecSNAC), the campaign id (i.e., TEST) and the mutex name (i.e., Global\Restart0).
The aforementioned config fields are very similar as the ones reported in the analysis performed by DrWeb. Analyzing some of the different Talisman recovered configurations, we observed the following embedded campaign ids:
We don’t exactly know how the “campaign_id” field is used by the actors, but we presume it may be used to identify the victims, or the malware version in their operations.
Talisman has, much like the original PlugX version, several ways of persisting itself. Depending on the number of command-line arguments, and the internal configuration, the sample may opt to not persist using one of the following methods:
- No persistence
- A scheduled task
- An auto-starting service
Note that the service is only created if administrative permissions are available to the sample. If this is not the case, the auto-run registry key is created instead.
Talisman has, much like other PlugX variants, the ability to use plug-ins. Some of these are embedded by default, as also described by the United States’ CISA: Disk, Nethood, Netstat, Option, PortMap, RegEdit, Service, Shell, SQL, and Telnet. The plug-in names are relatively self-explanatory, as their name indicates the type of activities that can be performed with them. The screenshot below shows the first seven of the embedded plug-ins, as listed above.
Often, the third argument of the plug-in’s function (named “FunctionN” in the screenshot above, where “N” is a number) indicates the date of the plugin’s creation when viewed as a hexadecimal value. This holds true in Talisman’s case as well, albeit with a minor change: the digits of the year are inverted per byte. As an example, the “Service” plug-in’s date equals “0x81020315”. The first two bytes are “81 02”, which equal “20 18” when inverted per byte, marking 2018 as a year. The specific date for this plugin would be 3 March 2018. The table below provides the dates for all embedded plug-ins.
A small change like this can indicate that the actor has access to the source code of the malware, rather than a builder with an executable stub, as these generally do not provide the option for such granular changes.
During our research we analysed three different Talisman PlugX samples, from which we extracted the command-and-control servers. This allowed us to cluster the actors’ infrastructure. We found that one of the samples (SHA-256: 6dc98a3c771f9f20d099e2d64995564dd083be9ac6ed9586a6e57c20ebd4176c) connects to “dhsg123[.]jkub[.]com” as the command-and-control domain. This overlaps with the RedFoxtrot group, on which Recorded Future already reported.
Moreover, in the sample identified by the SHA256 hash fdada5ba799bd9f5270b218cfad543d99fde3eb7898fd9e3ee79603b643b3c48, the command-and-control domain is “final[.]staticd[.]dynamic-dns[.]net”, which resolved to 158[.]247[.]204[.]191. Pivoting on that IP, we identified two PCShare samples communicating to that IP, both of which use the same injection method into the Remote Desktop shared clipboard (RDPclip.exe). PCShare is an open-source backdoor, which has been leveraged by Chinese actors, as documented by BlackBerry. Additionally, the same mutex (being “78de65b0701f3c9238a37”) is used as the ones reported by Recorded Future.
One interesting note on the TTPs employed by the actors is that unused, parked, or decommissioned domains are set to resolve to localhost (127.0.0.1), or public services such as Google (220.127.116.11) or Cloudflare (18.104.22.168, note that the “11” at the end is not a typo).
All the domains we’ve detected are using Dynamic DNS providers. The main reason to use a dynamic DNS provider is to quickly and easily change the IP address where the domain resolves. An additional advantage for the actor is the lack of WHOIS contact data regarding dynamic DNS subdomains, thus providing operational security. The main providers that the actors used to register the domains are Afraid FreeDNS, ChangeIP, and Dynu.
Interestingly, the vast majority of the threat actors’ infrastructure was hosted on virtual private servers of Choopa/Vultr company (AS 20473 - AS-CHOOPA) although we’ve seen some command-and-control servers hosted on Digital Ocean’s infrastructure (AS 14061 - DIGITALOCEAN-ASN).
We are sharing the full list of indicators of compromise regarding the Talisman PlugX command and control servers and the infrastructure of the actor in Appendix A of this blog.
Attribution & Victimology
We have observed the Talisman malware in a campaign which targets the telecommunication and defense sectors in South Asia. Moreover, the targets line up with the Chinese efforts to protect the Belt and Road Initiative, a program that aims to establish strong socioeconomically relationships across Europe, Asia, and Africa.
The South Asian region is of strategic interest for China for various reasons. Firstly, the stability in South Asia is a global concern, making it a logical focus area for all superpowers, including China. Secondly, companies in the telecommunication and defense sectors provide unique insights for attackers and are often targeted. Thirdly, given the military presence of multiple superpowers in the region, and the geographic location in relation to China, this area can be considered a priority for Chinese sponsored groups.
PlugX has been associated with various Chinese actors in recent years. This fact raises the question if the malware’s code base is shared among different Chinese state-backed groups. On the other hand, the alleged leak of the PlugX v1 builder, as reported by Airbus in 2015, indicates that not all occurrences of PlugX are necessarily tied to Chinese actors.
However, based on our analysis of the infrastructure overlaps with Recorded Future’s related research, we assess with medium confidence that the Talisman PlugX variant discussed in this blog is used by RedFoxtrot/Nomad Panda, a Chinese state sponsored actor. The victimology is in-line with the targets of this group as well. We have no evidence that this variant is exclusively used by this threat actor, instead we believe that Talisman could be shared among different Chinese groups to carry out their operations.
In this blog we have analysed the different steps the infamous PlugX RAT follows to start execution and avoid detection. Moreover, we highlighted several interesting characteristics of a new variant that we dubbed Talisman. During the technical analysis, we extracted various network artifacts that allowed us to not only find new samples, but also analyse the infrastructure overlap with a known Chinese state-backed group. This information, together with the analysis of the victims where we observed this PlugX variant, allowed us to attribute this campaign with medium confidence to the RedFoxtrot APT group, which is otherwise known as Nomad Panda.
Appendix A – Indicators of compromise
Talisman PlugX All execution files
Talisman PlugX Loader
Talisman PlugX Encrypted Payloads
Talisman PlugX Encrypted Configuration
Global\DelSelf(00000000) (where the zeros are the process ID in hexadecimal format, prepended with zeros to ensure 8 digits are used)
Appendix B – MITRE ATT&CK Techniques
Within this campaign, we have observed the following MITRE ATT&CK techniques.
|T1071||Application Layer Protocol||HTTP/DNS requests are used in the C&C traffic|
|T1059||Command and Scripting Interpreter||A reverse shell can be made by PlugX|
|T1543||Create or Modify System Process||One persistence option is a system service|
|T1140||Deobfuscate/Decode Files or Information||The API hashing and encrypted stack strings are obfuscation types. The decrypted Talisman payload is decompressed before it is used|
|T1574||Hijack Execution Flow||The sideloading of the described DLL|
|T1056||Input Capture||Keylogging capabilities|
|T1036||Masquerading||The registered task/service pretends to be benign by name|
|T1106||Modify Registry||The runkey which is made when persisting via the registry|
|T1106||Native API||Windows API functions are called directly|
|T1135||Network Share Discovery||Allows PlugX to scan network shares|
|T1095||Non-Application Layer Protocol||PlugX can work directly with TCP/UDP packets|
|T1057||Process Discovery||Iterates over all processes|
|T1012||Query Registry||Queries the registry to check for values|
|T1113||Screen Capture||Can capture the screen of the victim|
|T1049||System Network Connections Discovery||Possible via the embedded “netstat” module|
Sep 28, 2022
Trellix Empowers Next Generation of Cybersecurity Talent at Xpand Live
Sep 28, 2022
Trellix Accelerates Channel Success Through Unified Partner Program and Expanded Security Innovation Alliance
Sep 28, 2022
Trellix Expands XDR Platform to Transform Security Operations
Sep 26, 2022
60% of Cybersecurity Professionals Feel They Are Losing Ground Against Cybercriminals
Sep 21, 2022
Trellix Launches Advanced Research Center, Finds Estimated 350K Open-Source Projects at Risk to Supply Chain Vulnerability
By Britt Norwood · August 30, 2022
Our team understands the critical role organizations like AWS play in efforts to drive premium threat detection no matter a customer’s security architecture. We continuously look for partners with a similar desire to grow and innovate to relieve pain points for SecOps teams.
This blog is the third and final of a multi-part series focused on vulnerability discovery in a widely used access control system and describes our research journey from target acquisition all the way through exploitation, beginning with the vendor and product selection and a deep dive into the hardware hacking techniques.
Get the latest
We’re no strangers to cybersecurity. But we are a new company.
Stay up to date as we evolve.