Since the beginning of the year, security researchers from Check Point Research (CPR) have been investigating the activities of a Chinese cyber espionage threat actor focused on Southeast Asia, Africa, and South America. The toolkit for this threat actor includes the DinodasRAT [1] cross-platform backdoor, also known as XDealer, which was previously observed in attacks by the Chinese group known as LuoYu.

This article provides technical analysis of the Linux version (v11) of DinodasRAT, aka Linodas. The Linux edition appears to be more sophisticated than the Windows version and has a range of features specially tailored to Linux servers. In addition, the version under investigation introduces a separate bypass module to hide traces of malware in the system. The execution of the system binary files is modified by proxies.

Dinodas Origins

Several clues indicate DinodasRAT was originally based on the SimpleRemote [2] open source project. SimpleRemote is a remote access tool based on the Windows remote access trojan Gh0st RAT [3], but it has some additional improvements. Similarities between SimpleRemote and an older version of DinodasRAT include the use of the same Zlib library (version 1.2.11) and some overlaps in the code (Figure 1).

Figure 1: Similarities in the function for identifying the operating system version between the Dinodas example (left) and the open source code. © Check Point Software

The developers of DinodasRAT rehashed parts of the source code and added some additional open source code from another repository. This code includes functions for handling INI files. DinodasRAT uses encryption used in QQ Messenger.

Independent Code Base

All examples of the cross-platform DinodasRAT embed a string containing the internal version of the backdoor. Some strings reflecting the development of the backdoor appear in Table 1.

The earliest version for Linux was first spotted in the wild by security researchers in July 2021. Linodas has the same logic as the Windows version, but it adds a number of its own behaviors and specifically targets Linux servers. The latest Linodas version (v11) can also be observed in a Windows version, which communicates with the same C2 server update.microsoft-setting[.]com (see Table 2).

Two samples with different internal versions suggest that there were two different development teams or at least two backdoors in different stages of development communicating with the same C2 server. The Linux and Windows versions have overlapping command IDs that seamlessly support the same malware functionality for different operating systems. The cybercriminals have implanted their work on Linux servers to bolster their position on the network. Security researchers found malware files named ntfsys that pretend to be system or driver files in the context of the NTFS filesystem.

As soon as the backdoor is executed, it checks whether it has been launched for the first time by requesting two arguments: the letter d and the process ID of the calling daemon. If it cannot find the arguments, it calls the daemon function and establishes its persistence on the system. The backdoor then restarts itself. It retrieves the process ID and its exec self path and calls the system function to run the [SELF_PATH] d [SELF_PID] command.

Persistence Methods

The persistence process is relatively extensive and includes several Ubuntu versions and Red Hat distributions. The first step is to determine the current operating system version by reading the /proc/version and etc/lsb-release files and analyzing the output. Then, based on the data collected, persistence can be achieved using one of the following methods.

Method 1 (Ubuntu) – rc.local activated via systemd: The malware first checks whether the /lib/systemd/system/rc.local.service file exists and writes the code from Listing 1 to the file.

[Unit]
Description=/etc/rc.local Compatibility
ConditionFilelsExecutable=/etc/rc.local
After=network.target
[Service]
Type=forking
ExecStart/=etc/rc.local start
TimeoutSec=0
RemainAfterExit=yes

It then creates the following symlink.

/lib/systemd/system/rc.local.service --> /etc/systemd/system/

In the next step, the malware determines whether the /etc/rc.local file exists and, if it does, adds the following character string:

#!/bin/bash
[SELF_FILE_PATH] exit 0

Linodas then runs the chmod 777 command to make the /etc/rc.local file executable and evaluates whether the persistence has been correctly written to the file. Finally, the malware changes the INI fields in the /lib/systemd/system/rc.local.service file (Listing 2).

[Service]
RemainAfterExit=no
[Install]
WantedBy=multi-user.target Alias=rc-local.service

Method 2 (Red Hat) – init.d script: The backdoor calls up the command, the output from which is analyzed by Chkconfig, and attempts to execute it. If the command is found and executed correctly, it adds it to the PATH environment variable and continues with the actual persistence. The malware checks whether the file /etc/init.d/[SELF_FILE_NAME] exists and then writes the code from Listing 3 to it.

#!/bin/sh
### BEGIN INIT INFO
# Provides:          [SELF_FILE_NAME]
# Required Start:    $local_fs $network
# Required Stop:     $local_fs
# Default Start:     2 3 4 5
# Default Stop:      0 1 6
# Short Description: [SELF_FILE_NAME] service
# Description:       [SELF_FILE_NAME] service daemon
### END INIT INFO
[SELF_FULL_ATH] restart

If the file has not been created, it writes the same data to the /etc/ch.sh file and executes the following command:

mv /etc/ch.sh /etc/init.d/[SELF_FILE_NAME]

The malware then executes the chmod 777 command for the created file and checks the persistence using the next call:

chkconfig --list | grep [SELF_FILE_NAME]

If the result does not contain 6:, the following two commands are used:

chkconfig --add [SELF_FLE_NAME] chkconfig zentao [SELF_FLE_NAME]

Method 3 (Red Hat) – rc.local: Persistence takes place via the file /etc/rc.d/rc.local. If the file exists, the backdoor checks whether its self path exists in the content – if not, it adds itself to the file with the \n[SELF_PATH]\n string.