While monitoring Microsoft Exchange Server attacks in March 2021, Unit 42 researchers discovered a PlugX variant that was delivered to one of the infected servers as a remote access tool (RAT) after vulnerability exploitation. Unit 42 observed that this variant was unique in that it included a change to its core source code: replacing “PLUG” with “THOR.” The earliest discovered sample of THOR was in August 2019, which is the earliest known sample after the renaming code. New features are observed in this variant, including enhanced payload transport mechanisms and abuse of trusted binaries.

PlugX was first discovered in 2008, and after follow-up analysis, additional samples and the associated PlugX command and control (C2) infrastructure were found by the researchers.

AutoFocus users of Palo Alto Networks can track their PlugX and PKPLUG activities using PlugX and PKPLUG tags, respectively, They can see a complete visualization of the observed technology and its associated action process in the Unit 42 ATOM viewer.

Communication process

March 19, 2021, Unit 42 observed an attacker exploit an Exchange server from IP 101.36.120[.]227 through a series of zero-day vulnerabilities (CVE-2021-26855 and CVE-2021-27065) called ProxyLogon. After successful exploitation, a Webshell is uploaded to a publicly accessible Web directory, allowing code to be executed at the highest level of permission.

The attacker then used a technique called “Living Off the Land” (LotL), which uses trusted binaries to bypass antivirus detection. In this case, the Microsoft Windows binary bitsadmin.exe used to download from an attacker controlled GitHub target named aro.dat (SHA256: 59 ba902871e98934c054649ca582e2a01707998acc78b2570fef43dbd10f7b6f) harmless file.

Bitsadmin command sample

Aro.Dat

The first thousand bytes of aro.dat indicate that the file may have been encrypted or may have been compressed, but it turns out that this data is nothing more than random padding data, probably added as file headers to evade anti-virus signature blocking detection. The end of the fill data is null, which provides an identifier for the actual data entry point. Immediately following the NULL byte (0x00) is a set of x86 assembler instructions for decompressing files. In this sample, the x86 assembly starts at the file offset 0x4EC with the opcode 0x77, which is converted to JA’s assembly mnemonic (jump if the above is unsigned).

The aro.dat file header is shown below, ending with a NULL byte. For brevity, the data is truncated because bytes are meaningless until NULL. Red represents NULL bytes and green is where code execution begins.

Aro.dat File header

Aro.dat is designed to keep malicious programs undetected and unable to run without the help of a specific loader. As with the PlugX variant before it, code execution is implemented through a technique called DLL side loading. Static analysis shows that once loaded into memory, aro.dat begins to decompress itself and initiate communication with the C2 server.

Aro.dat is actually an encrypted and compressed PlugX payload, and the decryption routine in Aro.dat is very similar to the older PlugX variant in that it involves multiple decryption keys and bit-shift operations. Once decrypted, it is decompressed into a Windows module (DLL) via the Windows API RtlDecompressBuffer. The compression algorithm is LZ compression (COMPRESSION_FORMAT_LZNT1).

 

Comparison of PlugX decryption routines

Above highlighted entries is Aro. The dat and the old version 2012 PlugX samples (SHA256: A68CA9D35D26505A83C92202B0220F7BB8F615BC1E8D4E2266AADDB0DFE7BD15) using static decryption key. Each PlugX builds a slightly different decryption routine by using different static keys and different use of addition and subtraction.

The aro.dat that you decrypt and extract is an x86 Windows DLL or PE file.

Aro.dat: Code execution

The aro.dat file contains the following string names: aros.dll, aro.exe, and aro.dat. The association of these three files provides insight into how code execution is implemented. VirusTotal has the following files:

Aro.exe (SHA256: 18A98C2D905A1DA1D9D855E86866921E543F4BF8621FAEA05EB14D8E5B23B60C)

Aross.dll (SHA256: 9FFFB3894B008D5A54343CCF8395A47ACFE953394FFFE2C58550E444FF20EC47)

According to open source research, aro.exe is part of the “Aro 2012 Advanced Repair and Optimization Tool.” It is a freely available tool that claims to fix Windows registry errors. It is digitally signed, has a known association with the PlugX loader, and loads aross.dll dynamically. Aros.dll is the DLL file used by the attacker to load the encrypted payload file aro.dat. With this information, we can infer that these two files are necessary to load the encrypted THOR payload aro.dat.

Aro.dat DLL side loading

Aro.Dat: RunTime operation

Once the decrypted payload is running in memory, it exhibits the same behavior as the previous PlugX implant variant. It first decrypts the embedded PlugX hard-coded configuration Settings. Decryption algorithms and XOR keys are fairly consistent across PlugX implants. The code behavior is very similar to the behavior of RedDelta PlugX reported by the Insikt Group. One significant difference in this sample compared to all other known PlugX malware families is the magic value checking performed during PlugX plug-in initialization. Historically, this number has been 0x504C5547, which corresponds to the PLUG value in the ASCII encoding. In this sample, the magic value is 0x54484F52, corresponding to the THOR value in the ASCII encoding.

