Often attributed to Chinese-speaking threat actors, PlugX a remote access trojan(RAT), was identified by security researchers in 2012. With several variants of the RAT identified by vendors over the year, many techniques used to compromise systems have remained the same.
While perusing public malware sandboxes for interesting new samples, I stumbled upon a Windows executable that at the time, had a VirusTotal score of 9 out of 68 anti-virus vendors.
As this sample was found via a sandbox, the delivery method is unknown, and will not be covered in this post.
This sample was identified by VT user PerMorten as a dropper for the reflective loading of PlugX. Looking a little closer at the supposed dropper file, three additional files within the PE are identified:
WinHelp32.exe is a legitimate software application that will be described further below. For PlugX aficionados, the above trio of documents likely looks familiar. A well-known technique of PlugX is to utilize a dropper or self-extracting RAR PE file to extract files on the victim system for execution.
The Legitimate App
Winhelp32.exe is a legitimate application from the Beijing Rising IT company, a Chinese software company that develops Rising Antivirus among other computer security software.
As the network infrastructure utilized with this malware was only recently registered as of November 2021, the reasoning for using an outdated application is unknown. The threat actor, in this case, may have purposefully utilized a Rising Antivirus executable in the targeting of the intended victim or picked a random executable for their malware.
The rscom.dll file does not contain much to write about other than its main purpose is to load the .dat file, which is the compressed/encoded PlugX payload.
As the payload is what everyone is here for, let’s dive a bit deeper into the data file.
The well-known magic “GULP” is visible in the .dat file through a hex editor. Additionally, within the file, MZ and PE headers are also visible.
The .dat file is likely padded/compressed to evade antivirus engines. Upon execution, the file is decompressed via a call to the Windows API, RtlDecompressBuffer, and run in memory.
Identified in a number of reports on network intrusions involving PlugX, a familiar decryption routine (Figure 6) is also seen in rscom.dll.dat. The decryption routine contains multiple keys and shift operations, identified by the shr and shl calls below.
The unnamed dropper places the three files into “C:\\ProgramData\Log’” in addition to a file named NvSmart.hlp (Figure 7). Upon running WinHelp32, the application deletes itself which is another interesting choice by the threat actor, as this would likely raise suspicions by the victim running the antivirus software.
Watching the execution flow in your favorite Windows process monitoring software, old-school PlugX is in full effect. WinHelp32.exe injects itself into svchost.exe, with the usual second injected process, msiexec.exe not being seen in this case.
In most cases, if services.exe is not the process launching svchost.exe, this would be an easy win for defenders to detect. It is likely the threat actor is relying on the behavior of antivirus software injecting itself into a process that would not raise alarms.
Taking a look at the injected process read, write, executable (RWX) properties, we once again see that the MZ and PE headers have been replaced with GULP, or PLUG backward.
A number of hardcoded values including command and control (C2) information are located within the decoded configuration:
Upon further research, an additional network indicator is located that appears to be a proxy for the C2.
So far we know the following about the network capabilities of this malware sample:
- A C2 domain of xiguamomomo[.]com
- Utilizes HTTP
- Communicates with a proxy server of 43.129.208[.]226
References to localhost, 127.0.0.1 can be seen in Figure 9, but the malware also seems to utilize the address for debug or anti-analysis purposes. This technique could possibly be utilized to slow researchers who may not be running the malware as needed for proper execution (running only the DLL file for example).
In addition to the possible debug strings seen in Figure 11, some 28 .cpp files indicating additional capabilities of the RAT were also found:
The following interesting PDB paths were also found:
According to PassiveDNS information, the domain xiguamomomo[.]com resolves to 111.73.46[.]103, located in China, first seen 2021-10-12.
WHOIS information reveals the domain was registered through GoDaddy, with the registrant country listed as Cambodia, and the registrant identified as “ewrwer.”
In what could certainly be a coincidence, both xigua, and momo are popular apps originating from China. Xigua, an online video-sharing app with users across the world, boasts some 160 million users. Momo, currently only available in Chinese, is a social networking app with a large following.
It should be noted that not only are the delivery method of the RAT unknown, but also the targeting. The above should be taken as low confidence at best, but certainly interesting nonetheless.
An additional IP address of 111.73.46[.]30 (open ports: 3389, 8000, 5985, 5987, and 24681) was also identified through packet captures.
The ports 3389 (RDP), and 5985 are largely seen among many other suspected PlugX C2 infrastructure. This IP address belongs to the Chinanet-Backbone ASN.
The possible proxy address 43.129.208[.]226 (open ports: 22, 3306, and 8443) is located in Hong Kong and belongs to the TENCENT-NET-AP-CN ASN.
Multiple User-Agent values were also found within the decoded configuration data as seen in Figure 13.
**Featured image: Photo by Markus Spiske on Unsplash
As there is quite a bit of information missing with this variant of PlugX, the fresh command and control infrastructure and domain naming indicate that even dated versions of this RAT still get the job done.
Please keep an eye out for updates to this post as I look deeper into the network infrastructure to possibly tie additional domains/malware to the above findings.
- Dropper file: d88731851cc739ee72daf53700b0008db59ebb467e2394f9b3fc2162cd3a062f
- WinHelp32.exe (legitimate application): ec200f75e4884933a56e82531f3f52e64e73a3347ad4a3b9e6318df82cdca92a
- Rscom.dll (loader) : 7af30d3c192f3fb85e1cadbf5c01f049f11eb036ca8107abb3451ffa0cc218b7
- Rscom.dll.dat (PlugX payload): ec46e04df901d7ec76ff1ad9ad6ceb54f8c2ad5e3597173365e094c5602e0049
- xiguamomomo[.]com >> 111.73.46[.]103
- 43.129.208[.]226 (proxy)
- “/update?id=” (Callback URI in config)
- Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
- Mozilla/4.0 (compatible; MSIE 8.0; Win32)
- Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
- Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.16 Safari/537.36
- Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)
- Mozilla/5.0 (Windows NT 6.2; rv:12.0) Gecko/20100101 Firefox/12.0
- Mozilla/5.0 (Windows NT 6.2) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5
- Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch)
- Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
- Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; Xbox)
- Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
- Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
- Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
- Mozilla/5.0 (iPad; CPU OS 5_0 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3