Linux.BackDoor.Gates.5

A malicious program targeting 32-bit versions of Linux. It combines the features of a backdoor and a DDoS bot. The malware consists of two modules: the main module is the backdoor that can execute received commands and the second module serves the purpose of launching DDoS attacks. Interaction between these modules is carried out via an opened port on the infected computer. The port number is incorporated in the Trojan’s body.

Linux.BackDoor.Gates.5 gathers the following system-related information and sends it to cybercriminals:

1. Number of CPU cores (from /proc/cpuinfo)
2. CPU frequency (from /proc/cpuinfo)
3. CPU usage (from /proc/stat)
4. Gate IP (from /proc/net/route)
5. Gate MAC address (from /proc/net/arp)
6. Information on network interfaces (from /proc/net/dev)
7. Network adapter MAC address
8. Amount of RAM (MemTotal from /proc/meminfo is used)
9. Volume of data sent and received (from /proc/net/dev)
10. OS name and version (the uname command is used)

Once launched, Linux.BackDoor.Gates.5 checks the path to the folder from which it is run.

%curdir%/getty
usr/bin/getty
/bin/netstat
/bin/lsof
/bin/ps
/usr/bin/netstat
/usr/bin/lsof
/usr/bin/ps
/usr/sbin/netstat
/usr/sbin/lsof
/usr/sbin/ps

If the path is different from the paths to netstat, lsof, and ps utilities, the Trojan launches itself as a daemon. Then it starts the initialization procedure during which it extracts a configuration file from its body. The file looks as follows:

struct CONFIG
{
    std::string g_strConnTgt;
    DWORD g_iGatsPort;
    DWORD g_iGatsIsFx;
    DWORD g_iIsService;
    std::string g_strBillTail;
    std::string g_strForceNote;
    std::string g_bDoBackboor;
    std::string g_strCryptStart;
    std::string g_strDStart;
    std::string g_strNStart;
};

Depending on the value of the g_iGatsIsFx parameter specified in the configuration file, the Trojan either connects to the command and control server or binds a socket to the port specified in g_iGatsPort and waits for an incoming connection. Moreover, the backdoor can update itself. The received command contains the link to download the update. The file is saved to /tmp/%d, where %d stands for a random number.

Installation

During installation, the Trojan checks the /tmp/moni.lock file for the PID process and, if this process is found, the program “kills” it. Then the malware verifies that its DDoS module is running. The verification is carried out by binding a socket to the specified port. If the attempt fails, the Trojan considers the module to be running. Then the backdoor reads PID of the DDoS module from the /tmp/bill.lock file and “kills” this process.

Next, the malware creates a file whose name is generated from the name of the launched file and the g_strBillTail value specified in the configuration file. Using offset of 0x81583, 0x5651C bytes are written into the file. This file is the DDoS module. If the g_iIsService flag is set in the configuration file, the Trojan adds the #!/bin/bash\n<path_to_backdoor> string to the /etc/init.d/ file to be launched at system startup. Then Linux.BackDoor.Gates.5 creates the following symlinks:

ln -s /etc/init.d/DbSecuritySpt /etc/rc1.d/S97DbSecuritySpt
ln -s /etc/init.d/DbSecuritySpt /etc/rc2.d/S97DbSecuritySpt
ln -s /etc/init.d/DbSecuritySpt /etc/rc3.d/S97DbSecuritySpt
ln -s /etc/init.d/DbSecuritySpt /etc/rc4.d/S97DbSecuritySpt

If the g_bDoBackdoor option is available in the configuration file, the Trojan attempts to open the /root/.profile file to check whether its own process is granted root privileges.

Then it verifies that the backdoor’s process is running. The /usr/bin/bsd-port/getty.lock file is used as the backdoor’s LOCK file. The malware’s PID is entered in this file once Linux.BackDoor.Gates.5 is launched. If the process is running, the Trojan “kills” it. The backdoor copies itself to /usr/bin/bsd-port/getty and launches the executable file.

At the final stage of the installation, Linux.BackDoor.Gates.5 creates another copy of itself and places it into /usr/bin/ under the name specified in the configuration file (the g_strForceNote parameter) and then replaces the following utilities:

/bin/netstat
/bin/lsof
/bin/ps
/usr/bin/netstat
/usr/bin/lsof
/usr/bin/ps
/usr/sbin/netstat
/usr/sbin/lsof
/usr/sbin/ps