DLL PlugX magic value comparison

The hard-coded PlugX configuration Settings in the sample are decoded to the following values:

 

Hard coded configuration Settings for decryption

As shown in the figure above, the specific PlugX implant configuration is as follows:

Four C2 fields for rainydaysweb[.]com;

Communicates with ports 80, 443, 53, and 8000. Data is transmitted over TCP and UDP. Outputs the data transferred to the debugger (outputdebugstringW) to the debugger (if attached).

 

Debug output

With the HTTP protocol, the initial handshake with C2 is not HTTP, but consists of random bytes of variable length. The implant needs to return 16 bytes of data, and based on the returned value (command), HTTP communication will start. The PlugX SxWorkProc thread is responsible for handling HTTP traffic, and an example of an HTTP header is shown below:

 

HTTP POST sample

The above image is revealed as follows:

POST data consists of random bytes;

User-agent is a hard-coded value: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 10.0; . NET4.0 C; . NET4.0 E; Tablet PC 2.0);

Utmcn, UTMCS, UTMSr, and UTMSC are hard-coded user agent values;

61456 is a known PlugX constant;

The HTTP header is similar to the RedDelta PlugX variant in Recorded Future Page 11;

Create Windows services with name and description: HP Digital Image;

 

The PlugX sample is run as HP Digital Image

Possible 1234 attack ID;

When run, system events such as process creation, date and time, and user names are recorded in a hidden file named ntuser.dat, located in the C: ProgramData MSDN 6.0 directory, which is encrypted using the double-byte key 0x4F6F.

PlugX also has two other recognizable properties:

1. The hidden Windows class name is Static, as shown in Figure 10, and this window is used for intra-process communication.

 

PlugX Windows class name

2. The MZ and PE headers of the RWX memory module are removed and replaced with ASCII ROHT (THOR backwards), as shown below.

 

Memory module artifact

This sample has the following PlugX plug-ins, which have separate hard-coded date stamps, as shown in the following table. In the past, a lot has been said about these PlugX’s. Together, they provide attackers with a variety of ways to monitor, update, and interact with infected systems to achieve their goals.

 

PlugX plug-in

The sample also appears to contain a key or hard-coded date 20180209, which is used in the structure and propagated when the function object is called.

Relationship with PKPLUG

PlugX modules, such as Aro.dat, contain hard-coded configuration information that allows for multiple C2 addresses. This provides an alternate option for backdoors in case some remote services are unavailable in the event of a leak. In this particular PlugX implant (SHA256: 59 ba902871e98934c054649ca582e2a01707998acc78b2570fef43dbd10f7b6f), as shown in the above, all four C2 configuration option refers to the domain name rainydaysweb [.] com.

The following figure highlights the overlap between recently discovered PlugX samples with THOR magic bytes (infrastructure) and other objects related to known PKPLUG activity, represented by orange and red rectangles, respectively.

As mentioned earlier, aro.dat (SHA256: 59 ba902871e98934c054649ca582e2a01707998acc78b2570fef43dbd10f7b6f) using bitsadmin from actor control the making of the repository to download to the target Microsoft Exchange Server. Therefore, the specific component responsible for loading and decrypting the module is unknown. Its connection to RainydaysWeb [.]com is shown in the blue oval below.

The Maltego diagram highlights the overlap between THOR and the existing PKPLUG infrastructure

The researchers found some overlap between relevant infrastructure and common malicious behavior, as described in the figure below.

PlugX samples (SHA256: 93 d33626886e97abf4087f5445b2a02738ea21d8624b3f015625cd646e9d986e) [1], first appeared in 2021 on March 19, Use the traditional PLUG(instead of THOR) identifier and communicate with the same C2rainydaysweb[.]com. This sample also shares some behavior characteristics with other PlugX, namely registry activities specific to creating the key HKLM\Software\CLASSES\ MS-pu \PROXY. Some of these samples use the C2 infrastructure linked to PKPLUG activities in the past, such as the PlugX sample in late 2020 using C2 Manager2013 [.]com (SHA256: A15FED60E69EC07BFD01A23BEEC2C8E9B14AD457EA052BA29BD7A7B806AB63B4).

Additional examples in the collection using common registry keys reveal additional samples containing C2 communication information related to the third level domain upload.ukbbcnews[.]com by using the shared infrastructure. This domain name is not and never has been a legitimate BBC domain name and was registered as such a victim. This domain resolves to IPv4 address 45.248.87[.]217 as PlugX sample (SHA256: 690 c488a9902978f2ef05aa23d21f4fa30a52dd9d11191f9b49667cd08618d87) [5] provide C2 channel, the THOR module MPSVC. UI (SHA256: 64 e2fe0e9d52812d2da956b1d92b51e7c215e579241649316cf996f9721e466e) from 2020 began to run in early August.

