ChinaZ Updates Toolkit by Introducing New, Undetected Malware

Introduction

ChinaZ is a Chinese cybercrime group and the author of several DDoS malware. We have profiled this group in a previous article discussing connections between ChinaZ and other Chinese threat actors.

Recently, we have discovered new tools being utilized by ChinaZ which have low detection rates in comparison to the group’s other, more common malware.

VirusTotal detection rate of one of the discovered samples

Some of the components reported in this article have been present in the wild for at least one year, which implies the active state of this group. We have based this conclusion upon seeing that the first submission was made to VirusTotal one year ago:

VirusTotal analysis of an older, related sample

We believe this may be an attempt by ChinaZ to retool its current toolset, using new malware with low detection rates to accomplish its operations, since the group has received more attention from the infosec community in recent years.

The new malware samples seem to implement a combination of backdoor and DDoS bot capabilities to mainly target Linux servers. However, we do not discount the possibility that Windows variants may exist, since this is a recurrent pattern we have observed from ChinaZ malware in the past.

In addition, we were able to retrieve a CNC binary from one of the samples, which has enabled us to learn more about the network protocol along with some of the malware’s capabilities.

In this post, we will present the technical findings of those tools, including a technical analysis of the files and network protocols.

Technical Analysis

We’ve received several hits of suspicious files from VirusTotal Intelligence that communicated with given subdomains under the domain l11l1.com. All of the identified subdomains were hosting several HttpFileServer panels, web servers specifically designed for publishing and sharing files. ChinaZ is known to have used these types of panels in the past.

HttpFileServer panel of one of the identified servers

Based on VirusTotal passive DNS records, it appears that some Windows malware samples were also hosted on some of these subdomains:

VirusTotal Intelligence graph from one of the discovered samples

After analyzing some of the Windows binaries we observed that based on code reuse analysis, the majority of these files seem to be variants of Gh0st or ServStart, modified Chinese RATs with DDoS capabilities known to be leveraged by ChinaZ in the past.

These samples are also infected by common PE file infectors such as Sality, Parite, and Virut. ChinaZ has a reputation for deploying infected malware compromised with these aforementioned file infectors:

Sality genes from one of the hosted Windows malware samples

As seen in the screenshot above, a Gh0st RAT instance deployed by ChinaZ contains code from Sality. This implies that the subject Gh0st RAT is infected with Sality. We documented this same pattern in our previous article on the subject matter. This finding may imply that these new malware samples may be operating from the same servers as other malware under the ChinaZ umbrella.

Furthermore, when we analyze the newly discovered samples using Genetic Malware Analysis, we observed that they all share the same ratio of genes across several malware families related to ChinaZ threat actors.

Malware Analysis across samples under the ChinaZ umbrella

After analyzing these connections we observed that they all have been statically compiled with specific versions of some C++ libraries.

C++ function similarities between one of the identified samples and a XorDDoS instance

These code similarities are from C++ statically linked library code, which at first glance are often considered non-attributive. However, based on the high number of code connections between hundreds of other malware samples related to ChinaZ, we can interpret them as if the authors of these newly discovered samples will be using the same compiler version or toolchain to generate their implants as the one used by a large number of ChinaZ threat actors.

Among the different identified samples we were able to classify three variants with different functionalities. Each of these variants were found hosted together and often sharing the same CNC server. The following section includes an analysis of each of the new implants we discovered.

1. NewManager

NewManager is a minimalistic backdoor with arbitrary command execution and file upload capabilities. The functionality of the backdoor is fairly simple in logic. NewManager is intended to be executed as root, therefore we can assume the backdoor is used as a stager when a given target is compromised.

The backdoor will daemonize itself and set persistence mechanisms. These persistence mechanisms are primarily based on setting symbolic links to specific directories in which the presence of those symbolic links implies file execution on boot time. These mechanisms are predominant among all discovered samples.

We have observed that across the discovered implants the name of the persistent binary will be set differently. The name used to label NewManager was ‘new manager’, therefore its name:

The malware will then execute a series of functions that will initialize the communication with the CNC to start receiving commands.