Once installation is complete, the malicious program starts performing its primary duties.

Payload

The Trojan launches itself as a daemon process on the infected computer, decrypts the configuration file, and initiates initialization. Then it reads the relevant LOCK file to determine whether the malware’s components are running (if not, launches them). However, the backdoor uses different names to save the files and to modify the startup scripts. Depending on the start path, the Trojan either waits for commands from the command and control server or establishes a connection to the server by itself. The Trojan launches two threads. By checking /tmp/gates.lock every 6,000 ms, the first thread verifies that the backdoor is running (if not, launches it). By binding a socket to the specified port, the second thread checks whether the DDoS module is operating (if not, launches it).

Once a connection to the command and control server is established, Linux.BackDoor.Gates.5 receives information about the task that needs to be performed. Upon receiving the corresponding command from cybercriminals, the malicious program can update itself, launch or terminate a DDoS attack on a remote host with a specified IP address and port, execute a command listed in the configuration file, or establish a connection to execute commands directed at another remote host at a specified IP address.

The control packet received from the server has a TASK structure and looks as follows:

struct IP_LIST
{
    char szIP[0]; //C string containing the IP address for the DDoS attack
    WORD wPort; //Port
}
struct SUBTASK
{
    DWORD Cmd;
    BYTE Type; //DDoS attack type
    BYTE byte05;
    BYTE byte06;
    BYTE dummy; //0x00
    DWORD dword08;
    BYTE byte0C;
    BYTE byte0D;
    WORD word0E;
    WORD word10;
    WORD word12;
    BYTE byte14;
    BYTE byte15;
    BYTE dummy2[2]; //0x00
    DWORD dword18;
    DWORD dword1C;
    DWORD dwThreadCount; //Number of threads used for the DDoS attack
    DWORD dword24;
    char szDomens[0]; //C string containing the domain list, separated by ','
    DWORD dwIPCount; //Number of IP_LIST structures
    struct IP_LIST[0]; //IP:port pairs for the DDoS attack
};
struct TASK
{
    DWORD Cmd;
    DWORD Size;
    BYTE Data[0x0D];
    DWORD dword15;
    DWORD dword19;
    DWORD dwSubTaskCount; //Number of SUBTASK structures in the command
    struct SUBTASK[0];
};

To maintain an established connection, the following simplified structure is used:

struct TASK_ping
{
    DWORD Cmd; // 0x04
    DWORD Size; // 0x00
}

Depending on the CMD structure’s value of TASK, the Trojan can execute the following commands:

Communication with the command and control server

A connection to the command and control server is established in two steps. At the first step, the Trojan sends a 119-byte package to the server. The package contains the configuration information (configuration file data, system data).

0000000000: 01 00 00 00 6F 00 00 00 │ 00 F4 01 00 00 32 00 00  ☺   o    ф☺  2
0000000010: 00 E8 03 00 00 00 00 00 │ 00 00 00 00 00 00 00 00   и♥
0000000020: 00 01 00 01 02 00 00 00 │ 01 00 00 00 C0 A8 00 C8   ☺ ☺☻   ☺   АЁ И
0000000030: C0 A8 00 C8 C0 A8 00 C8 │ C0 A8 00 C8 C0 A8 00 C8  АЁ ИАЁ ИАЁ ИАЁ И
0000000040: FF FF 01 00 00 00 00 00 │ 6D 6D 3A 00 01 00 00 00  яя☺     mm: ☺
0000000050: B8 0B 00 00 E9 03 00 00 │ 4C 69 6E 75 78 20 33 2E  ё♂  й♥  Linux 3.
0000000060: 31 33 2E 30 2D 32 34 2D │ 67 65 6E 65 72 69 63 00  13.0-24-generic
0000000070: 47 2D 31 2E 39 30 00    │                          G-1.90

The server responds with a 20-byte package that looks as follows:

0000000000: 08 00 00 00 0C 00 00 00 │ 00 00 00 00 00 00 00 00  ◘   ♀
0000000010: E8 FD 00 00             │                          ??

The package consists of three parts. The first part has the size of 4 bytes and contains a command. The second part contains 4 bytes that are read as DWORD. This DWORD is the size value of the next package (the third part of the package). The third part contains the configuration file with the task that needs to be performed.

To maintain the connection, the package exchange is initiated. If there is no command to be executed, 4 bytes of the second part are equal to zero (that is, the package size is set to 0 and the command reception is ignored).