As early as May 2019 to March 2021, other “ukbbcnews” three-tier domains (i.e. BBC., news. And WWW.) exist and resolve to the same 45.248.87[.]217 IPv4 address. It appears to have been used as a C2 channel in various PlugX samples in 2018, 2019, and 2020. PlugX samples from June 2018 onwards (SHA256: 3 cdd33dea12f21a4f222eb060e1e8ca8a20d5f6ca0fd849715f125b973f3a257) [6] sharing behavior traits, Set the registry key HKLM\SOFTWARE\Classes\ ket. FAST\CLSID[7] to -1.

Of the three PlugX samples known to Unit 42 that changed registry key values, one sample (SHA256: A9511CDAA96ED59DE73A7A7C7DC375DE204BEE7A9511C5EE71BF013010324A91) [8] in the same period (June 2018) using domain tibetsl [.] com and many third level domain name, used to C2 communications. The third PlugX samples (80 deed939a520696968335d1bb2a9fcce7053c0156f679ba261824d0a2d44967 SHA256:) [9], also use the THOR identifier in the set. From November 2019, the sample and its configuration module arosx.dat (SHA256: C5DCD3073904FAD5D9A8FE1026141A832E05C9CA03A88FEE96587921F42773D4) use 108.61.182 [.] 34 for C2 communications, the same domain name is also used in C2 communication.

Another configuration module using THOR identifiers, Acrobat.chm (SHA256: Was PlugX B5C0DB62184325FFBE2B8EF7E6F13F5D5926DEAC331EF6D542C5FA50144E0280) sample Acrobat. DLL (SHA256: 3 c5e2a4afe58634f45c48f4e800dc56bae3907dde308ff97740e9cd5684d1c53) loaded, the sample appeared for the first time in late October 2020. The C2 channel in the configuration is tools.scbbgroup[.]com, which was resolved to 167.88.180[.]131 at the time and has continued to be resolved to 103.85.24[.]158 under ASN 6134 and 134835 since early February 2021.

Samples include www.ixiaoyver[.]com and www.systeminfor[.]com, which were resolved to 103.85.24[.]190 in April and May 2020 respectively, They act as C2 channels for multiple PlugX samples (using the PLUG identifier).

This resolution was briefly changed to 167.88.180[.]32 (ASN 6134) after a brief two days at www.systeminfor[.]com resolving to 103.85.24[.]190, other PKPLUG related domains resolved during 2020. One of these domains is www.cabsecnow[.]com, which is used as another PlugX C2 communication sample (SHA256: A9CBCE007A7467BA1394EED32B9C1774AD09A9A9FB74EB2CCC584749273FAC01) and configuration module Smadav. Dat (SHA256: E2D21B5E34189FA1ACA39A13A405C792B19B6EDF020907FB9840AF1AAFBAA2F4) in August 2020, use of THOR magic bytes.

The final PlugX sample uses the THOR identifier smadhook32.dll (SHA256: 125 fdf108dc1ad6f572cbdde74b0c7fa938a9adce0cc80cb5ce00f1c030b0c93), its configuration module Smadav. Dat (SHA256: CC1AFB373F8286C08869CD786FEE75B8002DF595586E00255F52892016FD7A4F) is the most recent THOR samples. First appearing in March 2021, the C2 of this sample references news.cqpeizi[.]com, which has resolved to loopback address 127.0.0[.]1 since late 2019.

Knowing how the encrypted payload file was built, the Unit 42 researchers created a signature based on x86 assembly instructions. These instructions are used to decompress the payload.

Following analysis, the researchers found other payloads of PlugX encryption with different encoding schemes and file headers. These samples are XOR encoded using a decryption key consisting of bytes starting at the file offset zero up to NULL bytes. Typically, the key is 10 bytes long. After decryption, the sample is a PE file (DLL) sample.

Currently, the researchers have identified two additional PlugX encrypted payload files with different encoding schemes. These files are manually decrypted and identified as PlugX variants.

 

Unit 42 PlugX Payload decryption

Unit 42 creates a Python script that decrypts and decompresses encrypted PlugX payloads without the associated PlugX loader. It attempts to detect the type of the PlugX encrypted sample and outputs the following:

The PlugX module (DLL) for decryption and decompression, since MZ headers do not exist in the memory module, MZ headers are added to the file, which is only applicable to encryption loads with random byte headers (THOR loads);

Hardcoded PlugX profiles (C2 information) (if supported);

A video of sample tools in use can be found here. The decrypter tool is hosted in Unit 42’s common tools GitHub repository.

conclusion

The PlugX family of malware is 13 years old but still a threat. After making changes to the source code component, the developers changed its signature magic value from “PLUG” to “THOR”. New features are observed in this variant, including enhanced payload propagation mechanisms and abuse of trusted binaries. With the THOR identifier signature, Unit 42 continues to search for additional samples and variants that may be associated with this new PlugX variant.

 

There is a need for relevant information can be concerned about private letter I oh!!