The client will collect interface information from /proc/net/dev and cpu information from /proc/stat

Functions executed prior to CNC command handling

This collected information serves to inform the operator of the network interface and cpu performance of the compromised machine.

After this information is collected, the client will craft the beaconing packet that will be sent periodically to send interface and cpu statistics to the CNC.

After analyzing the network protocol we observed that packets are crafted in a similar manner, although they will differ depending on the payload based on the command type sent. In order to show the packet’s structure, the following diagram shows the beaconing packet:

After this specific information is configured to be sent in intervals to the CNC, the backdoor will send its own handshake packet.

This packet transfers the kernel version to the backdoor operator. Once this command is sent, the operator will be able to see the compromised machine on its panel:

NewManager CNC panel

NewManager supports three commands. They are the following:

Command	ID	Specification
Execute command	0x11000011	Executes an arbitrary bash command
Create file	0x11000002	Creates a file on an arbitrary path
Read file	0x11000003	Reads a file on an arbitrary path

The command ID after packet parsing is fairly straightforward on the backdoor’s side.

Command selection implementation in NewManager

2. AmpManager

The second piece of malware we were able to analyze is AmpManager.

The reason we named this malware AmpManager is due to its resemblance to NewManager, however, it appears that the spectrum of supported commands is wider, implementing more functionalities along with a range of DDoS attack methodologies.

Although AmpManager and NewManager share most of their code base and CNC communication protocol, there are more commands implemented in AmpManager and some command IDs do not match with the command IDs implemented by NewManager.

For that reason—although we see a high volume of code reuse—we consider AmpManager to be a different malware, although it’s clear that NewManager is AmpManager’s predecessor.

The name AmpManager chooses to persist in a given system is shown below:

The following is an overview of the command implementation code:

Command selection implementation in AmpManager

As we can see, the command implementation code is broader than the one NewManager implements. One of the main differences between AmpManager and NewManager is AmpManager introduces DDoS attacks among other features.

There are three different DDoS attack methodologies implemented: SSDP, DNS, and NTP amplifications.

SSDP flood UDP header

These floods have some configurations set under the /etc/ directory that will impact the number of iterations that each flood will run for.

The following table shows the supported commands implemented in AmpManager:

Command	ID	Specification
NTP amplification	0x11000002	Executes a NTP amplification flood against a target IP address
Send flood configurations	0x11000003	Send the established configurations for each flood to the CNC
SSDP amplification	0x11000006	Executes a SSDP amplification flood against a target IP address
All amplifications	0x11000007	Executes all implemented amplification floods against a target IP address
DNS amplification	0x11000008	Executes a DNS amplification flood against a target IP address
Download HTTP	0x11000009	Downloads a given file to a target path via HTTP GET
Execute command	0x11000011	Executes a target bash command in the target machine
Update current time	0x11000012	Saves the time via gettimeofday
Apply flood configurations	0x11000023	Applies flood configurations for each respective DDoS methodology

3. DDoSManager

In contrast to the two previously reported malware samples, DDoSManager seems to be based on a completely different code base and network protocol.

Although its overall functionality is similar to AmpManager due to the fact that it’s also a DDoS bot, uses the same persistence mechanisms and overall preliminary functionality before CNC communication, it’s important to highlight that DDoSManager uses different DDoS attack methodologies than AmpManager.

In addition, we noticed that this sample contains known Elknot/BillGates artifacts, which are some of the most popular malware families leveraged by ChinaZ.

The following is a small write up from a report by Novetta covering in detail the internals of BillGates malware.

If we take a closer look, we can see that these two C++ classes are also used in DDoSManager:

This reinforces the connection between these malware samples and the developers of Elknot/BillGates, and with respect to the ChinaZ umbrella, in addition to the connections explained previously.

As is the case with the previous samples, DDoSManager commences by setting persistence mechanisms. The techniques applied are the same ones covered in NewManager and AmpManager as previously mentioned. DDoSManager will use the name SingTool to masquerade itself:

Interface and performance information will be collected as with the previous samples. However, an additional thread will be launched.

This thread is in charge of listening for packets to then decode and parse them for CNC communication.

When we intercepted the network traffic we noticed that the traffic was encoded:

After analysis we observed that packets were encoded and decoded with a simple sub/xor algorithm. This algorithm is the following:

After applying this algorithm to each given packet, we can retrieve their plain text version. The following is the structure of each packet after decoding:

Furthermore, the command ID will be extracted from each packet in order to execute the desired task.

Command selection implementation in DDoSManager

DDoSManager supports a total of seven commands. These are the following:

Command	ID	Specification
Read configuration	0x64	Configuration is retrieved to the CNC
Write configuration entry	0x65	Entry is added to the configuration file
HeartBeat	0x66	Beaconing command
Not implemented	0x67	Not implemented
Execute Manager Function	0x68	Invoke internal manager function
Stop command	0x69	Stop an ongoing command
Execute DDoS attack	0x6a, 0x6b, 0x6c	Execute a DDoS flood on a target IP address

The malware sets a configuration file for the targets it will attempt to DDoS. This configuration file is located at /tmp/Cfg.9:

When a DDoS command is executed, a series of fields will be provided from the CNC packet in order to execute the command. These fields are clearly shown on a debug message in the binary:

There are three different DDoS amplification algorithms supported. These are SYN, UDP, and DNS amplifications. Interestingly, in the analyzed samples of DDoSManager we found that the DNS amplification algorithm was not implemented.

Conclusion

We have analyzed three new malware variants in which we have named NewManager, AmpManager, and DDoSManager.

These three variants were found to be hosted together, sharing the same CNC address, and are nearly identical in terms of overall preliminary functionality.

Some of the servers where the malware is hosted are also serving Windows DDoS bots based on modified versions of Chinese RATs such as Gh0st and ServStart. It is well-known that ChinaZ has utilized these malware families in previous campaigns.

In addition, we presented evidence that the Windows implants were infected with common PE file infectors, also resembling a known pattern of ChinaZ Windows malware samples seen in the past.

Furthermore, we highlighted the use of a common compiler/toolchain used to generate the discovered binaries which seems to be shared across a high number of samples belonging to the ChinaZ umbrella. We also found artifact similarities between the BillGates malware and DDoSManager, specifically the name of two core C++ classes used by the malware.

A technical analysis of the overall functionality and network protocol for each of the discovered samples was provided explaining their main features and capabilities.

We believe these findings indicate the need by some ChinaZ threat actors to update their malware toolsets, since they have not conducted a major retooling process in years, and the majority of the older malware utilized by this group is largely detected by Anti-Virus engines.

The code from these samples are now indexed in Intezer Analyze so users can detect and classify NewManager, AmpManager, DDoSManager, and other threats that share code with these malware. We have also generated a YARA rule which can be used by organizations to hunt for additional samples of these threats.

For more information about ChinaZ and code reuse connections between Chinese threat groups, download the Chinese DDoS Threat Landscape report.

IOCs

syn.l11l1[.]com
ccyk.l11l1[.]com
yk.l11l1[.]com
fd.l11l1[.]com
1bfa8af4b51d9fc54d4baa49df27116f44ce269da9123625c1f2ba17289ea2cd
625c57c7090e63472f2bd4d12bf5c821ac821327ee4274a728846fa0bb967b00
F0a2b4c223d6c0c537d9e75b38a2d9b4031485bcfc0c03da96a2b49d7f91591e
B79af4e394cbc8c19fc9b5410fa69b10325fd23f58bec330954caae135239a1f
Dda419d145d4ec7f0eec74ee6cf14ab0b35f22a1af7f39ffbe914c66c445bdf5
3be01b2b27a2cb7b7a852c6305f7a26f35d60fa80ab0050643d97486feaf09dd
33d44642d47488ca0e9fba1935944433e618ec212c5a24969aed406e7b50c611
E3e979d00006fb102279f1033d02bfb8d2ceb6b92c1377195ccb8daa36093c8b
4f5cfb805feb7576e594f1bb3b773ba0ca80e09e49bfb7e3507f815f774ac62d
8ad95b128ab477cc80cba9e4ddccc9d74d423415c17d2837d537c406e6ac81cd